Re: [RFC PATCH 1/4] mm/hugetlb: Simplify hugetlb unmap
> @@ -3157,19 +3156,22 @@ void __unmap_hugepage_range(struct mmu_gather *tlb,
> struct vm_area_struct *vma,
> tlb_start_vma(tlb, vma);
> mmu_notifier_invalidate_range_start(mm, mmun_start, mmun_end);
> address = start;
> -again:
> for (; address < end; address += sz) {
With the again label cut off, you can also make a change in the for line.
thanks
Hillf
> ptep = huge_pte_offset(mm, address);
> if (!ptep)
> continue;
Re: [PATCH v2] sched: fix first task of a task group is attached twice
On 27 May 2016 at 22:38, Dietmar Eggemann wrote: > On 27/05/16 18:16, Vincent Guittot wrote: >> On 27 May 2016 at 17:48, Dietmar Eggemann wrote: >>> On 25/05/16 16:01, Vincent Guittot wrote: The cfs_rq->avg.last_update_time is initialize to 0 with the main effect that the 1st sched_entity that will be attached, will keep its last_update_time set to 0 and will attached once again during the enqueue. Initialize cfs_rq->avg.last_update_time to 1 instead. Signed-off-by: Vincent Guittot --- v2: - rq_clock_task(rq_of(cfs_rq)) can't be used because lock is not held kernel/sched/fair.c | 8 1 file changed, 8 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 218f8e8..3724656 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8586,6 +8586,14 @@ void init_tg_cfs_entry(struct task_group *tg, struct cfs_rq *cfs_rq, se->depth = parent->depth + 1; } + /* + * Set last_update_time to something different from 0 to make + * sure the 1st sched_entity will not be attached twice: once + * when attaching the task to the group and one more time when + * enqueueing the task. + */ + tg->cfs_rq[cpu]->avg.last_update_time = 1; + > > Couldn't you not just set the value in init_cfs_rq(): yes, there is no good reason to use init_tg_cfs_entry instead of init_cfs_rq > > @@ -8482,6 +8482,7 @@ void init_cfs_rq(struct cfs_rq *cfs_rq) > cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime; > #endif > #ifdef CONFIG_SMP > + cfs_rq->avg.last_update_time = 1; > atomic_long_set(&cfs_rq->removed_load_avg, 0); > atomic_long_set(&cfs_rq->removed_util_avg, 0); > #endif > se->my_q = cfs_rq; /* guarantee group entities always have weight */ update_load_set(&se->load, NICE_0_LOAD); >>> >>> So why not setting the last_update_time value for those cfs_rq's when >>> we have the lock? E.g. in task_move_group_fair() or attach_task_cfs_rq(). >> >> I'm not sure that it's worth adding this init in functions that are >> then used often only for the init of it. > > Yeah, there will be this if condition overhead. > >> If you are concerned by the update of the load of the 1st task that >> will be attached, it can still have elapsed a long time between the >> creation of the group and the 1st enqueue of a task. This was the case >> for the test i did when i found this issue. > > Understood, but for me, creation of the task group is > cpu_cgroup_css_alloc -> sched_create_group() -> ... -> init_cfs_rq(), > init_tg_cfs_entry(), ... > > and the functions which are called when the first task is put into the > task group are cpu_cgroup_attach() and cpu_cgroup_fork() and they whould > trigger the initial setup of the cfs_rq->avg.last_update_time. > >> >> Beside this point, I have to send a new version to set >> load_last_update_time_copy for not 64 bits system. Fengguang points me >> the issue > > OK. > > [...] >>> >>> + if (!cfs_rq->avg.last_update_time) >>> + cfs_rq->avg.last_update_time = rq_clock_task(rq_of(cfs_rq)); >>> + >>> /* Synchronize task with its cfs_rq */ >>> attach_entity_load_avg(cfs_rq, se); >>
Re: [PATCH] Revert "i2c: dev: switch from register_chrdev to cdev API"
On Sat, May 28, 2016 at 06:04:58PM +0200, Wolfram Sang wrote: > > > These kinds of use after frees don't always cause a runtime problem. I > > found it using static analysis, but I bet you could detect it if you > > enabled kasan. The other option is to enable PAGE_POISONING? > > Thanks, PAGE_POISONING did trigger the issue. So, I now picked up your > patch instead of the revert because I could verify the problem and the > proper solution. Thanks again. > > What I still wonder: Which analysis reported the problem to you? I > always run sparse, smatch, cppcheck, and coccicheck on the patches when > applying and no-one reported the issue. It's a Smatch warning but you have to build the cross function db to detect this. It takes a while (a few hours) but the command is simple enough. ./smatch_scripts/build_kernel_data.sh regards, dan carpenter
Re: [PATCH 3/6] mm, oom_adj: make sure processes sharing mm have same view of oom_score_adj
On Fri 27-05-16 19:18:21, Vladimir Davydov wrote:
> On Fri, May 27, 2016 at 01:18:03PM +0200, Michal Hocko wrote:
> ...
> > @@ -1087,7 +1105,25 @@ static int __set_oom_adj(struct file *file, int
> > oom_adj, bool legacy)
> > unlock_task_sighand(task, &flags);
> > err_put_task:
> > put_task_struct(task);
> > +
> > + if (mm) {
> > + struct task_struct *p;
> > +
> > + rcu_read_lock();
> > + for_each_process(p) {
> > + task_lock(p);
> > + if (!p->vfork_done && process_shares_mm(p, mm)) {
> > + p->signal->oom_score_adj = oom_adj;
> > + if (!legacy && has_capability_noaudit(current,
> > CAP_SYS_RESOURCE))
> > + p->signal->oom_score_adj_min =
> > (short)oom_adj;
> > + }
> > + task_unlock(p);
>
> I.e. you write to /proc/pid1/oom_score_adj and get
> /proc/pid2/oom_score_adj updated if pid1 and pid2 share mm?
> IMO that looks unexpected from userspace pov.
How much different it is from threads in the same thread group?
Processes sharing the mm without signals is a rather weird threading
model isn't it? Currently we just lie to users about their oom_score_adj
in this weird corner case. The only exception was OOM_SCORE_ADJ_MIN
where we really didn't kill the task but all other values are simply
ignored in practice.
> May be, we'd better add mm->oom_score_adj and set it to the min
> signal->oom_score_adj over all processes sharing it? This would
> require iterating over all processes every time oom_score_adj gets
> updated, but that's a slow path.
Not sure I understand. So you would prefer that mm->oom_score_adj might
disagree with p->signal->oom_score_adj?
--
Michal Hocko
SUSE Labs
[PATCH 3/7] binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer
Add DT binding doc for Broadcom MDIO bus mutiplexer driver.
Signed-off-by: Pramod Kumar
---
.../bindings/net/brcm,mdio-mux-iproc.txt | 64 ++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
new file mode 100644
index 000..dd74ee0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt
@@ -0,0 +1,64 @@
+Properties for an MDIO bus mutiplexer found in Broadcom iProc based SoCs.
+
+This MDIO bus multiplexer defines buses that could be internal as well as
+external to SoCs and could accept MDIO transaction compatible to C-22 or
+C-45 Clause. When Child bus is selected, one need to select these two
+properties as well to generate desired MDIO trascation on appropriate bus.
+
+Required properties in addition to the generic multiplexer properties:
+
+MDIO multiplexer node:
+- complatible: brcm,mdio-mux-iproc.
+
+Child bus node:
+-brcm,is-c45: Boolean property indicating PHYs attached to this bus supports
+ C-45 mdio transaction.
+
+Every non-ethernet PHY requires a compatible so that it could be probed based
+on this compatible string.
+
+Additional information regarding generic multiplexer properties could be found
+at- Documentation/devicetree/bindings/net/mdio-mux.txt
+
+
+for example:
+ mdio_mux_iproc: mdio_mux_iproc@6602023c {
+ compatible = "brcm,mdio-mux-iproc";
+ reg = <0x6602023c 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio-integrated-mux;
+
+ mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci_phy0: pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
+ };
+
+ mdio@7 {
+ reg = <0x7>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci_phy1: pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
+ };
+ mdio@10 {
+ reg = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gphy0: eth-phy@10 {
+ reg = <0x10>;
+ };
+ };
+ };
--
1.9.1
[PATCH 2/7] DT: phy.txt: Add mdio-integrated-mux property
This property is used by integrated MDIO multiplexer which has bus selection and mdio transaction generation logic, integrated inside. Signed-off-by: Pramod Kumar --- Documentation/devicetree/bindings/net/mdio-mux.txt | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt index 491f5bd..b5ad83e 100644 --- a/Documentation/devicetree/bindings/net/mdio-mux.txt +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt @@ -5,13 +5,20 @@ numbered uniquely in a device dependent manner. The nodes for an MDIO bus multiplexer/switch will have one child node for each child bus. Required properties: -- mdio-parent-bus : phandle to the parent MDIO bus. - #address-cells = <1>; - #size-cells = <0>; Optional properties: +- mdio-parent-bus : phandle to the parent MDIO bus. Should be used + if parent mdio bus is not part of multiplexer. +- mdio-integrated-mux: boolean property indicateing that the hardware + is an integrated multiplex supporting muxed bus selection + and MDIO transaction logic generation. - Other properties specific to the multiplexer/switch hardware. +Note: one of mdio-parent-bus and mdio-integrated-mux is mandatory to +get parent bus regsitered. + Required properties for child nodes: - #address-cells = <1>; - #size-cells = <0>; -- 1.9.1
[PATCH 1/7] mdio:mux: Enhanced MDIO mux framework for integrated multiplexers
An integrated multiplexer uses same address space for
"muxed bus selection" and "generation of mdio transaction"
hence its good to register parent bus from mux driver.
Hence added a mechanism where mux driver could register a
parent bus and pass it down to framework via mdio_mux_init api.
Below changes are required to make this happen-
1. When mdio-mux parent bus is registered, mdio framework should not
parse for child as it will be muxed bus node not PHYs.
-created a new property "mdio-mux-bus-parent". if this property is present,
of_mdiobus_register will not scan for phys.
2. Passed down parent bus to mdio mux framework via mdio-mux-init api.
Signed-off-by: Pramod Kumar
---
drivers/net/phy/mdio-mux-gpio.c| 2 +-
drivers/net/phy/mdio-mux-mmioreg.c | 2 +-
drivers/net/phy/mdio-mux.c | 28 ++--
drivers/of/of_mdio.c | 3 +++
include/linux/mdio-mux.h | 4 +++-
5 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
index 7ddb1ab..9199499 100644
--- a/drivers/net/phy/mdio-mux-gpio.c
+++ b/drivers/net/phy/mdio-mux-gpio.c
@@ -55,7 +55,7 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
return PTR_ERR(s->gpios);
r = mdio_mux_init(&pdev->dev,
- mdio_mux_gpio_switch_fn, &s->mux_handle, s);
+ mdio_mux_gpio_switch_fn, &s->mux_handle, s, NULL);
if (r != 0) {
gpiod_put_array(s->gpios);
diff --git a/drivers/net/phy/mdio-mux-mmioreg.c
b/drivers/net/phy/mdio-mux-mmioreg.c
index 7fde454..d0bed52 100644
--- a/drivers/net/phy/mdio-mux-mmioreg.c
+++ b/drivers/net/phy/mdio-mux-mmioreg.c
@@ -126,7 +126,7 @@ static int mdio_mux_mmioreg_probe(struct platform_device
*pdev)
}
ret = mdio_mux_init(&pdev->dev, mdio_mux_mmioreg_switch_fn,
- &s->mux_handle, s);
+ &s->mux_handle, s, NULL);
if (ret) {
dev_err(&pdev->dev, "failed to register mdio-mux bus %s\n",
np->full_name);
diff --git a/drivers/net/phy/mdio-mux.c b/drivers/net/phy/mdio-mux.c
index 308ade0..521ab90 100644
--- a/drivers/net/phy/mdio-mux.c
+++ b/drivers/net/phy/mdio-mux.c
@@ -95,7 +95,8 @@ static int parent_count;
int mdio_mux_init(struct device *dev,
int (*switch_fn)(int cur, int desired, void *data),
void **mux_handle,
- void *data)
+ void *data,
+ struct mii_bus *mux_bus)
{
struct device_node *parent_bus_node;
struct device_node *child_bus_node;
@@ -107,10 +108,21 @@ int mdio_mux_init(struct device *dev,
if (!dev->of_node)
return -ENODEV;
- parent_bus_node = of_parse_phandle(dev->of_node, "mdio-parent-bus", 0);
+ if (!mux_bus) {
+ parent_bus_node = of_parse_phandle(dev->of_node,
+ "mdio-parent-bus", 0);
- if (!parent_bus_node)
- return -ENODEV;
+ if (!parent_bus_node)
+ return -ENODEV;
+
+ parent_bus = of_mdio_find_bus(parent_bus_node);
+ if (!parent_bus) {
+ ret_val = -EPROBE_DEFER;
+ goto err_parent_bus;
+ }
+ } else {
+ parent_bus = mux_bus;
+ }
pb = devm_kzalloc(dev, sizeof(*pb), GFP_KERNEL);
if (pb == NULL) {
@@ -118,11 +130,6 @@ int mdio_mux_init(struct device *dev,
goto err_parent_bus;
}
- parent_bus = of_mdio_find_bus(parent_bus_node);
- if (parent_bus == NULL) {
- ret_val = -EPROBE_DEFER;
- goto err_parent_bus;
- }
pb->switch_data = data;
pb->switch_fn = switch_fn;
@@ -183,7 +190,8 @@ int mdio_mux_init(struct device *dev,
put_device(&pb->mii_bus->dev);
err_parent_bus:
- of_node_put(parent_bus_node);
+ if (!mux_bus)
+ of_node_put(parent_bus_node);
return ret_val;
}
EXPORT_SYMBOL_GPL(mdio_mux_init);
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 8453f08..cf40e7a 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -225,6 +225,9 @@ int of_mdiobus_register(struct mii_bus *mdio, struct
device_node *np)
if (rc)
return rc;
+ if (of_property_read_bool(np, "mdio-integrated-mux"))
+ return 0;
+
/* Loop over the child nodes and register a phy_device for each phy */
for_each_available_child_of_node(np, child) {
addr = of_mdio_parse_addr(&mdio->dev, child);
diff --git a/include/linux/mdio-mux.h b/include/linux/mdio-mux.h
index a243dbb..61f5b21 100644
--- a/include/linux/mdio-mux.h
+++ b/include/linux/mdio-mux.h
@@ -10,11 +10,13 @@
#ifndef __LINUX_MDIO_MUX_H
#define __LINUX_MDI
[PATCH 0/7] Add MDIO bus multiplexer support for iProc SoCs
Broadcom iProc based SoCs use a MDIO bus multiplexer where child buses could be internal as well external to SoCs. These buses could supports MDIO transaction compatible to C-22/C-45. Broadcom MDIO bus mulitplexer is an integrated multiplexer where child bus selection and mdio transaction logic lies inside multiplexer itself. To accommodate this multiplexer in existing mux framework below changes were required- 1. Passed MDIO parent bus via mdio_mux_init to MDIO mux framework. 2. Defined one new boolean property named "mdio-integrated-mux". Integrated bus Multiplexer node defines this so when parent bus is registered by calling "of_mdiobus_register", this api will not scan for child nodes. Child node of integrated multiplexer will be muxed nodes not PHYs one hence should not be scanned. This patch set includes MDIO bus multiplexer driver along with above framework changes. It includes one external bus node having Ethernet PHY attached and two internal bus node holding PCIe PHYs. This patch series is based on v4.6.0-rc1 and is available from github- repo: https://github.com/Broadcom/arm64-linux.git branch:mdio-mux-v1 Pramod Kumar (7): mdio:mux: Enhanced MDIO mux framework for integrated multiplexers DT: phy.txt: Add mdio-integrated-mux property binding: mdio-mux: Add DT binding doc for Broadcom MDIO bus mutiplexer DT:mdio-mux: Add mdio multiplexer driver node net:mdio-mux: Add MDIO mux driver for iProc SoCs Binding:PHY: Binding doc for NS2 PCIe PHYs. phy: Add Northstar2 PCI Phy support .../bindings/net/brcm,mdio-mux-iproc.txt | 64 + Documentation/devicetree/bindings/net/mdio-mux.txt | 9 +- .../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 +++ arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 + arch/arm64/boot/dts/broadcom/ns2.dtsi | 32 +++ drivers/net/phy/Kconfig| 11 + drivers/net/phy/Makefile | 1 + drivers/net/phy/mdio-mux-bcm-iproc.c | 263 + drivers/net/phy/mdio-mux-gpio.c| 2 +- drivers/net/phy/mdio-mux-mmioreg.c | 2 +- drivers/net/phy/mdio-mux.c | 28 ++- drivers/of/of_mdio.c | 3 + drivers/phy/Kconfig| 8 + drivers/phy/Makefile | 1 + drivers/phy/phy-bcm-ns2-pcie.c | 115 + include/linux/mdio-mux.h | 4 +- 16 files changed, 568 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt create mode 100644 Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt create mode 100644 drivers/net/phy/mdio-mux-bcm-iproc.c create mode 100644 drivers/phy/phy-bcm-ns2-pcie.c -- 1.9.1
[PATCH 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs
iProc based SoCs supports the integrated mdio multiplexer which
has the bus selection as well as mdio transaction generation logic
inside.
This mutiplexer has child buses for PCIe, SATA, USB and ETH. These
buses could be internal or external to SOC where PHYs are attached.
These buses could use C-45 or C-22 mdio transaction.
Signed-off-by: Pramod Kumar
---
drivers/net/phy/Kconfig | 11 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-mux-bcm-iproc.c | 263 +++
3 files changed, 275 insertions(+)
create mode 100644 drivers/net/phy/mdio-mux-bcm-iproc.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 6dad9a9..38faecf 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -254,6 +254,17 @@ config MDIO_BUS_MUX_MMIOREG
Currently, only 8-bit registers are supported.
+config MDIO_BUS_MUX_BCM_IPROC
+ tristate "Support for iProc based MDIO bus multiplexers"
+ depends on OF && OF_MDIO && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select MDIO_BUS_MUX
+ default ARCH_BCM_IPROC
+ help
+ This module provides a driver for MDIO bus multiplexers found in
+ iProc based Broadcom SoCs. This mulitplexer connects one of several
+ child MDIO bus to a parent bus. Buses could be interal as well as
+ external and selection logic lies inside the same multiplexer.
+
config MDIO_BCM_UNIMAC
tristate "Broadcom UniMAC MDIO bus controller"
depends on HAS_IOMEM
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index fcdbb92..f5951d5a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_AMD_PHY) += amd.o
obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO)+= mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
+obj-$(CONFIG_MDIO_BUS_MUX_BCM_IPROC) += mdio-mux-bcm-iproc.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
obj-$(CONFIG_MDIO_BCM_UNIMAC) += mdio-bcm-unimac.o
diff --git a/drivers/net/phy/mdio-mux-bcm-iproc.c
b/drivers/net/phy/mdio-mux-bcm-iproc.c
new file mode 100644
index 000..40c32ee
--- /dev/null
+++ b/drivers/net/phy/mdio-mux-bcm-iproc.c
@@ -0,0 +1,263 @@
+/*
+ * Copyright 2016 Broadcom
+ *
+ * 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 (the "GPL").
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License version 2 (GPLv2) for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * version 2 (GPLv2) along with this source code.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MDIO_PARAM_OFFSET 0x00
+#define MDIO_PARAM_MIIM_CYCLE 29
+#define MDIO_PARAM_INTERNAL_SEL25
+#define MDIO_PARAM_BUS_ID 22
+#define MDIO_PARAM_C45_SEL 21
+#define MDIO_PARAM_PHY_ID 16
+#define MDIO_PARAM_PHY_DATA0
+
+#define MDIO_READ_OFFSET 0x04
+#define MDIO_READ_DATA_MASK0x
+#define MDIO_ADDR_OFFSET 0x08
+
+#define MDIO_CTRL_OFFSET 0x0C
+#define MDIO_CTRL_WRITE_OP 0x1
+#define MDIO_CTRL_READ_OP 0x2
+
+#define MDIO_STAT_OFFSET 0x10
+#define MDIO_STAT_DONE 1
+
+#define BUS_MAX_ADDR 32
+#define EXT_BUS_START_ADDR 16
+
+struct mdiomux_bus_param {
+ bool is_c45;
+};
+
+struct iproc_mdiomux_desc {
+ void *mux_handle;
+ void __iomem *base;
+ struct device *dev;
+ struct mii_bus *mii_bus;
+ struct mdiomux_bus_param bus_param[BUS_MAX_ADDR];
+};
+
+static int iproc_mdio_wait_for_idle(void __iomem *base, bool result)
+{
+ u32 val;
+ unsigned int timeout = 1000; /* loop for 1s */
+
+ do {
+ val = readl(base + MDIO_STAT_OFFSET);
+ if ((val & MDIO_STAT_DONE) == result)
+ return 0;
+
+ usleep_range(1000, 2000);
+ } while (timeout--);
+
+ return -ETIMEDOUT;
+}
+
+/* start_miim_ops- Program and start MDIO transaction over mdio bus.
+ * @base: Base address
+ * @phyid: phyid of the selected bus.
+ * @reg: register offset to be read/written.
+ * @val :0 if read op else value to be written in @reg;
+ * @op: Operation that need to be carried out.
+ * MDIO_CTRL_READ_OP: Read transaction.
+ * MDIO_CTRL_WRITE_OP: Write transaction.
+ *
+ * Return value: Successful Read operation returns read reg values and write
+ * operation returns 0. Failure o
[PATCH 4/7] DT:mdio-mux: Add mdio multiplexer driver node
Add integrated MDIO multiplexer driver node which contains
two mux PCIe bus and one ethernet bus along with phys
lying on these bus.
Signed-off-by: Pramod Kumar
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12
arch/arm64/boot/dts/broadcom/ns2.dtsi| 32
2 files changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index ce0ab84..8f6a6cc 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -87,3 +87,15 @@
#size-cells = <1>;
};
};
+
+&mdio_mux_iproc {
+ mdio@10 {
+ reg = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gphy0: eth-phy@10 {
+ reg = <0x10>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 6f81c9d..efc320a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -330,6 +330,38 @@
<0x6526 0x1000>;
};
+ mdio_mux_iproc: mdio_mux_iproc@6602023c {
+ compatible = "brcm,mdio-mux-iproc";
+ reg = <0x6602023c 0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mdio-integrated-mux;
+
+ mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci_phy0: pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
+ };
+
+ mdio@7 {
+ reg = <0x7>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci_phy1: pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
+ };
+ };
+
timer0: timer@6603 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x6603 0x1000>;
--
1.9.1
[PATCH 7/7] phy: Add Northstar2 PCI Phy support
Add PCI Phy support for Broadcom Northstar2 SoCs. This driver uses the
interface from the iproc mdio mux driver to enable the devices
respective phys.
Signed-off-by: Jon Mason
Signed-off-by: Pramod Kumar
---
drivers/phy/Kconfig| 8 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-ns2-pcie.c | 115 +
3 files changed, 124 insertions(+)
create mode 100644 drivers/phy/phy-bcm-ns2-pcie.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 26566db..5ff60b2 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -421,4 +421,12 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_NS2_PCIE
+ tristate "Broadcom Northstar2 PCIe PHY driver"
+ depends on OF && MDIO_BUS_MUX_BCM_IPROC
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Northstar2 PCIe PHY.
+ If unsure, say N.
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 24596a9..77d51ff 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -52,3 +52,4 @@ obj-$(CONFIG_PHY_TUSB1210)+= phy-tusb1210.o
obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
+obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
diff --git a/drivers/phy/phy-bcm-ns2-pcie.c b/drivers/phy/phy-bcm-ns2-pcie.c
new file mode 100644
index 000..65c3870
--- /dev/null
+++ b/drivers/phy/phy-bcm-ns2-pcie.c
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ns2_pci_phy {
+ struct mdio_device *mdiodev;
+ struct phy *phy;
+};
+
+#define BLK_ADDR_REG_OFFSET0x1f
+#define PLL_AFE1_100MHZ_BLK0x2100
+#define PLL_CLK_AMP_OFFSET 0x03
+#define PLL_CLK_AMP_2P05V 0x2b18
+
+static int ns2_pci_phy_init(struct phy *p)
+{
+ struct ns2_pci_phy *phy = phy_get_drvdata(p);
+ int rc;
+
+ /* select the AFE 100MHz block page */
+ rc = mdiobus_write(phy->mdiodev->bus, phy->mdiodev->addr,
+ BLK_ADDR_REG_OFFSET, PLL_AFE1_100MHZ_BLK);
+ if (rc)
+ goto err;
+
+ /* set the 100 MHz reference clock amplitude to 2.05 v */
+ rc = mdiobus_write(phy->mdiodev->bus, phy->mdiodev->addr,
+ PLL_CLK_AMP_OFFSET, PLL_CLK_AMP_2P05V);
+ if (rc)
+ goto err;
+
+ return 0;
+
+err:
+ dev_err(&phy->mdiodev->dev, "Error %d writing to phy\n", rc);
+ return rc;
+}
+
+static struct phy_ops ns2_pci_phy_ops = {
+ .init = ns2_pci_phy_init,
+};
+
+static int ns2_pci_phy_probe(struct mdio_device *mdiodev)
+{
+ struct device *dev = &mdiodev->dev;
+ struct phy_provider *provider;
+ struct ns2_pci_phy *p;
+ struct phy *phy;
+
+ phy = devm_phy_create(dev, dev->of_node, &ns2_pci_phy_ops);
+ if (IS_ERR_OR_NULL(phy)) {
+ dev_err(dev, "failed to create Phy\n");
+ return PTR_ERR(phy);
+ }
+
+ p = devm_kmalloc(dev, sizeof(struct ns2_pci_phy),
+GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ p->mdiodev = mdiodev;
+ dev_set_drvdata(dev, p);
+
+ p->phy = phy;
+ phy_set_drvdata(phy, p);
+
+ provider = devm_of_phy_provider_register(&phy->dev,
+of_phy_simple_xlate);
+ if (IS_ERR(provider)) {
+ dev_err(dev, "failed to register Phy provider\n");
+ return PTR_ERR(provider);
+ }
+
+ dev_info(dev, "%s PHY registered\n", dev_name(dev));
+
+ return 0;
+}
+
+static const struct of_device_id ns2_pci_phy_of_match[] = {
+ { .compatible = "brcm,ns2-pcie-phy", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ns2_pci_phy_of_match);
+
+static struct mdio_driver ns2_pci_phy_driver = {
+ .mdiodrv = {
+ .driver = {
+ .name = "phy-bcm-ns2-pci",
+ .of_match_table = ns2_pci_phy_of_match,
+ },
+ },
+ .probe = ns2_pci_phy_probe,
+};
+mdio_module_driver(ns2_pci_phy_driver);
+
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom Northstar2 PCI Phy driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("
[PATCH 6/7] Binding:PHY: Binding doc for NS2 PCIe PHYs.
Binding doc for NS2 PCIe PHYs.
Signed-off-by: Jon Mason
Signed-off-by: Pramod Kumar
---
.../bindings/phy/brcm,mdio-mux-bus-pci.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt
b/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt
new file mode 100644
index 000..5b51007
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt
@@ -0,0 +1,27 @@
+* Broadcom NS2 PCIe PHY binding document
+
+Required bus properties:
+- reg: MDIO Bus number for the MDIO interface
+- #address-cells: must be 1
+- #size-cells: must be 0
+
+Required PHY properties:
+- compatible: should be "brcm,ns2-pcie-phy"
+- reg: MDIO Phy ID for the MDIO interface
+- #phy-cells: must be 0
+
+This is a child bus node of "brcm,mdio-mux-iproc" node.
+
+Example:
+
+mdio@0 {
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pci_phy0: pci-phy@0 {
+ compatible = "brcm,ns2-pcie-phy";
+ reg = <0x0>;
+ #phy-cells = <0>;
+ };
+};
--
1.9.1
Re: [PATCH 4/6] mm, oom: skip over vforked tasks
On Fri 27-05-16 19:48:30, Vladimir Davydov wrote:
> On Thu, May 26, 2016 at 02:40:13PM +0200, Michal Hocko wrote:
[...]
> > @@ -839,6 +841,13 @@ void oom_kill_process(struct oom_control *oc, struct
> > task_struct *p,
> > for_each_process(p) {
> > if (!process_shares_mm(p, mm))
> > continue;
> > + /*
> > +* vforked tasks are ignored because they will drop the mm soon
> > +* hopefully and even if not they will not mind being oom
> > +* reaped because they cannot touch any memory.
>
> They shouldn't modify memory, but they still can touch it AFAIK.
You are right. This means that the vforked child might see zero pages.
Let me think whether this is acceptable or not.
Thanks!
>
> > +*/
> > + if (p->vfork_done)
> > + continue;
> > if (same_thread_group(p, victim))
> > continue;
> > if (unlikely(p->flags & PF_KTHREAD) || is_global_init(p) ||
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm: memcontrol: fix possible css ref leak on oom
On Fri 27-05-16 13:36:29, Johannes Weiner wrote: > On Mon, May 23, 2016 at 07:02:10PM +0300, Vladimir Davydov wrote: > > mem_cgroup_oom may be invoked multiple times while a process is handling > > a page fault, in which case current->memcg_in_oom will be overwritten > > leaking the previously taken css reference. > > There is a task_in_memcg_oom() check before calling mem_cgroup_oom(). > > How can this happen? Ble, I have missed that... Thanks for pointing that out -- Michal Hocko SUSE Labs
Build regressions/improvements in v4.7-rc1
Below is the list of build error/warning regressions/improvements in v4.7-rc1[1] compared to v4.6[2]. Summarized: - build errors: +17/-7 - build warnings: +1165/-547 Note that there may be false regressions, as some logs are incomplete. Still, they're build errors/warnings. As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.7-rc1.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/10404/ (262 out of 263 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/10344/ (all 263 configs) *** ERRORS *** 17 error regressions: + /home/kisskb/slave/src/arch/powerpc/include/asm/nohash/64/pgalloc.h: error: implicit declaration of function 'pte_fragment_fre' [-Werror=implicit-function-declaration]/home/kisskb/slave/src/arch/powerpc/mm/pgtable.c: At top level:: => 175:2 + /home/kisskb/slave/src/arch/powerpc/include/asm/nohash/64/pgalloc.h: error: implicit declaration of function 'pte_fragment_fre' [-Werror=implicit-function-declaration]: => 175:2 + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: 'struct pci_dn' has no member named 'edev': => 272:8 + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: dereferencing pointer to incomplete type: => 215:7 + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: implicit declaration of function 'eeh_dev_init' [-Werror=implicit-function-declaration]: => 212:3 + /home/kisskb/slave/src/arch/powerpc/mm/init_64.c: error: 'PUD_TABLE_SIZE' undeclared (first use in this function): => 90:18 + /home/kisskb/slave/src/arch/sh/kernel/setup.c: error: implicit declaration of function 'early_init_dt_scan' [-Werror=implicit-function-declaration]: => 256:2 + /tmp/ccmbHrDo.s: Error: pcrel too far BFD_RELOC_BFIN_10: => 889 + error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: => N/A + error: fou6.c: undefined reference to `ip6_tnl_encap_add_ops': => .init.text+0x4b0f), .init.text+0x4b24) + error: fou6.c: undefined reference to `ip6_tnl_encap_del_ops': => .exit.text+0x438), .init.text+0x4b39), .exit.text+0x447) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `.__alloc_workqueue_key' defined in .text section in kernel/built-in.o: => (.text+0x1ff9ba0) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `.__raw_spin_lock_init' defined in .text section in kernel/built-in.o: => (.text+0x1ff9b2c), (.text+0x1ff9c70), (.text+0x1ff9c88) + error: relocation truncated to fit: R_PPC64_REL24 against symbol `.msleep' defined in .text section in kernel/built-in.o: => (.text+0x1ff99e0) + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.__wake_up' defined in .text section in kernel/built-in.o: => (.text+0x1ff9660), (.text+0x1ff9780), (.text+0x1ff9204) + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol `._raw_spin_unlock_irqrestore' defined in .spinlock.text section in kernel/built-in.o: => (.text+0x1ff95c4) + error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.enable_irq' defined in .text section in kernel/built-in.o: => (.text+0x1ff95a8) 7 error improvements: - /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' undeclared (first use in this function): 99:17 => - /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit declaration of function 'cpu_context' [-Werror=implicit-function-declaration]: 192:2 => - /tmp/ccSuvE7E.s: Error: pcrel too far BFD_RELOC_BFIN_10: 889 => - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/kernel/built-in.o: (.text+0x1ffa6f8), (.text+0x1ffaca4), (.text+0x1ffaeec), (.text+0x1ffa59c), (.text+0x1ffa8a8), (.text+0x1ffb134), (.text+0x1ffaa5c) => - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_18' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ff9314) => - error: hns_dsaf_main.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_27' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ffb284) => - error: relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_28' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: (.text+0x1ff7890) => *** WARNINGS *** [Deleted 1300 lines about "warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]" on parisc-allmodconfig] 1165 warning regressions: + /home/kisskb/slave/src/arch/cris/arch-v10/drivers/axisflashmap.c: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t' [-Wformat] LD sound/isa/gus/built-in.o: => 368:10 + /home/kisskb/slave/src/arch/powerpc/include/
Re: [STLinux Kernel] [PATCH 02/11] drivers: clk: st: Add clock propagation for audio clocks
On 27 May 2016 at 17:41, Rob Herring wrote: > On Fri, May 27, 2016 at 09:23:20AM +0200, loic pallardy wrote: >> >> >> On 05/26/2016 03:20 PM, Rob Herring wrote: >> >On Thu, May 26, 2016 at 8:05 AM, loic pallardy wrote: >> >> >> >> >> >>On 05/26/2016 02:46 PM, Rob Herring wrote: >> >>> >> >>>On Thu, May 26, 2016 at 4:49 AM, Gabriel Fernandez >> >>> wrote: >> >> On 25 May 2016 at 19:24, Rob Herring wrote: >> > >> > >> >On Wed, May 18, 2016 at 10:41:23AM +0200, Gabriel Fernandez wrote: >> >> >> >>This patch allows fine tuning of the quads FS for audio clocks >> >>accuracy. >> >> > >> >>> >> >>>That is no different and suffers the same point I raised. It requires >> >>>updating the DT for any clock configuration change or enhancement. >> >>> >> >>Agree with you, DT update is needed as soon as a clock configuration should >> >>be changed. This is due to STiH clock driver design based on DT description >> >>of SoC clock tree. >> >> >> >>This clock driver was accepted 2 years ago. At the time being there was >> >>discussion about clock tree description location: driver or DT. >> >>Bad choice was done for this driver... >> >> >> >>If we decide to redesign STiH clock driver using in-driver clock tree >> >>description, this will modify STiH clock DT nodes description and so break >> >>DT backward compatibility. >> >> >> >>What's from your pov the best option? >> > >> >You can break it once or every time you need a clock change. I'd go >> >with the former. Maybe more specific compatible strings throughout >> >alone would be enough rather than a flag day changing the binding. >> >> So if I understand you correctly, main issue is d0 and d2 signification. >> d0 and d2 are indeed location of the flexgen in the SoC. But that's right >> flexgen are dedicated to clocks generation for features (system, audio, >> video). >> What about "st,flexgen-audio" and "st,flexgen-video"? > > It is not so much the name of these 2, but whether there are other cases > for different clock nodes that could need the same thing. If so, update > them all now rather than 1 by 1. > > Rob Hi Rob, Ok i will send a V2 for that. Mike, the first patch "drivers: clk: st: Add fs660c32 synthesizer algorithm" can be taken into account regardless the remark of Rob. Can you have a look ? Thanks. Best Regards Gabriel
Re: [PATCH v3] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219
Hi,
Could any guys help me to review this patch?
Thanks.
On 2016年05月26日 21:02, Xing Zheng wrote:
There are multi codec devices on the RK3399 platform, we can use
this patch support and control these codecs.
Signed-off-by: Xing Zheng
---
Changes in v3:
- rename DOC to rockchip,rk3399-max98357a-rt5514-da7219.txt
- rename compatible to rockchip,rk3399-max98357a-rt5514-da7219
- rename source code to rk3399_max98357a_rt5514_da7219.c
Changes in v2:
- use the FS 256 to set mclks of the max98357a and rt5514 danamically
- add more sample rate for da7219
.../rockchip,rk3399-max98357a-rt5514-da7219.txt| 15 +
sound/soc/rockchip/Kconfig | 11 +
sound/soc/rockchip/Makefile|2 +
.../soc/rockchip/rk3399_max98357a_rt5514_da7219.c | 333
4 files changed, 361 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/rockchip,rk3399-max98357a-rt5514-da7219.txt
create mode 100644 sound/soc/rockchip/rk3399_max98357a_rt5514_da7219.c
diff --git
a/Documentation/devicetree/bindings/sound/rockchip,rk3399-max98357a-rt5514-da7219.txt
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-max98357a-rt5514-da7219.txt
new file mode 100644
index 000..3ae603e
--- /dev/null
+++
b/Documentation/devicetree/bindings/sound/rockchip,rk3399-max98357a-rt5514-da7219.txt
@@ -0,0 +1,15 @@
+ROCKCHIP with MAX98357A/RT5514/DA7219 codecs
+
+Required properties:
+- compatible: "rockchip,rk3399-max98357a-rt5514-da7219"
+- rockchip,cpu: The phandle of the Rockchip I2S controller that's
+ connected to the codecs
+- rockchip,codec: The phandle of the MAX98357A/RT5514/DA7219 codecs
+
+Example:
+
+sound {
+ compatible = "rockchip,rk3399-max98357a-rt5514-da7219";
+ rockchip,cpu =<&i2s0&i2s0&i2s1>;
+ rockchip,codec =<&max98357a&headsetcodec&codec>;
+};
diff --git a/sound/soc/rockchip/Kconfig b/sound/soc/rockchip/Kconfig
index f1e0c70..e5bd1f9 100644
--- a/sound/soc/rockchip/Kconfig
+++ b/sound/soc/rockchip/Kconfig
@@ -41,3 +41,14 @@ config SND_SOC_ROCKCHIP_RT5645
help
Say Y or M here if you want to add support for SoC audio on Rockchip
boards using the RT5645/RT5650 codec, such as Veyron.
+
+config SND_SOC_RK3399_MAX98357A_RT5514_DA7219
+ tristate "ASoC support for Rockchip RK3399 boards using the
MAX98357A/RT5514/DA7219"
+ depends on SND_SOC_ROCKCHIP&& GPIOLIB
+ select SND_SOC_ROCKCHIP_I2S
+ select SND_SOC_MAX98357A
+ select SND_SOC_RT5514
+ select SND_SOC_DA7219
+ help
+ Say Y or M here if you want to add support for SoC audio on Rockchip
RK3399
+ boards using the MAX98357A/RT5514/DA7219.
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index c0bf560..0d9ca0a 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_SND_SOC_ROCKCHIP_SPDIF) += snd-soc-rockchip-spdif.o
snd-soc-rockchip-max98090-objs := rockchip_max98090.o
snd-soc-rockchip-rt5645-objs := rockchip_rt5645.o
+snd-soc-rk3399-max98357a-rt5514-da7219-objs := rk3399_max98357a_rt5514_da7219.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_MAX98090) += snd-soc-rockchip-max98090.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_RT5645) += snd-soc-rockchip-rt5645.o
+obj-$(CONFIG_SND_SOC_RK3399_MAX98357A_RT5514_DA7219) +=
snd-soc-rk3399-max98357a-rt5514-da7219.o
diff --git a/sound/soc/rockchip/rk3399_max98357a_rt5514_da7219.c
b/sound/soc/rockchip/rk3399_max98357a_rt5514_da7219.c
new file mode 100644
index 000..ec88600
--- /dev/null
+++ b/sound/soc/rockchip/rk3399_max98357a_rt5514_da7219.c
@@ -0,0 +1,333 @@
+/*
+ * Rockchip machine ASoC driver for boards using MAX98357A/RT5514/DA7219
+ *
+ * Copyright (c) 2016, ROCKCHIP CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: Build regressions/improvements in v4.7-rc1
On Mon, May 30, 2016 at 9:28 AM, Geert Uytterhoeven
wrote:
> + /home/kisskb/slave/src/arch/powerpc/include/asm/nohash/64/pgalloc.h:
> error: implicit declaration of function 'pte_fragment_fre'
> [-Werror=implicit-function-declaration]/home/kisskb/slave/src/arch/powerpc/mm/pgtable.c:
> At top level:: => 175:2
> + /home/kisskb/slave/src/arch/powerpc/include/asm/nohash/64/pgalloc.h:
> error: implicit declaration of function 'pte_fragment_fre'
> [-Werror=implicit-function-declaration]: => 175:2
> + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: 'struct
> pci_dn' has no member named 'edev': => 272:8
> + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: dereferencing
> pointer to incomplete type: => 215:7
> + /home/kisskb/slave/src/arch/powerpc/kernel/pci_dn.c: error: implicit
> declaration of function 'eeh_dev_init'
> [-Werror=implicit-function-declaration]: => 212:3
> + /home/kisskb/slave/src/arch/powerpc/mm/init_64.c: error: 'PUD_TABLE_SIZE'
> undeclared (first use in this function): => 90:18
powerpc-randconfig
> + /home/kisskb/slave/src/arch/sh/kernel/setup.c: error: implicit
> declaration of function 'early_init_dt_scan'
> [-Werror=implicit-function-declaration]: => 256:2
sh-randconfig
> + error: fou6.c: undefined reference to `ip6_tnl_encap_add_ops': =>
> .init.text+0x4b0f), .init.text+0x4b24)
> + error: fou6.c: undefined reference to `ip6_tnl_encap_del_ops': =>
> .exit.text+0x438), .init.text+0x4b39), .exit.text+0x447)
i386-randconfig (fix from Arnd just applied by DaveM).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RESEND PATCH 5/6] ASoC: cdn-dp: Add cdn DP codec driver
Hi Mark & Vinod Thanks for your suggestion, I am going to use this HDMI codec driver. But it seems no one use it, currently. On 05/30/2016 11:33 AM, Vinod Koul wrote: On Fri, May 27, 2016 at 09:23:12PM +0100, Mark Brown wrote: On Fri, May 27, 2016 at 06:45:41PM +0800, Chris Zhong wrote: codec driver get some interfaces from cdn-dp driver, than using those to set DP audio formats, corresponding to alsa formats. I'm not seeing anything Rockchip specific in here... DisplayPort is backwards compatible with HDMI, shouldn't this be using the existing hdmi-codec code? Yup, typically only difference between the two would be programming the info frame for DP or HDMI, otherwise it is pretty much same stuff... They should patch hdmi-codec for that, if that is not supported. Thanks
[Question] Crash when cat /dev/kmem in arm/arm64 but not in x86
Hi all, When cat /dev/kmem in arm/arm64, it will crash, this is caused by "from = 0" in copy_to_user(void __user *to, const void *from, unsigned long n), call trace shows below(eg, arm64) [9.913370] Unable to handle kernel NULL pointer dereference at virtual address [9.914391] pgd = 88345000 [9.914976] [] *pgd=482bb003, *pud=f69b4003, *pmd= [9.918036] Internal error: Oops: 9606 [#1] PREEMPT SMP [9.918683] Modules linked in: [9.919413] CPU: 6 PID: 1021 Comm: cat Not tainted 4.6.0+ #80 [9.920410] Hardware name: linux,dummy-virt (DT) [9.921003] task: 8000b6448000 ti: 883b task.ti: 883b [9.922356] PC is at __copy_to_user+0x180/0x280 [9.922847] LR is at read_kmem+0x200/0x220 [9.923265] pc : [] lr : [] pstate: 2145 [9.923988] sp : 883b3d60 [9.924670] x29: 883b3d60 x28: 1000 [9.925420] x27: 1000 x26: 883b3ec8 [9.926039] x25: 883b x24: 08a20638 [9.926810] x23: 1000 x22: e4dac550 [9.927668] x21: x20: 1000 [9.928771] x19: x18: e4dab240 [9.929494] x17: 00497458 x16: 081bc098 [9.930162] x15: x14: ff00 [9.930857] x13: x12: 0038 [9.931629] x11: 00c7 x10: 0006 [9.932649] x9 : 0006 x8 : 207a73202c296c6c [9.933356] x7 : 756e282020202020 x6 : e4dab550 [9.934050] x5 : e4dac550 x4 : [9.934801] x3 : x2 : 0f80 [9.935601] x1 : x0 : e4dab550 but in x86, cat /dev/kmem, will just return "Bad address". After check the x86 code, copy_to_user -> _copy_to_user(copy_user_64.S, fixup) -> copy_user_handle_tail (will return len > 0), then the copy_to_user() will return -EFAULT, the fixup_exception will deal with this situation, so does the arm/arm64 need the same mechanism to deal with it too? Thanks Kefeng
Re: [Qemu-ppc] [PATCH] powerpc/pseries: start rtasd before PCI probing
On Mon, 23 May 2016 10:28:28 +0200
Greg Kurz wrote:
> A strange behaviour is observed when comparing PCI hotplug in QEMU, between
> x86 and pseries. If you consider the following steps:
> - start a VM
> - add a PCI device via the QEMU monitor before the rtasd has started (for
> example starting the VM in paused state, or hotplug during FW or boot
> loader)
> - resume the VM execution
>
> The x86 kernel detects the PCI device, but the pseries one does not.
>
> This happens because the rtasd kernel worker is currently started under
> device_initcall, while PCI probing happens earlier under subsys_initcall.
>
> As a consequence, if we have a pending RTAS event at boot time, a message
> is printed and the event is dropped.
>
> This patch moves all the initialization of rtasd to arch_initcall, which is
> run before subsys_call: this way, logging_enabled is true when the RTAS
> event pops up and it is not lost anymore.
>
> The proc fs bits stay at device_initcall because they cannot be run before
> fs_initcall.
>
> Signed-off-by: Greg Kurz
> ---
Ping ?
> arch/powerpc/kernel/rtasd.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
> index e864b7c5884e..ad9e4e1a2d5d 100644
> --- a/arch/powerpc/kernel/rtasd.c
> +++ b/arch/powerpc/kernel/rtasd.c
> @@ -526,10 +526,8 @@ void rtas_cancel_event_scan(void)
> }
> EXPORT_SYMBOL_GPL(rtas_cancel_event_scan);
>
> -static int __init rtas_init(void)
> +static int __init rtas_event_scan_init(void)
> {
> - struct proc_dir_entry *entry;
> -
> if (!machine_is(pseries) && !machine_is(chrp))
> return 0;
>
> @@ -562,13 +560,24 @@ static int __init rtas_init(void)
> return -ENOMEM;
> }
>
> + start_event_scan();
> +
> + return 0;
> +}
> +arch_initcall(rtas_event_scan_init);
> +
> +static int __init rtas_init(void)
> +{
> + struct proc_dir_entry *entry;
> +
> + if (!machine_is(pseries) && !machine_is(chrp))
> + return 0;
> +
> entry = proc_create("powerpc/rtas/error_log", S_IRUSR, NULL,
> &proc_rtas_log_operations);
> if (!entry)
> printk(KERN_ERR "Failed to create error_log proc entry\n");
>
> - start_event_scan();
> -
> return 0;
> }
> __initcall(rtas_init);
>
>
Re: [PATCH 4/7] x86/dumpstack: If addr_limit is non-default, display it
On Sun, May 29, 2016 at 12:08:29PM -0700, Andy Lutomirski wrote: > Sure, but how do I implement that? There's no "does this arch have > addr_limit in thread_info" general flag that I know of. What about get_fs()? Looks like all arches implement that and on sparc it is something called thread_info.current_ds... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
Re: [PATCH 2/2] ARM: dts: Add async-bridge clock to MFC power domain for Exynos5420
On 05/24/2016 07:41 PM, Javier Martinez Canillas wrote: > The MFC IP is also inter-connected by an Async-Bridge so the CLK_ACLK333 > has to be ungated during a power domain switch. Trying to do it when the > clock is gated will fail and lead to an imprecise external abort error > when the driver tries to access the MFC registers with the PD disabled. > > For example, if the s5p-mfc module is removed and the MFC PD turned off: > > [ 186.835606] Power domain power-domain@10044060 disable failed > [ 186.835671] s5p-mfc 1100.codec: Removing 1100.codec > [ 186.837670] Power domain power-domain@10044060 disable failed > > And when the module is inserted again: > > [ 2395.176956] s5p_mfc_wait_for_done_dev:34: Interrupt (dev->int_type:0, > command:12) timed out > [ 2395.177031] s5p_mfc_init_hw:272: Failed to load firmware > [ 2395.177384] Unhandled fault: imprecise external abort (0x1406) at > 0x > [ 2395.177441] pgd = ec3b4000 > [ 2395.177467] [] *pgd= > [ 2395.177507] Internal error: : 1406 [#1] PREEMPT SMP ARM > [ 2395.177550] Modules linked in: s5p_mfc mwifiex_sdio mwifiex uvcvideo > s5p_jpeg v4l2_mem2mem videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops > videobuf2_v4l2 videobuf2_core v4l2_common videodev media [last unloaded: > s5p_mfc] > [ 2395.14] CPU: 1 PID: 2382 Comm: v4l_id Tainted: GW > 4.6.0-rc6-next-20160502-00010-g7730dc64d2c1-dirty #179 > [ 2395.177857] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 2395.177906] task: ed275500 ti: e6c8c000 task.ti: e6c8c000 > [ 2395.177996] PC is at s5p_mfc_reset+0x1c4/0x284 [s5p_mfc] > [ 2395.178057] LR is at s5p_mfc_reset+0x1a4/0x284 [s5p_mfc] > > This patch fixes this issue by adding the CLK_ACLK333 as an Async-Bridge > clock for the MFC power domain, so the PD configuration works properly. > > Signed-off-by: Javier Martinez Canillas > > --- > > arch/arm/boot/dts/exynos5420.dtsi | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Thanks, applied. Krzysztof
[PATCH] mmc: core: fix the wrong error control
After applied "remove lots of IS_ERR_VALUE abuses", it shoold be
misoperation. (commit 287980e49)
If mmc_bus_test is successful, it returned the bus-witdh bit.
The below log is error log
[2.542260] mmc0: mmc_select_hs200 failed, error 3
[2.542275] mmc0: error 3 whilst initialising MMC card
Signed-off-by: Jaehoon Chung
---
drivers/mmc/core/mmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index c984321..aafb73d 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1276,7 +1276,7 @@ static int mmc_select_hs200(struct mmc_card *card)
* switch to HS200 mode if bus width is set successfully.
*/
err = mmc_select_bus_width(card);
- if (!err) {
+ if (err > 0) {
val = EXT_CSD_TIMING_HS200 |
card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
@@ -1583,7 +1583,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
} else if (mmc_card_hs(card)) {
/* Select the desired bus width optionally */
err = mmc_select_bus_width(card);
- if (!err) {
+ if (err > 0) {
err = mmc_select_hs_ddr(card);
if (err)
goto free_card;
--
1.9.1
Re: [PATCH] mutex: Report recursive ww_mutex locking early
Op 26-05-16 om 22:08 schreef Chris Wilson:
> Recursive locking for ww_mutexes was originally conceived as an
> exception. However, it is heavily used by the DRM atomic modesetting
> code. Currently, the recursive deadlock is checked after we have queued
> up for a busy-spin and as we never release the lock, we spin until
> kicked, whereupon the deadlock is discovered and reported.
>
> A simple solution for the now common problem is to move the recursive
> deadlock discovery to the first action when taking the ww_mutex.
>
> Testcase: igt/kms_cursor_legacy
> Suggested-by: Maarten Lankhorst
> Signed-off-by: Chris Wilson
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: linux-kernel@vger.kernel.org
> ---
>
> Maarten suggested this as a simpler fix to the immediate problem. Imo,
> we still want to perform deadlock detection within the spin in order to
> catch more complicated deadlocks without osq_lock() forcing fairness!
Reviewed-by: Maarten Lankhorst
Should this be Cc: sta...@vger.kernel.org ?
I think in the normal case things would move forward even with osq_lock,
but you can make a separate patch to add it to mutex_can_spin_on_owner,
with the same comment as in mutex_optimistic_spin.
> ---
> kernel/locking/mutex.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index d60f1ba3e64f..1659398dc8f8 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -502,9 +502,6 @@ __ww_mutex_lock_check_stamp(struct mutex *lock, struct
> ww_acquire_ctx *ctx)
> if (!hold_ctx)
> return 0;
>
> - if (unlikely(ctx == hold_ctx))
> - return -EALREADY;
> -
> if (ctx->stamp - hold_ctx->stamp <= LONG_MAX &&
> (ctx->stamp != hold_ctx->stamp || ctx > hold_ctx)) {
> #ifdef CONFIG_DEBUG_MUTEXES
> @@ -530,6 +527,12 @@ __mutex_lock_common(struct mutex *lock, long state,
> unsigned int subclass,
> unsigned long flags;
> int ret;
>
> + if (use_ww_ctx) {
> + struct ww_mutex *ww = container_of(lock, struct ww_mutex, base);
> + if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
> + return -EALREADY;
> + }
> +
> preempt_disable();
> mutex_acquire_nest(&lock->dep_map, subclass, 0, nest_lock, ip);
>
Re: [PATCH 13/15] mtd: nand: samsung: retrieve ECC requirements from extended ID
Hi Valdis,
On Sun, 29 May 2016 20:20:35 -0400
valdis.kletni...@vt.edu wrote:
> On Fri, 27 May 2016 14:54:59 +0200, Boris Brezillon said:
> > From: Hans de Goede
> >
> > On some nand controllers with hw-ecc the controller code wants to know
> > the ecc strength and size and having these as 0, 0 is not accepted.
> >
> > Specifying these in devicetree is possible but undesirable as the nand
> > may be different in different production runs of the same board, so it
> > is better to get this info from the nand id where possible.
> >
> > This commit adds code to read the ecc strength and size from the nand
> > for Samsung extended-id nands. This code is based on the info for the 5th
> > id byte in the datasheets for the following Samsung nands: K9GAG08U0E,
> > K9GAG08U0F, K9GAG08X0D, K9GBG08U0A, K9GBG08U0B. These all use these bits
> > in the exact same way.
>
> Is this correct for all Samsung nand devices supported by this driver?
>
> (If this driver only covers those 5 specific parts, it's OK. If there's
> others, more research is needed)
Actually, that was my first reaction [1], but the more I think about it
the more I realize it's a non-issue.
AFAICT, there's no full-id entries for Samsung NANDs in the nand_ids
table, so this either means there's no real users of Samsung MLCs or
NAND controller drivers connecting to those chips don't care about the
->ecc_{step_ds,strength_ds} fields.
I agree that the solution is not perfect, but I'd prefer seeing the
NAND detection code iteratively improved than rejecting everything
until we're 100% sure that all cases are correctly handled (which might
never happen since NAND vendors introduce new NAND ID scheme if they
need to).
BTW, do you have Samsung datasheets describing a different NAND ID
format, or is it purely hypothetical?
Regards,
Boris
[1]http://lists.infradead.org/pipermail/linux-mtd/2015-July/060582.html
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [RESEND PATCH 5/6] ASoC: cdn-dp: Add cdn DP codec driver
On 05/30/16 10:26, Chris Zhong wrote: > Hi Mark & Vinod > > Thanks for your suggestion, I am going to use this HDMI codec driver. > But it seems no one use it, currently. > There is three users working on getting their code accepted in main line. I have been trying to get my tda998x patches reviewed for some time now, but not lately, because I have been busy with my other tasks. The two others are Philipp Zabel and Arnaud Pouliquen, both in cc. Not sure if they actually have some patches already queued for mainline. Best regards, Jyri > On 05/30/2016 11:33 AM, Vinod Koul wrote: >> On Fri, May 27, 2016 at 09:23:12PM +0100, Mark Brown wrote: >>> On Fri, May 27, 2016 at 06:45:41PM +0800, Chris Zhong wrote: codec driver get some interfaces from cdn-dp driver, than using those to set DP audio formats, corresponding to alsa formats. >>> I'm not seeing anything Rockchip specific in here... DisplayPort is >>> backwards compatible with HDMI, shouldn't this be using the existing >>> hdmi-codec code? >> >> Yup, typically only difference between the two would be programming the >> info frame for DP or HDMI, otherwise it is pretty much same stuff... >> >> They should patch hdmi-codec for that, if that is not supported. >> >> Thanks > >
[PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
This patch add g/s_selection support for MT8173
Signed-off-by: Tiffany Lin
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 74
1 file changed, 74 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
index 6e72d73..23ef9a1 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
@@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file
*file, void *priv,
return vidioc_try_fmt(f, fmt);
}
+static int vidioc_venc_g_selection(struct file *file, void *priv,
+struct v4l2_selection *s)
+{
+ struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
+ struct mtk_q_data *q_data;
+
+ /* crop means compose for output devices */
+ switch (s->target) {
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ case V4L2_SEL_TGT_CROP:
+ case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+ case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+ case V4L2_SEL_TGT_COMPOSE:
+ if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ mtk_v4l2_err("Invalid s->type = %d", s->type);
+ return -EINVAL;
+ }
+ break;
+ default:
+ mtk_v4l2_err("Invalid s->target = %d", s->target);
+ return -EINVAL;
+ }
+
+ q_data = mtk_venc_get_q_data(ctx, s->type);
+ if (!q_data)
+ return -EINVAL;
+
+ s->r.top = 0;
+ s->r.left = 0;
+ s->r.width = q_data->visible_width;
+ s->r.height = q_data->visible_height;
+
+ return 0;
+}
+
+static int vidioc_venc_s_selection(struct file *file, void *priv,
+struct v4l2_selection *s)
+{
+ struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
+ struct mtk_q_data *q_data;
+
+ switch (s->target) {
+ case V4L2_SEL_TGT_CROP_DEFAULT:
+ case V4L2_SEL_TGT_CROP_BOUNDS:
+ case V4L2_SEL_TGT_CROP:
+ case V4L2_SEL_TGT_COMPOSE_DEFAULT:
+ case V4L2_SEL_TGT_COMPOSE_BOUNDS:
+ case V4L2_SEL_TGT_COMPOSE:
+ if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
+ mtk_v4l2_err("Invalid s->type = %d", s->type);
+ return -EINVAL;
+ }
+ break;
+ default:
+ mtk_v4l2_err("Invalid s->target = %d", s->target);
+ return -EINVAL;
+ }
+
+ q_data = mtk_venc_get_q_data(ctx, s->type);
+ if (!q_data)
+ return -EINVAL;
+
+ s->r.top = 0;
+ s->r.left = 0;
+ q_data->visible_width = s->r.width;
+ q_data->visible_height = s->r.height;
+
+ return 0;
+}
+
static int vidioc_venc_qbuf(struct file *file, void *priv,
struct v4l2_buffer *buf)
{
@@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
.vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
.vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
+
+ .vidioc_g_selection = vidioc_venc_g_selection,
+ .vidioc_s_selection = vidioc_venc_s_selection,
};
static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
--
1.7.9.5
Re: [lkp] [mm] 55834c5909: boot-slabinfo.num_objs +31.9% increasement
On Mon, May 30, 2016 at 4:17 AM, kernel test robot
wrote:
>
> FYI, we noticed boot-slabinfo.num_objs +31.9% increasement due to commit:
>
> commit 55834c59098d0c5a97b0f3247e55832b67facdcf ("mm: kasan: initial memory
> quarantine implementation")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> in testcase: boot
> on test machine: vm-lkp-wsx03-2G: 2 threads qemu-system-x86_64 -enable-kvm
> -cpu host with 2G memory
> with following parameters: sleep=1
>
>
> Details are as below:
> -->
>
>
> =
> compiler/kconfig/rootfs/sleep/tbox_group/testcase:
>
> gcc-6/x86_64-randconfig-s4-05280557/debian-x86_64-2015-02-07.cgz/1/vm-lkp-wsx03-2G/boot
>
> commit:
> b8f1a75d61d8405a753380c6fb17ba84a5603cd4
> 55834c59098d0c5a97b0f3247e55832b67facdcf
>
> b8f1a75d61d8405a 55834c59098d0c5a97b0f3247e
> --
> %stddev %change %stddev
> \ |\
> 165450 ± 0% +31.9% 218176 ± 1% boot-slabinfo.num_objs
> 19095 ± 5%+104.3% 39013 ± 3% boot-slabinfo.num_pages
> 107.27 ± 2% +14.1% 122.43 ± 13% boot-time.boot
> 97.13 ± 1% +4.3% 101.31 ± 1% boot-time.idle
>1105076 ± 0% -7.2%1025056 ± 0% boot-meminfo.MemFree
> 36269 ± 12%+215.7% 114517 ± 5% boot-meminfo.SUnreclaim
> 76469 ± 5%+104.5% 156343 ± 4% boot-meminfo.Slab
>
>
>
>boot-slabinfo.num_objs
>
> 23 ++-+
> |O O |
> 22 ++O OO OO OO O O OO OO |
> OO O O OOO O O OO O |
> 21 ++ |
> | |
> 20 ++ |
> | |
> 19 ++ |
> | |
> 18 ++ |
> | |
> 17 ++ |
>
> 16 ++-+
>
>
>boot-slabinfo.num_pages
>
> 45000 ++-O+
> | O O OO O O O O OOO |
> 4 +O OOO OOOO O O |
> O OO O O O O O OOO O |
> | O OO|
> 35000 ++ |
> | |
> 3 ++ |
> | |
> 25000 ++ |
> | |
> | ***
> 2 +* * * ** * * * * * * ** ** * * * * * * :: * *** *|
> * * ** ** * * ** *** * ** *** * * * * * ** *** * ** ** ** * * |
> 15000 ++--+
>
>
> [*] bisect-good sample
> [O] bisect-bad sample
Hi Xiaolong,
It is with CONFIG_KASAN=y? If yes, then increased memory usage is expected.
[PATCH] mmc: sdhci: use udelay instead of mdelay
From: Chuanxiao Dong
This patch will use udelay instead of mdelay when waiting for
SDHCI hardware to be stable. udelay can help to reduce the waiting
time when is in critical region which is protected by spinlock.
With this patch, __sdhci_set_ios only take a few microseconds to be
done.
Signed-off-by: Chuanxiao Dong
---
drivers/mmc/host/sdhci.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e010ea4eb6f5..56d2c7567d97 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -173,8 +173,8 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
sdhci_runtime_pm_bus_off(host);
}
- /* Wait max 100 ms */
- timeout = 100;
+ /* Wait max 1 ms */
+ timeout = 1;
/* hw clears the bit when it's done */
while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
@@ -185,7 +185,7 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
return;
}
timeout--;
- mdelay(1);
+ udelay(10);
}
}
EXPORT_SYMBOL_GPL(sdhci_reset);
@@ -985,8 +985,8 @@ void sdhci_send_command(struct sdhci_host *host, struct
mmc_command *cmd)
/* Initially, a command has no error */
cmd->error = 0;
- /* Wait max 10 ms */
- timeout = 10;
+ /* Wait max 1000 ms */
+ timeout = 1000;
mask = SDHCI_CMD_INHIBIT;
if ((cmd->data != NULL) || (cmd->flags & MMC_RSP_BUSY))
@@ -1007,7 +1007,7 @@ void sdhci_send_command(struct sdhci_host *host, struct
mmc_command *cmd)
return;
}
timeout--;
- mdelay(1);
+ udelay(10);
}
timeout = jiffies;
@@ -1240,8 +1240,8 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned
int clock)
clk |= SDHCI_CLOCK_INT_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
- /* Wait max 20 ms */
- timeout = 20;
+ /* Wait max 2000 ms */
+ timeout = 2000;
while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
& SDHCI_CLOCK_INT_STABLE)) {
if (timeout == 0) {
@@ -1251,7 +1251,7 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned
int clock)
return;
}
timeout--;
- mdelay(1);
+ udelay(10);
}
clk |= SDHCI_CLOCK_CARD_EN;
--
Regards,
Beata Baranowska
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk
Sąd Rejonowy Gdańsk Północ
VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882
NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN
Re: WMI driver no longer load after switching to generic UUID library
On Sun, 2016-05-29 at 13:22 -0700, Linus Torvalds wrote:
> Andy?
>
> Looking at that commit, it does look like what wmi_parse_guid +
> wmi_swap_bytes did was to implement a LE uuid. So the conversion looks
> correct, but the fact that it breaks something obviously means that
> there's something missing. What's going on?
I proposed to add print to the loops to see what's going on there.
>
> And dammit, how I hate uuid's and the idiotic byte ordering issue.
> It's possibly the only idiotic standard that is even worse than xml.
T'so seems has the same opinion http://www.spinics.net/lists/kernel/msg2
26.html
>
> Linus
>
> On Sun, May 29, 2016 at 11:35 AM, Kui Zhang
> wrote:
> > Hello,
> >
> > After commit 538d7eb86d58 ("drivers/platform/x86/wmi.c: use generic
> > UUID library")
> >
> > some keyboard functions stopped working:
> >
> > clevo-wmi - git://git.code.sf.net/p/clevo-wmi/code
> > [ 83.877887] Clevo Get GUID not found
> >
> > /*
> > #define CLWMI_GET_GUID "ABBC0F6D-8EA1-11d1-00A0-C9062910"
> >
> > ...
> > if(!wmi_has_guid(CLWMI_GET_GUID)) {
> > pr_err("Clevo Get GUID not found\n");
> > return -ENODEV;
> > }
> >
> >
> > */
> >
> > clevo-xsm-wmi - https://bitbucket.org/lynthium/clevo-xsm-wmi.git
> > insmod: ERROR: could not insert module clevo-xsm-wmi.ko: No such
> > device
> >
> > /*
> >
> > #define CLEVO_GET_GUID"ABBC0F6D-8EA1-11D1-00A0-C9062910"
> >
> > ...
> >
> > if (!wmi_has_guid(CLEVO_GET_GUID)) {
> > CLEVO_XSM_INFO("No known WMI control method GUID found\n");
> > return -ENODEV;
> > }
> >
> > */
> >
> >
> > thanks
> > Kui.Z
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH] ARM: dts: exynos: Remove unneded always-on for regulators on Peach boards
On 05/19/2016 11:52 PM, Javier Martinez Canillas wrote:
> The regulator always-on property should only be used for regulators
> that either can't be disabled or the drivers for the client devices
> are not enabling the regulator and so being disabled due to unused.
>
> There are some max77802 regulators in the Peach Pit and Pi boards
> that are always-on but shouldn't since they are enabled by drivers:
>
> BUCK5 is max77802 inl1 supply
> BUCK7 is max77802 inl{2,10} supply
> BUCK9 is max77802 inl{3,4,5,7} supply
> BUCK10 is mmc1 vqmmc supply
> LDO9 is adc vdd supply
>
> This patch removes the always-on property for these regulators.
>
> Some regulators should remain always-on even when they are used as
> input supplies, because these regulators are also used by other
> components that are not described in the DT, for example:
>
> LDO10 is hdmi vdd_osc supply but it's also used as input supply for
> the Exynos5420 temperature sensor.
>
> LDO8 is hdmi vdd and vdd_pll supply but it's also used as supply for
> the Exynos5420 Display port.
>
> BUCK2 and BUCK6 are the vdd supplies for the EAGLE and KFC clusters.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 5 -
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 -
> 2 files changed, 10 deletions(-)
Thanks, applied.
Best regards,
Krzysztof
Re: [PATCH] Fix annoyingly awkward typo in drm_edid_load.c
On Mon, May 30, 2016 at 02:26:38AM -0400, Valdis Kletnieks wrote: > Fix egregious typo in comment. > > Signed-off-by: Valdis Kletnieks Applied to drm-misc, thanks. -Daniel > > --- a/drivers/gpu/drm/drm_edid_load.c 2016-04-20 17:54:27.208059935 -0400 > +++ b/drivers/gpu/drm/drm_edid_load.c 2016-05-30 02:15:43.747105384 -0400 > @@ -271,7 +271,7 @@ >* by commas, search through the list looking for one that >* matches the connector. >* > - * If there's one or more that don't't specify a connector, keep > + * If there's one or more that doesn't specify a connector, keep >* the last one found one as a fallback. >*/ > fwstr = kstrdup(edid_firmware, GFP_KERNEL); > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] mmc: sdhci: use udelay instead of mdelay
On Monday, May 30, 2016 7:55:55 AM CEST Baranowska, BeataX wrote:
> From: Chuanxiao Dong
>
> This patch will use udelay instead of mdelay when waiting for
> SDHCI hardware to be stable. udelay can help to reduce the waiting
> time when is in critical region which is protected by spinlock.
>
> With this patch, __sdhci_set_ios only take a few microseconds to be
> done.
>
> Signed-off-by: Chuanxiao Dong
> ---
> drivers/mmc/host/sdhci.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index e010ea4eb6f5..56d2c7567d97 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -173,8 +173,8 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
> sdhci_runtime_pm_bus_off(host);
> }
>
> - /* Wait max 100 ms */
> - timeout = 100;
> + /* Wait max 1 ms */
> + timeout = 1;
>
> /* hw clears the bit when it's done */
> while (sdhci_readb(host, SDHCI_SOFTWARE_RESET) & mask) {
> @@ -185,7 +185,7 @@ void sdhci_reset(struct sdhci_host *host, u8 mask)
> return;
> }
> timeout--;
> - mdelay(1);
> + udelay(10);
> }
> }
> EXPORT_SYMBOL_GPL(sdhci_reset);
This can significantly increase the timeout length. I think you should
instead use time_before() to see how many jiffies have passed since
the start.
However, the real question is why the reset function gets called under
a spinlock in the first place. Can you try to rearrange the code so
it doesn't need the lock at all and you can just use msleep() instead?
Arnd
[PATCH] mmc: host: use pr_err for sdhci_dumpregs
From: Chuanxiao Dong
sdhci_dumpregs is used to dump registers when error happens. Thus it should
use pr_err instead of pr_debug to show more information about the hardware.
Signed-off-by: Chuanxiao Dong
---
drivers/mmc/host/sdhci.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e010ea4eb6f5..99441742d86e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -52,58 +52,58 @@ static int sdhci_get_cd(struct mmc_host *mmc);
static void sdhci_dumpregs(struct sdhci_host *host)
{
- pr_debug(DRIVER_NAME ": === REGISTER DUMP (%s)===\n",
+ pr_err(DRIVER_NAME ": === REGISTER DUMP (%s)===\n",
mmc_hostname(host->mmc));
- pr_debug(DRIVER_NAME ": Sys addr: 0x%08x | Version: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Sys addr: 0x%08x | Version: 0x%08x\n",
sdhci_readl(host, SDHCI_DMA_ADDRESS),
sdhci_readw(host, SDHCI_HOST_VERSION));
- pr_debug(DRIVER_NAME ": Blk size: 0x%08x | Blk cnt: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Blk size: 0x%08x | Blk cnt: 0x%08x\n",
sdhci_readw(host, SDHCI_BLOCK_SIZE),
sdhci_readw(host, SDHCI_BLOCK_COUNT));
- pr_debug(DRIVER_NAME ": Argument: 0x%08x | Trn mode: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Argument: 0x%08x | Trn mode: 0x%08x\n",
sdhci_readl(host, SDHCI_ARGUMENT),
sdhci_readw(host, SDHCI_TRANSFER_MODE));
- pr_debug(DRIVER_NAME ": Present: 0x%08x | Host ctl: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Present: 0x%08x | Host ctl: 0x%08x\n",
sdhci_readl(host, SDHCI_PRESENT_STATE),
sdhci_readb(host, SDHCI_HOST_CONTROL));
- pr_debug(DRIVER_NAME ": Power:0x%08x | Blk gap: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Power:0x%08x | Blk gap: 0x%08x\n",
sdhci_readb(host, SDHCI_POWER_CONTROL),
sdhci_readb(host, SDHCI_BLOCK_GAP_CONTROL));
- pr_debug(DRIVER_NAME ": Wake-up: 0x%08x | Clock:0x%08x\n",
+ pr_err(DRIVER_NAME ": Wake-up: 0x%08x | Clock:0x%08x\n",
sdhci_readb(host, SDHCI_WAKE_UP_CONTROL),
sdhci_readw(host, SDHCI_CLOCK_CONTROL));
- pr_debug(DRIVER_NAME ": Timeout: 0x%08x | Int stat: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Timeout: 0x%08x | Int stat: 0x%08x\n",
sdhci_readb(host, SDHCI_TIMEOUT_CONTROL),
sdhci_readl(host, SDHCI_INT_STATUS));
- pr_debug(DRIVER_NAME ": Int enab: 0x%08x | Sig enab: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Int enab: 0x%08x | Sig enab: 0x%08x\n",
sdhci_readl(host, SDHCI_INT_ENABLE),
sdhci_readl(host, SDHCI_SIGNAL_ENABLE));
- pr_debug(DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
+ pr_err(DRIVER_NAME ": AC12 err: 0x%08x | Slot int: 0x%08x\n",
sdhci_readw(host, SDHCI_ACMD12_ERR),
sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
- pr_debug(DRIVER_NAME ": Caps: 0x%08x | Caps_1: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Caps: 0x%08x | Caps_1: 0x%08x\n",
sdhci_readl(host, SDHCI_CAPABILITIES),
sdhci_readl(host, SDHCI_CAPABILITIES_1));
- pr_debug(DRIVER_NAME ": Cmd: 0x%08x | Max curr: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Cmd: 0x%08x | Max curr: 0x%08x\n",
sdhci_readw(host, SDHCI_COMMAND),
sdhci_readl(host, SDHCI_MAX_CURRENT));
- pr_debug(DRIVER_NAME ": Host ctl2: 0x%08x\n",
+ pr_err(DRIVER_NAME ": Host ctl2: 0x%08x\n",
sdhci_readw(host, SDHCI_HOST_CONTROL2));
if (host->flags & SDHCI_USE_ADMA) {
if (host->flags & SDHCI_USE_64_BIT_DMA)
- pr_debug(DRIVER_NAME ": ADMA Err: 0x%08x | ADMA Ptr:
0x%08x%08x\n",
+ pr_err(DRIVER_NAME ": ADMA Err: 0x%08x | ADMA Ptr:
0x%08x%08x\n",
readl(host->ioaddr + SDHCI_ADMA_ERROR),
readl(host->ioaddr + SDHCI_ADMA_ADDRESS_HI),
readl(host->ioaddr + SDHCI_ADMA_ADDRESS));
else
- pr_debug(DRIVER_NAME ": ADMA Err: 0x%08x | ADMA Ptr:
0x%08x\n",
+ pr_err(DRIVER_NAME ": ADMA Err: 0x%08x | ADMA Ptr:
0x%08x\n",
readl(host->ioaddr + SDHCI_ADMA_ERROR),
readl(host->ioaddr + SDHCI_ADMA_ADDRESS));
}
- pr_debug(DRIVER_NAME ": ===\n");
+ pr_err(DRIVER_NAME ": ===\n");
}
/*\
--
Regards,
Beata Baranowska
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk
Sąd Rejonowy Gdańsk
Re: [PATCH block/for-4.7-fixes] writeback: use higher precision calculation in domain_dirty_limits()
On Fri 27-05-16 14:34:46, Tejun Heo wrote: > As vm.dirty_[background_]bytes can't be applied verbatim to multiple > cgroup writeback domains, they get converted to percentages in > domain_dirty_limits() and applied the same way as > vm.dirty_[background]ratio. However, if the specified bytes is lower > than 1% of available memory, the calculated ratios become zero and the > writeback domain gets throttled constantly. > > Fix it by using per-PAGE_SIZE instead of percentage for ratio > calculations. Also, the updated DIV_ROUND_UP() usages now should > yield 1/4096 (0.0244%) as the minimum ratio as long as the specified > bytes are above zero. The patch looks good to me. You can add: Reviewed-by: Jan Kara Just one nit below: > @@ -386,26 +387,28 @@ static void domain_dirty_limits(struct > dirty_throttle_control *dtc) > /* >* The byte settings can't be applied directly to memcg >* domains. Convert them to ratios by scaling against > - * globally available memory. > + * globally available memory. As the ratios are in > + * per-PAGE_SIZE, they can be obtained by dividing bytes by > + * pages. The comment would be more comprehensible to me is the last sentence was "... by dividing bytes by number of pages". Honza -- Jan Kara SUSE Labs, CR
Re: [RFC PATCH 2/4] mm: Change the interface for __tlb_remove_page
> diff --git a/mm/memory.c b/mm/memory.c
> index 15322b73636b..a01db5bc756b 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -292,23 +292,24 @@ void tlb_finish_mmu(struct mmu_gather *tlb, unsigned
> long start, unsigned long e
> * handling the additional races in SMP caused by other CPUs caching valid
> * mappings in their TLBs. Returns the number of free page slots left.
> * When out of page slots we must call tlb_flush_mmu().
> + *returns true if the caller should flush.
> */
> -int __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
> +bool __tlb_remove_page(struct mmu_gather *tlb, struct page *page)
> {
> struct mmu_gather_batch *batch;
>
> VM_BUG_ON(!tlb->end);
>
> batch = tlb->active;
> - batch->pages[batch->nr++] = page;
> if (batch->nr == batch->max) {
> if (!tlb_next_batch(tlb))
> - return 0;
> + return true;
> batch = tlb->active;
> }
> VM_BUG_ON_PAGE(batch->nr > batch->max, page);
Still needed?
>
> - return batch->max - batch->nr;
> + batch->pages[batch->nr++] = page;
> + return false;
> }
>
> #endif /* HAVE_GENERIC_MMU_GATHER */
> @@ -1109,6 +1110,7 @@ static unsigned long zap_pte_range(struct mmu_gather
> *tlb,
> pte_t *start_pte;
> pte_t *pte;
> swp_entry_t entry;
> + struct page *pending_page = NULL;
>
> again:
> init_rss_vec(rss);
> @@ -1160,8 +1162,9 @@ again:
> page_remove_rmap(page, false);
> if (unlikely(page_mapcount(page) < 0))
> print_bad_pte(vma, addr, ptent, page);
> - if (unlikely(!__tlb_remove_page(tlb, page))) {
> + if (unlikely(__tlb_remove_page(tlb, page))) {
> force_flush = 1;
> + pending_page = page;
> addr += PAGE_SIZE;
> break;
> }
> @@ -1202,7 +1205,12 @@ again:
> if (force_flush) {
> force_flush = 0;
> tlb_flush_mmu_free(tlb);
> -
> + if (pending_page) {
> + /* remove the page with new size */
> + __tlb_adjust_range(tlb, tlb->addr);
Would you please specify why tlb->addr is used here?
thanks
Hillf
> + __tlb_remove_page(tlb, pending_page);
> + pending_page = NULL;
> + }
> if (addr != end)
> goto again;
> }
> --
> 2.7.4
Re: [PATCH 1/3] ARM: dts: sun5i: a10s: add spi2 pins
On Thu, May 26, 2016 at 07:25:22PM -, Michal Suchanek wrote: > Used on A10s Olinuxino. > > Signed-off-by: Michal Suchanek Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 2/3] ARM: dts: sun5i: add spi2 on A10s Olinuxino Micro
Hi,
On Thu, May 26, 2016 at 07:25:23PM -, Michal Suchanek wrote:
> spi2 is available on the UEXT connector
>
> Signed-off-by: Michal Suchanek
> ---
> arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> index 86d046a..7d2ff60 100644
> --- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
> @@ -192,6 +192,13 @@
> status = "okay";
> };
>
> +&spi2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi2_pins_a>,
> + <&spi2_cs0_pins_a>;
> + status = "okay";
> +};
> +
This should be ordered alphabetically.
Fixed it, and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume
On Fri, May 27, 2016 at 9:16 AM, Lv Zheng wrote:
> Linux userspace (systemd-logind) keeps on rechecking lid state when the
> lid state is closed. If it failed to update the lid state to open after
> boot/resume, the system suspending right after the boot/resume could be
> resulted.
> Graphics drivers also uses the lid notifications to implment
> MODESET_ON_LID_OPEN option.
>
> Before the situation is improved from the userspace and from the graphics
> driver, simply send initial "open" lid state to avoid issues. After this is
> improved from the userspace and from the graphics driver, Linux kernel
> could simply revert this minimal commit.
>
> Link 1: https://lkml.org/2016/3/7/460
> Link 2: https://github.com/systemd/systemd/issues/2087
> Signed-off-by: Lv Zheng
> Cc: Bastien Nocera:
> ---
> drivers/acpi/button.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index e706e4b..6e77312 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -342,6 +342,8 @@ static int acpi_button_resume(struct device *dev)
> struct acpi_button *button = acpi_driver_data(device);
>
> button->suspended = false;
> + if (button->type == ACPI_BUTTON_TYPE_LID)
> + return acpi_lid_notify_state(device, 1);
As Valdis replied on 0/3, I don't think this is a good solution (even
temporary). Linux should not assume the current state of a input
device, and sending unconditionally 1 here is wrong. If the device is
on a docking station, you will wake up the wrong monitor and screw the
user session (and this will be a regression).
How about we simply send the current LID state stored in the ACPI?
something like calling acpi_lid_send_state() directly?
[15 min later, after writing a long email]
Well, it looks like we already have that in the kernel and for a long
time apparently.
So, I think the issue is that Microsoft does not wake up the system by
lid opening (seen in one of the comments in the mentioned bugs and by
looking at the behavior on the surface devices). It must be just
querying it's state on resume or might even not care at all until it
receives a close event.
If I read correctly, we managed to get the 3 bogus devices to a
correct state at the ACPI level (/proc/acpi/button/lid/LID0/state),
but we did not get the notification. Given that the LID state is
triggered by an ACPI operation region, there is no guarantee that the
resume of the acpi/button.c driver will be called after the region has
been updated/called.
I propose as a workaround to enable a kthread that will monitor the
lid state and update the correct value to userspace (5 sec of polling
time should be enough given that systemd checks every 20 sec).
We should probably have this workaround only for a set of known
devices, as it might just be temporary for those until the actual
underlying problem is fixed (wrong DSDT in the Surface 3 case that
doesn't notify at all, issue in the EC for the Surface Pro 1 and the
Samsung N210).
Cheers,
Benjamin
> return 0;
> }
> #endif
> @@ -422,6 +424,7 @@ static int acpi_button_add(struct acpi_device *device)
> if (error)
> goto err_remove_fs;
> if (button->type == ACPI_BUTTON_TYPE_LID) {
> + (void)acpi_lid_notify_state(device, 1);
> /*
> * This assumes there's only one lid device, or if there are
> * more we only care about the last one...
> --
> 1.7.10
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] drm: Add helper for simple display pipeline
On Sun, May 29, 2016 at 05:38:39PM +0200, Noralf Trønnes wrote:
>
> Den 12.05.2016 20:25, skrev Noralf Trønnes:
> >Provides helper functions for drivers that have a simple display
> >pipeline. Plane, crtc and encoder are collapsed into one entity.
> >
> >Cc: jsa...@ti.com
> >Signed-off-by: Noralf Trønnes
> >---
>
> [...]
>
> >diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> >b/drivers/gpu/drm/drm_simple_kms_helper.c
> >new file mode 100644
> >index 000..d45417a
> >--- /dev/null
> >+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> >@@ -0,0 +1,208 @@
> >+/*
> >+ * Copyright (C) 2016 Noralf Trønnes
> >+ *
> >+ * This program is free software; you can redistribute it and/or modify
> >+ * it under the terms of the GNU General Public License as published by
> >+ * the Free Software Foundation; either version 2 of the License, or
> >+ * (at your option) any later version.
> >+ */
> >+
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+
> >+/**
> >+ * DOC: overview
> >+ *
> >+ * This helper library provides helpers for drivers for simple display
> >+ * hardware.
> >+ *
> >+ * drm_simple_display_pipe_init() initializes a simple display pipeline
> >+ * which has only one full-screen scanout buffer feeding one output. The
> >+ * pipeline is represented by struct &drm_simple_display_pipe and binds
> >+ * together &drm_plane, &drm_crtc and &drm_encoder structures into one fixed
> >+ * entity. Some flexibility for code reuse is provided through a separately
> >+ * allocated &drm_connector object and supporting optional &drm_bridge
> >+ * encoder drivers.
> >+ */
> >+
> >+static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> >+.destroy = drm_encoder_cleanup,
> >+};
> >+
> >+static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> >+{
> >+struct drm_simple_display_pipe *pipe;
> >+
> >+pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> >+if (!pipe->funcs || !pipe->funcs->enable)
> >+return;
> >+
> >+pipe->funcs->enable(pipe, crtc->state);
> >+}
> >+
> >+static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> >+{
> >+struct drm_simple_display_pipe *pipe;
> >+
> >+pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> >+if (!pipe->funcs || !pipe->funcs->disable)
> >+return;
> >+
> >+pipe->funcs->disable(pipe);
> >+}
> >+
> >+static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs
> >= {
> >+.disable = drm_simple_kms_crtc_disable,
> >+.enable = drm_simple_kms_crtc_enable,
> >+};
> >+
> >+static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
> >+.reset = drm_atomic_helper_crtc_reset,
> >+.destroy = drm_crtc_cleanup,
> >+.set_config = drm_atomic_helper_set_config,
> >+.page_flip = drm_atomic_helper_page_flip,
> >+.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> >+.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> >+};
> >+
> >+static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
> >+struct drm_plane_state *plane_state)
> >+{
> >+struct drm_rect src = {
> >+.x1 = plane_state->src_x,
> >+.y1 = plane_state->src_y,
> >+.x2 = plane_state->src_x + plane_state->src_w,
> >+.y2 = plane_state->src_y + plane_state->src_h,
> >+};
> >+struct drm_rect dest = {
> >+.x1 = plane_state->crtc_x,
> >+.y1 = plane_state->crtc_y,
> >+.x2 = plane_state->crtc_x + plane_state->crtc_w,
> >+.y2 = plane_state->crtc_y + plane_state->crtc_h,
> >+};
> >+struct drm_rect clip = { 0 };
> >+struct drm_simple_display_pipe *pipe;
> >+struct drm_crtc_state *crtc_state;
> >+bool visible;
> >+int ret;
> >+
> >+pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> >+crtc_state = drm_atomic_get_existing_crtc_state(plane_state->state,
> >+&pipe->crtc);
> >+if (crtc_state->enable != !!plane_state->crtc)
> >+return -EINVAL; /* plane must match crtc enable state */
> >+
> >+if (!crtc_state->enable)
> >+return 0; /* nothing to check when disabling or disabled */
> >+
> >+clip.x2 = crtc_state->adjusted_mode.hdisplay;
> >+clip.y2 = crtc_state->adjusted_mode.vdisplay;
> >+ret = drm_plane_helper_check_update(plane, &pipe->crtc,
> >+plane_state->fb,
> >+&src, &dest, &clip,
> >+DRM_PLANE_HELPER_NO_SCALING,
> >+DRM_PLANE_HELPER_NO_SCALING,
> >+false, true, &visible);
> >+if (ret)
> >+return ret;
> >+
> >+if (!visible)
> >+return -EINVAL;
> >+
> >+if (!pipe->funcs || !pipe->fu
Re: [PATCH 1/2] staging: slicoss: fix coding style spacing issues
On Sun, May 29, 2016 at 08:31:06AM -0500, Jaime Arrocha wrote:
> struct slic_cmdqueue {
> struct slic_hostcmd *head;
> struct slic_hostcmd *tail;
> - int count;
> - spinlock_t lock;
> + int count;
> + spinlock_t lock;
> };
The original code was better. Same for the rest.
regards,
dan carpenter
Re: [PATCH v9 7/7] MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers
Hi Baolu, On Mon, May 30, 2016 at 01:51:44PM +0800, Lu Baolu wrote: > Add a maintainer entry for Intel USB dual role mux drivers and > add myself as a maintainer. > > Signed-off-by: Lu Baolu > --- > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ed1229e..edaeebe 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5961,6 +5961,16 @@ S: Maintained > F: arch/x86/include/asm/intel_telemetry.h > F: drivers/platform/x86/intel_telemetry* > > +INTEL USB DUAL ROLE PORT MUX DRIVERS > +M: Lu Baolu > +L: linux-...@vger.kernel.org > +S: Supported > +F: include/linux/usb/portmux.h > +F: drivers/usb/mux/portmux-core.c > +F: drivers/usb/mux/portmux-intel-gpio.c > +F: drivers/usb/mux/portmux-intel-drcfg.c > +F: drivers/mfd/intel-vuport.c > + > IOC3 ETHERNET DRIVER > M: Ralf Baechle > L: linux-m...@linux-mips.org > -- > 2.1.4 This one does not apply on top of v4.7-rc1. Thanks, -- heikki
Re: [PATCH v3] Axi-usb: Add support for 64-bit addressing.
On Monday, May 30, 2016 5:46:21 AM CEST Nava kishore Manne wrote: > > > The Axi-usb 5.00 IP is a FPGA based one. This IP needs to support two H/w > designs one with 32 bit DMA addressing another one is 64 bit DMA addressing. > And also in the software point for view we don’t have any register to figure > out whether it is supporting 32 bit DMA addressing or 64 bit DMA addressing. > To support both the designs I kept addrwidth property in the dt. I think here > addrwidth property is make sense to differentiate the h/w configurations. > If you want me to changes it to boolean please let me know I will fix it in > the next version. I think boolean would be more logical here, since what is configurable here is not how many bits are supported, but whether the XUSB_DMA_DSAR_ADDR register is present or not. Arnd
Re: [lkp] [mm] 55834c5909: boot-slabinfo.num_objs +31.9% increasement
On Mon, May 30, 2016 at 09:53:25AM +0200, Dmitry Vyukov wrote:
>On Mon, May 30, 2016 at 4:17 AM, kernel test robot
> wrote:
>>
>> FYI, we noticed boot-slabinfo.num_objs +31.9% increasement due to commit:
>>
>> commit 55834c59098d0c5a97b0f3247e55832b67facdcf ("mm: kasan: initial memory
>> quarantine implementation")
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: boot
>> on test machine: vm-lkp-wsx03-2G: 2 threads qemu-system-x86_64 -enable-kvm
>> -cpu host with 2G memory
>> with following parameters: sleep=1
>>
>>
>> Details are as below:
>> -->
>>
>>
>> =
>> compiler/kconfig/rootfs/sleep/tbox_group/testcase:
>>
>> gcc-6/x86_64-randconfig-s4-05280557/debian-x86_64-2015-02-07.cgz/1/vm-lkp-wsx03-2G/boot
>>
>> commit:
>> b8f1a75d61d8405a753380c6fb17ba84a5603cd4
>> 55834c59098d0c5a97b0f3247e55832b67facdcf
>>
>> b8f1a75d61d8405a 55834c59098d0c5a97b0f3247e
>> --
>> %stddev %change %stddev
>> \ |\
>> 165450 ± 0% +31.9% 218176 ± 1% boot-slabinfo.num_objs
>> 19095 ± 5%+104.3% 39013 ± 3% boot-slabinfo.num_pages
>> 107.27 ± 2% +14.1% 122.43 ± 13% boot-time.boot
>> 97.13 ± 1% +4.3% 101.31 ± 1% boot-time.idle
>>1105076 ± 0% -7.2%1025056 ± 0% boot-meminfo.MemFree
>> 36269 ± 12%+215.7% 114517 ± 5% boot-meminfo.SUnreclaim
>> 76469 ± 5%+104.5% 156343 ± 4% boot-meminfo.Slab
>>
>>
>>
>>boot-slabinfo.num_objs
>>
>> 23 ++-+
>> |O O |
>> 22 ++O OO OO OO O O OO OO |
>> OO O O OOO O O OO O |
>> 21 ++ |
>> | |
>> 20 ++ |
>> | |
>> 19 ++ |
>> | |
>> 18 ++ |
>> | |
>> 17 ++ |
>>
>> 16 ++-+
>>
>>
>>boot-slabinfo.num_pages
>>
>> 45000 ++-O+
>> | O O OO O O O O OOO |
>> 4 +O OOO OOOO O O |
>> O OO O O O O O OOO O |
>> | O OO|
>> 35000 ++ |
>> | |
>> 3 ++ |
>> | |
>> 25000 ++ |
>> | |
>> | ***
>> 2 +* * * ** * * * * * * ** ** * * * * * * :: * *** *|
>> * * ** ** * * ** *** * ** *** * * * * * ** *** * ** ** ** * * |
>> 15000 ++--+
>>
>>
>> [*] bisect-good sample
>> [O] bisect-bad sample
>
>
>Hi Xiaolong,
>
>It is with CONFIG_KASAN=y? If yes, then increased memory usage is expected.
Hi, Dmitry
Yes, CONFIG_KASAN=y is set in config, see attached config file used for test.
# CONFIG_KMEMCHECK is not set
CONFIG_HAVE_ARCH_KASAN=y
CONFIG_KASAN=y
CONFIG_KASAN_OUTLINE=y
# CONFIG_KASAN_INLINE is not set
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.6.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG
[PATCH v5 5/7] ASoC: omap-mcbsp: Rename omap_mcbsp_sysfs_remove() to omap_mcbsp_cleanup()
The function will do more then removing the sysfs files in the future.
Signed-off-by: Peter Ujfalusi
Acked-by: Mark Brown
---
sound/soc/omap/mcbsp.c | 2 +-
sound/soc/omap/mcbsp.h | 2 +-
sound/soc/omap/omap-mcbsp.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index 4a16e778966b..ace73b97769f 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -1088,7 +1088,7 @@ err_thres:
return ret;
}
-void omap_mcbsp_sysfs_remove(struct omap_mcbsp *mcbsp)
+void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp)
{
if (mcbsp->pdata->buffer_size)
sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h
index 96d1b086bcf8..ce6cbbf923a4 100644
--- a/sound/soc/omap/mcbsp.h
+++ b/sound/soc/omap/mcbsp.h
@@ -349,6 +349,6 @@ int omap_st_disable(struct omap_mcbsp *mcbsp);
int omap_st_is_enabled(struct omap_mcbsp *mcbsp);
int omap_mcbsp_init(struct platform_device *pdev);
-void omap_mcbsp_sysfs_remove(struct omap_mcbsp *mcbsp);
+void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp);
#endif /* __ASOC_MCBSP_H */
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index fd99d89de6a8..db07debb4a9c 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -832,7 +832,7 @@ static int asoc_mcbsp_remove(struct platform_device *pdev)
if (mcbsp->pdata->ops && mcbsp->pdata->ops->free)
mcbsp->pdata->ops->free(mcbsp->id);
- omap_mcbsp_sysfs_remove(mcbsp);
+ omap_mcbsp_cleanup(mcbsp);
clk_put(mcbsp->fclk);
--
2.8.3
[PATCH v5 1/7] ARM: dts: omap3: Add clocks to McBSP nodes
Add clock properties to the McBSP nodes. McBSP2 and 3 need to have ick also since the Sidetone block of these modules are operating using the McBSP interface clock. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/omap3.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 9fbda38528dc..4c3c471d2a83 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -493,6 +493,8 @@ dmas = <&sdma 31>, <&sdma 32>; dma-names = "tx", "rx"; + clocks = <&mcbsp1_fck>; + clock-names = "fck"; status = "disabled"; }; @@ -511,6 +513,8 @@ dmas = <&sdma 33>, <&sdma 34>; dma-names = "tx", "rx"; + clocks = <&mcbsp2_fck>, <&mcbsp2_ick>; + clock-names = "fck", "ick"; status = "disabled"; }; @@ -529,6 +533,8 @@ dmas = <&sdma 17>, <&sdma 18>; dma-names = "tx", "rx"; + clocks = <&mcbsp3_fck>, <&mcbsp3_ick>; + clock-names = "fck", "ick"; status = "disabled"; }; @@ -545,6 +551,8 @@ dmas = <&sdma 19>, <&sdma 20>; dma-names = "tx", "rx"; + clocks = <&mcbsp4_fck>; + clock-names = "fck"; status = "disabled"; }; @@ -561,6 +569,8 @@ dmas = <&sdma 21>, <&sdma 22>; dma-names = "tx", "rx"; + clocks = <&mcbsp5_fck>; + clock-names = "fck"; status = "disabled"; }; -- 2.8.3
[PATCH v5 6/7] ASoC: omap-mcbsp: sidetone: Use the new callback for iclk handling
The McBSP sidetone (in OMAP3 McBSP2 and 3 module) is working with the
module's interface clock. When the sidetone is enabled the iclk must not
idle because it will result in choppy sidetone.
Switch to use the new callback for handling the iclk allow/deny idle
configuration.
For this the driver needs to get the module's ick clock and pass the clk
pointer to the callback.
In DT boot, the pdata-quirk is going to set up the callback for the driver
so save it if it is set in the pdata of the device.
Signed-off-by: Peter Ujfalusi
Acked-by: Mark Brown
---
sound/soc/omap/mcbsp.c | 19 ++-
sound/soc/omap/mcbsp.h | 1 +
sound/soc/omap/omap-mcbsp.c | 3 +++
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index ace73b97769f..76ce33199bf9 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -257,8 +257,8 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
{
unsigned int w;
- if (mcbsp->pdata->enable_st_clock)
- mcbsp->pdata->enable_st_clock(mcbsp->id, 1);
+ if (mcbsp->pdata->force_ick_on)
+ mcbsp->pdata->force_ick_on(mcbsp->st_data->mcbsp_iclk, true);
/* Disable Sidetone clock auto-gating for normal operation */
w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
@@ -287,8 +287,8 @@ static void omap_st_off(struct omap_mcbsp *mcbsp)
w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w | ST_AUTOIDLE);
- if (mcbsp->pdata->enable_st_clock)
- mcbsp->pdata->enable_st_clock(mcbsp->id, 0);
+ if (mcbsp->pdata->force_ick_on)
+ mcbsp->pdata->force_ick_on(mcbsp->st_data->mcbsp_iclk, false);
}
static void omap_st_fir_write(struct omap_mcbsp *mcbsp, s16 *fir)
@@ -946,6 +946,13 @@ static int omap_st_add(struct omap_mcbsp *mcbsp, struct
resource *res)
if (!st_data)
return -ENOMEM;
+ st_data->mcbsp_iclk = clk_get(mcbsp->dev, "ick");
+ if (IS_ERR(st_data->mcbsp_iclk)) {
+ dev_warn(mcbsp->dev,
+"Failed to get ick, sidetone might be broken\n");
+ st_data->mcbsp_iclk = NULL;
+ }
+
st_data->io_base_st = devm_ioremap(mcbsp->dev, res->start,
resource_size(res));
if (!st_data->io_base_st)
@@ -1093,6 +1100,8 @@ void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp)
if (mcbsp->pdata->buffer_size)
sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
- if (mcbsp->st_data)
+ if (mcbsp->st_data) {
sysfs_remove_group(&mcbsp->dev->kobj, &sidetone_attr_group);
+ clk_put(mcbsp->st_data->mcbsp_iclk);
+ }
}
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h
index ce6cbbf923a4..61e93b1c185d 100644
--- a/sound/soc/omap/mcbsp.h
+++ b/sound/soc/omap/mcbsp.h
@@ -280,6 +280,7 @@ struct omap_mcbsp_reg_cfg {
struct omap_mcbsp_st_data {
void __iomem *io_base_st;
+ struct clk *mcbsp_iclk;
bool running;
bool enabled;
s16 taps[128]; /* Sidetone filter coefficients */
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index db07debb4a9c..d018e966e533 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -788,6 +788,7 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
match = of_match_device(omap_mcbsp_of_match, &pdev->dev);
if (match) {
struct device_node *node = pdev->dev.of_node;
+ struct omap_mcbsp_platform_data *pdata_quirk = pdata;
int buffer_size;
pdata = devm_kzalloc(&pdev->dev,
@@ -799,6 +800,8 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
memcpy(pdata, match->data, sizeof(*pdata));
if (!of_property_read_u32(node, "ti,buffer-size", &buffer_size))
pdata->buffer_size = buffer_size;
+ if (pdata_quirk)
+ pdata->force_ick_on = pdata_quirk->force_ick_on;
} else if (!pdata) {
dev_err(&pdev->dev, "missing platform data.\n");
return -EINVAL;
--
2.8.3
[PATCH v5 2/7] ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data
The McBSPLP's sidetone main clock is the McBSPLP's ICLK, not FCLK as the
sidetone only receives the ICLK from the main McBSP module.
Since the McBSP and sidetone is using the very same clock from PRCM level
the sidetone must not have the prcm section to check the clock status since
the sidetone is only used when McBSP is already configured.
If two separate hwmods looking at the same bit and they would use
pm_runtime in nested way (as it must happen with McBSP and it's ST module)
the hwmod would warn, because the idlest will not match what it is expected
after enable/disable of the clocks.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 9869a75c5d96..d72ee6185d5e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1322,16 +1322,8 @@ static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod
= {
.name = "mcbsp2_sidetone",
.class = &omap3xxx_mcbsp_sidetone_hwmod_class,
.mpu_irqs = omap3xxx_mcbsp2_sidetone_irqs,
- .main_clk = "mcbsp2_fck",
- .prcm = {
- .omap2 = {
- .prcm_reg_id = 1,
-.module_bit = OMAP3430_EN_MCBSP2_SHIFT,
- .module_offs = OMAP3430_PER_MOD,
- .idlest_reg_id = 1,
- .idlest_idle_bit = OMAP3430_ST_MCBSP2_SHIFT,
- },
- },
+ .main_clk = "mcbsp2_ick",
+ .flags = HWMOD_NO_IDLEST,
};
/* mcbsp3_sidetone */
@@ -1344,16 +1336,8 @@ static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod
= {
.name = "mcbsp3_sidetone",
.class = &omap3xxx_mcbsp_sidetone_hwmod_class,
.mpu_irqs = omap3xxx_mcbsp3_sidetone_irqs,
- .main_clk = "mcbsp3_fck",
- .prcm = {
- .omap2 = {
- .prcm_reg_id = 1,
- .module_bit = OMAP3430_EN_MCBSP3_SHIFT,
- .module_offs = OMAP3430_PER_MOD,
- .idlest_reg_id = 1,
- .idlest_idle_bit = OMAP3430_ST_MCBSP3_SHIFT,
- },
- },
+ .main_clk = "mcbsp3_ick",
+ .flags = HWMOD_NO_IDLEST,
};
/* SR common */
--
2.8.3
[PATCH v5 4/7] ARM: OMAP3: pdata-quirks: Add support for McBSP2/3 sidetone handling
McBSP2/3 module's sidetone module operates using the module's ICLK clock.
When the Sidetone is in use the interface clock of the module must not
idle. To prevent the iclk idling the driver expects to have pdata callback
to call. With this patch the callback is going to be set up for DT boot
also.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c | 9 +
arch/arm/mach-omap2/pdata-quirks.c | 18 ++
include/linux/platform_data/asoc-ti-mcbsp.h | 2 ++
3 files changed, 29 insertions(+)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 959cb4cb1062..edf4f41c0135 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -59,6 +59,15 @@ static int omap3_mcbsp_force_ick_on(struct clk *clk, bool
force_on)
return omap2_clk_allow_idle(clk);
}
+void __init omap3_mcbsp_init_pdata_callback(
+ struct omap_mcbsp_platform_data *pdata)
+{
+ if (!pdata)
+ return;
+
+ pdata->force_ick_on = omap3_mcbsp_force_ick_on;
+}
+
static int __init omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
{
int id, count = 1;
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 6571ad959908..ab2b2b2b90e5 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include "common.h"
@@ -505,6 +506,16 @@ static struct platform_device __maybe_unused
rx51_lirc_device = {
},
};
+#if IS_ENABLED(CONFIG_SND_OMAP_SOC_MCBSP)
+static struct omap_mcbsp_platform_data mcbsp_pdata;
+static void __init omap3_mcbsp_init(void)
+{
+ omap3_mcbsp_init_pdata_callback(&mcbsp_pdata);
+}
+#else
+static void __init omap3_mcbsp_init(void) {}
+#endif
+
/*
* Few boards still need auxdata populated before we populate
* the dev entries in of_platform_populate().
@@ -536,6 +547,11 @@ static struct of_dev_auxdata omap_auxdata_lookup[]
__initdata = {
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
&am35xx_emac_pdata),
+ /* McBSP modules with sidetone core */
+#if IS_ENABLED(CONFIG_SND_OMAP_SOC_MCBSP)
+ OF_DEV_AUXDATA("ti,omap3-mcbsp", 0x49022000, "49022000.mcbsp",
&mcbsp_pdata),
+ OF_DEV_AUXDATA("ti,omap3-mcbsp", 0x49024000, "49024000.mcbsp",
&mcbsp_pdata),
+#endif
#endif
#ifdef CONFIG_SOC_AM33XX
OF_DEV_AUXDATA("ti,am3352-wkup-m3", 0x44d0, "44d0.wkup_m3",
@@ -608,6 +624,8 @@ void __init pdata_quirks_init(const struct of_device_id
*omap_dt_match_table)
of_machine_is_compatible("ti,omap3"))
omap_sdrc_init(NULL, NULL);
+ if (of_machine_is_compatible("ti,omap3"))
+ omap3_mcbsp_init();
pdata_quirks_check(auxdata_quirks);
of_platform_populate(NULL, omap_dt_match_table,
omap_auxdata_lookup, NULL);
diff --git a/include/linux/platform_data/asoc-ti-mcbsp.h
b/include/linux/platform_data/asoc-ti-mcbsp.h
index 73e5e832fa23..5530971abf4d 100644
--- a/include/linux/platform_data/asoc-ti-mcbsp.h
+++ b/include/linux/platform_data/asoc-ti-mcbsp.h
@@ -56,4 +56,6 @@ struct omap_mcbsp_dev_attr {
const char *sidetone;
};
+void omap3_mcbsp_init_pdata_callback(struct omap_mcbsp_platform_data *pdata);
+
#endif
--
2.8.3
[PATCH v5 7/7] ARM: OMAP2+: McBSP: Remove the old iclk allow/deny idle code
The new pdata callback (force_ick_on) is now used by the driver and the old
callback related code can be removed.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c | 18 --
include/linux/platform_data/asoc-ti-mcbsp.h | 1 -
2 files changed, 19 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index edf4f41c0135..fc04be74e064 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -34,20 +34,6 @@
#include "cm3xxx.h"
#include "cm-regbits-34xx.h"
-static struct clk *mcbsp_iclks[5];
-
-static int omap3_enable_st_clock(unsigned int id, bool enable)
-{
- /*
-* Sidetone uses McBSP ICLK - which must not idle when sidetones
-* are enabled or sidetones start sounding ugly.
-*/
- if (enable)
- return omap2_clk_deny_idle(mcbsp_iclks[id]);
- else
- return omap2_clk_allow_idle(mcbsp_iclks[id]);
-}
-
static int omap3_mcbsp_force_ick_on(struct clk *clk, bool force_on)
{
if (!clk)
@@ -75,7 +61,6 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
struct omap_hwmod *oh_device[2];
struct omap_mcbsp_platform_data *pdata = NULL;
struct platform_device *pdev;
- char clk_name[11];
sscanf(oh->name, "mcbsp%d", &id);
@@ -116,10 +101,7 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
if (oh->dev_attr) {
oh_device[1] = omap_hwmod_lookup((
(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
- pdata->enable_st_clock = omap3_enable_st_clock;
pdata->force_ick_on = omap3_mcbsp_force_ick_on;
- sprintf(clk_name, "mcbsp%d_ick", id);
- mcbsp_iclks[id] = clk_get(NULL, clk_name);
count++;
}
pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
diff --git a/include/linux/platform_data/asoc-ti-mcbsp.h
b/include/linux/platform_data/asoc-ti-mcbsp.h
index 5530971abf4d..e684543254f3 100644
--- a/include/linux/platform_data/asoc-ti-mcbsp.h
+++ b/include/linux/platform_data/asoc-ti-mcbsp.h
@@ -44,7 +44,6 @@ struct omap_mcbsp_platform_data {
/* McBSP platform and instance specific features */
bool has_wakeup; /* Wakeup capability */
bool has_ccr; /* Transceiver has configuration control registers */
- int (*enable_st_clock)(unsigned int, bool);
int (*force_ick_on)(struct clk *clk, bool force_on);
};
--
2.8.3
[PATCH v5 3/7] ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration
McBSP2/3 module's sidetone module operates using the module's ICLK clock.
When the Sidetone is in use the interface clock of the module must not
idle. The new callback expects to receive the *clk of the module's ick and
not the id number of the McBSP. This will allow us more cleanups and going
to simplify the ICLK handling.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/mcbsp.c | 12
include/linux/platform_data/asoc-ti-mcbsp.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index b4ac3af1160c..959cb4cb1062 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -48,6 +48,17 @@ static int omap3_enable_st_clock(unsigned int id, bool
enable)
return omap2_clk_allow_idle(mcbsp_iclks[id]);
}
+static int omap3_mcbsp_force_ick_on(struct clk *clk, bool force_on)
+{
+ if (!clk)
+ return 0;
+
+ if (force_on)
+ return omap2_clk_deny_idle(clk);
+ else
+ return omap2_clk_allow_idle(clk);
+}
+
static int __init omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
{
int id, count = 1;
@@ -97,6 +108,7 @@ static int __init omap_init_mcbsp(struct omap_hwmod *oh,
void *unused)
oh_device[1] = omap_hwmod_lookup((
(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
pdata->enable_st_clock = omap3_enable_st_clock;
+ pdata->force_ick_on = omap3_mcbsp_force_ick_on;
sprintf(clk_name, "mcbsp%d_ick", id);
mcbsp_iclks[id] = clk_get(NULL, clk_name);
count++;
diff --git a/include/linux/platform_data/asoc-ti-mcbsp.h
b/include/linux/platform_data/asoc-ti-mcbsp.h
index 3c73c045f8da..73e5e832fa23 100644
--- a/include/linux/platform_data/asoc-ti-mcbsp.h
+++ b/include/linux/platform_data/asoc-ti-mcbsp.h
@@ -45,6 +45,7 @@ struct omap_mcbsp_platform_data {
bool has_wakeup; /* Wakeup capability */
bool has_ccr; /* Transceiver has configuration control registers */
int (*enable_st_clock)(unsigned int, bool);
+ int (*force_ick_on)(struct clk *clk, bool force_on);
};
/**
--
2.8.3
Re: [v2 PATCH] arm64: kasan: instrument user memory access API
On 05/28/2016 12:01 AM, Yang Shi wrote:
> The upstream commit 1771c6e1a567ea0ba20a4ffe68a1419fd8ef
> ("x86/kasan: instrument user memory access API") added KASAN instrument to
> x86 user memory access API, so added such instrument to ARM64 too.
>
> Define __copy_to/from_user in C in order to add kasan_check_read/write call,
> rename assembly implementation to __arch_copy_to/from_user.
>
> Tested by test_kasan module.
>
> Signed-off-by: Yang Shi
>
Acked-by: Andrey Ryabinin
Re: [RFC PATCH 3/4] mm/mmu_gather: Track page size with mmu gather and force flush if page size change
> diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
> index 2ac8fe202e9a..3ca36c111b47 100644
> --- a/include/asm-generic/tlb.h
> +++ b/include/asm-generic/tlb.h
> @@ -112,6 +112,7 @@ struct mmu_gather {
>* that that we can adjust the range after the flush
>*/
> unsigned long addr;
> + int page_size;
Add a comment for it please.
Hillf
> };
Re: [patch v2 net-next 12/13] net: hns: implement the miscellaneous operation by asl
On Mon, 2016-05-30 at 10:10 +0800, Kejian Yan wrote:
> The miscellaneous operation is implemented in BIOS, the kernel can
> call
> _DSM method help to call the implementation in ACPI case. Here is a
> patch
> to do that.
>
> +static phy_interface_t hns_mac_get_phy_if_acpi(struct hns_mac_cb
> *mac_cb)
> +{
> + phy_interface_t phy_if = PHY_INTERFACE_MODE_NA;
> + union acpi_object *obj;
> + union acpi_object obj_args, argv4;
> +
> + obj_args.integer.type = ACPI_TYPE_INTEGER;
> + obj_args.integer.value = mac_cb->mac_id;
> +
> + argv4.type = ACPI_TYPE_PACKAGE,
> + argv4.package.count = 1,
> + argv4.package.elements = &obj_args,
> +
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(mac_cb->dev),
> + hns_dsaf_acpi_dsm_uuid, 0,
> + HNS_OP_GET_PORT_TYPE_FUNC, &argv4);
> +
> + if (!obj || obj->type != ACPI_TYPE_INTEGER)
Seems you have potential memory leak here
if (!obj)
return phy_if;
if (obj->...)
goto exit_free;
> + return phy_if;
> +
> + phy_if = obj->integer.value ?
> + PHY_INTERFACE_MODE_XGMII : PHY_INTERFACE_MODE_SGMII;
> +
> + dev_dbg(mac_cb->dev, "mac_id=%d, phy_if=%d\n", mac_cb-
> >mac_id, phy_if);
> +
+ exit_free:
> + ACPI_FREE(obj);
> +
> + return phy_if;
> +}
>
--
Andy Shevchenko
Intel Finland Oy
[PATCH v5 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support
Hi, Changes since v4: - Moved DTS patch as the first in the series - rebased on top of 4.7-rc1 Changes since v3: - Rebased on next-20160525 [1] to apply cleanly - Fixed subject line for patch5 - Added Mark's acked-by to the ASoC patches [1] "ASoC: omap-mcbsp: Enable/disable sidetone block auto clock gating for omap3" is gone missing from linux-next - it was in next-20160517 and I'm not sure when it got dropped. Tony: since Paul did not replied to the series, I'm sending the v4 now, I hope he will have time to look at this. Commit message from v3: Based on the ongoing discussion on v2 (ARM: OMAP3: Fix McBSP2/3 hwmod setup for sidetone) I have dropped the removal of the sidetone hwmod and only corrected it. The series now includes all related changes needed to have correct sidetone support whenever we boot in legacy or in DT mode. This time the ASoC part have dependency on earlier patches so they can not be applied separately. Regards, Peter --- Peter Ujfalusi (7): ARM: dts: omap3: Add clocks to McBSP nodes ARM: OMAP3: hwmod data: Fix McBSP2/3 sidetone data ARM: OMAP3: McBSP: New callback for McBSP2/3 ICLK idle configuration ARM: OMAP3: pdata-quirks: Add support for McBSP2/3 sidetone handling ASoC: omap-mcbsp: Rename omap_mcbsp_sysfs_remove() to omap_mcbsp_cleanup() ASoC: omap-mcbsp: sidetone: Use the new callback for iclk handling ARM: OMAP2+: McBSP: Remove the old iclk allow/deny idle code arch/arm/boot/dts/omap3.dtsi| 10 ++ arch/arm/mach-omap2/mcbsp.c | 31 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 24 -- arch/arm/mach-omap2/pdata-quirks.c | 18 + include/linux/platform_data/asoc-ti-mcbsp.h | 4 +++- sound/soc/omap/mcbsp.c | 21 +-- sound/soc/omap/mcbsp.h | 3 ++- sound/soc/omap/omap-mcbsp.c | 5 - 8 files changed, 73 insertions(+), 43 deletions(-) -- 2.8.3
Re: [patch v2 net-next 00/13] net: hns: add support of ACPI
On Mon, 2016-05-30 at 10:10 +0800, Kejian Yan wrote:
> This series adds HNS support of acpi. The routine will call some ACPI
> helper functions, like acpi_dev_found() and acpi_evaluate_dsm(), which
> are not included in other cases. In order to make system compile
> successfully in other cases except ACPI, it needs to add relative stub
> functions to linux/acpi.h. And we use device property functions
> instead
> of serial helper functions to suport both DT and ACPI cases. And then
> add the supports of ACPI for HNS.
Looks better. I have only kinda bikeshedding comments in mind, which I
didn't put here, though there is one you perhaps need to address.
Otherwise FWIW:
Reviewed-by: Andy Shevchenko
>
> change log:
> v1 -> v2:
> 1. use acpi_dev_found() instead of acpi_match_device_ids() to check
> if
> it is a acpi node.
> 2. use is_of_node() instead of IS_ENABLED() to check if it is a DT
> node.
> 3. split the patch("add support of acpi for hns-mdio") into two
> patches:
> 3.1 Move to use fwnode_handle
> 3.2 Add ACPI
> 4. add the patch which subject is dsaf misc operation method
> 5. fix the comments by Andy Shevchenko
>
> Kejian Yan (13):
> ACPI: bus: add stub acpi_dev_found() to linux/acpi.h
> ACPI: bus: add stub acpi_evaluate_dsm() to linux/acpi.h
> net: hisilicon: cleanup to prepare for other cases
> net: hisilicon: add support of acpi for hns-mdio
> net: hns: use device_* APIs instead of of_* APIs
> net: hns: use platform_get_irq instead of irq_of_parse_and_map
> net: hns: enet specify a reference to dsaf by fwnode_handle
> net: hns: add uniform interface for phy connection
> net: hns: add dsaf misc operation method
> net: hns: dsaf adds support of acpi
> net: hns: register phy device in each mac initial sequence
> net: hns: implement the miscellaneous operation by asl
> net: hns: net: hns: enet adds support of acpi
>
> drivers/net/ethernet/hisilicon/hns/hnae.c | 18 +-
> drivers/net/ethernet/hisilicon/hns/hnae.h | 5 +-
> drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 6 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 6 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 247
> +++-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.h | 4 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 105 ++---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 33 ++-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 250
> ++---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.h | 7 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 15 +-
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 5 +-
> .../net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c| 10 +-
> drivers/net/ethernet/hisilicon/hns/hns_enet.c | 90 +---
> drivers/net/ethernet/hisilicon/hns/hns_enet.h | 2 +-
> drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 2 +-
> drivers/net/ethernet/hisilicon/hns_mdio.c | 147 +++-
> include/linux/acpi.h | 13 ++
> 18 files changed, 710 insertions(+), 255 deletions(-)
>
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH 3/3] ARM: dts: sun5i: Add spi2 alias on A10s Olinuxino
On Thu, May 26, 2016 at 07:25:24PM -, Michal Suchanek wrote: > spi2 is available on the UEXT connector > > The bus is named spi2 in the A10s manual and Olinuxino manual so it is > pointless to alias it to something else like spi0. That's not how aliases work in the DT. It's about indexing the devices that are enabled on the board, so it should definitely be 0, especially since it's the only SPI bus usable on that board anyway. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [RFC PATCH 0/2] scpi: Add SCPI framework to handle vendors variants
On 05/27/2016 10:17 AM, Neil Armstrong wrote: > Hi, > On 05/26/2016 06:29 PM, Sudeep Holla wrote: >> Hi Neil, >> >> On 26/05/16 10:38, Neil Armstrong wrote: >>> Since the current SCPI implementation, based on [0]: >>> - is (at leat) JUNO specific >> >> Agreed. >> >>> - does not specify a strong "standard" >> >> Not exactly, it's extensible. Refer section 3.2.2. Get SCP capability >> Extended Set Enabled bit. > > Well, I was not thinking about an extension, but this should be upstreamed > for sure. > >> >>> - does not specify a strong MHU interface specification >>> >> >> Not really required, any mailbox must do. >> >>> SoC vendors could implement a variant with slight changes in message >>> indexes, >> >> I assume you mean command index here >> >>> new messages types, >> >> Also fine with extended command set. >> >>> different messages data format or >> >> you mean the header or payload ? If they don't follow the header, then >> how can be group them as same protocol ? >> >>> different MHU communication scheme. >> >> Not a problem as I mentioned above. >> >>> >>> To keep the spirit of the SCPI interface, add a thin "register" layer to get >>> the ops from the parent node and switch the drivers using the ops to use >>> the new of_scpi_ops_get() call. >>> >> >> All I can see is that you share the code to register such drivers which >> is hardly anything. It's hard to say all drivers use same protocol or >> interface after this change. I may be missing to see something here so >> it would be easy to appreciate/review this change with one user of this. > > I'm actually working on an "SCPI" implementation from Amlogic for their arm64 > plaform, > and their implementation is slightly different but enough to need a separate > driver. > > For instance, the differences are : > - they do not implement virtual channels > - they pass the command word by the mailbox interface > - they use the "sender id" to group the command in a sort of "class" > - the payload size is shifted by 20 instead of 16 > - the command word is not in the SRAM, so we cannot use a rx command queue, > only a single command by channel at a single time > - the command indexes are slightly shifted > - in clk_set_value, "rate" is first instead of last entry > - in sensor_value, they only use a 32bit entry > - some commands are only accepted on the high priority channel, the others > only on the low priority > - MAX_DVFS_DOMAINS is 3 instead of 8 > - MAX_DVFS_OPPS is 16 instead of 8 > > But, It's still a "SCPI" interface by design and usage because : > - they implement 90% of the same commands, in the same way > - the usage is exactly the same and architecture is similar > - they use the same error code scheme > > Finally, it would be stupid to add an exact copy of the scpi-sensors and > scpi-clocks ! > The scpi-cpufreq is another story since they only have a single A53 cluster, > it's not adapted. > > This is why I wrote a very thin layer, and it can also clean up the arm_scpi > and the scpi driver to use a cleaner registry interface. > It would also be a good point to add a private_data to the ops and pass it to > the scpi callbacks, to completely remove the global variables. > > I found an issue with scpi-cpufreq, since the device is created by the > scpi-clocks probe, it does not have a proper node and my current > of_scpi_ops_get won't work... > The scpi-cpufreq should have a proper DT node and use the deffered probe to > register after the scpi-clocks. > >> >> My idea of extending this driver if vendor implements extensions based >> on SCPI specification is something like below: >> While looking for other ARMv8 based platform, I found that the RK3368 platform has the same SCPI implementation as Amlogic. They extended it with DDR, system and thermal commands. Look at : https://github.com/geekboxzone/mmallow_kernel/blob/geekbox/drivers/mailbox/scpi_cmd.h https://github.com/geekboxzone/mmallow_kernel/blob/geekbox/drivers/mailbox/scpi_protocol.c So the SCPI must have a framework to allow different protocol versions, and must allow command extension. Grouping Rockchip and Amlogic should be done, thus needing a generic name like vendor_scpi or with a version. Sudeep, could you somehow find out which version of the protocol AmLogic and Rockchip based their SCPI development ? Thanks ! Neil > Neil >
Re: [PATCH 2/5] spi: sun4i: fix FIFO limit
Hi, On Thu, May 26, 2016 at 07:25:24PM -, Michal Suchanek wrote: > When testing SPI without DMA I noticed that filling the FIFO on the > spi controller causes timeout. > > Always leave room for one byte in the FIFO. > > Signed-off-by: Michal Suchanek Sending it to stable would be great (with a fixes tag too). > > --- > v2: > use EMSGSIZE instead of EINVAL > --- > drivers/spi/spi-sun4i.c | 8 ++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c > index fe63bbd..04f1b77 100644 > --- a/drivers/spi/spi-sun4i.c > +++ b/drivers/spi/spi-sun4i.c > @@ -180,7 +180,9 @@ static int sun4i_spi_transfer_one(struct spi_master > *master, > > /* We don't support transfer larger than the FIFO */ > if (tfr->len > SUN4I_FIFO_DEPTH) > - return -EINVAL; > + return -EMSGSIZE; One new line here. > + if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH) > + return -EMSGSIZE; > > reinit_completion(&sspi->done); > sspi->tx_buf = tfr->tx_buf; > @@ -271,7 +273,9 @@ static int sun4i_spi_transfer_one(struct spi_master > *master, > sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len)); > > /* Fill the TX FIFO */ > - sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH); > + /* Filling the FIFO fully causes timeout for some reason > + * at least on spi2 on A10s */ This is not the proper comment style and generate a warning with checkpatch, please fix that (and merge the comment with the previous comment). Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3] gpu: drm: amd: amdkfd: Remove create_workqueue()
On Sun, May 29, 2016 at 6:44 PM, Bhaktipriya Shridhar
wrote:
> alloc_workqueue replaces deprecated create_workqueue().
>
> create_workqueue has been replaced with alloc_workqueue with max_active
> as 0 since there is no need for throttling the number of active work items.
>
> WQ_MEM_RECLAIM has not been set to because kfd_process_wq will not be
> used in memory reclaim path.
>
> kfd_process_wq is used for delay destruction. A work item embedded in
> kfd_process gets queued to kfd_process_wq and when it executes it
> destroys and frees the containing kfd_process and thus itself.
>
> This requires a dedicated workqueue because a work item once queued, may
> get freed at any point of time and any external entity cannot
> flush the work item. So, in order to wait for such a work item,
> it needs to be put on a dedicated workqueue.
>
> kfd_module_exit() calls kfd_process_destroy_wq which ensures that all
> pending work items are finished before the module is removed.
>
> flush_workqueue is unnecessary since destroy_workqueue() itself calls
> drain_workqueue() which flushes repeatedly till the workqueue
> becomes empty.
>
> Hence flush_workqueue has been removed.
>
> Signed-off-by: Bhaktipriya Shridhar
> ---
> Changes in v3:
> - Corrected space between arguments.
>
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index ac00579..6482fee 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -63,13 +63,12 @@ static struct kfd_process *create_process(const struct
> task_struct *thread);
> void kfd_process_create_wq(void)
> {
> if (!kfd_process_wq)
> - kfd_process_wq = create_workqueue("kfd_process_wq");
> + kfd_process_wq = alloc_workqueue("kfd_process_wq", 0, 0);
> }
>
> void kfd_process_destroy_wq(void)
> {
> if (kfd_process_wq) {
> - flush_workqueue(kfd_process_wq);
> destroy_workqueue(kfd_process_wq);
> kfd_process_wq = NULL;
> }
> --
> 2.1.4
>
Thanks!
I'll apply it to my -next tree.
Oded
Re: [PATCH 3/5] spi: sunxi: expose maximum transfer size limit
On Thu, May 26, 2016 at 07:25:24PM -, Michal Suchanek wrote: > The sun4i spi hardware can trasfer at most 63 bytes of data without DMA > support so report the limitation. Same on sun6i. Is it? Is there timeouts on the A31 and later SoCs? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3 7/7] [wip] virtio-gpu: add page flip support
On Fri, May 27, 2016 at 09:50:27AM +0200, Daniel Vetter wrote: > On Fri, May 27, 2016 at 09:46:03AM +0200, Gerd Hoffmann wrote: > > On Mi, 2016-05-25 at 18:37 +0200, Daniel Vetter wrote: > > > On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote: > > > > Signed-off-by: Gerd Hoffmann > > > > > > So I entirely missed this, but this isn't really how to implement > > > page_flip for an atomic driver. Working on some stuff and will hack up > > > a likely totally broken patch, but should be enough as guideline. > > > -Daniel > > > > Hmm, no patch in my inbox yet. Care to send it over or give some hints > > what is wrong with this? > > You should use drm_atomic_helper_page_flip as .page_flip hook instead of > rolling your own, when you have a brand-new atomic driver. If that helper > doesn't work that means you have a bug in your driver somewhere. > > And indeed virtio just plugs in drm_atomic_helper_commit, which thus far > doesnt' do nonblocking commits, which means the page flip stuff won't > work. I'm working on generic nonblocking atomic to fix this up. Currently > still wip and buggy though, hence no patches. > > But I'll take you up on the implied offer to help out and test ;-) Ok, patches are now on the list and also in my fdo repo at: https://cgit.freedesktop.org/~danvet/drm/log/ git://people.freedesktop.org/~danvet/drm stuff Would be really awesome if you could test this on virtio. Note that the new nonblocking helpers require that your atomic backend gets the drm event handling right. So if there's a bug in that logic then you'll see lots of dmesg noise about waits timing out (after 10s of waiting). From a quick inspection it should work though. Upshot is that once you get normal modeset to work with those new helpers, then nonblocking should Just Work, and there's no need anymore for additional testing. Or at least shouldn't. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH RESEND 0/3] Support Mediatek Soc MT2701 disp pwm
Sorry for sending many times, because of company permission settings, many people and groups can't receive these patches before. These series patches modify pwm-mtk-disp.c and dts/dtsi config to support MT2701 disp pwm. Weiqing Kong (3): dt-bindings: pwm: Add MediaTek display PWM bindings pwm: Add MediaTek MT2701 display PWM driver support dts: Add disp bls dsti and dts config for MT2701 .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 5 +- arch/arm/boot/dts/mt2701-evb.dts | 29 +++ arch/arm/boot/dts/mt2701.dtsi | 9 +++ drivers/pwm/pwm-mtk-disp.c | 89 +- 4 files changed, 113 insertions(+), 19 deletions(-) -- 1.8.1.1.dirty
[PATCH 2/3] pwm: Add MediaTek MT2701 display PWM driver support
Use the mtk_pwm_data struction to define different registers
and add MT2701 specific register operations, such as MT2701
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select manual mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Weiqing Kong
---
drivers/pwm/pwm-mtk-disp.c | 89 +-
1 file changed, 72 insertions(+), 17 deletions(-)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 0ad3385..03b9c9e 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -18,33 +18,44 @@
#include
#include
#include
+#include
#include
#include
#include
#define DISP_PWM_EN0x00
-#define PWM_ENABLE_MASKBIT(0)
#define DISP_PWM_COMMIT0x08
#define PWM_COMMIT_MASKBIT(0)
-#define DISP_PWM_CON_0 0x10
#define PWM_CLKDIV_SHIFT 16
#define PWM_CLKDIV_MAX 0x3ff
#define PWM_CLKDIV_MASK(PWM_CLKDIV_MAX << PWM_CLKDIV_SHIFT)
-#define DISP_PWM_CON_1 0x14
#define PWM_PERIOD_BIT_WIDTH 12
#define PWM_PERIOD_MASK((1 << PWM_PERIOD_BIT_WIDTH) - 1)
#define PWM_HIGH_WIDTH_SHIFT 16
#define PWM_HIGH_WIDTH_MASK(0x1fff << PWM_HIGH_WIDTH_SHIFT)
+#define MT2701_PWM_MANUAL_SEL_MASK BIT(1)
+#define MT2701_PWM_BLS_DEBUG 0xb0
+#define MT2701_PWM_BLS_DEBUG_MASK 0x3
+
+struct mtk_pwm_data {
+ unsigned int enable_bit;
+ unsigned int con0;
+ unsigned int con0_sel;
+ unsigned int con1;
+ bool have_commit_reg;
+};
+
struct mtk_disp_pwm {
struct pwm_chip chip;
struct clk *clk_main;
struct clk *clk_mm;
void __iomem *base;
+ const struct mtk_pwm_data *data;
};
static inline struct mtk_disp_pwm *to_mtk_disp_pwm(struct pwm_chip *chip)
@@ -106,12 +117,18 @@ static int mtk_disp_pwm_config(struct pwm_chip *chip,
struct pwm_device *pwm,
return err;
}
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_CON_0, PWM_CLKDIV_MASK,
+ mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
+PWM_CLKDIV_MASK,
clk_div << PWM_CLKDIV_SHIFT);
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_CON_1,
-PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK, value);
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_COMMIT, PWM_COMMIT_MASK, 1);
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_COMMIT, PWM_COMMIT_MASK, 0);
+ mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
+PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
+value);
+ if (mdp->data->have_commit_reg) {
+ mtk_disp_pwm_update_bits(mdp, DISP_PWM_COMMIT,
+PWM_COMMIT_MASK, 0x1);
+ mtk_disp_pwm_update_bits(mdp, DISP_PWM_COMMIT,
+PWM_COMMIT_MASK, 0x0);
+ }
clk_disable(mdp->clk_mm);
clk_disable(mdp->clk_main);
@@ -134,7 +151,9 @@ static int mtk_disp_pwm_enable(struct pwm_chip *chip,
struct pwm_device *pwm)
return err;
}
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, PWM_ENABLE_MASK, 1);
+ mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN,
+mdp->data->enable_bit,
+mdp->data->enable_bit);
return 0;
}
@@ -143,7 +162,8 @@ static void mtk_disp_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
- mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN, PWM_ENABLE_MASK, 0);
+ mtk_disp_pwm_update_bits(mdp, DISP_PWM_EN,
+mdp->data->enable_bit, 0x0);
clk_disable(mdp->clk_mm);
clk_disable(mdp->clk_main);
@@ -156,12 +176,41 @@ static const struct pwm_ops mtk_disp_pwm_ops = {
.owner = THIS_MODULE,
};
+static const struct mtk_pwm_data mt8173_pwm_data = {
+ .enable_bit = BIT(0),
+ .con0 = 0x10,
+ .con0_sel = 0x0,
+ .con1 = 0x14,
+ .have_commit_reg = true,
+};
+
+static const struct mtk_pwm_data mt2701_pwm_data = {
+ .enable_bit = BIT(16),
+ .con0 = 0xa8,
+ .con0_sel = 0x2,
+ .con1 = 0xac,
+ .have_commit_reg = false,
+};
+
+static const struct of_device_id mtk_disp_pwm_of_match[] = {
+ { .compatible = "mediatek,mt2701-disp-bls", .data = &mt2701_pwm_data},
+ { .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { }
+};
+MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
+
static int mtk_disp_pwm_probe(struct platform_device *pdev)
{
+ const struct of_device_id *id;
struct mtk_disp_pwm *mdp;
struct resource *r;
int ret;
+ id = of_match_devi
[PATCH 3/3] dts: Add disp bls dsti and dts config for MT2701
Signed-off-by: Weiqing Kong
---
arch/arm/boot/dts/mt2701-evb.dts | 29 +
arch/arm/boot/dts/mt2701.dtsi| 9 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..6d572f4 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -22,6 +22,35 @@
memory {
reg = <0 0x8000 0 0x4000>;
};
+
+ backlight_lcd: backlight_lcd {
+ compatible = "pwm-backlight";
+ pwms = <&disp_bls 0 10>;
+ brightness-levels = <
+ 0 16 32 48 64 80 96 112
+ 128 144 160 176 192 208 224 240
+ 255
+ >;
+ default-brightness-level = <9>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_bls_gpio>;
+ };
+};
+
+&disp_bls {
+ status = "okay";
+};
+
+&mmsys {
+ status = "okay";
+};
+
+&pio {
+ pwm_bls_gpio: pwm_bls_gpio {
+ pins_cmd_dat {
+ pinmux = ;
+ };
+ };
};
&uart0 {
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 42d5a37..dae55d6 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -234,6 +234,15 @@
status = "disabled";
};
+ disp_bls: dispsys@1400a000 {
+ compatible = "mediatek,mt2701-disp-bls";
+ reg = <0 0x1400a000 0 0x1000>;
+ #pwm-cells = <2>;
+ clocks = <&mmsys CLK_MM_MDP_BLS_26M>, <&mmsys CLK_MM_DISP_BLS>;
+ clock-names = "main", "mm";
+ status = "disabled";
+ };
+
imgsys: syscon@1500 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
--
1.8.1.1.dirty
[PATCH 1/3] dt-bindings: pwm: Add MediaTek display PWM bindings
Add MT2701 compatible string. Signed-off-by: Weiqing Kong --- Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt index f8f59ba..f2f2fa9 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -1,9 +1,10 @@ MediaTek display PWM controller Required properties: - - compatible: should be "mediatek,-disp-pwm": - - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. + - compatible: should be like these: + - "mediatek,mt2701-disp-bls": found on mt2701 SoC. - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. -- 1.8.1.1.dirty
Re: [patch V2 2/7] futex: Hash private futexes per process
On Fri, May 27, 2016 at 06:52:11PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-19 14:21:48 [+0200], Peter Zijlstra wrote:
> > > +static void futex_populate_hash(unsigned int hash_bits)
> > > +{
> …
> > > + raw_spin_lock(&mm->futex_hash.lock);
> > > + /* We might have raced with another task allocating the hash. */
> > > + if (!mm->futex_hash.hash) {
> > > + mm->futex_hash.hash_bits = hash_bits;
> > > + /*
> > > + * Ensure that the above is visible before we store
> > > + * the pointer.
> > > + */
> > > + smp_wmb(); /* (A0) Pairs with (B) */
> > > + mm->futex_hash.hash = hb;
> >
> > smp_store_release(&mm->futex_hash.hash, hb); ?
>
> just to be clear: You suggest to use "smp_store_release()" instead
> smp_wmb() followed by the assignment?
Yes, smp_store_release() is the most natural way to publish things like
this. Note that rcu_assign_pointer() also switched to using that. See
commit: 88c1863066cc ("rcu: Define rcu_assign_pointer() in terms of
smp_store_release()") for detail on the difference.
Re: DRM DMA Engine
Hi Daniel, Thanks for your answer. On 26-05-2016 09:06, Daniel Vetter wrote: > On Wed, May 25, 2016 at 04:46:15PM +0100, Jose Abreu wrote: >> Hi all, >> >> Currently I am trying to develop a DRM driver that will use >> Xilinx VDMA to transfer video data to a HDMI TX Phy and I am >> facing a difficulty regarding the understanding of the DRM DMA >> Engine. I looked at several sources and at the DRM core source >> but the flow of creating and interfacing with the DMA controller >> is still not clear to me. >> >> At DRI web page the X server is mentioned. Does it mean that the >> channel creation and handling is done by the X server? If so, >> what is the DRM driver responsible to do then and what exactly >> does the DRM core do? As I am using Xilinx VDMA do you foresee >> any special implementation details? >> >> Just for reference here is the description of the Xilinx VDMA: >> "The Advanced eXtensible Interface Video Direct Memory Access >> (AXI VDMA) core is a soft Xilinx Intellectual Property (IP) core >> providing high-bandwidth direct memory access between memory and >> AXI4-Stream video type target peripherals including peripherals >> which support AXI4-Stream Video Protocol." The driver is >> available at "drivers/dma/xilinx/xilinx_vdma.c". >> >> Another important point: I am using PCI Express connected to a >> FPGA which has all the necessary components (Xilinx VDMA, I2S, >> ...) and the HDMI TX Phy. >> >> Looking forward to you help. > If your dma engine is just for HDMI display, forget all the stuff you find > about DRI and X server on the various wikis. That's for opengl rendering. > > The only thing you need is a kernel-modesetting driver, and nowadays those > are written using the atomic modeset framework. There's plenty of > introductory talks and stuff all over the web (I suggest the latest > version of Laurent Pinchart's talk as a good starting point). > -Daniel I watched the talk of Laurent and I already have a simple KMS driver with an encoder (which is bridge dw-hdmi), a connector and a crtc. My doubt now is how do I setup the video path so that video samples are sent using the Xilinx VDMA to our hdmi phy. Sorry if I am making some mistake (I am quite new to DRM and DMA) but here is my thoughts: - A DMA channel or some kind of mapping must be done so that the DRM driver knows where to send samples; - The Xilinx VDMA driver must be instantiated (which I am already doing); - Some kind of association between the DRM DMA engine and Xilinx VDMA must be done; - A callback should exist that is called on each frame and updates the data that is sent to Xilinx VDMA. Does this looks okay to you or am I missing something? I still haven't figured out how should I associate the VDMA to the DRM DMA engine and how should I map the DMA to the DRM driver. Can you give me some help or refer me to someone who can? Also, is there a DRM driver that uses a similar architecture? >> Best regards, >> Jose Miguel Abreu >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel Best regards, Jose Miguel Abreu
[PATCH] mm/memcontrol.c: add memory allocation result check
From: Wenwei Tao
The mem_cgroup_tree_per_node allocation might fail,
check that before continue the memcg init. Since it
is in the init phase, trigger the panic if that failure
happens.
Signed-off-by: Wenwei Tao
---
mm/memcontrol.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 925b431..6385c62 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5712,6 +5712,7 @@ static int __init mem_cgroup_init(void)
rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL,
node_online(node) ? node : NUMA_NO_NODE);
+ BUG_ON(!rtpn);
for (zone = 0; zone < MAX_NR_ZONES; zone++) {
struct mem_cgroup_tree_per_zone *rtpz;
--
1.8.3.1
Re: [PATCH RFT] regulator: max8972: Fix setting ramp delay
On 05/29/2016 01:16 PM, Axel Lin wrote:
> Current code can set ramp delay to a wrong setting that the return value
> from .set_voltage_time_sel is not enough for proper delay.
I don't understand what yo wanted to say here. What wrong setting is
possible? Why do you mention set_voltage_time_sel() here?
Can you elaborate?
The only difference I spotted is how you round up the ramp_delay values.
Best regards,
Krzysztof
> Fix the logic in .set_ramp_delay and also remove unused ret_val variable.
>
> Signed-off-by: Axel Lin
> ---
> drivers/regulator/max8973-regulator.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/regulator/max8973-regulator.c
> b/drivers/regulator/max8973-regulator.c
> index 08d2f13..3958f50 100644
> --- a/drivers/regulator/max8973-regulator.c
> +++ b/drivers/regulator/max8973-regulator.c
> @@ -271,22 +271,18 @@ static int max8973_set_ramp_delay(struct regulator_dev
> *rdev,
> struct max8973_chip *max = rdev_get_drvdata(rdev);
> unsigned int control;
> int ret;
> - int ret_val;
>
> /* Set ramp delay */
> - if (ramp_delay < 25000) {
> + if (ramp_delay <= 12000)
> control = MAX8973_RAMP_12mV_PER_US;
> - ret_val = 12000;
> - } else if (ramp_delay < 5) {
> + else if (ramp_delay <= 25000)
> control = MAX8973_RAMP_25mV_PER_US;
> - ret_val = 25000;
> - } else if (ramp_delay < 20) {
> + else if (ramp_delay <= 5)
> control = MAX8973_RAMP_50mV_PER_US;
> - ret_val = 5;
> - } else {
> + else if (ramp_delay <= 20)
> control = MAX8973_RAMP_200mV_PER_US;
> - ret_val = 20;
> - }
> + else
> + return -EINVAL;
>
> ret = regmap_update_bits(max->regmap, MAX8973_CONTROL1,
> MAX8973_RAMP_MASK, control);
>
Re: [PATCH 1/7] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions
On Fri 27-05-16 09:40:27, Tim Chen wrote: > On Tue, 2016-05-03 at 14:01 -0700, Tim Chen wrote: > > This patch prepares the code for being able to batch the anonymous > > pages > > to be swapped out. It reorganizes shrink_page_list function with > > 2 new functions: handle_pgout and pg_finish. > > > > The paging operation in shrink_page_list is consolidated into > > handle_pgout function. > > > > After we have scanned a page shrink_page_list and completed any > > paging, > > the final disposition and clean up of the page is conslidated into > > pg_finish. The designated disposition of the page from page scanning > > in shrink_page_list is marked with one of the designation in > > pg_result. > > > > This is a clean up patch and there is no change in functionality or > > logic of the code. > > Hi Michal, > > We've talked about doing the clean up of shrink_page_list code > before attempting to do batching on the swap out path as those > set of patches I've previously posted are quit intrusive. Wonder > if you have a chance to look at this patch and has any comments? I have noticed your http://lkml.kernel.org/r/1463779979.22178.142.ca...@linux.intel.com but still haven't found time to look at it. Sorry about that. There is rather a lot on my pile... -- Michal Hocko SUSE Labs
Re: [PATCH RFT] regulator: max8972: Fix setting ramp delay
2016-05-30 16:48 GMT+08:00 Krzysztof Kozlowski : > On 05/29/2016 01:16 PM, Axel Lin wrote: >> Current code can set ramp delay to a wrong setting that the return value >> from .set_voltage_time_sel is not enough for proper delay. > > I don't understand what yo wanted to say here. What wrong setting is > possible? Why do you mention set_voltage_time_sel() here? > > Can you elaborate? > > The only difference I spotted is how you round up the ramp_delay values. Assume rdev->constraints->ramp_delay is 2. Original code will set MAX8973_RAMP_12mV_PER_US. However, in regulator_set_voltage_time_sel() return DIV_ROUND_UP(abs(new_volt - old_volt), ramp_delay); This return value is not enough if the device is using MAX8973_RAMP_12mV_PER_US setting.
Re: [PATCH v6 08/11] perf tools: Show warnings for unsupported cross-platform unwind
On Sat, May 28, 2016 at 11:59:57AM +, He Kuang wrote:
> Currently, perf script uses host unwind methods to parse perf.data
> callchain info regardless of the target architecture. So we get wrong
> result without any warnings when unwinding callchains of x86(32-bit)
> on x86(64-bit) machine.
>
> This patch shows warning messages when we do remote unwind x86(32-bit)
> on other machines. Same thing for other platforms will be added in
> next patches.
>
> Signed-off-by: He Kuang
> ---
> tools/perf/config/Makefile | 8
> tools/perf/util/thread.c | 2 +-
> tools/perf/util/unwind-libunwind.c | 30 +-
> tools/perf/util/unwind.h | 5 +++--
> 4 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index 3a304a3..e156f76 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -355,6 +355,14 @@ endif
>
> ifndef NO_LIBUNWIND
>have_libunwind :=
> +
> + ifeq ($(feature-libunwind-x86), 1)
> +$(call detected,CONFIG_LIBUNWIND_X86)
> +CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT
> +LDFLAGS += -lunwind-x86
> +have_libunwind = 1
> + endif
this hunk together with the ifdef in
unwind__prepare_access should go to patch:
perf callchain: Support x86 target platform
thanks
jirka
SNIP
> + arch = normalize_arch(thread->mg->machine->env->arch);
> +
> + if (!strcmp(arch, "x86")) {
> + if (dso_type != DSO__TYPE_64BIT)
> +#ifdef HAVE_LIBUNWIND_X86_SUPPORT
> + pr_err("unwind: target platform=%s is not
> implemented\n", arch);
> +#else
> + pr_err("unwind: target platform=%s is not supported\n",
> arch);
> +#endif
SNIP
Re: [PATCH v6 04/11] perf tools: Move unwind__prepare_access from thread_new into thread__insert_map
On Sat, May 28, 2016 at 11:59:53AM +, He Kuang wrote:
> For determine the libunwind methods to use, we should get the
> 32bit/64bit information from maps of a thread. When a thread is newly
> created, the information is not prepared. This patch moves
> unwind__prepare_access() into thread__insert_map() so we can get the
> information we need from maps.
>
> Signed-off-by: He Kuang
> ---
> tools/perf/util/thread.c | 7 ++-
> tools/perf/util/unwind-libunwind.c | 7 +++
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index 6d3900c..045477d 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -43,11 +43,6 @@ struct thread *thread__new(pid_t pid, pid_t tid)
> thread->cpu = -1;
> INIT_LIST_HEAD(&thread->comm_list);
>
> - register_local_unwind_libunwind_ops(thread);
> -
> - if (unwind__prepare_access(thread) < 0)
> - goto err_thread;
> -
> comm_str = malloc(32);
> if (!comm_str)
> goto err_thread;
> @@ -207,6 +202,8 @@ void thread__insert_map(struct thread *thread, struct map
> *map)
> {
> map_groups__fixup_overlappings(thread->mg, map, stderr);
> map_groups__insert(thread->mg, map);
> +
> + unwind__prepare_access(thread);
so thread__insert_map does not return value,
I think we should change it now when it calls
unwind__prepare_access
I was also thinking to keepcall unwind__prepare_access
separatelly but this function seems to fit better
thanks,
jirka
Re: [PATCH v6 10/11] perf callchain: Support x86 target platform
On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/unwind-libunwind-local.c
> b/tools/perf/util/unwind-libunwind-local.c
> index b391e3e..849fec1 100644
> --- a/tools/perf/util/unwind-libunwind-local.c
> +++ b/tools/perf/util/unwind-libunwind-local.c
> @@ -5,7 +5,9 @@
> #include
> #include
> #include
> +#ifndef REMOTE_UNWIND_LIBUNWIND
> #include
> +#endif
> #include "callchain.h"
> #include "thread.h"
> #include "session.h"
> @@ -671,7 +673,9 @@ _unwind_libunwind_ops = {
> .get_entries= _unwind__get_entries,
> };
>
> +#ifndef REMOTE_UNWIND_LIBUNWIND
> void register_local_unwind_libunwind_ops(struct thread *thread)
> {
> thread->unwind_libunwind_ops = &_unwind_libunwind_ops;
> }
> +#endif
above hunks should go to separate patch
however I still think it'd be more clear if we separate the code like:
code template - util/unwind-libunwind.c
arch template - arch/x86/util/unwind-libunwind.c
wrapper for local - util/unwind-libunwind-local.c
wrapper for x86_32 - arch/x86/util/unwind-libunwind-x86_32.c
wrapper for arm64 - arch/x86/util/unwind-libunwind-arm64.c
jirka
Re: [PATCH v6 05/11] perf tools: Separate local/remote libunwind config
On Sat, May 28, 2016 at 11:59:54AM +, He Kuang wrote: SNIP > diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile > index 6f9f566..3a304a3 100644 > --- a/tools/perf/config/Makefile > +++ b/tools/perf/config/Makefile > @@ -354,10 +354,24 @@ ifeq ($(ARCH),powerpc) > endif > > ifndef NO_LIBUNWIND > + have_libunwind := >ifneq ($(feature-libunwind), 1) > msg := $(warning No libunwind found. Please install libunwind-dev[el] >= > 1.1 and/or set LIBUNWIND_DIR); > +NO_LOCAL_LIBUNWIND := 1 > + else > +have_libunwind := 1 > +CFLAGS += -DHAVE_LIBUNWIND_LOCAL_SUPPORT > +$(call detected,CONFIG_LOCAL_LIBUNWIND) > + endif > + > + ifneq ($(have_libunwind), 1) > NO_LIBUNWIND := 1 > + else > +CFLAGS += -I$(LIBUNWIND_DIR)/include > +LDFLAGS += -L$(LIBUNWIND_DIR)/lib changelog says it's just switch, then why do we need to add above setup? jirka
Re: [PATCH v6 10/11] perf callchain: Support x86 target platform
On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote:
SNIP
> --- /dev/null
> +++ b/tools/perf/arch/x86/util/unwind-libunwind_x86_32.c
> @@ -0,0 +1,21 @@
> +#define REMOTE_UNWIND_LIBUNWIND
> +
> +#define LIBUNWIND__ARCH_REG_ID libunwind__x86_reg_id
> +
> +#include "unwind.h"
> +#include "debug.h"
> +#include "libunwind-x86.h"
> +#include <../../../../../arch/x86/include/uapi/asm/perf_regs.h>
> +
> +#undef HAVE_ARCH_X86_64_SUPPORT
> +#include "unwind-libunwind.c"
> +
> +#undef NO_LIBUNWIND_DEBUG_FRAME
> +#define NO_LIBUNWIND_DEBUG_FRAME
> +#include "util/unwind-libunwind-local.c"
> +
> +int register_x86_32_unwind_libunwind_ops(struct thread *thread)
> +{
> + thread->unwind_libunwind_ops = &_unwind_libunwind_ops;
> + return 0;
> +}
hum, how about export the arch ops:
struct unwind_libunwind_ops *x86_32_unwind_libunwind_ops =
&_unwind_libunwind_ops;
and have single unwind__register_ops(ops) function
jirka
Re: [RFC PATCH v2 1/3] arch/powerpc : Add detour buffer support for optprobes
On 2016/05/24 03:45PM, Madhavan Srinivasan wrote:
>
>
> On Thursday 19 May 2016 08:40 PM, Anju T wrote:
> > Detour buffer contains instructions to create an in memory pt_regs.
> > After the execution of prehandler a call is made for instruction emulation.
> > The NIP is decided after the probed instruction is executed. Hence a branch
> > instruction is created to the NIP returned by emulate_step().
> >
> > Instruction slot for detour buffer is allocated from
> > the reserved area. For the time being 64KB is reserved
> > in memory for this purpose.
> >
> > Signed-off-by: Anju T
> > ---
> > arch/powerpc/include/asm/kprobes.h | 25
> > arch/powerpc/kernel/optprobes_head.S | 108
> > +++
> > 2 files changed, 133 insertions(+)
> > create mode 100644 arch/powerpc/kernel/optprobes_head.S
> >
> > diff --git a/arch/powerpc/include/asm/kprobes.h
> > b/arch/powerpc/include/asm/kprobes.h
> > index 039b583..3e4c998 100644
> > --- a/arch/powerpc/include/asm/kprobes.h
> > +++ b/arch/powerpc/include/asm/kprobes.h
> > @@ -38,7 +38,25 @@ struct pt_regs;
> > struct kprobe;
> >
> > typedef ppc_opcode_t kprobe_opcode_t;
> > +
> > +extern kprobe_opcode_t optinsn_slot;
> > +/* Optinsn template address */
> > +extern kprobe_opcode_t optprobe_template_entry[];
> > +extern kprobe_opcode_t optprobe_template_call_handler[];
> > +extern kprobe_opcode_t optprobe_template_call_emulate[];
> > +extern kprobe_opcode_t optprobe_template_ret_branch[];
> > +extern kprobe_opcode_t optprobe_template_ret[];
> > +extern kprobe_opcode_t optprobe_template_insn[];
> > +extern kprobe_opcode_t optprobe_template_op_address1[];
> > +extern kprobe_opcode_t optprobe_template_op_address2[];
> > +extern kprobe_opcode_t optprobe_template_end[];
> > +
> > #define MAX_INSN_SIZE 1
> > +#define MAX_OPTIMIZED_LENGTH4
> > +#define MAX_OPTINSN_SIZE \
> > + ((unsigned long)&optprobe_template_end -\
> > + (unsigned long)&optprobe_template_entry)
> > +#define RELATIVEJUMP_SIZE 4
> >
> > #ifdef CONFIG_PPC64
> > #if defined(_CALL_ELF) && _CALL_ELF == 2
> > @@ -129,5 +147,12 @@ struct kprobe_ctlblk {
> > extern int kprobe_exceptions_notify(struct notifier_block *self,
> > unsigned long val, void *data);
> > extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
> > +
> > +struct arch_optimized_insn {
> > + kprobe_opcode_t copied_insn[1];
> > + /* detour buffer */
> > + kprobe_opcode_t *insn;
> > +};
> > +
> > #endif /* __KERNEL__ */
> > #endif /* _ASM_POWERPC_KPROBES_H */
> > diff --git a/arch/powerpc/kernel/optprobes_head.S
> > b/arch/powerpc/kernel/optprobes_head.S
> > new file mode 100644
> > index 000..ce32aec
> > --- /dev/null
> > +++ b/arch/powerpc/kernel/optprobes_head.S
> > @@ -0,0 +1,108 @@
> > +/*
> > + * Code to prepare detour buffer for optprobes in kernel.
> > + *
> > + * Copyright 2016, Anju T, IBM Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
You should also add an align directive here:
.align 2
> > +.global optinsn_slot
> > +optinsn_slot:
> > + /* Reserve an area to allocate slots for detour buffer */
> > + .space 65536
>
> Can we replace "65536" with SLOT_SIZE?
Yes, a macro will be good to have.
>
> > +.global optprobe_template_entry
> > +optprobe_template_entry:
> > + stdur1,-INT_FRAME_SIZE(r1)
> > + SAVE_GPR(0,r1)
> > + /* Save the previous SP into stack */
> > + addir0,r1,INT_FRAME_SIZE
> > + std 0,GPR1(r1)
> > + SAVE_2GPRS(2,r1)
> > + SAVE_8GPRS(4,r1)
> > + SAVE_10GPRS(12,r1)
> > + SAVE_10GPRS(22,r1)
> > + /* Save SPRS */
> > + mfcfar r5
> > + std r5,_NIP(r1)
> > + mfmsr r5
> > + std r5,_MSR(r1)
> > + mfctr r5
> > + std r5,_CTR(r1)
> > + mflrr5
> > + std r5,_LINK(r1)
> > + mfspr r5,SPRN_XER
> > + std r5,_XER(r1)
> > + li r5,0
> > + std r5,_TRAP(r1)
> > + mfdar r5
> > + std r5,_DAR(r1)
> > + mfdsisr r5
> > + std r5,_DSISR(r1)
>
> We are missing _CCR (CR register)?
Yes, and I think we need to ensure we fill reasonable values for all
registers in pt_regs including softe (from paca), orig_gpr3 (0?) and
result (0).
>
> Why tab space for the comment? and
> a new line before the command will be good
... new line before *each section* will be good :)
>
> > + /* Pass parameters for optimized_callback */
> > +.global optprobe_template_op_address1
> > +optprobe_template_op_address1:
So, the general style is to align labels at the start of a line and to
align everything else as per the code indentation.
In this case though, I think it's best to use a ma
Re: [PATCH v6 10/11] perf callchain: Support x86 target platform
On Sat, May 28, 2016 at 11:59:59AM +, He Kuang wrote: > Support x86(32-bit) cross platform callchain unwind. > > Signed-off-by: He Kuang > --- > tools/perf/arch/Build | 1 + > tools/perf/arch/x86/util/unwind-libunwind.c| 7 --- > tools/perf/arch/x86/util/unwind-libunwind_x86_32.c | 21 + > tools/perf/util/unwind-libunwind-local.c | 4 > tools/perf/util/unwind-libunwind.c | 19 +-- > tools/perf/util/unwind.h | 10 ++ > 6 files changed, 53 insertions(+), 9 deletions(-) > create mode 100644 tools/perf/arch/x86/util/unwind-libunwind_x86_32.c > > diff --git a/tools/perf/arch/Build b/tools/perf/arch/Build > index 109eb75..3fc4af1 100644 > --- a/tools/perf/arch/Build > +++ b/tools/perf/arch/Build > @@ -1,2 +1,3 @@ > libperf-y += common.o > libperf-y += $(ARCH)/ > +libperf-$(CONFIG_LIBUNWIND_X86) += x86/util/unwind-libunwind_x86_32.o we have Build file directly in arch/x86/util/ if you do it like this to include generic file easily we better fix the include then jirka
Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup
On 2016年05月28日 11:41, Waiman Long wrote: On 05/27/2016 06:32 AM, xinhui wrote: On 2016年05月27日 02:31, Waiman Long wrote: On 05/25/2016 02:09 AM, Pan Xinhui wrote: In pv_wait_head_or_lock, if there is a spurious_wakeup, and it fails to get the lock as there is lock stealing, then after a short spin, we need hash the lock again and enter pv_wait to yield. Currently after a spurious_wakeup, as l->locked is not _Q_SLOW_VAL, pv_wait might do nothing and return directly, that is not paravirt-friendly because pv_wait_head_or_lock will just spin on the lock then. Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 39 + 1 file changed, 31 insertions(+), 8 deletions(-) Is this a problem you can easily reproduce on PPC? I have not observed this issue when testing on x86. Hi, Waiman I notice the spurious_wakeup count is very high when I do benchmark tests and stress tests. So after a simple investigation, I find pv_wait_head_or_lock() just keep loops. That shouldn't happen in normal case. When testing on x86, I typically get the following stat data for an over-commited guest: pv_lock_slowpath=9256211 pv_lock_stealing=36398363 pv_spurious_wakeup=311 pv_wait_again=294 pv_wait_early=3255605 pv_wait_head=173 pv_wait_node=3256280 OK, here is the result after run command perf bench sched messaging -g 512 pv_lock_slowpath=2331407 pv_lock_stealing=192038 pv_spurious_wakeup=236319 pv_wait_again=215668 pv_wait_early=177299 pv_wait_head=9206 pv_wait_node=228781 The queue head don't call pv_wait that often. There are a bit of spurious wakeup, but it is mostly caused by lock stealing. How long is a cpu_relax() in PPC takes? 946012160 cpu_relax loops with 10 seconds. So if SPIN_THRESHOLD is 1<<15, it costs 0.3ms to spin on the lock. How about x86? And only 10134976 pv_wait/pv_kick hyper-call loops within 10 seconds. so every hyper-call itself(the so-called latency) costs less than 1us. Here is my story, in my pv-qspinlcok patchset V1&&v2, pv_wait on ppc ignore the first two parameters of *ptr and val, that makes lock_stealing hit too much. The pvqspinlock code does depend on pv_wait() doing a final check to see if the lock value change. The code may not work reliably without that. agree, So pv_wait now do the check of *ptr and val. and when I change SPIN_THRESHOLD to a small value, system is very much unstable because waiter will enter pv_wait quickly and no one will kick waiter's cpu if we enter pv_wait twice thanks to the lock_stealing. So what I do in my pv-qspinlcok patchset V3 is that add if (*ptr == val) in pv_wait. However as I mentioned above, then spurious_wakeup count is too high, that also means our cpu slice is wasted. The SPIN_THRESHOLD should be sufficiently big. A small value will cause too many waits and wake-up's which may not be good. Anyway, more testing and tuning may be needed to make the pvqspinlock code work well with PPC. agree , but I think the SPIN_THRESHOLD (1<<15) for ppc is a little large. I even come up with an idea that make SPIN_THRESHOLD an extern variable on ppc. But I am busy and I wonder if it's worth doing that. Cheers, Longman
Re: [PATCH v6 03/11] perf tools: Introducing struct unwind_libunwind_ops for local unwind
On Sat, May 28, 2016 at 11:59:52AM +, He Kuang wrote:
> Currently, libunwind operations are fixed, and they are chosen
> according to the host architecture. This will lead a problem that if a
> thread is run as x86_32 on x86_64 machine, perf will use libunwind
> methods for x86_64 to parse the callchain and get wrong result.
>
> This patch changes the fixed methods of libunwind operations to
> thread/map related, and each thread can have indivadual libunwind
> operations. Local libunwind methods are registered as default value.
>
> Signed-off-by: He Kuang
> ---
> tools/perf/util/thread.c | 2 ++
> tools/perf/util/thread.h | 14 +-
> tools/perf/util/unwind-libunwind.c | 55
> ++
> tools/perf/util/unwind.h | 5
> 4 files changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index 45fcb71..6d3900c 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -43,6 +43,8 @@ struct thread *thread__new(pid_t pid, pid_t tid)
> thread->cpu = -1;
> INIT_LIST_HEAD(&thread->comm_list);
>
> + register_local_unwind_libunwind_ops(thread);
> +
> if (unwind__prepare_access(thread) < 0)
> goto err_thread;
>
> diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
> index aa3a8ff..647b011 100644
> --- a/tools/perf/util/thread.h
> +++ b/tools/perf/util/thread.h
> @@ -12,6 +12,17 @@
>
> struct thread_stack;
>
> +struct unwind_entry;
> +typedef int (*unwind_entry_cb_t)(struct unwind_entry *entry, void *arg);
> +struct unwind_libunwind_ops {
> + int (*prepare_access)(struct thread *thread);
> + void (*flush_access)(struct thread *thread);
> + void (*finish_access)(struct thread *thread);
> + int (*get_entries)(unwind_entry_cb_t cb, void *arg,
> +struct thread *thread,
> +struct perf_sample *data, int max_stack);
> +};
> +
this should rather go to util/unwind.h
thanks,
jirka
Re: [PATCH] mm/memcontrol.c: add memory allocation result check
On Mon 30-05-16 16:45:51, Wenwei Tao wrote:
> From: Wenwei Tao
>
> The mem_cgroup_tree_per_node allocation might fail,
> check that before continue the memcg init. Since it
> is in the init phase, trigger the panic if that failure
> happens.
We would blow up in the very same function so what is the point of the
explicit BUG_ON?
> Signed-off-by: Wenwei Tao
> ---
> mm/memcontrol.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 925b431..6385c62 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5712,6 +5712,7 @@ static int __init mem_cgroup_init(void)
>
> rtpn = kzalloc_node(sizeof(*rtpn), GFP_KERNEL,
> node_online(node) ? node : NUMA_NO_NODE);
> + BUG_ON(!rtpn);
>
> for (zone = 0; zone < MAX_NR_ZONES; zone++) {
> struct mem_cgroup_tree_per_zone *rtpz;
> --
> 1.8.3.1
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
--
Michal Hocko
SUSE Labs
[PATCH v1 06/14] ARM: dts: omap5-board-common: Add pdmclk binding for audio
The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap5-board-common.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi
b/arch/arm/boot/dts/omap5-board-common.dtsi
index 19efaa079797..63d0352d068d 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -637,6 +637,7 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
+ #clock-cells = <0>;
reg = <0x4b>;
pinctrl-names = "default";
@@ -658,6 +659,10 @@
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
+
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+
status = "okay";
};
--
2.8.3
[PATCH v1 03/14] clk: twl6040: Rename the driver and use consistent names in the code
The driver is to provide the functional clock to OMAP4/5 McPDM. The clock
is named as pdmclk in the documentations so change the function names,
structure names and variables to align with this.
At the same time rename the driver from "twl6040-clk" to "twl6040-pdmclk".
This can be done w/o regression since the clock driver is not in use at
the moment, the MFD core driver is not even registering the device for it.
Signed-off-by: Peter Ujfalusi
---
drivers/clk/clk-twl6040.c | 77 +++
1 file changed, 45 insertions(+), 32 deletions(-)
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index 6a2dbe6a1627..c98b1ec76f54 100644
--- a/drivers/clk/clk-twl6040.c
+++ b/drivers/clk/clk-twl6040.c
@@ -26,60 +26,73 @@
#include
#include
-struct twl6040_clk {
+struct twl6040_pdmclk {
struct twl6040 *twl6040;
struct device *dev;
- struct clk_hw mcpdm_fclk;
+ struct clk_hw pdmclk_hw;
struct clk *clk;
int enabled;
};
-static int twl6040_bitclk_is_prepared(struct clk_hw *hw)
+static int twl6040_pdmclk_is_prepared(struct clk_hw *hw)
{
- struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
- mcpdm_fclk);
- return twl6040_clk->enabled;
+ struct twl6040_pdmclk *pdmclk = container_of(hw, struct twl6040_pdmclk,
+pdmclk_hw);
+
+ return pdmclk->enabled;
}
-static int twl6040_bitclk_prepare(struct clk_hw *hw)
+static int twl6040_pdmclk_prepare(struct clk_hw *hw)
{
- struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
- mcpdm_fclk);
+ struct twl6040_pdmclk *pdmclk = container_of(hw, struct twl6040_pdmclk,
+pdmclk_hw);
int ret;
- ret = twl6040_power(twl6040_clk->twl6040, 1);
+ ret = twl6040_power(pdmclk->twl6040, 1);
if (!ret)
- twl6040_clk->enabled = 1;
+ pdmclk->enabled = 1;
return ret;
}
-static void twl6040_bitclk_unprepare(struct clk_hw *hw)
+static void twl6040_pdmclk_unprepare(struct clk_hw *hw)
{
- struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
- mcpdm_fclk);
+ struct twl6040_pdmclk *pdmclk = container_of(hw, struct twl6040_pdmclk,
+pdmclk_hw);
int ret;
- ret = twl6040_power(twl6040_clk->twl6040, 0);
+ ret = twl6040_power(pdmclk->twl6040, 0);
if (!ret)
- twl6040_clk->enabled = 0;
+ pdmclk->enabled = 0;
+
+}
+
+static unsigned long twl6040_pdmclk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct twl6040_pdmclk *pdmclk = container_of(hw, struct twl6040_pdmclk,
+pdmclk_hw);
+
+ return twl6040_get_sysclk(pdmclk->twl6040);
}
-static const struct clk_ops twl6040_mcpdm_ops = {
- .is_prepared = twl6040_bitclk_is_prepared,
- .prepare = twl6040_bitclk_prepare,
- .unprepare = twl6040_bitclk_unprepare,
+static const struct clk_ops twl6040_pdmclk_ops = {
+ .is_prepared = twl6040_pdmclk_is_prepared,
+ .prepare = twl6040_pdmclk_prepare,
+ .unprepare = twl6040_pdmclk_unprepare,
+ .recalc_rate = twl6040_pdmclk_recalc_rate,
};
-static struct clk_init_data wm831x_clkout_init = {
- .name = "mcpdm_fclk",
- .ops = &twl6040_mcpdm_ops,
+static struct clk_init_data twl6040_pdmclk_init = {
+ .name = "pdmclk",
+ .ops = &twl6040_pdmclk_ops,
+ .flags = CLK_GET_RATE_NOCACHE,
};
-static int twl6040_clk_probe(struct platform_device *pdev)
+static int twl6040_pdmclk_probe(struct platform_device *pdev)
{
struct twl6040 *twl6040 = dev_get_drvdata(pdev->dev.parent);
- struct twl6040_clk *clkdata;
+ struct twl6040_pdmclk *clkdata;
clkdata = devm_kzalloc(&pdev->dev, sizeof(*clkdata), GFP_KERNEL);
if (!clkdata)
@@ -88,8 +101,8 @@ static int twl6040_clk_probe(struct platform_device *pdev)
clkdata->dev = &pdev->dev;
clkdata->twl6040 = twl6040;
- clkdata->mcpdm_fclk.init = &wm831x_clkout_init;
- clkdata->clk = devm_clk_register(&pdev->dev, &clkdata->mcpdm_fclk);
+ clkdata->pdmclk_hw.init = &twl6040_pdmclk_init;
+ clkdata->clk = devm_clk_register(&pdev->dev, &clkdata->pdmclk_hw);
if (IS_ERR(clkdata->clk))
return PTR_ERR(clkdata->clk);
@@ -99,16 +112,16 @@ static int twl6040_clk_probe(struct platform_device *pdev)
of_clk_src_simple_get, clkdata->clk);
}
-static struct platform_driver twl6040_clk_driver = {
+static struct platform_driver twl6040_pdmclk_driver =
[PATCH v1 07/14] ARM: dts: omap4-panda-common: Add pdmclk binding for audio
The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index df2e356ec089..e1d606f64cb7 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -376,6 +376,7 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
+ #clock-cells = <0>;
reg = <0x4b>;
pinctrl-names = "default";
@@ -479,6 +480,10 @@
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
+
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+
status = "okay";
};
--
2.8.3
[PATCH v1 02/14] clk: twl6040: Register the clock as of_clk_provider
In order ot be able to use the pdmclk clock via DT it need to be registered
as of_clk_provide.
Since the twl6040 clock driver does not have it's own DT node, use the
parent's node for registering.
Signed-off-by: Peter Ujfalusi
---
drivers/clk/clk-twl6040.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index e167e0bbaff5..6a2dbe6a1627 100644
--- a/drivers/clk/clk-twl6040.c
+++ b/drivers/clk/clk-twl6040.c
@@ -95,7 +95,8 @@ static int twl6040_clk_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, clkdata);
- return 0;
+ return of_clk_add_provider(pdev->dev.parent->of_node,
+ of_clk_src_simple_get, clkdata->clk);
}
static struct platform_driver twl6040_clk_driver = {
--
2.8.3
[PATCH v1 11/14] ASoC: omap: Kconfig: SND_OMAP_SOC_OMAP_ABE_TWL6040 to select CLK_TWL6040
The pdmclk is needed for McPDM. It is generated by twl6040. Signed-off-by: Peter Ujfalusi --- sound/soc/omap/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 5520273724ae..347705c04db1 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -119,6 +119,7 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040 select SND_SOC_TWL6040 select SND_SOC_DMIC select COMMON_CLK_PALMAS if (SOC_OMAP5 && MFD_PALMAS) + select CLK_TWL6040 help Say Y if you want to add support for SoC audio on OMAP boards using ABE and twl6040 codec. This driver currently supports: -- 2.8.3
[PATCH v1 12/14] ASoC: omap-mcpdm: Move the WD enable write inside omap_mcpdm_open_streams()
The DS4_WD_EN bit is only touched before calling omap_mcpdm_open_streams().
Move it inside of that function for simplicity.
Signed-off-by: Peter Ujfalusi
---
sound/soc/omap/omap-mcpdm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index b837265ac3e9..11bd07cdce22 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -173,6 +173,10 @@ static inline int omap_mcpdm_active(struct omap_mcpdm
*mcpdm)
*/
static void omap_mcpdm_open_streams(struct omap_mcpdm *mcpdm)
{
+ u32 ctrl = omap_mcpdm_read(mcpdm, MCPDM_REG_CTRL);
+
+ omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, ctrl | MCPDM_WD_EN);
+
omap_mcpdm_write(mcpdm, MCPDM_REG_IRQENABLE_SET,
MCPDM_DN_IRQ_EMPTY | MCPDM_DN_IRQ_FULL |
MCPDM_UP_IRQ_EMPTY | MCPDM_UP_IRQ_FULL);
@@ -258,12 +262,9 @@ static int omap_mcpdm_dai_startup(struct snd_pcm_substream
*substream,
mutex_lock(&mcpdm->mutex);
- if (!dai->active) {
- u32 ctrl = omap_mcpdm_read(mcpdm, MCPDM_REG_CTRL);
-
- omap_mcpdm_write(mcpdm, MCPDM_REG_CTRL, ctrl | MCPDM_WD_EN);
+ if (!dai->active)
omap_mcpdm_open_streams(mcpdm);
- }
+
mutex_unlock(&mcpdm->mutex);
return 0;
--
2.8.3
[PATCH v1 13/14] ASoC: omap-mcpdm: Support for suspend resume
Implement ASoC's suspend and resume callbacks.
Since McPDM does not use pcm_trigger for start and stop of the stream due
to strict sequencing needs with the twl6040, the callbacks will stop and
restart the McPDM in case the board suspended during audio activity.
Signed-off-by: Peter Ujfalusi
---
sound/soc/omap/omap-mcpdm.c | 46 +
1 file changed, 46 insertions(+)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 11bd07cdce22..74d6e6fdcfd0 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -66,6 +66,9 @@ struct omap_mcpdm {
/* McPDM needs to be restarted due to runtime reconfiguration */
bool restart;
+ /* pm state for suspend/resume handling */
+ int pm_active_count;
+
struct snd_dmaengine_dai_dma_data dma_data[2];
};
@@ -422,12 +425,55 @@ static int omap_mcpdm_remove(struct snd_soc_dai *dai)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int omap_mcpdm_suspend(struct snd_soc_dai *dai)
+{
+ struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
+
+ if (dai->active) {
+ omap_mcpdm_stop(mcpdm);
+ omap_mcpdm_close_streams(mcpdm);
+ }
+
+ mcpdm->pm_active_count = 0;
+ while (pm_runtime_active(mcpdm->dev)) {
+ pm_runtime_put_sync(mcpdm->dev);
+ mcpdm->pm_active_count++;
+ }
+
+ return 0;
+}
+
+static int omap_mcpdm_resume(struct snd_soc_dai *dai)
+{
+ struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
+
+ if (mcpdm->pm_active_count) {
+ while (mcpdm->pm_active_count--)
+ pm_runtime_get_sync(mcpdm->dev);
+
+ if (dai->active) {
+ omap_mcpdm_open_streams(mcpdm);
+ omap_mcpdm_start(mcpdm);
+ }
+ }
+
+
+ return 0;
+}
+#else
+#define omap_mcpdm_suspend NULL
+#define omap_mcpdm_resume NULL
+#endif
+
#define OMAP_MCPDM_RATES (SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000)
#define OMAP_MCPDM_FORMATS SNDRV_PCM_FMTBIT_S32_LE
static struct snd_soc_dai_driver omap_mcpdm_dai = {
.probe = omap_mcpdm_probe,
.remove = omap_mcpdm_remove,
+ .suspend = omap_mcpdm_suspend,
+ .resume = omap_mcpdm_resume,
.probe_order = SND_SOC_COMP_ORDER_LATE,
.remove_order = SND_SOC_COMP_ORDER_EARLY,
.playback = {
--
2.8.3
[PATCH v1 10/14] ARM: dts: omap4-duovero: Add pdmclk binding for audio
The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-duovero.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi
b/arch/arm/boot/dts/omap4-duovero.dtsi
index f2a94fa62552..a90b582e4c3f 100644
--- a/arch/arm/boot/dts/omap4-duovero.dtsi
+++ b/arch/arm/boot/dts/omap4-duovero.dtsi
@@ -177,6 +177,7 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
+ #clock-cells = <0>;
reg = <0x4b>;
interrupts = ; /*
IRQ_SYS_2N cascaded to gic */
ti,audpwron-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>; /*
gpio_160 */
@@ -207,6 +208,10 @@
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
+
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+
status = "okay";
};
--
2.8.3
[PATCH v1 14/14] ASoC: omap-mcpdm: Add support for pdmclk clock handling
McPDM module receives it's functional clock from external source. This
clock is the pdmclk provided by the twl6040 audio IC. If the clock is not
available all register accesses to McPDM fails and the module is not
operational.
Signed-off-by: Peter Ujfalusi
Acked-by: Rob Herring
---
.../devicetree/bindings/sound/omap-mcpdm.txt | 10
sound/soc/omap/omap-mcpdm.c| 27 ++
2 files changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
index 0741dff048dd..6f6c2f8e908d 100644
--- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
+++ b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
@@ -8,6 +8,8 @@ Required properties:
- interrupts: Interrupt number for McPDM
- interrupt-parent: The parent interrupt controller
- ti,hwmods: Name of the hwmod associated to the McPDM
+- clocks: phandle for the pdmclk provider, likely <&twl6040>
+- clock-names: Must be "pdmclk"
Example:
@@ -19,3 +21,11 @@ mcpdm: mcpdm@40132000 {
interrupt-parent = <&gic>;
ti,hwmods = "mcpdm";
};
+
+In board DTS file the pdmclk needs to be added:
+
+&mcpdm {
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+ status = "okay";
+};
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 74d6e6fdcfd0..2d2119e7d094 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -54,6 +55,7 @@ struct omap_mcpdm {
unsigned long phys_base;
void __iomem *io_base;
int irq;
+ struct clk *pdmclk;
struct mutex mutex;
@@ -388,6 +390,12 @@ static int omap_mcpdm_probe(struct snd_soc_dai *dai)
struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
int ret;
+ ret = clk_prepare_enable(mcpdm->pdmclk);
+ if (!ret) {
+ dev_err(mcpdm->dev, "Failed to enable PDMCLK: %d\n", ret);
+ return ret;
+ }
+
pm_runtime_enable(mcpdm->dev);
/* Disable lines while request is ongoing */
@@ -422,6 +430,7 @@ static int omap_mcpdm_remove(struct snd_soc_dai *dai)
pm_runtime_disable(mcpdm->dev);
+ clk_disable_unprepare(mcpdm->pdmclk);
return 0;
}
@@ -441,12 +450,21 @@ static int omap_mcpdm_suspend(struct snd_soc_dai *dai)
mcpdm->pm_active_count++;
}
+ clk_disable_unprepare(mcpdm->pdmclk);
+
return 0;
}
static int omap_mcpdm_resume(struct snd_soc_dai *dai)
{
struct omap_mcpdm *mcpdm = snd_soc_dai_get_drvdata(dai);
+ int ret;
+
+ ret = clk_prepare_enable(mcpdm->pdmclk);
+ if (!ret) {
+ dev_err(mcpdm->dev, "Failed to enable PDMCLK: %d\n", ret);
+ return ret;
+ }
if (mcpdm->pm_active_count) {
while (mcpdm->pm_active_count--)
@@ -541,6 +559,15 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
mcpdm->dev = &pdev->dev;
+ mcpdm->pdmclk = devm_clk_get(&pdev->dev, "pdmclk");
+ if (IS_ERR(mcpdm->pdmclk)) {
+ if (PTR_ERR(mcpdm->pdmclk) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_warn(&pdev->dev, "Error getting pdmclk (%ld)!\n",
+PTR_ERR(mcpdm->pdmclk));
+ mcpdm->pdmclk = NULL;
+ }
+
ret = devm_snd_soc_register_component(&pdev->dev,
&omap_mcpdm_component,
&omap_mcpdm_dai, 1);
--
2.8.3
Re: [patch V2 3/7] futex: Add op for hash preallocation
On Fri, May 27, 2016 at 07:27:57PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-19 14:25:58 [+0200], Peter Zijlstra wrote:
> > On Thu, May 05, 2016 at 08:44:05PM -, Thomas Gleixner wrote:
> > > +static int futex_preallocate_hash(unsigned int slots)
> > > +{
> > > +#ifdef CONFIG_FUTEX_PRIVATE_HASH
> > > + struct mm_struct *mm = current->mm;
> > > + struct futex_hash_bucket *hb;
> > > + unsigned int bits;
> > > +
> > > + /* Try to allocate the requested nr of slots */
> > > + bits = order_base_2(slots);
> > > +
> > > + if (bits < FUTEX_MIN_HASH_BITS)
> > > + bits = FUTEX_MIN_HASH_BITS;
> > > +
> > > + if (bits > futex_max_hash_bits)
> > > + bits = futex_max_hash_bits;
> > > +
> > > + futex_populate_hash(bits);
> >
> > Should we not simply fail if the provided number of slots is not a power
> > of 2 ?
>
> We could if it is worth doing so. The procfs interface which limits the
> upper / lower limit is bits based. This is slot based which then gets
> converted to the number if bits.
> If we align this interface with proc's limits then we would expect the
> number of bits instead slots - now check for power of two anymore.
> Anyone?
I'm all for consistent and strict when it comes to things like this.
Re: [PATCH 3/5] spi: sunxi: expose maximum transfer size limit
Hello, On 30 May 2016 at 10:37, Maxime Ripard wrote: > On Thu, May 26, 2016 at 07:25:24PM -, Michal Suchanek wrote: >> The sun4i spi hardware can trasfer at most 63 bytes of data without DMA >> support so report the limitation. Same on sun6i. > > Is it? Is there timeouts on the A31 and later SoCs? > I have no sun6i hardware to test with. This is an advisory limit you can query and it better be smaller rather than unreliable. The hard limit in the driver is still SUN6I_FIFO_DEPTH (which is 128 bytes on sun6i). You can test his without any actual SPI device. Unused pins you can multiplex as SPI suffice. Thanks Michal
[PATCH v1 08/14] ARM: dts: omap4-sdp: Add pdmclk binding for audio
The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-sdp.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index aae513265dc2..7e6cd2d8ed5d 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -367,6 +367,7 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
+ #clock-cells = <0>;
reg = <0x4b>;
pinctrl-names = "default";
@@ -620,6 +621,10 @@
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
+
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+
status = "okay";
};
--
2.8.3
Re: [patch V2 2/7] futex: Hash private futexes per process
On Fri, May 27, 2016 at 07:10:01PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-05-19 14:24:06 [+0200], Peter Zijlstra wrote:
> > On Thu, May 05, 2016 at 08:44:04PM -, Thomas Gleixner wrote:
> > > +static struct futex_hash_bucket *hash_futex(union futex_key *key)
> > > +{
> > > +#ifdef CONFIG_FUTEX_PRIVATE_HASH
> > > + struct mm_struct *mm = current->mm;
> > > + unsigned int slot;
> > > +
> > > + /*
> > > + * Futexes which use the per process hash have the lower bits cleared
> > > + */
> > > + if (key->both.offset & (FUT_OFF_INODE | FUT_OFF_MMSHARED))
> > > + return hash_global_futex(key);
> > > +
> > > + slot = hash_long(key->private.address, mm->futex_hash.hash_bits);
> > > + return &mm->futex_hash.hash[slot];
> >
> > Do we want the option to WARN if we get collisions in this per-process
> > hash?
> >
> > Because afaiu there is no guarantee what so ever this doesn't happen,
> > and collisions here can create the very same priority inversions as are
> > possible in the global hash.
> >
> > Less likely etc.. more contained since its only the threads of the one
> > process that get tangled up, but still possible.
>
> Since the collision is contained the same process it is less dramatic.
Right, but can still cause significant malfunction inside the process.
So its not something to completely ignore. If your room sized CNC
machine gets the priorities of the logging thread and the motor control
thread confused bad things could happen.
> But how do you want to warn the user? A trace-event would be handy to
> dump the uaddr and slot.
So I think there's a number of cases:
- PREALLOC_HASH finds a taken bucket; in this case we can simply return
an error.
- PREALLOC_HASH succeeds, but an on demand hash later hits the same
bucket. This is harder; we could maybe mark all buckets taken by
PREALLOC_HASH and allow for a signal when this collision hits. Dunno.
> The user would have to check the trace and
> figure out which slot was assigend to different uaddr.
Yeah, that's not really workable, might work for debugging, but blergh.
> But due to ASLR
> the same application might result in a different behaviour on each run.
Yeah, ASLR makes this all somewhat non deterministic, which is why you
really don't want a silent collision for your PREALLOC_HASH buckets.
Because once every 100 runs it does weird,..
> However, it might be good for a indication about the size of the private
> hash…
Yeah, now if online resize wasn't such a pain ;-)
[PATCH v1 09/14] ARM: dts: omap4-var-som-om44: Add pdmclk binding for audio
The twl6040 codec is generating the pdmclk, which is used by the McPDM as
functional clock.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-var-som-om44.dtsi
b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
index a17997f4e9aa..873cfc87260c 100644
--- a/arch/arm/boot/dts/omap4-var-som-om44.dtsi
+++ b/arch/arm/boot/dts/omap4-var-som-om44.dtsi
@@ -189,6 +189,7 @@
twl6040: twl@4b {
compatible = "ti,twl6040";
+ #clock-cells = <0>;
reg = <0x4b>;
pinctrl-names = "default";
@@ -252,6 +253,10 @@
&mcpdm {
pinctrl-names = "default";
pinctrl-0 = <&mcpdm_pins>;
+
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+
status = "okay";
};
--
2.8.3
[PATCH v1 00/14] clk/mfd/ASoC/ARM: OMAP4/5: McPDM/twl6040 pdmclk support
Hi, Changes since v1: - Added Rob's Acked-by to patch 5 and 14 - Check the return value of clk_prepare_enable() calls in the last patch this is something I wanted to do for a long time... First of all: sorry for the cross domain series. I did tested alone all the domain patches and they are not causing any regression. When they come together we will have ability to control the pdmclk needed by McPDM. CLK patches: The driver was w/o DT support and needed some cleanup so we can use the driver. I have also renamed it to twl6040-pdmclk from twl6040-clk to be precise. MFD patches: The regmap_sync() was not working since the twl6040 does not support bulk access and now we are going to create the needed child for the pdmclk. ARM patches: Updatding the board DTS files and add the needed lines for the pdmclk. ASoC patches: The machine driver needs to select the twl6040-clk driver as it will be used by the omap-mcpdm. I needed to do some cleanup and add also suspend/resume support before adding the code for pdmclk handling since I don't want to keep the twl6040 powered on when the board is suspended. At the moment it is not possible to do true dynamic twl6040 power up/down due to pop noises, but I will be looking at that later. The driver in the future will fail if it is not able to get the pdmclk to avoid kernel crash (McPDM registers are not accessible when pdmclk is not available). I have tested the patches by domain and also in all (I hope) permutation they could be. I have not experienced any regression. Regards, Peter --- Peter Ujfalusi (14): clk: twl6040: Correct clk_ops clk: twl6040: Register the clock as of_clk_provider clk: twl6040: Rename the driver and use consistent names in the code mfd: twl6040: The chip does not support bulk access mfd: twl6040: Register child device for twl6040-pdmclk ARM: dts: omap5-board-common: Add pdmclk binding for audio ARM: dts: omap4-panda-common: Add pdmclk binding for audio ARM: dts: omap4-sdp: Add pdmclk binding for audio ARM: dts: omap4-var-som-om44: Add pdmclk binding for audio ARM: dts: omap4-duovero: Add pdmclk binding for audio ASoC: omap: Kconfig: SND_OMAP_SOC_OMAP_ABE_TWL6040 to select CLK_TWL6040 ASoC: omap-mcpdm: Move the WD enable write inside omap_mcpdm_open_streams() ASoC: omap-mcpdm: Support for suspend resume ASoC: omap-mcpdm: Add support for pdmclk clock handling Documentation/devicetree/bindings/mfd/twl6040.txt | 1 + .../devicetree/bindings/sound/omap-mcpdm.txt | 10 +++ arch/arm/boot/dts/omap4-duovero.dtsi | 5 ++ arch/arm/boot/dts/omap4-panda-common.dtsi | 5 ++ arch/arm/boot/dts/omap4-sdp.dts| 5 ++ arch/arm/boot/dts/omap4-var-som-om44.dtsi | 5 ++ arch/arm/boot/dts/omap5-board-common.dtsi | 5 ++ drivers/clk/clk-twl6040.c | 80 - drivers/mfd/twl6040.c | 6 ++ include/linux/mfd/twl6040.h| 2 +- sound/soc/omap/Kconfig | 1 + sound/soc/omap/omap-mcpdm.c| 84 -- 12 files changed, 170 insertions(+), 39 deletions(-) -- 2.8.3
[PATCH v1 01/14] clk: twl6040: Correct clk_ops
Since the drover only supports prepare callbacks, the use of is_enabled is
not correct, it should be handling is_prepared.
Signed-off-by: Peter Ujfalusi
---
drivers/clk/clk-twl6040.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index 697c66757400..e167e0bbaff5 100644
--- a/drivers/clk/clk-twl6040.c
+++ b/drivers/clk/clk-twl6040.c
@@ -34,7 +34,7 @@ struct twl6040_clk {
int enabled;
};
-static int twl6040_bitclk_is_enabled(struct clk_hw *hw)
+static int twl6040_bitclk_is_prepared(struct clk_hw *hw)
{
struct twl6040_clk *twl6040_clk = container_of(hw, struct twl6040_clk,
mcpdm_fclk);
@@ -66,7 +66,7 @@ static void twl6040_bitclk_unprepare(struct clk_hw *hw)
}
static const struct clk_ops twl6040_mcpdm_ops = {
- .is_enabled = twl6040_bitclk_is_enabled,
+ .is_prepared = twl6040_bitclk_is_prepared,
.prepare = twl6040_bitclk_prepare,
.unprepare = twl6040_bitclk_unprepare,
};
--
2.8.3
[PATCH v1 04/14] mfd: twl6040: The chip does not support bulk access
Bulk access is not working with twl6040, we need to use single register
access. Bulk access would happen when we try to sync the regcache after
power on.
Signed-off-by: Peter Ujfalusi
---
drivers/mfd/twl6040.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index f3dcf3a85e84..2596546553aa 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -608,6 +608,7 @@ static const struct regmap_config twl6040_regmap_config = {
.writeable_reg = twl6040_writeable_reg,
.cache_type = REGCACHE_RBTREE,
+ .use_single_rw = true,
};
static const struct regmap_irq twl6040_irqs[] = {
--
2.8.3
