* [PATCH 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Jerome Brunet @ 2016-10-19 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871709-8359-1-git-send-email-jbrunet@baylibre.com>
This commit adds the device tree bindings description for Amlogic's GPIO
interrupt controller available on the meson8, meson8b and gxbb SoC families
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Rob, I did not include the Ack you gave for the RFC as bindings have slightly
changed. Only the interrupt property has be removed following a discussion I
had with Marc.
.../amlogic,meson-gpio-intc.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
new file mode 100644
index 000000000000..2464d9a0865d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
@@ -0,0 +1,31 @@
+Amlogic meson GPIO interrupt controller
+
+Meson SoCs contains an interrupt controller which is able watch the SoC pads
+and generate an interrupt on edges or level. The controller is essentially a
+256 pads to 8 GIC interrupt multiplexer, with a filter block to select edge
+or level and polarity. We don?t expose all 256 mux inputs because the
+documentation shows that upper part is not mapped to any pad. The actual number
+of interrupt exposed depends on the SoC.
+
+Required properties:
+
+- compatible : should be either
+ "amlogic,meson8-gpio-intc? for meson8 SoCs (AML7826MX) or
+ ?amlogic,meson8b-gpio-intc? for meson8b SoCs (S805) or
+ ?amlogic,meson-gxbb-gpio-intc? for GXBB SoCs (S905)
+- interrupt-parent : a phandle to the GIC the interrupts are routed to.
+ Usually this is provided at the root level of the device tree as it is
+ common to most of the SoC
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 2.
+
+Example:
+
+gpio_interrupt: interrupt-controller at 9880 {
+ compatible = "amlogic,meson-gxbb-gpio-intc";
+ reg = <0x0 0x9880 0x0 0x10>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/9] irqchip: meson: add support for gpio interrupt controller
From: Jerome Brunet @ 2016-10-19 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871709-8359-1-git-send-email-jbrunet@baylibre.com>
Add support for the interrupt gpio controller found on Amlogic's meson
SoC family.
Unlike what the IP name suggest, it is not directly linked to the gpio
subsystem. It is actually an independent IP that is able to spy on the
SoC pad. For that purpose, it can mux and filter (edge or level and
polarity) any single SoC pad to one of the 8 GIC's interrupts it owns.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/irqchip/Kconfig | 9 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-meson-gpio.c | 423 +++++++++++++++++++++++++++++++++++++++
3 files changed, 433 insertions(+)
create mode 100644 drivers/irqchip/irq-meson-gpio.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 82b0b5daf3f5..168837263e80 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -279,3 +279,12 @@ config EZNPS_GIC
config STM32_EXTI
bool
select IRQ_DOMAIN
+
+config MESON_GPIO_IRQ
+ bool "Meson GPIO Interrupt Multiplexer"
+ depends on ARCH_MESON || COMPILE_TEST
+ select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
+ help
+ Support Meson SoC Family GPIO Interrupt Multiplexer
+
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e4dbfc85abdb..33f913d037d0 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
+obj-$(CONFIG_MESON_GPIO_IRQ) += irq-meson-gpio.o
diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
new file mode 100644
index 000000000000..869b4df8c483
--- /dev/null
+++ b/drivers/irqchip/irq-meson-gpio.c
@@ -0,0 +1,423 @@
+/*
+ * Copyright (c) 2015 Endless Mobile, Inc.
+ * Author: Carlo Caione <carlo@endlessm.com>
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Jerome Brunet <jbrunet@baylibre.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/irqchip.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#define IRQ_FREE (-1)
+
+#define REG_EDGE_POL 0x00
+#define REG_PIN_03_SEL 0x04
+#define REG_PIN_47_SEL 0x08
+#define REG_FILTER_SEL 0x0c
+
+#define REG_EDGE_POL_MASK(x) (BIT(x) | BIT(16 + (x)))
+#define REG_EDGE_POL_EDGE(x) BIT(x)
+#define REG_EDGE_POL_LOW(x) BIT(16 + (x))
+#define REG_PIN_SEL_SHIFT(x) (((x) % 4) * 8)
+#define REG_FILTER_SEL_SHIFT(x) ((x) * 4)
+
+struct meson_gpio_irq_params {
+ unsigned int nhwirq;
+ irq_hw_number_t *source;
+ int nsource;
+};
+
+struct meson_gpio_irq_domain {
+ void __iomem *base;
+ int *map;
+ const struct meson_gpio_irq_params *params;
+};
+
+struct meson_gpio_irq_chip_data {
+ void __iomem *base;
+ int index;
+};
+
+static irq_hw_number_t meson_parent_hwirqs[] = {
+ 64, 65, 66, 67, 68, 69, 70, 71,
+};
+
+static const struct meson_gpio_irq_params meson8_params = {
+ .nhwirq = 134,
+ .source = meson_parent_hwirqs,
+ .nsource = ARRAY_SIZE(meson_parent_hwirqs),
+};
+
+static const struct meson_gpio_irq_params meson8b_params = {
+ .nhwirq = 119,
+ .source = meson_parent_hwirqs,
+ .nsource = ARRAY_SIZE(meson_parent_hwirqs),
+};
+
+static const struct meson_gpio_irq_params meson_gxbb_params = {
+ .nhwirq = 133,
+ .source = meson_parent_hwirqs,
+ .nsource = ARRAY_SIZE(meson_parent_hwirqs),
+};
+
+static const struct of_device_id meson_irq_gpio_matches[] = {
+ {
+ .compatible = "amlogic,meson8-gpio-intc",
+ .data = &meson8_params
+ },
+ {
+ .compatible = "amlogic,meson8b-gpio-intc",
+ .data = &meson8b_params
+ },
+ {
+ .compatible = "amlogic,meson-gxbb-gpio-intc",
+ .data = &meson_gxbb_params
+ },
+ {}
+};
+
+static void meson_gpio_irq_update_bits(void __iomem *base, unsigned int reg,
+ u32 mask, u32 val)
+{
+ u32 tmp;
+
+ tmp = readl(base + reg);
+ tmp &= ~mask;
+ tmp |= val;
+
+ writel(tmp, base + reg);
+}
+
+static int meson_gpio_irq_get_index(struct meson_gpio_irq_domain *domain_data,
+ int hwirq)
+{
+ int i;
+
+ for (i = 0; i < domain_data->params->nsource; i++) {
+ if (domain_data->map[i] == hwirq)
+ return i;
+ }
+
+ return -1;
+}
+
+static int mesion_gpio_irq_map_source(struct meson_gpio_irq_domain *domain_data,
+ irq_hw_number_t hwirq,
+ irq_hw_number_t *source)
+{
+ int index;
+ unsigned int reg;
+
+ index = meson_gpio_irq_get_index(domain_data, IRQ_FREE);
+ if (index < 0) {
+ pr_err("No irq available\n");
+ return -ENOSPC;
+ }
+
+ domain_data->map[index] = hwirq;
+
+ reg = (index < 4) ? REG_PIN_03_SEL : REG_PIN_47_SEL;
+ meson_gpio_irq_update_bits(domain_data->base, reg,
+ 0xff << REG_PIN_SEL_SHIFT(index),
+ hwirq << REG_PIN_SEL_SHIFT(index));
+
+ *source = domain_data->params->source[index];
+
+ pr_debug("hwirq %lu assigned to channel %d - source %lu\n",
+ hwirq, index, *source);
+
+ return index;
+}
+
+static int meson_gpio_irq_type_setup(unsigned int type, void __iomem *base,
+ int index)
+{
+ u32 val = 0;
+
+ type &= IRQ_TYPE_SENSE_MASK;
+
+ if (type == IRQ_TYPE_EDGE_BOTH)
+ return -EINVAL;
+
+ if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
+ val |= REG_EDGE_POL_EDGE(index);
+
+ if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING))
+ val |= REG_EDGE_POL_LOW(index);
+
+ meson_gpio_irq_update_bits(base, REG_EDGE_POL,
+ REG_EDGE_POL_MASK(index), val);
+
+ return 0;
+}
+
+static unsigned int meson_gpio_irq_type_output(unsigned int type)
+{
+ unsigned int sense = type & IRQ_TYPE_SENSE_MASK;
+
+ type &= ~IRQ_TYPE_SENSE_MASK;
+
+ /*
+ * If the polarity of interrupt is low, the controller will
+ * invert the signal for gic
+ */
+ if (sense & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
+ type |= IRQ_TYPE_LEVEL_HIGH;
+ else if (sense & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
+ type |= IRQ_TYPE_EDGE_RISING;
+
+ return type;
+}
+
+static int meson_gpio_irq_set_type(struct irq_data *data, unsigned int type)
+{
+ struct meson_gpio_irq_chip_data *cd = irq_data_get_irq_chip_data(data);
+ int ret;
+
+ pr_debug("set type of hwirq %lu to %u\n", data->hwirq, type);
+
+ ret = meson_gpio_irq_type_setup(type, cd->base, cd->index);
+ if (ret)
+ return ret;
+
+ return irq_chip_set_type_parent(data,
+ meson_gpio_irq_type_output(type));
+}
+
+static struct irq_chip meson_gpio_irq_chip = {
+ .name = "meson-gpio-irqchip",
+ .irq_mask = irq_chip_mask_parent,
+ .irq_unmask = irq_chip_unmask_parent,
+ .irq_eoi = irq_chip_eoi_parent,
+ .irq_set_type = meson_gpio_irq_set_type,
+ .irq_retrigger = irq_chip_retrigger_hierarchy,
+#ifdef CONFIG_SMP
+ .irq_set_affinity = irq_chip_set_affinity_parent,
+#endif
+};
+
+static int meson_gpio_irq_domain_translate(struct irq_domain *domain,
+ struct irq_fwspec *fwspec,
+ unsigned long *hwirq,
+ unsigned int *type)
+{
+ if (is_of_node(fwspec->fwnode)) {
+ if (fwspec->param_count != 2)
+ return -EINVAL;
+
+ *hwirq = fwspec->param[0];
+ *type = fwspec->param[1];
+
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int meson_gpio_irq_allocate_gic_irq(struct irq_domain *domain,
+ unsigned int virq,
+ irq_hw_number_t source,
+ unsigned int type)
+{
+ struct irq_fwspec fwspec;
+
+ if (!irq_domain_get_of_node(domain->parent))
+ return -EINVAL;
+
+ fwspec.fwnode = domain->parent->fwnode;
+ fwspec.param_count = 3;
+ fwspec.param[0] = 0; /* SPI */
+ fwspec.param[1] = source;
+ fwspec.param[2] = meson_gpio_irq_type_output(type);
+
+ return irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+}
+
+static int meson_gpio_irq_domain_alloc(struct irq_domain *domain,
+ unsigned int virq,
+ unsigned int nr_irqs,
+ void *data)
+{
+ struct irq_fwspec *fwspec = data;
+ struct meson_gpio_irq_domain *domain_data = domain->host_data;
+ struct meson_gpio_irq_chip_data *cd;
+ unsigned long hwirq, source;
+ unsigned int type;
+ int i, index, ret;
+
+ ret = meson_gpio_irq_domain_translate(domain, fwspec, &hwirq, &type);
+ if (ret)
+ return ret;
+
+ pr_debug("irq %d, nr_irqs %d, hwirqs %lu\n", virq, nr_irqs, hwirq);
+
+ for (i = 0; i < nr_irqs; i++) {
+ index = mesion_gpio_irq_map_source(domain_data, hwirq + i,
+ &source);
+ if (index < 0)
+ return index;
+
+ ret = meson_gpio_irq_type_setup(type, domain_data->base,
+ index);
+ if (ret)
+ return ret;
+
+ cd = kzalloc(sizeof(*cd), GFP_KERNEL);
+ if (!cd)
+ return -ENOMEM;
+
+ cd->base = domain_data->base;
+ cd->index = index;
+
+ irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+ &meson_gpio_irq_chip, cd);
+
+ ret = meson_gpio_irq_allocate_gic_irq(domain, virq + i,
+ source, type);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void meson_gpio_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq,
+ unsigned int nr_irqs)
+{
+ struct meson_gpio_irq_domain *domain_data = domain->host_data;
+ struct meson_gpio_irq_chip_data *cd;
+ struct irq_data *irq_data;
+ int i;
+
+ for (i = 0; i < nr_irqs; i++) {
+ irq_data = irq_domain_get_irq_data(domain, virq + i);
+ cd = irq_data_get_irq_chip_data(irq_data);
+
+ domain_data->map[cd->index] = IRQ_FREE;
+ kfree(cd);
+ }
+
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+
+}
+
+static const struct irq_domain_ops meson_gpio_irq_domain_ops = {
+ .alloc = meson_gpio_irq_domain_alloc,
+ .free = meson_gpio_irq_domain_free,
+ .translate = meson_gpio_irq_domain_translate,
+};
+
+static int __init
+meson_gpio_irq_init_domain(struct device_node *node,
+ struct meson_gpio_irq_domain *domain_data,
+ const struct meson_gpio_irq_params *params)
+{
+ int i;
+ int nsource = params->nsource;
+ int *map;
+
+ map = kcalloc(nsource, sizeof(*map), GFP_KERNEL);
+ if (!map)
+ return -ENOMEM;
+
+ for (i = 0; i < nsource; i++)
+ map[i] = IRQ_FREE;
+
+ domain_data->map = map;
+ domain_data->params = params;
+
+ return 0;
+}
+
+static int __init meson_gpio_irq_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+ struct irq_domain *domain, *parent_domain;
+ const struct of_device_id *match;
+ const struct meson_gpio_irq_params *params;
+ struct meson_gpio_irq_domain *domain_data;
+ int ret;
+
+ match = of_match_node(meson_irq_gpio_matches, node);
+ if (!match)
+ return -ENODEV;
+ params = match->data;
+
+ if (!parent) {
+ pr_err("missing parent interrupt node\n");
+ return -ENODEV;
+ }
+
+ parent_domain = irq_find_host(parent);
+ if (!parent_domain) {
+ pr_err("unable to obtain parent domain\n");
+ return -ENXIO;
+ }
+
+ domain_data = kzalloc(sizeof(*domain_data), GFP_KERNEL);
+ if (!domain_data)
+ return -ENOMEM;
+
+ domain_data->base = of_iomap(node, 0);
+ if (!domain_data->base) {
+ ret = -ENOMEM;
+ goto out_free_dev;
+ }
+
+ ret = meson_gpio_irq_init_domain(node, domain_data, params);
+ if (ret < 0)
+ goto out_free_dev_content;
+
+ domain = irq_domain_add_hierarchy(parent_domain, 0, params->nhwirq,
+ node, &meson_gpio_irq_domain_ops,
+ domain_data);
+
+ if (!domain) {
+ pr_err("failed to allocated domain\n");
+ ret = -ENOMEM;
+ goto out_free_dev_content;
+ }
+
+ pr_info("%d to %d gpio interrupt mux initialized\n",
+ params->nhwirq, params->nsource);
+
+ return 0;
+
+out_free_dev_content:
+ kfree(domain_data->map);
+ iounmap(domain_data->base);
+
+out_free_dev:
+ kfree(domain_data);
+
+ return ret;
+}
+
+IRQCHIP_DECLARE(meson8_gpio_intc, "amlogic,meson8-gpio-intc",
+ meson_gpio_irq_of_init);
+IRQCHIP_DECLARE(meson8b_gpio_intc, "amlogic,meson8b-gpio-intc",
+ meson_gpio_irq_of_init);
+IRQCHIP_DECLARE(gxbb_gpio_intc, "amlogic,meson-gxbb-gpio-intc",
+ meson_gpio_irq_of_init);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/9] irqchip: meson: add support for the gpio interrupt controller
From: Jerome Brunet @ 2016-10-19 10:08 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the GPIO interrupt controller found
on Amlogic's meson SoC families.
Unlike what the name suggests, this controller is not part of the SoC GPIO
subsystem. It's an indepedent controller which can watch almost all pad of
the SoC and generate and interrupt from it. Some pins, which are not part
of the public datasheet, don't seem to have this capability though.
Hardware wise, the controller is a 256 to 8 multiplexer. It can take up
to 256 input pads and route them to any of 8 GIC's interrupts. There is
also a filter block in the middle to select the appropriate edge or level.
The number of interrupt declared by the irqchip is lowered from 256 to the
actual number of signal routed to the controller on each SoC family. As we
have access to only 8 GIC?s interrupts, these are allocated when an
interrupt is requested from the controller, on a first come, first served
basis.
This series has been tested on Amlogic S905-P200 board with the front
panel power button. Directly passing an IRQ or using gpio_to_irq both work
with this driver.
This work is derived from the previous work of Carlo Caione [1].
Changes since RFC : [2]
* Remove interrupt property in device tree: the controller cannot generate
interrupts on its own and is merely routing the interrupt to the GIC,
therefore it should not use the interrupt property. This data is now
stored directly in the driver, same as the pinctrl data.
* Improve compatibility checking of meson pinctrl on its interrupt parent
to activate gpio_to_irq callback
* Drop IRQ_BOTH hack. Need more work to have an acceptable solution for
this
[1] : http://lkml.kernel.org/r/1448987062-31225-1-git-send-email-carlo at caione.org
[2] : http://lkml.kernel.org/r/1475593708-10526-1-git-send-email-jbrunet at baylibre.com
Jerome Brunet (9):
irqchip: meson: add support for gpio interrupt controller
dt-bindings: interrupt-controller: add DT binding for meson GPIO
interrupt controller
pinctrl: meson: update pinctrl data with gpio irq data
pinctrl: meson: allow gpio to request irq
dt-bindings: pinctrl: meson: update gpio dt-bindings
ARM64: meson: enable MESON_IRQ_GPIO in Kconfig
ARM: meson: enable MESON_IRQ_GPIO in Kconfig for meson8
ARM64: dts: amlogic: enable gpio interrupt controller on gxbb
ARM: dts: amlogic: enable gpio interrupt controller on meson8
.../amlogic,meson-gpio-intc.txt | 31 ++
.../devicetree/bindings/pinctrl/meson,pinctrl.txt | 4 +
arch/arm/boot/dts/meson8.dtsi | 11 +
arch/arm/boot/dts/meson8b.dtsi | 11 +
arch/arm/mach-meson/Kconfig | 2 +
arch/arm64/Kconfig.platforms | 1 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 9 +
drivers/irqchip/Kconfig | 9 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-meson-gpio.c | 423 +++++++++++++++++++++
drivers/pinctrl/Kconfig | 2 +
drivers/pinctrl/meson/pinctrl-meson-gxbb.c | 24 +-
drivers/pinctrl/meson/pinctrl-meson.c | 77 +++-
drivers/pinctrl/meson/pinctrl-meson.h | 17 +-
drivers/pinctrl/meson/pinctrl-meson8.c | 22 +-
drivers/pinctrl/meson/pinctrl-meson8b.c | 34 +-
16 files changed, 641 insertions(+), 37 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt
create mode 100644 drivers/irqchip/irq-meson-gpio.c
--
2.7.4
^ permalink raw reply
* [PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap
From: Arvind Yadav @ 2016-10-19 10:04 UTC (permalink / raw)
To: linux-arm-kernel
Free memory mapping, if hdmi_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..ba28dec 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
err_hdmiphy:
if (hdata->hdmiphy_port)
put_device(&hdata->hdmiphy_port->dev);
+ if (hdata->regs_hdmiphy)
+ iounmap(hdata->regs_hdmiphy);
err_ddc:
put_device(&hdata->ddc_adpt->dev);
@@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata->hdmiphy_port)
put_device(&hdata->hdmiphy_port->dev);
+ if (hdata->regs_hdmiphy)
+ iounmap(hdata->regs_hdmiphy);
+
put_device(&hdata->ddc_adpt->dev);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] cpufreq: retire the Integrator cpufreq driver
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org>
After switching the core module clocks controlling the Integrator
clock frequencies to the common clock framework, defining the
operating points in the device tree, and activating the generic
DT-based CPUfreq driver, we can retire the old Integrator
cpufreq driver.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/Kconfig.arm | 8 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/integrator-cpufreq.c | 239 -----------------------------------
3 files changed, 248 deletions(-)
delete mode 100644 drivers/cpufreq/integrator-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..fdbc630272b3 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -60,14 +60,6 @@ config ARM_IMX6Q_CPUFREQ
If in doubt, say N.
-config ARM_INTEGRATOR
- tristate "CPUfreq driver for ARM Integrator CPUs"
- depends on ARCH_INTEGRATOR
- default y
- help
- This enables the CPUfreq driver for ARM Integrator CPUs.
- If in doubt, say Y.
-
config ARM_KIRKWOOD_CPUFREQ
def_bool MACH_KIRKWOOD
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0a9b6a093646..7dde82179d62 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -56,7 +56,6 @@ obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ) += highbank-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) += imx6q-cpufreq.o
-obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
diff --git a/drivers/cpufreq/integrator-cpufreq.c b/drivers/cpufreq/integrator-cpufreq.c
deleted file mode 100644
index 79e3ff2771a6..000000000000
--- a/drivers/cpufreq/integrator-cpufreq.c
+++ /dev/null
@@ -1,239 +0,0 @@
-/*
- * Copyright (C) 2001-2002 Deep Blue Solutions Ltd.
- *
- * 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.
- *
- * CPU support functions
- */
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/cpufreq.h>
-#include <linux/sched.h>
-#include <linux/smp.h>
-#include <linux/init.h>
-#include <linux/io.h>
-#include <linux/platform_device.h>
-#include <linux/of.h>
-#include <linux/of_address.h>
-
-#include <asm/mach-types.h>
-#include <asm/hardware/icst.h>
-
-static void __iomem *cm_base;
-/* The cpufreq driver only use the OSC register */
-#define INTEGRATOR_HDR_OSC_OFFSET 0x08
-#define INTEGRATOR_HDR_LOCK_OFFSET 0x14
-
-static struct cpufreq_driver integrator_driver;
-
-static const struct icst_params lclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 8,
- .vd_max = 132,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-static const struct icst_params cclk_params = {
- .ref = 24000000,
- .vco_max = ICST525_VCO_MAX_5V,
- .vco_min = ICST525_VCO_MIN,
- .vd_min = 12,
- .vd_max = 160,
- .rd_min = 24,
- .rd_max = 24,
- .s2div = icst525_s2div,
- .idx2s = icst525_idx2s,
-};
-
-/*
- * Validate the speed policy.
- */
-static int integrator_verify_policy(struct cpufreq_policy *policy)
-{
- struct icst_vco vco;
-
- cpufreq_verify_within_cpu_limits(policy);
-
- vco = icst_hz_to_vco(&cclk_params, policy->max * 1000);
- policy->max = icst_hz(&cclk_params, vco) / 1000;
-
- vco = icst_hz_to_vco(&cclk_params, policy->min * 1000);
- policy->min = icst_hz(&cclk_params, vco) / 1000;
-
- cpufreq_verify_within_cpu_limits(policy);
- return 0;
-}
-
-
-static int integrator_set_target(struct cpufreq_policy *policy,
- unsigned int target_freq,
- unsigned int relation)
-{
- cpumask_t cpus_allowed;
- int cpu = policy->cpu;
- struct icst_vco vco;
- struct cpufreq_freqs freqs;
- u_int cm_osc;
-
- /*
- * Save this threads cpus_allowed mask.
- */
- cpus_allowed = current->cpus_allowed;
-
- /*
- * Bind to the specified CPU. When this call returns,
- * we should be running on the right CPU.
- */
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* get current setting */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else if (machine_is_cintegrator())
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
- freqs.old = icst_hz(&cclk_params, vco) / 1000;
-
- /* icst_hz_to_vco rounds down -- so we need the next
- * larger freq in case of CPUFREQ_RELATION_L.
- */
- if (relation == CPUFREQ_RELATION_L)
- target_freq += 999;
- if (target_freq > policy->max)
- target_freq = policy->max;
- vco = icst_hz_to_vco(&cclk_params, target_freq * 1000);
- freqs.new = icst_hz(&cclk_params, vco) / 1000;
-
- if (freqs.old == freqs.new) {
- set_cpus_allowed_ptr(current, &cpus_allowed);
- return 0;
- }
-
- cpufreq_freq_transition_begin(policy, &freqs);
-
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator()) {
- cm_osc &= 0xfffff800;
- cm_osc |= vco.s << 8;
- } else if (machine_is_cintegrator()) {
- cm_osc &= 0xffffff00;
- }
- cm_osc |= vco.v;
-
- __raw_writel(0xa05f, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
- __raw_writel(cm_osc, cm_base + INTEGRATOR_HDR_OSC_OFFSET);
- __raw_writel(0, cm_base + INTEGRATOR_HDR_LOCK_OFFSET);
-
- /*
- * Restore the CPUs allowed mask.
- */
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- cpufreq_freq_transition_end(policy, &freqs, 0);
-
- return 0;
-}
-
-static unsigned int integrator_get(unsigned int cpu)
-{
- cpumask_t cpus_allowed;
- unsigned int current_freq;
- u_int cm_osc;
- struct icst_vco vco;
-
- cpus_allowed = current->cpus_allowed;
-
- set_cpus_allowed_ptr(current, cpumask_of(cpu));
- BUG_ON(cpu != smp_processor_id());
-
- /* detect memory etc. */
- cm_osc = __raw_readl(cm_base + INTEGRATOR_HDR_OSC_OFFSET);
-
- if (machine_is_integrator())
- vco.s = (cm_osc >> 8) & 7;
- else
- vco.s = 1;
- vco.v = cm_osc & 255;
- vco.r = 22;
-
- current_freq = icst_hz(&cclk_params, vco) / 1000; /* current freq */
-
- set_cpus_allowed_ptr(current, &cpus_allowed);
-
- return current_freq;
-}
-
-static int integrator_cpufreq_init(struct cpufreq_policy *policy)
-{
-
- /* set default policy and cpuinfo */
- policy->max = policy->cpuinfo.max_freq = 160000;
- policy->min = policy->cpuinfo.min_freq = 12000;
- policy->cpuinfo.transition_latency = 1000000; /* 1 ms, assumed */
-
- return 0;
-}
-
-static struct cpufreq_driver integrator_driver = {
- .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK,
- .verify = integrator_verify_policy,
- .target = integrator_set_target,
- .get = integrator_get,
- .init = integrator_cpufreq_init,
- .name = "integrator",
-};
-
-static int __init integrator_cpufreq_probe(struct platform_device *pdev)
-{
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENODEV;
-
- cm_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
- if (!cm_base)
- return -ENODEV;
-
- return cpufreq_register_driver(&integrator_driver);
-}
-
-static int __exit integrator_cpufreq_remove(struct platform_device *pdev)
-{
- return cpufreq_unregister_driver(&integrator_driver);
-}
-
-static const struct of_device_id integrator_cpufreq_match[] = {
- { .compatible = "arm,core-module-integrator"},
- { },
-};
-
-MODULE_DEVICE_TABLE(of, integrator_cpufreq_match);
-
-static struct platform_driver integrator_cpufreq_driver = {
- .driver = {
- .name = "integrator-cpufreq",
- .of_match_table = integrator_cpufreq_match,
- },
- .remove = __exit_p(integrator_cpufreq_remove),
-};
-
-module_platform_driver_probe(integrator_cpufreq_driver,
- integrator_cpufreq_probe);
-
-MODULE_AUTHOR("Russell M. King");
-MODULE_DESCRIPTION("cpufreq driver for ARM Integrator CPUs");
-MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] ARM: defconfig: turn on the DT cpufreq for Integrator
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org>
The Integrators are now migrated to handle the CPUfreq
scaling using the generic devicetree CPUfreq driver using the
common clock framework and have the required device tree
modifications, so turn off the old driver and turn on the new
generic driver.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/integrator_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/integrator_defconfig b/arch/arm/configs/integrator_defconfig
index 869faae67201..69cb8f1efcea 100644
--- a/arch/arm/configs/integrator_defconfig
+++ b/arch/arm/configs/integrator_defconfig
@@ -26,6 +26,7 @@ CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: Add Integrator/CP cpus node and operating points
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org>
This adds the cpus node to the Integrator/CP device tree so
that we have a proper placeholder to put in the DT-defined
operating points for the generic DT/OPP cpufreq driver,
along with two working operating points.
I have only put in 48 and 50 MHz because going to e.g. 36
MHz hangs the system when CLCD graphics are active.
Presumably the memory bus gets to slow to feed the display
and the systems hangs for this reason. The ideal solution
would be for the display controller to put constraints on
the memory bus frequency, but that need to be a separate
longer-term project.
We define a CPU node since this is required for cpufreq-dt,
however we do not define any compatible string for the CPU
since this architecture has pluggable CPU modules and we
do not know which one will be used. If necessary, the CPU
compatible can be filled in by the boot loader, but for
just cpufreq-dt it is not required.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/integratorcp.dts | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/integratorcp.dts b/arch/arm/boot/dts/integratorcp.dts
index 1b5e4b006b72..97f38b57a702 100644
--- a/arch/arm/boot/dts/integratorcp.dts
+++ b/arch/arm/boot/dts/integratorcp.dts
@@ -13,6 +13,32 @@
bootargs = "root=/dev/ram0 console=ttyAMA0,38400n8 earlyprintk";
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ /*
+ * Since the board has pluggable CPU modules, we
+ * cannot define a proper compatible here. Let the
+ * boot loader fill in the apropriate compatible
+ * string if necessary.
+ */
+ /* compatible = "arm,arm920t"; */
+ reg = <0>;
+ /*
+ * TBD comment.
+ */
+ /* kHz uV */
+ operating-points = <50000 0
+ 48000 0>;
+ clocks = <&cmcore>;
+ clock-names = "cpu";
+ clock-latency = <1000000>; /* 1 ms */
+ };
+ };
+
/*
* The Integrator/CP overall clocking architecture can be found in
* ARM DUI 0184B page 7-28 "Integrator/CP922T system clocks" which
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: Add Integrator/AP cpus node and operating points
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org>
This adds the cpus node to the Integrator/AP device tree so
that we have a proper placeholder to put in the DT-defined
operating points for the generic DT/OPP cpufreq driver,
along with the proper operating points.
The old Integrator cpufreq driver would resolve the max
frequency to 71MHz, and the min frequency to 12 MHz, but
the clock driver can actually handle any frequency inbetween
so I picked a few select frequencies as OPPs. The cpufreq
framework doesn't seem to deal with sliding frequency scales,
only fixed points so 7 OPPs is better than 2 atleast.
We define a CPU node since this is required for cpufreq-dt,
however we do not define any compatible string for the CPU
since this architecture has pluggable CPU modules and we
do not know which one will be used. If necessary, the CPU
compatible can be filled in by the boot loader, but for
just cpufreq-dt it is not required.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/boot/dts/integratorap.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/integratorap.dts b/arch/arm/boot/dts/integratorap.dts
index 6f16d09dc5a4..e8b249f92fb3 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -10,6 +10,41 @@
compatible = "arm,integrator-ap";
dma-ranges = <0x80000000 0x0 0x80000000>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ /*
+ * Since the board has pluggable CPU modules, we
+ * cannot define a proper compatible here. Let the
+ * boot loader fill in the apropriate compatible
+ * string if necessary.
+ */
+ /* compatible = "arm,arm926ej-s"; */
+ reg = <0>;
+ /*
+ * The documentation in ARM DUI 0138E page 3-12 states
+ * that the maximum frequency for this clock is 200 MHz
+ * but painful trial-and-error has proved to me that it
+ * is actually just hanging the system above 71 MHz.
+ * Sad but true.
+ */
+ /* kHz uV */
+ operating-points = <71000 0
+ 66000 0
+ 60000 0
+ 48000 0
+ 36000 0
+ 24000 0
+ 12000 0>;
+ clocks = <&cmosc>;
+ clock-names = "cpu";
+ clock-latency = <1000000>; /* 1 ms */
+ };
+ };
+
aliases {
arm,timer-primary = &timer2;
arm,timer-secondary = &timer1;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] cpufreq: enable the DT cpufreq driver on the Integrators
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476871154-32243-1-git-send-email-linus.walleij@linaro.org>
This enables the generic DT and OPP-based cpufreq driver on the
ARM Integrator/AP and Integrator/CP.
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 71267626456b..142a6f615e52 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -26,6 +26,9 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "allwinner,sun8i-a83t", },
{ .compatible = "allwinner,sun8i-h3", },
+ { .compatible = "arm,integrator-ap", },
+ { .compatible = "arm,integrator-cp", },
+
{ .compatible = "hisilicon,hi6220", },
{ .compatible = "fsl,imx27", },
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] Switch to the DT cpufreq policy on the Integrator
From: Linus Walleij @ 2016-10-19 9:59 UTC (permalink / raw)
To: linux-arm-kernel
This switches the ARM Integrator/AP and Integrator/CP to use the
Device Tree cpufreq policy with its definition of operating points
using the generic OPP library.
The Integrators does not need to control a regulator to switch
frequency, only a clock. This clock and its device tree bindings
have been defined in the device tree and merged upstream for v4.9.
This approach provides a little better granularity on the
Integrator/AP where I defined a few operating points: before
this change the Integrator would just switch between min speed
(12 MHz) and max speed (71 MHz). Now it can switch between a
few arbitrarily chosen OPPs as in the examples below:
The following tests were made on the Integrator/AP:
/sys/devices/system/cpu/cpufreq/policy0 echo ondemand > scaling_governor
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 24000000 Hz
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 24000000 Hz
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 24000000 Hz --> 12000000 Hz
The switch from 12 to 24 MHz is triggered by as little as using the
command line with the ondemand governor. If we do this:
yes > /dev/null &
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 36000000 Hz
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 36000000 Hz --> 71000000 Hz
pkill yes
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
So the algorithm is indeed using all the OPPs.
Also as a confirmation test to make sure performance is affected by the
speed changes, we set the performance governor and:
echo 12000 > scaling_max_freq
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 71000000 Hz --> 12000000 Hz
time find /sys|sort|uniq > /dev/null
real 0m 45.51s
user 0m 11.15s
sys 0m 26.74s
echo 71000 > scaling_max_freq
cpu cpu0: dev_pm_opp_set_rate: switching OPP: 12000000 Hz --> 71000000 Hz
time find /sys|sort|uniq
> /dev/null
real 0m 9.13s
user 0m 2.35s
sys 0m 5.50s
So it is working.
If people are happy with this approach and approve of the patches
I'd like an ACK from the cpufreq people and then merge the whole set
through ARM SoC.
Linus Walleij (5):
cpufreq: enable the DT cpufreq driver on the Integrators
ARM: dts: Add Integrator/AP cpus node and operating points
ARM: dts: Add Integrator/CP cpus node and operating points
ARM: defconfig: turn on the DT cpufreq for Integrator
cpufreq: retire the Integrator cpufreq driver
arch/arm/boot/dts/integratorap.dts | 35 +++++
arch/arm/boot/dts/integratorcp.dts | 26 ++++
arch/arm/configs/integrator_defconfig | 1 +
drivers/cpufreq/Kconfig.arm | 8 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
drivers/cpufreq/integrator-cpufreq.c | 239 ----------------------------------
7 files changed, 65 insertions(+), 248 deletions(-)
delete mode 100644 drivers/cpufreq/integrator-cpufreq.c
--
2.7.4
^ permalink raw reply
* [PATCH] clk: sunxi-ng: sun6i-a31: Force AHB1 clock to use PLL6 as parent
From: Maxime Ripard @ 2016-10-19 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018054209.24546-1-wens@csie.org>
On Tue, Oct 18, 2016 at 01:42:09PM +0800, Chen-Yu Tsai wrote:
> On the A31, the DMA engine only works if AHB1 is clocked from PLL6.
> In addition, the hstimer is clocked from AHB1, and if AHB1 is clocked
> from the CPU clock, and cpufreq is working, we get an unstable timer.
>
> Force the AHB1 clock to use PLL6 as its parent. Previously this was done
> in the device tree with the assigned-clocks and assigned-clocks-parent
> bindings. However with this new monolithic driver, the system critical
> clocks aren't exported through the device tree. The alternative is to
> force this setting in the driver before the clocks are registered.
>
> This is also done in newer versions of mainline U-boot. But people still
> using an older version, or even the vendor version, can still hit this
> issue. Hence the need to do it in the kernel as well.
>
> Reported-by: Hans de Goede <hdegoede@redhat.com>
> Reported-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/bc1a6152/attachment-0001.sig>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: Pavel Machek @ 2016-10-19 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018104539.GB15639@leverpostej>
On Tue 2016-10-18 11:45:39, Mark Rutland wrote:
> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
> > > >b. in arm64, if some platform has its own suspend flow, couldn't it
> > > >adopts arm/match-xxx to register its own global suspend method?
> > >
> > > No, PSCI is highly recommended.
> >
> > Relying on firmware for suspend on x86 was a great disaster, lets not repeat
> > that mistake. arm32 has better powermanagement than x86 ever will (see Nokia N900
> > for example) -- feel free to copy that code from arm32.
>
> Quite frankly, copying hundreds of lines of board-specific code
> (including assembly that won't compile) is unlikely to help.
>
> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
> PSCI). That cleanly separates concerns (e.g. anyone can implement the
> backend without mandatory changes to the kernel), and keeps things
> maintainable.
Either the lowlevel suspend code is stable and bug free, and then
having that code is not a problem. Or the lowlevel suspend code is
complex enough to contain some bugs, and in such case it is better to
debug and update it with kernel.
> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
> can use and build atop of. It's open source (three-clause BSD with DCO),
> and accepts board ports. You can have a completely open stack,
> regardless of whether part of that stack is firmware.
If something is called "Trusted", it is not trustworthy.
BSD is better than closed source, but it also means that you will not
get the sources from your hw vendor.
Being separate module means it will be never updated.
Being separate module means it will be hard to debug, in area where
debugging is already pretty hard.
Can it do advanced stuff like deep powersaving on N900 idle?
Just don't do it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/05d8de63/attachment.sig>
^ permalink raw reply
* [PATCH] reset: uniphier: rename MIO reset to SD reset for Pro5, PXs2, LD20 SoCs
From: Philipp Zabel @ 2016-10-19 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476865429-13143-1-git-send-email-yamada.masahiro@socionext.com>
Hi Masahiro,
Am Mittwoch, den 19.10.2016, 17:23 +0900 schrieb Masahiro Yamada:
> I made a mistake as for naming for this block. The MIO block is not
> implemented for these 3 SoCs in the first place. The current naming
> will be a trouble if an SoC with both MIO and SD-ctrl blocks appear
> in the future.
>
> This driver has just been merged in the previous merge window.
> Rename it before the release.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Philipp,
>
> If you do not mind, may I include this in my PR
> along with the "select ARCH_HAS_RESET_CONTROLLER" patches?
Should be fine, I don't see any potential for conflicts with the reset
tree.
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
> .../devicetree/bindings/reset/uniphier-reset.txt | 22 +++++++++++-----------
> drivers/reset/reset-uniphier.c | 16 ++++++++--------
> 2 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index e6bbfcc..78cd735 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -19,12 +19,12 @@ Required properties:
> Example:
>
> sysctrl at 61840000 {
> - compatible = "socionext,uniphier-ld20-sysctrl",
> + compatible = "socionext,uniphier-ld11-sysctrl",
> "simple-mfd", "syscon";
> reg = <0x61840000 0x4000>;
>
> reset {
> - compatible = "socionext,uniphier-ld20-reset";
> + compatible = "socionext,uniphier-ld11-reset";
> #reset-cells = <1>;
> };
>
> @@ -32,8 +32,8 @@ Example:
> };
>
>
> -Media I/O (MIO) reset
> ----------------------
> +Media I/O (MIO) reset, SD reset
> +-------------------------------
>
> Required properties:
> - compatible: should be one of the following:
> @@ -41,21 +41,21 @@ Required properties:
> "socionext,uniphier-ld4-mio-reset" - for PH1-LD4 SoC.
> "socionext,uniphier-pro4-mio-reset" - for PH1-Pro4 SoC.
> "socionext,uniphier-sld8-mio-reset" - for PH1-sLD8 SoC.
> - "socionext,uniphier-pro5-mio-reset" - for PH1-Pro5 SoC.
> - "socionext,uniphier-pxs2-mio-reset" - for ProXstream2/PH1-LD6b SoC.
> + "socionext,uniphier-pro5-sd-reset" - for PH1-Pro5 SoC.
> + "socionext,uniphier-pxs2-sd-reset" - for ProXstream2/PH1-LD6b SoC.
> "socionext,uniphier-ld11-mio-reset" - for PH1-LD11 SoC.
> - "socionext,uniphier-ld20-mio-reset" - for PH1-LD20 SoC.
> + "socionext,uniphier-ld20-sd-reset" - for PH1-LD20 SoC.
> - #reset-cells: should be 1.
>
> Example:
>
> mioctrl at 59810000 {
> - compatible = "socionext,uniphier-ld20-mioctrl",
> + compatible = "socionext,uniphier-ld11-mioctrl",
> "simple-mfd", "syscon";
> reg = <0x59810000 0x800>;
>
> reset {
> - compatible = "socionext,uniphier-ld20-mio-reset";
> + compatible = "socionext,uniphier-ld11-mio-reset";
> #reset-cells = <1>;
> };
>
> @@ -80,12 +80,12 @@ Required properties:
> Example:
>
> perictrl at 59820000 {
> - compatible = "socionext,uniphier-ld20-perictrl",
> + compatible = "socionext,uniphier-ld11-perictrl",
> "simple-mfd", "syscon";
> reg = <0x59820000 0x200>;
>
> reset {
> - compatible = "socionext,uniphier-ld20-peri-reset";
> + compatible = "socionext,uniphier-ld11-peri-reset";
> #reset-cells = <1>;
> };
>
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 8b2558e..968c3ae 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -154,7 +154,7 @@ struct uniphier_reset_data {
> UNIPHIER_RESET_END,
> };
>
> -const struct uniphier_reset_data uniphier_pro5_mio_reset_data[] = {
> +const struct uniphier_reset_data uniphier_pro5_sd_reset_data[] = {
> UNIPHIER_MIO_RESET_SD(0, 0),
> UNIPHIER_MIO_RESET_SD(1, 1),
> UNIPHIER_MIO_RESET_EMMC_HW_RESET(6, 1),
> @@ -360,7 +360,7 @@ static int uniphier_reset_probe(struct platform_device *pdev)
> .compatible = "socionext,uniphier-ld20-reset",
> .data = uniphier_ld20_sys_reset_data,
> },
> - /* Media I/O reset */
> + /* Media I/O reset, SD reset */
> {
> .compatible = "socionext,uniphier-sld3-mio-reset",
> .data = uniphier_sld3_mio_reset_data,
> @@ -378,20 +378,20 @@ static int uniphier_reset_probe(struct platform_device *pdev)
> .data = uniphier_sld3_mio_reset_data,
> },
> {
> - .compatible = "socionext,uniphier-pro5-mio-reset",
> - .data = uniphier_pro5_mio_reset_data,
> + .compatible = "socionext,uniphier-pro5-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> },
> {
> - .compatible = "socionext,uniphier-pxs2-mio-reset",
> - .data = uniphier_pro5_mio_reset_data,
> + .compatible = "socionext,uniphier-pxs2-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> },
> {
> .compatible = "socionext,uniphier-ld11-mio-reset",
> .data = uniphier_sld3_mio_reset_data,
> },
> {
> - .compatible = "socionext,uniphier-ld20-mio-reset",
> - .data = uniphier_pro5_mio_reset_data,
> + .compatible = "socionext,uniphier-ld20-sd-reset",
> + .data = uniphier_pro5_sd_reset_data,
> },
> /* Peripheral reset */
> {
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Neil Armstrong @ 2016-10-19 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018221744.5e574e82@bbrezillon>
Hi Boris,
On 10/18/2016 10:17 PM, Boris Brezillon wrote:
> Hi Neil,
>
> On Tue, 18 Oct 2016 11:09:27 +0200
> Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
>> This is a simple memory mapped NAND controller with single chip select and
>> software ECC.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
>> drivers/mtd/nand/Kconfig | 5 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
>> 4 files changed, 174 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> create mode 100644 drivers/mtd/nand/oxnas_nand.c
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/oxnas-nand.txt b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> new file mode 100644
>> index 0000000..83b684d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/oxnas-nand.txt
>> @@ -0,0 +1,24 @@
>> +* Oxford Semiconductor OXNAS NAND Controller
>> +
>> +Please refer to nand.txt for generic information regarding MTD NAND bindings.
>> +
>> +Required properties:
>> + - compatible: "oxsemi,ox820-nand"
>> + - reg: Base address and length for NAND mapped memory.
>> +
>> +Optional Properties:
>> + - clocks: phandle to the NAND gate clock if needed.
>> + - resets: phandle to the NAND reset control if needed.
>> +
>> +Example:
>> +
>> +nand: nand at 41000000 {
>> + compatible = "oxsemi,ox820-nand";
>> + reg = <0x41000000 0x100000>;
>> + nand-ecc-mode = "soft";
>> + clocks = <&stdclk CLK_820_NAND>;
>> + resets = <&reset RESET_NAND>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + status = "disabled";
>> +};
>
> Can you switch to new DT representation for NAND controllers, with one
> node for the NAND controller and NAND devices connected to this NAND
> controller defined as sub-nodes of this NAND controller [1]?
Yes, I was wondering if this existed... my bad, next time I will search further.
>
>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>> index 7b7a887..c023125 100644
>> --- a/drivers/mtd/nand/Kconfig
>> +++ b/drivers/mtd/nand/Kconfig
>> @@ -426,6 +426,11 @@ config MTD_NAND_ORION
>> No board specific support is done by this driver, each board
>> must advertise a platform_device for the driver to attach.
>>
>> +config MTD_NAND_OXNAS
>> + tristate "NAND Flash support for Oxford Semiconductor SoC"
>> + help
>> + This enables the NAND flash controller on Oxford Semiconductor SoCs.
>> +
>> config MTD_NAND_FSL_ELBC
>> tristate "NAND support for Freescale eLBC controllers"
>> depends on FSL_SOC
>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
>> index cafde6f..05fc054 100644
>> --- a/drivers/mtd/nand/Makefile
>> +++ b/drivers/mtd/nand/Makefile
>> @@ -35,6 +35,7 @@ obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
>> obj-$(CONFIG_MTD_NAND_PLATFORM) += plat_nand.o
>> obj-$(CONFIG_MTD_NAND_PASEMI) += pasemi_nand.o
>> obj-$(CONFIG_MTD_NAND_ORION) += orion_nand.o
>> +obj-$(CONFIG_MTD_NAND_OXNAS) += oxnas_nand.o
>> obj-$(CONFIG_MTD_NAND_FSL_ELBC) += fsl_elbc_nand.o
>> obj-$(CONFIG_MTD_NAND_FSL_IFC) += fsl_ifc_nand.o
>> obj-$(CONFIG_MTD_NAND_FSL_UPM) += fsl_upm.o
>> diff --git a/drivers/mtd/nand/oxnas_nand.c b/drivers/mtd/nand/oxnas_nand.c
>> new file mode 100644
>> index 0000000..ee402ab
>> --- /dev/null
>> +++ b/drivers/mtd/nand/oxnas_nand.c
>> @@ -0,0 +1,144 @@
>> +/*
>> + * Oxford Semiconductor OXNAS NAND driver
>> + *
>> + * Heavily based on plat_nand.c :
>> + * Author: Vitaly Wool <vitalywool@gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/clk.h>
>> +#include <linux/reset.h>
>> +#include <linux/mtd/mtd.h>
>> +#include <linux/mtd/nand.h>
>> +#include <linux/mtd/partitions.h>
>> +
>> +/* nand commands */
>> +#define NAND_CMD_ALE BIT(18)
>> +#define NAND_CMD_CLE BIT(19)
>> +#define NAND_CMD_CS 0
>
> I guess this is zero here because you only support connecting a NAND to
> CS0.
> It's probably something like
>
> OX820_NAND_CS(x) ((x) << CS_FIELD_SHIFT)
The hardware seems to be able to drive multiple chip selects, but no implementation does this.
We will stick to CS0 only here for test reasons.
>
>> +#define NAND_CMD_RESET 0xff
>
> Why do you have to redefine it? it's already defined here [2].
>
>> +#define NAND_CMD (NAND_CMD_CS | NAND_CMD_CLE)
>> +#define NAND_ADDR (NAND_CMD_CS | NAND_CMD_ALE)
>> +#define NAND_DATA (NAND_CMD_CS)
>
> Please prefix those macros with OX820, has stated above, this can
> conflict with generic definitions.
> Also, I'm not sure you should pass the CS information here.
>
>> +
>> +struct oxnas_nand_data {
>> + struct nand_chip chip;
>> + void __iomem *io_base;
>> + struct clk *clk;
>> +};
>
> Even if your driver does not seem to support connecting several chips
> to the same controller, I'd like you to clearly separate the NAND
> controller and NAND chip objects:
>
> #define OXNAS_NAND_MAX_CHIPS 1
>
> struct oxnas_nand_controller {
> struct nand_hw_control base;
> void __iomem *io_base;
> struct clk *clk;
> struct nand_chip *chips[OXNAS_NAND_MAX_CHIPS];
> }
Ok.
>
>> +
>> +static void oxnas_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
>> + unsigned int ctrl)
>> +{
>> + struct nand_chip *this = mtd->priv;
>> + unsigned long nandaddr = (unsigned long) this->IO_ADDR_W;
>
> Please use the ->io_base field directly, and do not use ->IO_ADDR_W/R
> (I'd like to get rid of them at some point).
Yes, it seems cleaner.
>
> Also, declare the nandaddr as a void __iomem *, and use the '+'
> operator instead of '|'.
>
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + nandaddr &= ~(NAND_CMD | NAND_ADDR);
>
> This is not needed.
>
>> + if (ctrl & NAND_CLE)
>> + nandaddr |= NAND_CMD;
>> + else if (ctrl & NAND_ALE)
>> + nandaddr |= NAND_ADDR;
>> + this->IO_ADDR_W = (void __iomem *) nandaddr;
>
> This is not needed, is it?
No more if we stick to ->io_base
>
>> + }
>> +
>> + if (cmd != NAND_CMD_NONE)
>> + writeb(cmd, (void __iomem *) nandaddr);
>> +}
>> +
>> +/*
>> + * Probe for the NAND device.
>> + */
>> +static int oxnas_nand_probe(struct platform_device *pdev)
>> +{
>> + struct oxnas_nand_data *data;
>> + struct mtd_info *mtd;
>> + struct resource *res;
>> + int err = 0;
>> +
>> + /* Allocate memory for the device structure (and zero it) */
>> + data = devm_kzalloc(&pdev->dev, sizeof(struct oxnas_nand_data),
>> + GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + data->io_base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(data->io_base))
>> + return PTR_ERR(data->io_base);
>> +
>> + data->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(data->clk))
>> + data->clk = NULL;
>> +
>> + nand_set_flash_node(&data->chip, pdev->dev.of_node);
>> + mtd = nand_to_mtd(&data->chip);
>> + mtd->dev.parent = &pdev->dev;
>> + mtd->priv = &data->chip;
>> +
>> + data->chip.IO_ADDR_R = data->io_base;
>> + data->chip.IO_ADDR_W = data->io_base;
>
> As I said above, don't use these fields.
>
>> + data->chip.cmd_ctrl = oxnas_nand_cmd_ctrl;
>> + data->chip.chip_delay = 30;
>> + data->chip.ecc.mode = NAND_ECC_SOFT;
>> + data->chip.ecc.algo = NAND_ECC_HAMMING;
>
> Probably a good idea to support soft ECC as well...
This was taken from plat_nand.c, I was not sure if it was necessary, will remove this and rely on DT attributes.
>
>> +
>> + platform_set_drvdata(pdev, data);
>> +
>> + clk_prepare_enable(data->clk);
>> + device_reset_optional(&pdev->dev);
>> +
>> + /* Scan to find existence of the device */
>> + if (nand_scan(mtd, 1)) {
>
> Why not returning nand_scan() error code?
Same, bad plat_nand.c copy/paste.
>
>> + err = -ENXIO;
>> + goto out;
>
> Return directly here.
>
>> + }
>> +
>> + err = mtd_device_parse_register(mtd, NULL, NULL, NULL, 0);
>
> Use mtd_device_register() here.
>
>> + if (!err)
>> + return err;
>> +
>> + nand_release(mtd);
>
> Why not
>
> if (err)
> nand_release(mtd);
>
>> +out:
>
> Drop this label.
Will refactor this error management.
>
>> + return err;
>> +}
>> +
>> +static int oxnas_nand_remove(struct platform_device *pdev)
>> +{
>> + struct oxnas_nand_data *data = platform_get_drvdata(pdev);
>> +
>> + nand_release(nand_to_mtd(&data->chip));
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id oxnas_nand_match[] = {
>> + { .compatible = "oxsemi,ox820-nand" },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, oxnas_nand_match);
>> +
>> +static struct platform_driver oxnas_nand_driver = {
>> + .probe = oxnas_nand_probe,
>> + .remove = oxnas_nand_remove,
>> + .driver = {
>> + .name = "oxnas_nand",
>> + .of_match_table = oxnas_nand_match,
>> + },
>> +};
>> +
>> +module_platform_driver(oxnas_nand_driver);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Vitaly Wool");
>> +MODULE_DESCRIPTION("Oxnas NAND driver");
>> +MODULE_ALIAS("platform:oxnas_nand");
>
> Thanks,
>
> Boris
Thanks,
Neil
>
> [1]https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/nand.txt?id=refs/tags/v4.9-rc1#n57
> [2]http://lxr.free-electrons.com/source/include/linux/mtd/nand.h#L90
>
^ permalink raw reply
* partial bluetooth success on n900 [was Re: bluetooth/uart timeout handling]
From: Pavel Machek @ 2016-10-19 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018224259.jrwbaal27irzjqyo@earth>
Hi!
[Ccing lists.]
> Can you push the patch, which gets further than negotiation into
> some git branch available to me? I tried to apply your patch to
> my code, but it did not work for me.
Ok, I've pushed the branch to kernel.org:
git push git at gitolite.kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900.git bt-2-v4.9:bt-2-v4.9
In retrospect, I did make some changes to dts, they may be neccessary,
too.
If it still does not work, please try with my .config. I'm using
modules here, using this script:
pavel at n900:/my/modules$ cat run2
echo removing...
sudo killall a.out
rmmod nokia_h4p
#rmmod omap_serial
#rmmod serial_core
rmmod hci_uart.ko
#rmmod bcm2048.ko
echo installing...
insmod serial_core.ko
insmod omap-serial.ko
insmod bcm2048.ko
insmod hci_uart.ko
ls -al /dev/ttyO1
sleep 1
stty crtscts < /dev/ttyO1
/my/tui/ofone/a.out &
For the record, dmesg says:
Good luck,
Pavel
[ 30.694274] g_ether gadget: notify connect true
[ 30.714080] g_ether gadget: notify speed 425984000
[ 127.719146] ssi-protocol ssi-protocol: WAKELINES TEST OK
[ 218.542694] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp at 68000000/serial at 4806c000[0]'
[ 218.546264] 4806c000.serial: ttyO1 at MMIO 0x4806c000 (irq = 89,
base_baud = 3000000) is a OMAP UART1
[ 218.574157] of_get_named_gpiod_flags: can't parse 'rts-gpio'
property of node '/ocp at 68000000/serial at 49020000[0]'
[ 218.574340] 49020000.serial: ttyO2 at MMIO 0x49020000 (irq = 90,
base_baud = 3000000) is a OMAP UART2
[ 218.650115] bcm2048: probe
[ 218.650177] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer reset
[ 218.650177] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650360] of_get_named_gpiod_flags: parsed 'reset-gpios' property
of node '/ocp at 68000000/serial at 4806c000/bluetooth[0]' - status (0)
[ 218.650390] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer host-wakeup
[ 218.650421] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650482] of_get_named_gpiod_flags: parsed 'host-wakeup-gpios'
property of node '/ocp at 68000000/serial at 4806c000/bluetooth[0]' - status
(0)
[ 218.650512] bcm2048 4806c000.serial:bluetooth: GPIO lookup for
consumer bluetooth-wakeup
[ 218.650543] bcm2048 4806c000.serial:bluetooth: using device tree
for GPIO lookup
[ 218.650604] of_get_named_gpiod_flags: parsed
'bluetooth-wakeup-gpios' property of node
'/ocp at 68000000/serial@4806c000/bluetooth[0]' - status (0)
[ 218.650817] bcm2048 4806c000.serial:bluetooth: parent uart: ttyO1
[ 218.650817] bcm2048 4806c000.serial:bluetooth: sysclk speed: 38400
kHz
[ 218.650848] bcm2048 4806c000.serial:bluetooth: probe: 0
[ 218.774139] Bluetooth: HCI UART driver ver 2.3
[ 218.774169] Bluetooth: HCI UART protocol H4 registered
[ 218.774169] Bluetooth: HCI UART protocol H4+ registered
[ 218.774169] Bluetooth: HCI UART protocol BCSP registered
[ 218.774200] Bluetooth: HCI UART protocol LL registered
[ 218.774200] Bluetooth: HCI UART protocol ATH3K registered
[ 218.774200] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 219.904876] tty ttyO1: Nokia H4+ protocol initialized with
4806c000.serial:bluetooth!
[ 219.921112] tty ttyO1: Nokia H4+ protocol setup...
[ 219.921142] h4p_reset: reset
[ 219.921142] hci_uart_init_tty
[ 219.983520] h4p_reset: flush
[ 219.983551] h4p_reset: speed
[ 219.983581] tty ttyO1: setting speed to 120000 baud
[ 219.983673] h4p_reset: safety
[ 219.986480] tty ttyO1: wakeup received: 0 -> 1
[ 220.013488] tty ttyO1: wait for cts... received!
[ 220.013519] h4p_reset: flow
[ 220.013549] tty ttyO1: Sending negotiation...
[ 220.013580] tty ttyO1: gpio state: reset=1 wakehost=1 wakebt=1
[ 220.013610] enqueue: hu c304cc80 skb cd4da000
[ 220.017425] tty ttyO1: H4P negotiation:
[ 220.017456] tty ttyO1: baudrate = 416
[ 220.017486] tty ttyO1: system clock = 38400
[ 220.017486] tty ttyO1: manufacturer id = 4
[ 220.017486] tty ttyO1: version id = 11
[ 220.017578] tty ttyO1: setting speed to 921600 baud
[ 220.043457] tty ttyO1: wait for cts... received!
[ 220.043548] tty ttyO1: Negotiation successful...
[ 220.043579] tty ttyO1: Sending alive packet...
[ 220.043579] enqueue: hu c304cc80 skb cd4dacc0
[ 220.043853] tty ttyO1: Received alive packet!
[ 220.047851] tty ttyO1: FW: Skip negotion packet!
[ 220.047882] tty ttyO1: FW: Skip alive packet!
[ 220.052185] enqueue: hu c304cc80 skb cd4da480
[ 220.055175] enqueue: hu c304cc80 skb cd4dae40
[ 220.058776] enqueue: hu c304cc80 skb cd4da6c0
[ 220.058898] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.058929] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.064605] enqueue: hu c304cc80 skb cd4daf00
[ 220.068389] enqueue: hu c304cc80 skb cd4da0c0
[ 220.068542] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.068542] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.071960] enqueue: hu c304cc80 skb cd4da840
[ 220.072082] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.072082] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.075592] enqueue: hu c304cc80 skb cd4da180
[ 220.079803] enqueue: hu c304cc80 skb cd479cc0
[ 220.084381] enqueue: hu c304cc80 skb cd479180
[ 220.087982] enqueue: hu c304cc80 skb cd4793c0
[ 220.088104] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.088134] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.091522] enqueue: hu c304cc80 skb cd479e40
[ 220.095336] enqueue: hu c304cc80 skb cd479540
[ 220.098876] enqueue: hu c304cc80 skb cd479000
[ 220.102386] enqueue: hu c304cc80 skb cd479600
[ 220.102478] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.102508] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.105987] enqueue: hu c304cc80 skb cd479780
[ 220.109527] enqueue: hu c304cc80 skb cd450cc0
[ 220.109619] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.109649] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.113098] enqueue: hu c304cc80 skb cd484600
[ 220.113220] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.113250] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.116760] enqueue: hu c304cc80 skb cd4a9b40
[ 220.120300] enqueue: hu c304cc80 skb cd77c840
[ 220.124786] enqueue: hu c304cc80 skb cd4f7900
[ 220.128387] enqueue: hu c304cc80 skb c4fb2180
[ 220.131896] enqueue: hu c304cc80 skb c4fb23c0
[ 220.135498] enqueue: hu c304cc80 skb c4fb2cc0
[ 220.139007] enqueue: hu c304cc80 skb c4fb2000
[ 220.142486] enqueue: hu c304cc80 skb cd44fcc0
[ 220.146118] enqueue: hu c304cc80 skb cd4b60c0
[ 220.149627] enqueue: hu c304cc80 skb cf1986c0
[ 220.153106] enqueue: hu c304cc80 skb cf198480
[ 220.156738] enqueue: hu c304cc80 skb cf1980c0
[ 220.160278] enqueue: hu c304cc80 skb cf198240
[ 220.164733] enqueue: hu c304cc80 skb cd49f780
[ 220.168365] enqueue: hu c304cc80 skb cd4daf00
[ 220.171844] enqueue: hu c304cc80 skb cd4da6c0
[ 220.175445] enqueue: hu c304cc80 skb cd4dab40
[ 220.175567] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.175567] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.178955] enqueue: hu c304cc80 skb cd479780
[ 220.182434] enqueue: hu c304cc80 skb cd479540
[ 220.182525] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.182556] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.186035] enqueue: hu c304cc80 skb cd4793c0
[ 220.188140] enqueue: hu c304cc80 skb cd479b40
[ 220.188537] enqueue: hu c304cc80 skb cd484600
[ 220.236480] enqueue: hu c304cc80 skb cd4a9f00
[ 220.237701] enqueue: hu c304cc80 skb cd4f7900
[ 220.238830] enqueue: hu c304cc80 skb c4fb23c0
[ 220.239959] enqueue: hu c304cc80 skb c4fb2b40
[ 220.241119] enqueue: hu c304cc80 skb c3107000
[ 220.242187] enqueue: hu c304cc80 skb cd724240
[ 220.243286] enqueue: hu c304cc80 skb cf198540
[ 220.244781] enqueue: hu c304cc80 skb cf198540
[ 220.245758] enqueue: hu c304cc80 skb cd49f780
[ 220.246612] enqueue: hu c304cc80 skb cd4daf00
[ 220.247436] enqueue: hu c304cc80 skb cd479540
[ 220.248535] tty ttyO1: Sending radio packet...
[ 220.248565] enqueue: hu c304cc80 skb cd479cc0
[ 220.248596] tty ttyO1: Radio packet sent
[ 220.249328] Bluetooth: hci0: Frame reassembly failed (-84)
[ 220.272949] tty ttyO1: wakeup received: 1 -> 0
[ 221.283477] tty ttyO1: radio packet timeout!
[ 221.283630] enqueue: hu c304cc80 skb cd4a9b40
[ 223.363372] Bluetooth: hci0 command 0xfc18 tx timeout
pavel at n900:~$
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/4903439f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019090646.GA24243@lucifer>
On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> > yes this is the desirable and expected behavior.
> >
> > > wonder if this is desirable behaviour or whether this ought to be limited to
> > > ptrace system calls. Regardless, by making the flag more visible it makes it
> > > easier to see that this is happening.
> >
> > mem_open already enforces PTRACE_MODE_ATTACH
>
> Ah I missed this, that makes a lot of sense, thanks!
>
> I still wonder whether other invocations of access_remote_vm() in fs/proc/base.c
> (the principle caller of this function) need FOLL_FORCE, for example the various
> calls that simply read data from other processes, so I think the point stands
> about keeping this explicit.
I do agree. Making them explicit will help to clean them up later,
should there be a need.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Neil Armstrong @ 2016-10-19 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On 10/17/2016 09:51 PM, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> Changes in v2:
> - Remove unrelated changes added by mistake. Suggested by Jason Gunthorpe.
>
> drivers/char/hw_random/meson-rng.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
> index 58bef39f7286..51864a509be7 100644
> --- a/drivers/char/hw_random/meson-rng.c
> +++ b/drivers/char/hw_random/meson-rng.c
> @@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
> { .compatible = "amlogic,meson-rng", },
> {},
> };
> +MODULE_DEVICE_TABLE(of, meson_rng_of_match);
>
> static struct platform_driver meson_rng_driver = {
> .probe = meson_rng_probe,
>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Will Deacon @ 2016-10-19 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_A1XOL=yST_isyvMZL=9wUcuiFXdfmOqw7PO5te24Ktw@mail.gmail.com>
On Wed, Oct 19, 2016 at 09:49:46AM +0100, Ard Biesheuvel wrote:
> On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
> >> I was planning merging these for 4.10. But I'm fine with them
> >> going through the arm tree. Let me know what you guys want to
> >> do.
> >
> > I assumed you'd take them through crypto, as per usual, so I didn't
> > queue anything in the arm64 tree.
> >
> > Ard -- were you planning to get these in for 4.9?
> >
>
> These are arguably bug fixes, but I spotted them by accident, they
> weren't reported to me or anything. But it seems strange to add a cc
> stable and then hold off until the next merge window.
>
> In any case, I don't care deeply either way, as long as they get
> merged in the end. I think it makes sense to keep them together (arm64
> + ARM), so Herbert's tree is a more natural route for them to take. I
> will leave it up to Herbert whether they are sent onward as fixes or
> as part of v4.10
Sounds good to me.
Will
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Michal Hocko @ 2016-10-19 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019085815.GA22239@lucifer>
On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> > I am wondering whether we can go further. E.g. it is not really clear to
> > me whether we need an explicit FOLL_REMOTE when we can in fact check
> > mm != current->mm and imply that. Maybe there are some contexts which
> > wouldn't work, I haven't checked.
>
> This flag is set even when /proc/self/mem is used. I've not looked deeply into
> this flag but perhaps accessing your own memory this way can be considered
> 'remote' since you're not accessing it directly. On the other hand, perhaps this
> is just mistaken in this case?
My understanding of the flag is quite limited as well. All I know it is
related to protection keys and it is needed to bypass protection check.
See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
enforce PKEY permissions on remote mm access").
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Lorenzo Stoakes @ 2016-10-19 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019085204.GD7517@dhcp22.suse.cz>
On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> yes this is the desirable and expected behavior.
>
> > wonder if this is desirable behaviour or whether this ought to be limited to
> > ptrace system calls. Regardless, by making the flag more visible it makes it
> > easier to see that this is happening.
>
> mem_open already enforces PTRACE_MODE_ATTACH
Ah I missed this, that makes a lot of sense, thanks!
I still wonder whether other invocations of access_remote_vm() in fs/proc/base.c
(the principle caller of this function) need FOLL_FORCE, for example the various
calls that simply read data from other processes, so I think the point stands
about keeping this explicit.
^ permalink raw reply
* [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
From: Lorenzo Stoakes @ 2016-10-19 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018153050.GC13117@dhcp22.suse.cz>
On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> I am wondering whether we can go further. E.g. it is not really clear to
> me whether we need an explicit FOLL_REMOTE when we can in fact check
> mm != current->mm and imply that. Maybe there are some contexts which
> wouldn't work, I haven't checked.
This flag is set even when /proc/self/mem is used. I've not looked deeply into
this flag but perhaps accessing your own memory this way can be considered
'remote' since you're not accessing it directly. On the other hand, perhaps this
is just mistaken in this case?
> I guess there is more work in that area and I do not want to impose all
> that work on you, but I couldn't resist once I saw you playing in that
> area ;) Definitely a good start!
Thanks, I am more than happy to go as far down this rabbit hole as is helpful,
no imposition at all :)
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Laurent Pinchart @ 2016-10-19 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJXwZ8pQ58OgV4w88yNuG1Fd8++1yP-Frd2QJFO9uJJueQ@mail.gmail.com>
Hi Bartosz,
On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
> > On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
> >> Create the driver for the da8xx System Configuration and implement
> >> support for writing to the three Master Priority registers.
> >>
> >> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> [snip]
>
> >> +
> >> +Documentation:
> >> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "ti,da850-syscfg"
> >
> > Don't you need a reg property ?
>
> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>
> >> +Optional properties:
> >> +
> >> +The below properties are used to specify the priority of master
> >> peripherals.
> >> +They must be between 0-7 where 0 is the highest priority and 7 is the
> >> lowest.
> >> +
> >> +- ti,pri-arm-i: ARM_I port priority.
> >> +
> >> +- ti,pri-arm-d: ARM_D port priority.
> >> +
> >> +- ti,pri-upp: uPP port priority.
> >> +
> >> +- ti,pri-sata: SATA port priority.
> >> +
> >> +- ti,pri-pru0: PRU0 port priority.
> >> +
> >> +- ti,pri-pru1: PRU1 port priority.
> >> +
> >> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
> >> +
> >> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
> >> +
> >> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
> >> +
> >> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
> >> +
> >> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
> >> +
> >> +- ti,pri-emac: EMAC port priority.
> >> +
> >> +- ti,pri-usb0cfg: USB0 CFG port priority.
> >> +
> >> +- ti,pri-usb0cdma: USB0 CDMA port priority.
> >> +
> >> +- ti,pri-uhpi: HPI port priority.
> >> +
> >> +- ti,pri-usb1: USB1 port priority.
> >> +
> >> +- ti,pri-lcdc: LCDC port priority.
> >
> > I'm afraid this looks more like system configuration than hardware
> > description to me.
>
> While you're certainly right, this approach is already implemented in
> several other memory and bus drivers and it was also suggested by
> Sekhar in one of the tilcdc rev1 threads. There's also no real
> alternative that I know of.
The fact that other drivers get it wrong is no excuse for copying them :-)
> > There was a BoF session about how to support this kind of performance
> > knobs at ELCE last week:
> > https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perfor
> > mance-framework-michael-turquette-baylibre :-)
>
> I know, I was there. ;)
That's why I mentioned it :-)
> Unfortunately it was just a discussion about potential approaches -
> there's no code yet.
Patches are welcome ;-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v3 2/4] drivers: iio: ti_am335x_adc: add dma support
From: Mugunthan V N @ 2016-10-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d0105217-a8ee-cd8e-221d-34c19257765e@kernel.org>
On Sunday 09 October 2016 02:00 PM, Jonathan Cameron wrote:
> On 05/10/16 10:04, Mugunthan V N wrote:
>> This patch adds the required pieces to ti_am335x_adc driver for
>> DMA support
>>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> Hi,
>
> Just the one question inline. I'll also need an Ack from Lee as
> this touches code in mfd (as does the previous patch).
> We have obviously missed this merge window, so no particular rush.
>
> Otherwise, looking very nice indeed. Got to get my BBB out and play
> with this now ;)
>
> Jonathan
>> ---
>> drivers/iio/adc/ti_am335x_adc.c | 148 ++++++++++++++++++++++++++++++++++-
>> include/linux/mfd/ti_am335x_tscadc.h | 7 ++
>> 2 files changed, 152 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
>> index c3cfacca..ad9dec3 100644
>> --- a/drivers/iio/adc/ti_am335x_adc.c
>> +++ b/drivers/iio/adc/ti_am335x_adc.c
>> @@ -30,10 +30,28 @@
>> #include <linux/iio/buffer.h>
>> #include <linux/iio/kfifo_buf.h>
>>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> +
>> +#define DMA_BUFFER_SIZE SZ_2K
>> +
>> +struct tiadc_dma {
>> + struct dma_slave_config conf;
>> + struct dma_chan *chan;
>> + dma_addr_t addr;
>> + dma_cookie_t cookie;
>> + u8 *buf;
>> + int current_period;
>> + int period_size;
>> + u8 fifo_thresh;
>> +};
>> +
>> struct tiadc_device {
>> struct ti_tscadc_dev *mfd_tscadc;
>> + struct tiadc_dma dma;
>> struct mutex fifo1_lock; /* to protect fifo access */
>> int channels;
>> + int total_ch_enabled;
>> u8 channel_line[8];
>> u8 channel_step[8];
>> int buffer_en_ch_steps;
>> @@ -198,6 +216,67 @@ static irqreturn_t tiadc_worker_h(int irq, void *private)
>> return IRQ_HANDLED;
>> }
>>
>> +static void tiadc_dma_rx_complete(void *param)
>> +{
>> + struct iio_dev *indio_dev = param;
>> + struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + u8 *data;
>> + int i;
>> +
>> + data = dma->buf + dma->current_period * dma->period_size;
>> + dma->current_period = 1 - dma->current_period; /* swap the buffer ID */
>> +
>> + for (i = 0; i < dma->period_size; i += indio_dev->scan_bytes) {
>> + iio_push_to_buffers(indio_dev, data);
>> + data += indio_dev->scan_bytes;
>> + }
> Hmm. Another case for the mooted iio_push_to_buffers_multi. Guess
> we should move on with that one ;)
>> +}
>> +
>> +static int tiadc_start_dma(struct iio_dev *indio_dev)
>> +{
>> + struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + struct dma_async_tx_descriptor *desc;
>> +
>> + dma->current_period = 0; /* We start to fill period 0 */
>> + /*
>> + * Make the fifo thresh as the multiple of total number of
>> + * channels enabled, so make sure that cyclic DMA period
>> + * length is also a multiple of total number of channels
>> + * enabled. This ensures that no invalid data is reported
>> + * to the stack via iio_push_to_buffers().
>> + */
>> + dma->fifo_thresh = rounddown(FIFO1_THRESHOLD + 1,
>> + adc_dev->total_ch_enabled) - 1;
>> + /* Make sure that period length is multiple of fifo thresh level */
>> + dma->period_size = rounddown(DMA_BUFFER_SIZE / 2,
>> + (dma->fifo_thresh + 1) * sizeof(u16));
>> +
>> + dma->conf.src_maxburst = dma->fifo_thresh + 1;
>> + dmaengine_slave_config(dma->chan, &dma->conf);
>> +
>> + desc = dmaengine_prep_dma_cyclic(dma->chan, dma->addr,
>> + dma->period_size * 2,
>> + dma->period_size, DMA_DEV_TO_MEM,
>> + DMA_PREP_INTERRUPT);
>> + if (!desc)
>> + return -EBUSY;
>> +
>> + desc->callback = tiadc_dma_rx_complete;
>> + desc->callback_param = indio_dev;
>> +
>> + dma->cookie = dmaengine_submit(desc);
>> +
>> + dma_async_issue_pending(dma->chan);
>> +
>> + tiadc_writel(adc_dev, REG_FIFO1THR, dma->fifo_thresh);
>> + tiadc_writel(adc_dev, REG_DMA1REQ, dma->fifo_thresh);
>> + tiadc_writel(adc_dev, REG_DMAENABLE_SET, DMA_FIFO1);
>> +
>> + return 0;
>> +}
>> +
>> static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> @@ -218,20 +297,30 @@ static int tiadc_buffer_preenable(struct iio_dev *indio_dev)
>> static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + unsigned int irq_enable;
>> unsigned int enb = 0;
>> u8 bit;
>>
>> tiadc_step_config(indio_dev);
>> - for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels)
>> + for_each_set_bit(bit, indio_dev->active_scan_mask, adc_dev->channels) {
>> enb |= (get_adc_step_bit(adc_dev, bit) << 1);
>> + adc_dev->total_ch_enabled++;
>> + }
>> adc_dev->buffer_en_ch_steps = enb;
>>
>> + if (dma->chan)
>> + tiadc_start_dma(indio_dev);
>> +
>> am335x_tsc_se_set_cache(adc_dev->mfd_tscadc, enb);
>>
>> tiadc_writel(adc_dev, REG_IRQSTATUS, IRQENB_FIFO1THRES
>> | IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW);
>> - tiadc_writel(adc_dev, REG_IRQENABLE, IRQENB_FIFO1THRES
>> - | IRQENB_FIFO1OVRRUN);
>> +
>> + irq_enable = IRQENB_FIFO1OVRRUN;
>> + if (!dma->chan)
>> + irq_enable |= IRQENB_FIFO1THRES;
> This changes the non dma behaviour as we no longer set IRQENB_FIFO1THRES.
> Why? Was it wrong before?
In non DMA case, dms->chan will be NULL and IRQENB_FIFO1THRES interrupt
will be enabled to pop the ADC samples.
Regards
Mugunthan V N
>> + tiadc_writel(adc_dev, REG_IRQENABLE, irq_enable);
>>
>> return 0;
>> }
>> @@ -239,12 +328,18 @@ static int tiadc_buffer_postenable(struct iio_dev *indio_dev)
>> static int tiadc_buffer_predisable(struct iio_dev *indio_dev)
>> {
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> int fifo1count, i, read;
>>
>> tiadc_writel(adc_dev, REG_IRQCLR, (IRQENB_FIFO1THRES |
>> IRQENB_FIFO1OVRRUN | IRQENB_FIFO1UNDRFLW));
>> am335x_tsc_se_clr(adc_dev->mfd_tscadc, adc_dev->buffer_en_ch_steps);
>> adc_dev->buffer_en_ch_steps = 0;
>> + adc_dev->total_ch_enabled = 0;
>> + if (dma->chan) {
>> + tiadc_writel(adc_dev, REG_DMAENABLE_CLEAR, 0x2);
>> + dmaengine_terminate_async(dma->chan);
>> + }
>>
>> /* Flush FIFO of leftover data in the time it takes to disable adc */
>> fifo1count = tiadc_readl(adc_dev, REG_FIFO1CNT);
>> @@ -430,6 +525,41 @@ static const struct iio_info tiadc_info = {
>> .driver_module = THIS_MODULE,
>> };
>>
>> +static int tiadc_request_dma(struct platform_device *pdev,
>> + struct tiadc_device *adc_dev)
>> +{
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> + dma_cap_mask_t mask;
>> +
>> + /* Default slave configuration parameters */
>> + dma->conf.direction = DMA_DEV_TO_MEM;
>> + dma->conf.src_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
>> + dma->conf.src_addr = adc_dev->mfd_tscadc->tscadc_phys_base + REG_FIFO1;
>> +
>> + dma_cap_zero(mask);
>> + dma_cap_set(DMA_CYCLIC, mask);
>> +
>> + /* Get a channel for RX */
>> + dma->chan = dma_request_chan(adc_dev->mfd_tscadc->dev, "fifo1");
>> + if (IS_ERR(dma->chan)) {
>> + int ret = PTR_ERR(dma->chan);
>> +
>> + dma->chan = NULL;
>> + return ret;
>> + }
>> +
>> + /* RX buffer */
>> + dma->buf = dma_alloc_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + &dma->addr, GFP_KERNEL);
>> + if (!dma->buf)
>> + goto err;
>> +
>> + return 0;
>> +err:
>> + dma_release_channel(dma->chan);
>> + return -ENOMEM;
>> +}
>> +
>> static int tiadc_parse_dt(struct platform_device *pdev,
>> struct tiadc_device *adc_dev)
>> {
>> @@ -512,8 +642,14 @@ static int tiadc_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, indio_dev);
>>
>> + err = tiadc_request_dma(pdev, adc_dev);
>> + if (err && err == -EPROBE_DEFER)
>> + goto err_dma;
>> +
>> return 0;
>>
>> +err_dma:
>> + iio_device_unregister(indio_dev);
>> err_buffer_unregister:
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> err_free_channels:
>> @@ -525,8 +661,14 @@ static int tiadc_remove(struct platform_device *pdev)
>> {
>> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> struct tiadc_device *adc_dev = iio_priv(indio_dev);
>> + struct tiadc_dma *dma = &adc_dev->dma;
>> u32 step_en;
>>
>> + if (dma->chan) {
>> + dma_free_coherent(dma->chan->device->dev, DMA_BUFFER_SIZE,
>> + dma->buf, dma->addr);
>> + dma_release_channel(dma->chan);
>> + }
>> iio_device_unregister(indio_dev);
>> tiadc_iio_buffered_hardware_remove(indio_dev);
>> tiadc_channels_remove(indio_dev);
>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> index e45a208..b9a53e0 100644
>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> @@ -23,6 +23,8 @@
>> #define REG_IRQENABLE 0x02C
>> #define REG_IRQCLR 0x030
>> #define REG_IRQWAKEUP 0x034
>> +#define REG_DMAENABLE_SET 0x038
>> +#define REG_DMAENABLE_CLEAR 0x03c
>> #define REG_CTRL 0x040
>> #define REG_ADCFSM 0x044
>> #define REG_CLKDIV 0x04C
>> @@ -36,6 +38,7 @@
>> #define REG_FIFO0THR 0xE8
>> #define REG_FIFO1CNT 0xF0
>> #define REG_FIFO1THR 0xF4
>> +#define REG_DMA1REQ 0xF8
>> #define REG_FIFO0 0x100
>> #define REG_FIFO1 0x200
>>
>> @@ -126,6 +129,10 @@
>> #define FIFOREAD_DATA_MASK (0xfff << 0)
>> #define FIFOREAD_CHNLID_MASK (0xf << 16)
>>
>> +/* DMA ENABLE/CLEAR Register */
>> +#define DMA_FIFO0 BIT(0)
>> +#define DMA_FIFO1 BIT(1)
>> +
>> /* Sequencer Status */
>> #define SEQ_STATUS BIT(5)
>> #define CHARGE_STEP 0x11
>>
>
^ permalink raw reply
* [PATCH 08/10] mm: replace __access_remote_vm() write parameter with gup_flags
From: Michal Hocko @ 2016-10-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019084045.GA19441@lucifer>
On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> > On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > > This patch removes the write parameter from __access_remote_vm() and replaces it
> > > > with a gup_flags parameter as use of this function previously _implied_
> > > > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> > > >
> > > > We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> > > > (and hence bugs) within the mm subsystem.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> > >
> > > So I'm not convinced this (and the following two patches) is actually
> > > helping much. By grepping for FOLL_FORCE we will easily see that any caller
> > > of access_remote_vm() gets that semantics and can thus continue search
> >
> > I am really wondering. Is there anything inherent that would require
> > FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
> > non-trivial thing. It doesn't obey vma permissions so we should really
> > minimize its usage. Do all of those users really need FOLL_FORCE?
>
> I wonder about this also, for example by accessing /proc/self/mem you trigger
> access_remote_vm() and consequently get_user_pages_remote() meaning FOLL_FORCE
> is implied and you can use /proc/self/mem to override any VMA permissions. I
yes this is the desirable and expected behavior.
> wonder if this is desirable behaviour or whether this ought to be limited to
> ptrace system calls. Regardless, by making the flag more visible it makes it
> easier to see that this is happening.
mem_open already enforces PTRACE_MODE_ATTACH
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-19 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019084607.GB9193@arm.com>
On 19 October 2016 at 09:46, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Oct 19, 2016 at 11:03:33AM +0800, Herbert Xu wrote:
>> On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
>> > On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
>> > >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
>> > >> currently work, or have ever worked correctly when built for big endian. So this
>> > >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
>> > >> well, and an additional fix for XTS which escaped my attention before.
>> > >>
>> > >> Each of these patches carries a fixes tag, and could be backported to stable.
>> > >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
>> > >> fix is compatible with, not the patch that introduced the algorithm.
>> > >
>> > > I think for future reference, the Fixes tag should denote the commit
>> > > that introduced the issue. An explicit Cc: stable tag would state how
>> > > far back it should be applied.
>> > >
>> >
>> > OK, that sounds reasonable.
>> >
>> > >> Ard Biesheuvel (8):
>> > >> crypto: arm64/aes-ce - fix for big endian
>> > >> crypto: arm64/ghash-ce - fix for big endian
>> > >> crypto: arm64/sha1-ce - fix for big endian
>> > >> crypto: arm64/sha2-ce - fix for big endian
>> > >> crypto: arm64/aes-ccm-ce: fix for big endian
>> > >> crypto: arm64/aes-neon - fix for big endian
>> > >> crypto: arm64/aes-xts-ce: fix for big endian
>> > >> crypto: arm/aes-ce - fix for big endian
>> > >
>> > > The changes look fine to me but I can't claim I fully understand these
>> > > algorithms. FWIW:
>> > >
>> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>> > >
>> > > (Will may pick them up for 4.9-rcX)
>> >
>> > Thanks, although I was kind of expecting Herbert to pick these up,
>> > given that #8 affects ARM not arm64.
>> >
>> > But if you (or Will) can pick up #1 to #7, that is also fine, then I
>> > can drop #8 into rmk's patch database.
>>
>> I was planning merging these for 4.10. But I'm fine with them
>> going through the arm tree. Let me know what you guys want to
>> do.
>
> I assumed you'd take them through crypto, as per usual, so I didn't
> queue anything in the arm64 tree.
>
> Ard -- were you planning to get these in for 4.9?
>
These are arguably bug fixes, but I spotted them by accident, they
weren't reported to me or anything. But it seems strange to add a cc
stable and then hold off until the next merge window.
In any case, I don't care deeply either way, as long as they get
merged in the end. I think it makes sense to keep them together (arm64
+ ARM), so Herbert's tree is a more natural route for them to take. I
will leave it up to Herbert whether they are sent onward as fixes or
as part of v4.10
Thanks,
Ard.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox