* [crypto] [marvell-cesa] Possible regression after Linux 4.7
From: radioconfusion at gmail.com @ 2016-11-07 8:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Thu, 3 Nov 2016 14:57:06 +0100, Romain Perier wrote:
>
> > Do you have any improvement for the issue?
> > Please let me know if you need any help to resolve it.
> >
> > Best Regards,
> > Jussi
> >
>
> Sorry for the delay.
> Could you try to revert locally commit
> 2786cee8e50bb4b4303dc22665f391b72318fa84 (crypto: marvell - Move SRAM
> I/O operations to step functions) ?
>
> It seems to fix most of the issues I had with curl.
> I will continue to investigate, that's just to confirm if it fixes the
> issues for you.
>
Thanks for this suggestion.
Unfortunately, I didn't get improvements using curl with this revertion.
Thanks for your investigation. Waiting for your input.
Best Regards,
Jussi
^ permalink raw reply
* [PATCH 3/3 v4] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Linus Walleij @ 2016-11-07 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478508284-10847-1-git-send-email-linus.walleij@linaro.org>
This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
MPU-3050 and appear as a subdevice beyond it. We set up the
required GPIO and interrupt lines to make the devices work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v3->v4:
- Use interrupts-extended
- Add Bjorn's ACK.
ChangeLog v2->v3:
- Move the interrupt to the pm8058 alias to reflect the two patches
properly specifying the PMIC as interrupt parent.
ChangeLog v1->v2:
- Use the new I2C mux gate bindings from Peter Rosin (merged to
the I2C subsystem)
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 52 ++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index ea660ffa03ea..39d9e6ddefed 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -220,6 +220,14 @@
function = "ebi2";
};
};
+
+ /* Interrupt line for the KXSD9 accelerometer */
+ dragon_kxsd9_gpios: kxsd9 {
+ irq {
+ pins = "gpio57"; /* IRQ line */
+ bias-pull-up;
+ };
+ };
};
qcom,ssbi at 500000 {
@@ -272,6 +280,15 @@
power-source = <PM8058_GPIO_S3>;
};
};
+ dragon_mpu3050_gpios: mpu3050-gpios {
+ pinconf {
+ pins = "gpio17";
+ function = "normal";
+ input-enable;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
dragon_sdcc3_gpios: sdcc3-gpios {
pinconf {
pins = "gpio22";
@@ -389,6 +406,41 @@
vddd-supply = <&pm8058_lvs0>; // 1.8V
vdda-supply = <&pm8058_l14>; // 2.85V
};
+ mpu3050 at 68 {
+ compatible = "invensense,mpu3050";
+ reg = <0x68>;
+ /*
+ * GPIO17 has interrupt 208 on the
+ * PM8058, it is pulled high by a 10k
+ * resistor to VLOGIC so needs to be
+ * active low/falling edge.
+ */
+ interrupts-extended = <&pm8058 208 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_mpu3050_gpios>;
+ vlogic-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+
+ /*
+ * The MPU-3050 acts as a hub for the
+ * accelerometer.
+ */
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ kxsd9 at 18 {
+ compatible = "kionix,kxsd9";
+ reg = <0x18>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_kxsd9_gpios>;
+ iovdd-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+ };
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3 v4] ARM: dts: reference PM8058 as IRQ parent
From: Linus Walleij @ 2016-11-07 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478508284-10847-1-git-send-email-linus.walleij@linaro.org>
Some nodes are referencing the pm8058_gpio as IRQ parent, but
the HW IRQ offset they are supplying is actually that for the
parent to that controller: the PM8058 itself. Since that is the
proper parent, reference it directly.
We can switch this to the pm8058_gpio and the proper offset
once we have fixed the SSBI GPIO driver to properly deal with
the hierarchical IRQ domain and get proper local offset
translation.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Add Bjorn's ACK.
- Follow version numbering of the primary patch.
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4a532ddab53a..ea660ffa03ea 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -369,8 +369,8 @@
ak8975 at 0c {
compatible = "asahi-kasei,ak8975";
reg = <0x0c>;
- /* GPIO33 has interrupt 224 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO33 has interrupt 224 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <224 IRQ_TYPE_EDGE_RISING>;
pinctrl-names = "default";
pinctrl-0 = <&dragon_ak8975_gpios>;
@@ -380,8 +380,8 @@
bmp085 at 77 {
compatible = "bosch,bmp085";
reg = <0x77>;
- /* GPIO16 has interrupt 207 on the PM8058 */
- interrupt-parent = <&pm8058_gpio>;
+ /* FIXME: GPIO16 has interrupt 207 on the PM8058 */
+ interrupt-parent = <&pm8058>;
interrupts = <207 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 86 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3 v4] ARM: dts: rename MSM8660/APQ8060 pmicintc to pm8058
From: Linus Walleij @ 2016-11-07 8:44 UTC (permalink / raw)
To: linux-arm-kernel
The name "pmicintc" is ambiguous: there is a second power
management IC named PM8901 on these systems, and it is also
an interrupt controller. To make things clear, just name the
node alias "pm8058", this in unambigous and has all information
we need.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v4:
- Add Bjorn's ACK.
- Follow version numbering of the primary patch.
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660-surf.dts | 2 +-
arch/arm/boot/dts/qcom-msm8660.dtsi | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 4b8872cc8bf9..4a532ddab53a 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -412,7 +412,7 @@
* The second interrupt is the PME interrupt
* for network wakeup, connected to the TLMM.
*/
- interrupts-extended = <&pmicintc 198 IRQ_TYPE_EDGE_FALLING>,
+ interrupts-extended = <&pm8058 198 IRQ_TYPE_EDGE_FALLING>,
<&tlmm 29 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
vdd33a-supply = <&dragon_veth>;
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index 23de764558ab..1adc04978a47 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -48,7 +48,7 @@
};
};
-&pmicintc {
+&pm8058 {
keypad at 148 {
linux,keymap = <
MATRIX_KEY(0, 0, KEY_FN_F1)
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
index 4d828f810746..91c9a62ae725 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -163,7 +163,7 @@
reg = <0x500000 0x1000>;
qcom,controller-type = "pmic-arbiter";
- pmicintc: pmic at 0 {
+ pm8058: pmic at 0 {
compatible = "qcom,pm8058";
interrupt-parent = <&tlmm>;
interrupts = <88 8>;
@@ -176,7 +176,7 @@
compatible = "qcom,pm8058-gpio",
"qcom,ssbi-gpio";
reg = <0x150>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <192 IRQ_TYPE_NONE>,
<193 IRQ_TYPE_NONE>,
<194 IRQ_TYPE_NONE>,
@@ -232,7 +232,7 @@
reg = <0x50>;
gpio-controller;
#gpio-cells = <2>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts =
<128 IRQ_TYPE_NONE>,
<129 IRQ_TYPE_NONE>,
@@ -251,7 +251,7 @@
pwrkey at 1c {
compatible = "qcom,pm8058-pwrkey";
reg = <0x1c>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <50 1>, <51 1>;
debounce = <15625>;
pull-up;
@@ -260,7 +260,7 @@
keypad at 148 {
compatible = "qcom,pm8058-keypad";
reg = <0x148>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <74 1>, <75 1>;
debounce = <15>;
scan-delay = <32>;
@@ -270,7 +270,7 @@
rtc at 1e8 {
compatible = "qcom,pm8058-rtc";
reg = <0x1e8>;
- interrupt-parent = <&pmicintc>;
+ interrupt-parent = <&pm8058>;
interrupts = <39 1>;
allow-set-time;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v7 1/2] soc: samsung: add exynos chipid driver support
From: Arnd Bergmann @ 2016-11-07 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478347427-28409-2-git-send-email-pankaj.dubey@samsung.com>
On Saturday, November 5, 2016 5:33:46 PM CET Pankaj Dubey wrote:
> Exynos SoCs have Chipid, for identification of product IDs
> and SoC revisions. This patch intends to provide initialization
> code for all these functionalities, at the same time it provides some
> sysfs entries for accessing these information to user-space.
>
> This driver uses existing binding for exynos-chipid.
>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> drivers/soc/samsung/Kconfig | 5 ++
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 148 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 154 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-chipid.c
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2455339..f9ab858 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -14,4 +14,9 @@ config EXYNOS_PM_DOMAINS
> bool "Exynos PM domains" if COMPILE_TEST
> depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>
> +config EXYNOS_CHIPID
> + bool "Exynos Chipid controller driver" if COMPILE_TEST
> + depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
> + select SOC_BUS
> +
Please add a help text.
Why is this not enabled for ARM64 EXYNOS?
> + exynos_chipid_base = of_iomap(np, 0);
> +
> + if (!exynos_chipid_base)
> + return PTR_ERR(exynos_chipid_base);
> +
> + product_id = __raw_readl(exynos_chipid_base);
> + revision = product_id & EXYNOS_REV_MASK;
> + iounmap(exynos_chipid_base);
Never use __raw_readl/__raw_writel in device drivers, they are not endian
safe, and we just removed all instances for Exynos a while back.
> + return 0;
> +}
> +early_initcall(exynos_chipid_early_init);
>
Why is this early? Please add a code comment if it's really needed to be
an early_initcall, otherwise make it a device_initcall.
Arnd
^ permalink raw reply
* [PATCH v7 1/2] soc: samsung: add exynos chipid driver support
From: Arnd Bergmann @ 2016-11-07 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cafc255a-3bdb-7eb2-1092-545866752858@samsung.com>
On Monday, November 7, 2016 8:35:47 AM CET Marek Szyprowski wrote:
> This approach is a bit error prone. You have already missed Exynos5410
> and early Exynos 4210 are not detected because of the incorrect SOC MASK.
> IMHO you should replace above code and defines with a simple array,
> where each ID is present only once, so it will be much easier to add
> future SoCs:
>
> static const struct exynos_soc_id {
> const char *name;
> unsigned int id;
> unsigned int mask;
> } soc_ids[] = {
> { "EXYNOS3250", 0xE3472000, 0xFFFFF000 },
> { "EXYNOS4210", 0x43200000, 0xFFFE0000 },
> { "EXYNOS4212", 0x43220000, 0xFFFE0000 },
> { "EXYNOS4412", 0xE4412000, 0xFFFE0000 },
> { "EXYNOS4415", 0xE4415000, 0xFFFE0000 },
> { "EXYNOS5250", 0x43520000, 0xFFFFF000 },
> { "EXYNOS5260", 0xE5260000, 0xFFFFF000 },
> { "EXYNOS5410", 0xE5410000, 0xFFFFF000 },
> { "EXYNOS5420", 0xE5420000, 0xFFFFF000 },
> { "EXYNOS5440", 0xE5440000, 0xFFFFF000 },
> { "EXYNOS5800", 0xE5422000, 0xFFFFF000 },
> };
Good idea
>
> I'm also not sure about Exynos 4415, which has been scheduled for removal.
I'd vote for leaving it in the driver, and possibly adding other
models even if we don't support them in the other drivers, if
only for documentation purposes.
Arnd
^ permalink raw reply
* [PATCH V4 6/6] bus: Add support for Tegra Generic Memory Interface
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
The Generic Memory Interface bus can be used to connect high-speed
devices such as NOR flash, FPGAs, DSPs...
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
---
Changes in v2:
- Fixed some checkpatch errors
- Re-ordered probe to get rid of local variables
- Moved of_platform_default_populate call to the end of probe
- Use the timing and configuration properties from the child device
- Added warning if more then 1 child device exist
Changes in v3:
- added helper function to disable the controller which is used in remove and
on error.
- Added logic to parse CS# from "ranges" property with fallback to "reg"
property
Changes in v4:
- added sanity check of chip-select property (fail if invalid)
- adjusted for device tree binding property name changes
- fail probe if there are no child nodes
- removed superfluous error message
- removed superfluous newline in Kconfig
drivers/bus/Kconfig | 7 ++
drivers/bus/Makefile | 1 +
drivers/bus/tegra-gmi.c | 275 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 283 insertions(+)
create mode 100644 drivers/bus/tegra-gmi.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 4ed7d26..a9ebc4c 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -141,6 +141,13 @@ config TEGRA_ACONNECT
Driver for the Tegra ACONNECT bus which is used to interface with
the devices inside the Audio Processing Engine (APE) for Tegra210.
+config TEGRA_GMI
+ tristate "Tegra Generic Memory Interface bus driver"
+ depends on ARCH_TEGRA
+ help
+ Driver for the Tegra Generic Memory Interface bus which can be used
+ to attach devices such as NOR, UART, FPGA and more.
+
config UNIPHIER_SYSTEM_BUS
tristate "UniPhier System Bus driver"
depends on ARCH_UNIPHIER && OF
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ac84cc4..34e2bab 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -18,5 +18,6 @@ obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
obj-$(CONFIG_SIMPLE_PM_BUS) += simple-pm-bus.o
obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
+obj-$(CONFIG_TEGRA_GMI) += tegra-gmi.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
diff --git a/drivers/bus/tegra-gmi.c b/drivers/bus/tegra-gmi.c
new file mode 100644
index 0000000..687e212
--- /dev/null
+++ b/drivers/bus/tegra-gmi.c
@@ -0,0 +1,275 @@
+/*
+ * Driver for NVIDIA Generic Memory Interface
+ *
+ * Copyright (C) 2016 Host Mobility AB. All rights reserved.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/reset.h>
+
+#define TEGRA_GMI_CONFIG 0x00
+#define TEGRA_GMI_CONFIG_GO BIT(31)
+#define TEGRA_GMI_BUS_WIDTH_32BIT BIT(30)
+#define TEGRA_GMI_MUX_MODE BIT(28)
+#define TEGRA_GMI_RDY_BEFORE_DATA BIT(24)
+#define TEGRA_GMI_RDY_ACTIVE_HIGH BIT(23)
+#define TEGRA_GMI_ADV_ACTIVE_HIGH BIT(22)
+#define TEGRA_GMI_OE_ACTIVE_HIGH BIT(21)
+#define TEGRA_GMI_CS_ACTIVE_HIGH BIT(20)
+#define TEGRA_GMI_CS_SELECT(x) ((x & 0x7) << 4)
+
+#define TEGRA_GMI_TIMING0 0x10
+#define TEGRA_GMI_MUXED_WIDTH(x) ((x & 0xf) << 12)
+#define TEGRA_GMI_HOLD_WIDTH(x) ((x & 0xf) << 8)
+#define TEGRA_GMI_ADV_WIDTH(x) ((x & 0xf) << 4)
+#define TEGRA_GMI_CE_WIDTH(x) (x & 0xf)
+
+#define TEGRA_GMI_TIMING1 0x14
+#define TEGRA_GMI_WE_WIDTH(x) ((x & 0xff) << 16)
+#define TEGRA_GMI_OE_WIDTH(x) ((x & 0xff) << 8)
+#define TEGRA_GMI_WAIT_WIDTH(x) (x & 0xff)
+
+#define TEGRA_GMI_MAX_CHIP_SELECT 8
+
+struct tegra_gmi_priv {
+ void __iomem *base;
+ struct reset_control *rst;
+ struct clk *clk;
+
+ u32 snor_config;
+ u32 snor_timing0;
+ u32 snor_timing1;
+};
+
+static void tegra_gmi_disable(struct tegra_gmi_priv *priv)
+{
+ u32 config;
+
+ /* stop GMI operation */
+ config = readl(priv->base + TEGRA_GMI_CONFIG);
+ config &= ~TEGRA_GMI_CONFIG_GO;
+ writel(config, priv->base + TEGRA_GMI_CONFIG);
+
+ reset_control_assert(priv->rst);
+ clk_disable_unprepare(priv->clk);
+}
+
+static void tegra_gmi_init(struct device *dev, struct tegra_gmi_priv *priv)
+{
+ writel(priv->snor_timing0, priv->base + TEGRA_GMI_TIMING0);
+ writel(priv->snor_timing1, priv->base + TEGRA_GMI_TIMING1);
+
+ priv->snor_config |= TEGRA_GMI_CONFIG_GO;
+ writel(priv->snor_config, priv->base + TEGRA_GMI_CONFIG);
+}
+
+static int tegra_gmi_parse_dt(struct device *dev, struct tegra_gmi_priv *priv)
+{
+ struct device_node *child = of_get_next_available_child(dev->of_node,
+ NULL);
+ u32 property, ranges[4];
+ int ret;
+
+ if (!child) {
+ dev_err(dev, "no child nodes found\n");
+ return -ENODEV;
+ }
+
+ /*
+ * We currently only support one child device due to lack of
+ * chip-select address decoding. Which means that we only have one
+ * chip-select line from the GMI controller.
+ */
+ if (of_get_child_count(dev->of_node) > 1)
+ dev_warn(dev, "only one child device is supported.");
+
+ if (of_property_read_bool(child, "nvidia,snor-data-width-32bit"))
+ priv->snor_config |= TEGRA_GMI_BUS_WIDTH_32BIT;
+
+ if (of_property_read_bool(child, "nvidia,snor-mux-mode"))
+ priv->snor_config |= TEGRA_GMI_MUX_MODE;
+
+ if (of_property_read_bool(child, "nvidia,snor-rdy-active-before-data"))
+ priv->snor_config |= TEGRA_GMI_RDY_BEFORE_DATA;
+
+ if (of_property_read_bool(child, "nvidia,snor-rdy-active-high"))
+ priv->snor_config |= TEGRA_GMI_RDY_ACTIVE_HIGH;
+
+ if (of_property_read_bool(child, "nvidia,snor-adv-active-high"))
+ priv->snor_config |= TEGRA_GMI_ADV_ACTIVE_HIGH;
+
+ if (of_property_read_bool(child, "nvidia,snor-oe-active-high"))
+ priv->snor_config |= TEGRA_GMI_OE_ACTIVE_HIGH;
+
+ if (of_property_read_bool(child, "nvidia,snor-cs-active-high"))
+ priv->snor_config |= TEGRA_GMI_CS_ACTIVE_HIGH;
+
+ /* Decode the CS# */
+ ret = of_property_read_u32_array(child, "ranges", ranges, 4);
+ if (ret < 0) {
+ /* Invalid binding */
+ if (ret == -EOVERFLOW) {
+ dev_err(dev,
+ "failed to decode CS: invalid ranges length\n");
+ goto error_cs;
+ }
+
+ /*
+ * If we reach here it means that the child node has an empty
+ * ranges or it does not exist@all. Attempt to decode the
+ * CS# from the reg property instead.
+ */
+ ret = of_property_read_u32(child, "reg", &property);
+ if (ret < 0) {
+ dev_err(dev,
+ "failed to decode CS: no reg property found\n");
+ goto error_cs;
+ }
+ } else {
+ property = ranges[1];
+ }
+
+ /* Valid chip selects are CS0-CS7 */
+ if (property >= TEGRA_GMI_MAX_CHIP_SELECT) {
+ dev_err(dev, "invalid chip select: %d", property);
+ ret = -EINVAL;
+ goto error_cs;
+ }
+
+ priv->snor_config |= TEGRA_GMI_CS_SELECT(property);
+
+ /* The default values that are provided below are reset values */
+ if (!of_property_read_u32(child, "nvidia,snor-muxed-width", &property))
+ priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(property);
+ else
+ priv->snor_timing0 |= TEGRA_GMI_MUXED_WIDTH(1);
+
+ if (!of_property_read_u32(child, "nvidia,snor-hold-width", &property))
+ priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(property);
+ else
+ priv->snor_timing0 |= TEGRA_GMI_HOLD_WIDTH(1);
+
+ if (!of_property_read_u32(child, "nvidia,snor-adv-width", &property))
+ priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(property);
+ else
+ priv->snor_timing0 |= TEGRA_GMI_ADV_WIDTH(1);
+
+ if (!of_property_read_u32(child, "nvidia,snor-ce-width", &property))
+ priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(property);
+ else
+ priv->snor_timing0 |= TEGRA_GMI_CE_WIDTH(4);
+
+ if (!of_property_read_u32(child, "nvidia,snor-we-width", &property))
+ priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(property);
+ else
+ priv->snor_timing1 |= TEGRA_GMI_WE_WIDTH(1);
+
+ if (!of_property_read_u32(child, "nvidia,snor-oe-width", &property))
+ priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(property);
+ else
+ priv->snor_timing1 |= TEGRA_GMI_OE_WIDTH(1);
+
+ if (!of_property_read_u32(child, "nvidia,snor-wait-width", &property))
+ priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(property);
+ else
+ priv->snor_timing1 |= TEGRA_GMI_WAIT_WIDTH(3);
+
+error_cs:
+ of_node_put(child);
+ return ret;
+}
+
+static int tegra_gmi_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ struct tegra_gmi_priv *priv;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->clk = devm_clk_get(dev, "gmi");
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev, "can not get clock\n");
+ return PTR_ERR(priv->clk);
+ }
+
+ priv->rst = devm_reset_control_get(dev, "gmi");
+ if (IS_ERR(priv->rst)) {
+ dev_err(dev, "can not get reset\n");
+ return PTR_ERR(priv->rst);
+ }
+
+ ret = tegra_gmi_parse_dt(dev, priv);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(priv->clk);
+ if (ret) {
+ dev_err(dev, "fail to enable clock.\n");
+ return ret;
+ }
+
+ reset_control_assert(priv->rst);
+ udelay(2);
+ reset_control_deassert(priv->rst);
+
+ tegra_gmi_init(dev, priv);
+
+ ret = of_platform_default_populate(dev->of_node, NULL, dev);
+ if (ret < 0) {
+ dev_err(dev, "fail to create devices.\n");
+ tegra_gmi_disable(priv);
+ return ret;
+ }
+
+ dev_set_drvdata(dev, priv);
+
+ return 0;
+}
+
+static int tegra_gmi_remove(struct platform_device *pdev)
+{
+ struct tegra_gmi_priv *priv = dev_get_drvdata(&pdev->dev);
+
+ of_platform_depopulate(&pdev->dev);
+
+ tegra_gmi_disable(priv);
+
+ return 0;
+}
+
+static const struct of_device_id tegra_gmi_id_table[] = {
+ { .compatible = "nvidia,tegra20-gmi", },
+ { .compatible = "nvidia,tegra30-gmi", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tegra_gmi_id_table);
+
+static struct platform_driver tegra_gmi_driver = {
+ .probe = tegra_gmi_probe,
+ .remove = tegra_gmi_remove,
+ .driver = {
+ .name = "tegra-gmi",
+ .of_match_table = tegra_gmi_id_table,
+ },
+};
+module_platform_driver(tegra_gmi_driver);
+
+MODULE_AUTHOR("Mirza Krak <mirza.krak@gmail.com");
+MODULE_DESCRIPTION("NVIDIA Tegra GMI Bus Driver");
+MODULE_LICENSE("GPL v2");
--
2.1.4
^ permalink raw reply related
* [PATCH V4 5/6] ARM: tegra: Add Tegra20 GMI support
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
Add a device node for the GMI controller found on Tegra20.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
---
Changes in v2:
- added address-cells, size-cells and ranges properties
Changes in v3:
- fixed range address which is not the same as Tegra30.
Changes in v4:
- removed extra newline and a initial space in resets property.
arch/arm/boot/dts/tegra20.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 2207c08..e880750 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -376,6 +376,19 @@
status = "disabled";
};
+ gmi at 70009000 {
+ compatible = "nvidia,tegra20-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0xd0000000 0xfffffff>;
+ clocks = <&tegra_car TEGRA20_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ status = "disabled";
+ };
+
pwm: pwm at 7000a000 {
compatible = "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
--
2.1.4
^ permalink raw reply related
* [PATCH V4 4/6] ARM: tegra: Add Tegra30 GMI support
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
Add a device node for the GMI controller found on Tegra30.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
---
Changes in v2:
- added address-cells, size-cells and ranges properties
Changes in v3:
- no changes
Changes in v4:
- no changes
arch/arm/boot/dts/tegra30.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 5030065..bbb1c00 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -439,6 +439,19 @@
status = "disabled";
};
+ gmi at 70009000 {
+ compatible = "nvidia,tegra30-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 0x48000000 0x7ffffff>;
+ clocks = <&tegra_car TEGRA30_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ status = "disabled";
+ };
+
pwm: pwm at 7000a000 {
compatible = "nvidia,tegra30-pwm", "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
--
2.1.4
^ permalink raw reply related
* [PATCH V4 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
Document the devicetree bindings for the Generic Memory Interface (GMI)
bus driver found on Tegra SOCs.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v2:
- Updated examples and some information based on comments from Jon Hunter.
Changes in v3:
- Updates ranges description based on comments from Rob Herring
Changes in v4:
- renamed snor-*-inv to snor-*-active-high
.../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +++++++++++++++++++++
1 file changed, 132 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
new file mode 100644
index 0000000..83b0e54
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
@@ -0,0 +1,132 @@
+Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
+
+The Generic Memory Interface bus enables memory transfers between internal and
+external memory. Can be used to attach various high speed devices such as
+synchronous/asynchronous NOR, FPGA, UARTS and more.
+
+The actual devices are instantiated from the child nodes of a GMI node.
+
+Required properties:
+ - compatible : Should contain one of the following:
+ For Tegra20 must contain "nvidia,tegra20-gmi".
+ For Tegra30 must contain "nvidia,tegra30-gmi".
+ - reg: Should contain GMI controller registers location and length.
+ - clocks: Must contain an entry for each entry in clock-names.
+ - clock-names: Must include the following entries: "gmi"
+ - resets : Must contain an entry for each entry in reset-names.
+ - reset-names : Must include the following entries: "gmi"
+ - #address-cells: The number of cells used to represent physical base
+ addresses in the GMI address space. Should be 2.
+ - #size-cells: The number of cells used to represent the size of an address
+ range in the GMI address space. Should be 1.
+ - ranges: Must be set up to reflect the memory layout with three integer values
+ for each chip-select line in use (only one entry is supported, see below
+ comments):
+ <cs-number> <offset> <physical address of mapping> <size>
+
+Note that the GMI controller does not have any internal chip-select address
+decoding, because of that chip-selects either need to be managed via software
+or by employing external chip-select decoding logic.
+
+If external chip-select logic is used to support multiple devices it is assumed
+that the devices use the same timing and so are probably the same type. It also
+assumes that they can fit in the 256MB address range. In this case only one
+child device is supported which represents the active chip-select line, see
+examples for more insight.
+
+The chip-select number is decoded from the child nodes second address cell of
+'ranges' property, if 'ranges' property is not present or empty chip-select will
+then be decoded from the first cell of the 'reg' property.
+
+Optional child cs node properties:
+
+ - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
+ - nvidia,snor-mux-mode: Enable address/data MUX mode.
+ - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
+ If omitted it will be asserted with data.
+ - nvidia,snor-rdy-active-high: RDY signal is active high
+ - nvidia,snor-adv-active-high: ADV signal is active high
+ - nvidia,snor-oe-active-high: WE/OE signal is active high
+ - nvidia,snor-cs-active-high: CS signal is active high
+
+ Note that there is some special handling for the timing values.
+ From Tegra TRM:
+ Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
+
+ - nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
+ bus. Valid values are 0-15, default is 1
+ - nvidia,snor-hold-width: Number of cycles CE stays asserted after the
+ de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
+ (in case of MASTER Request). Valid values are 0-15, default is 1
+ - nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
+ Valid values are 0-15, default is 1.
+ - nvidia,snor-ce-width: Number of cycles before CE is asserted.
+ Valid values are 0-15, default is 4
+ - nvidia,snor-we-width: Number of cycles during which WE stays asserted.
+ Valid values are 0-15, default is 1
+ - nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
+ Valid values are 0-255, default is 1
+ - nvidia,snor-wait-width: Number of cycles before READY is asserted.
+ Valid values are 0-255, default is 3
+
+Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
+controllers with a simple-bus node since they are all connected to the same
+chip-select (CS4), in this example external address decoding is provided:
+
+gmi at 70090000 {
+ compatible = "nvidia,tegra20-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clocks = <&tegra_car TEGRA20_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ ranges = <4 0 0xd0000000 0xfffffff>;
+
+ status = "okay";
+
+ bus at 4,0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 4 0 0x40100>;
+
+ nvidia,snor-mux-mode;
+ nvidia,snor-adv-active-high;
+
+ can at 0 {
+ reg = <0 0x100>;
+ ...
+ };
+
+ can at 40000 {
+ reg = <0x40000 0x100>;
+ ...
+ };
+ };
+};
+
+Example with one SJA1000 CAN controller connected to the GMI bus
+on CS4:
+
+gmi at 70090000 {
+ compatible = "nvidia,tegra20-gmi";
+ reg = <0x70009000 0x1000>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clocks = <&tegra_car TEGRA20_CLK_NOR>;
+ clock-names = "gmi";
+ resets = <&tegra_car 42>;
+ reset-names = "gmi";
+ ranges = <4 0 0xd0000000 0xfffffff>;
+
+ status = "okay";
+
+ can at 4,0 {
+ reg = <4 0 0x100>;
+ nvidia,snor-mux-mode;
+ nvidia,snor-adv-active-high;
+ ...
+ };
+};
--
2.1.4
^ permalink raw reply related
* [PATCH V4 2/6] clk: tegra: add TEGRA30_CLK_NOR to init table
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
Add TEGRA30_CLK_NOR to init table and set default rate to 127 MHz which
is max rate.
The maximum rate value of 127 MHz is pulled from the downstream L4T
kernel.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
---
Changes in v2:
- no changes
Changes in v3:
- Added comment in commit message where I got the maximum rates from.
Changes in V4:
- no changes
drivers/clk/tegra/clk-tegra30.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 8e2db5e..67f1677 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1252,6 +1252,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
{ TEGRA30_CLK_SDMMC1, TEGRA30_CLK_PLL_P, 48000000, 0 },
{ TEGRA30_CLK_SDMMC2, TEGRA30_CLK_PLL_P, 48000000, 0 },
{ TEGRA30_CLK_SDMMC3, TEGRA30_CLK_PLL_P, 48000000, 0 },
+ { TEGRA30_CLK_NOR, TEGRA30_CLK_PLL_P, 127000000, 0 },
{ TEGRA30_CLK_PLL_M, TEGRA30_CLK_CLK_MAX, 0, 1 },
{ TEGRA30_CLK_PCLK, TEGRA30_CLK_CLK_MAX, 0, 1 },
{ TEGRA30_CLK_CSITE, TEGRA30_CLK_CLK_MAX, 0, 1 },
--
2.1.4
^ permalink raw reply related
* [PATCH V4 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table
From: Mirza Krak @ 2016-11-07 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478507405-13204-1-git-send-email-mirza.krak@gmail.com>
From: Mirza Krak <mirza.krak@gmail.com>
Add TEGRA20_CLK_NOR to init table and set default rate to 92 MHz which
is max rate.
The maximum rate value of 92 MHz is pulled from the downstream L4T
kernel.
Signed-off-by: Mirza Krak <mirza.krak@gmail.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <jonathanh@nvidia.com>
---
Changes in v2:
- no changes
Changes in v3:
- Added comment in commit message where I got the maximum rates from.
Changes in V4:
- no changes
drivers/clk/tegra/clk-tegra20.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 837e5cb..13d3b5a 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1047,6 +1047,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
{ TEGRA20_CLK_SDMMC3, TEGRA20_CLK_PLL_P, 48000000, 0 },
{ TEGRA20_CLK_SDMMC4, TEGRA20_CLK_PLL_P, 48000000, 0 },
{ TEGRA20_CLK_SPI, TEGRA20_CLK_PLL_P, 20000000, 0 },
+ { TEGRA20_CLK_NOR, TEGRA20_CLK_PLL_P, 92000000, 0 },
{ TEGRA20_CLK_SBC1, TEGRA20_CLK_PLL_P, 100000000, 0 },
{ TEGRA20_CLK_SBC2, TEGRA20_CLK_PLL_P, 100000000, 0 },
{ TEGRA20_CLK_SBC3, TEGRA20_CLK_PLL_P, 100000000, 0 },
--
2.1.4
^ permalink raw reply related
* [PATCH V4 0/6] Add support for Tegra GMI bus controller
From: Mirza Krak @ 2016-11-07 8:29 UTC (permalink / raw)
To: linux-arm-kernel
From: Mirza Krak <mirza.krak@hostmobility.com>
Hi.
This patch series adds support for the Tegra GMI bus controller.
I have tested this series on a Tegra30 using a Colibri T30 SOM on a custom
carrier board which has multiple CAN controllers (SJA1000) connected to the
GMI bus.
I have re-based on top of latest tegra/for-next in V4. Also see individual
patches for changes in V4.
Hopefully this will be the last round.
See below links for previous discussions.
Comments on RFC:
https://marc.info/?l=linux-clk&m=146893557629903&w=2
https://marc.info/?l=linux-tegra&m=146893541829801&w=2
https://marc.info/?l=linux-tegra&m=146893542429814&w=2
Comments on V1:
https://marc.info/?l=linux-arm-kernel&m=147051551821122&w=2
https://marc.info/?l=linux-arm-kernel&m=147051553121150&w=2
https://marc.info/?l=linux-arm-kernel&m=147194856600627&w=2
https://marc.info/?l=linux-arm-kernel&m=147072742432211&w=2
Comments on V2:
https://marc.info/?l=devicetree&m=147522253920226&w=2
https://marc.info/?l=linux-tegra&m=147204588027687&w=2
https://marc.info/?l=linux-tegra&m=147204588027687&w=2
https://marc.info/?l=devicetree&m=147256931318922&w=2
Comments on V3:
https://marc.info/?l=linux-tegra&m=147789181607782&w=2
https://marc.info/?l=linux-tegra&m=147816818203104&w=2
https://marc.info/?l=linux-tegra&m=147816897003332&w=2
https://marc.info/?l=linux-tegra&m=147818119107204&w=2
Mirza Krak (6):
clk: tegra: add TEGRA20_CLK_NOR to init table
clk: tegra: add TEGRA30_CLK_NOR to init table
dt/bindings: Add bindings for Tegra GMI controller
ARM: tegra: Add Tegra30 GMI support
ARM: tegra: Add Tegra20 GMI support
bus: Add support for Tegra Generic Memory Interface
.../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 ++++++++++
arch/arm/boot/dts/tegra20.dtsi | 13 +
arch/arm/boot/dts/tegra30.dtsi | 13 +
drivers/bus/Kconfig | 7 +
drivers/bus/Makefile | 1 +
drivers/bus/tegra-gmi.c | 275 +++++++++++++++++++++
drivers/clk/tegra/clk-tegra20.c | 1 +
drivers/clk/tegra/clk-tegra30.c | 1 +
8 files changed, 443 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
create mode 100644 drivers/bus/tegra-gmi.c
--
2.1.4
^ permalink raw reply
* ILP32 for ARM64: testing with glibc testsuite
From: Yury Norov @ 2016-11-07 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
Hi all,
[add libc-alpha mail list]
For libc-alpha: this is the part of LKML submission with latest
patches for aarch64/ilp32.
https://www.spinics.net/lists/arm-kernel/msg537846.html
Glibc that I use has also included consolidation patches from Adhemerval
Zanella and me that are still not in the glibc master. The full series is:
https://github.com/norov/glibc/tree/ilp32-2.24-dev2
Below is the results of glibc testsuite run for aarch64/lp64
in different configurations. Column names meaning:
kvgv: kernel is vanilla, glibc is vanilla;
kdgv: kernel has ilp32 patches applied, but ilp32 is disabled in config;
glibc is vanilla;
kegv: kernel has ilp32 patches applied and ilp32 is enabled, glibc is vanilla;
kege: kernel patches are applied and enabled, glibc patches are applied.
Only different lines are shown. Full results are in attached archive.
I didn't analyze regressions deep yet, so any ideas/suggestions are appreciated.
Yury.
Test kvgv kdgv kegv kege
conform/ISO/stdio.h/linknamespace PASS PASS PASS FAIL
conform/ISO11/stdio.h/linknamespace PASS PASS PASS FAIL
conform/ISO99/stdio.h/linknamespace PASS PASS PASS FAIL
conform/POSIX/stdio.h/linknamespace PASS PASS PASS FAIL
conform/POSIX/sys/stat.h/linknamespace PASS PASS PASS FAIL
conform/UNIX98/stdio.h/linknamespace PASS PASS PASS FAIL
conform/XOPEN2K/stdio.h/linknamespace PASS PASS PASS FAIL
conform/XPG3/stdio.h/linknamespace PASS PASS PASS FAIL
conform/XPG4/stdio.h/linknamespace PASS PASS PASS FAIL
csu/tst-atomic PASS PASS PASS FAIL
elf/check-localplt PASS PASS PASS FAIL
iconvdata/mtrace-tst-loading PASS FAIL PASS PASS
iconvdata/tst-loading PASS FAIL PASS PASS
io/check-installed-headers-c PASS PASS PASS FAIL
io/check-installed-headers-cxx PASS PASS PASS FAIL
malloc/tst-malloc-backtrace FAIL PASS PASS PASS
malloc/tst-malloc-thread-exit FAIL PASS PASS PASS
malloc/tst-malloc-usable FAIL PASS PASS PASS
malloc/tst-mallocfork FAIL PASS PASS PASS
malloc/tst-mallocstate FAIL PASS PASS PASS
malloc/tst-mallopt FAIL PASS PASS PASS
malloc/tst-mcheck FAIL PASS PASS PASS
malloc/tst-memalign FAIL PASS PASS PASS
malloc/tst-obstack FAIL PASS PASS PASS
malloc/tst-posix_memalign FAIL PASS PASS PASS
malloc/tst-pvalloc FAIL PASS PASS PASS
malloc/tst-realloc FAIL PASS PASS PASS
malloc/tst-scratch_buffer FAIL PASS PASS PASS
malloc/tst-trim1 FAIL PASS PASS PASS
nptl/tst-eintr4 PASS PASS PASS NA
posix/tst-regex2 PASS FAIL FAIL FAIL
posix/tst-getaddrinfo4 PASS PASS FAIL FAIL
posix/tst-getaddrinfo5 PASS PASS FAIL FAIL
sysvipc/test-sysvmsg NA NA NA FAIL
sysvipc/test-sysvsem NA NA NA FAIL
sysvipc/test-sysvshm NA NA NA FAIL
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lp64.sum.tar.gz
Type: application/gzip
Size: 37007 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/ad049b89/attachment-0001.gz>
^ permalink raw reply
* [BUG] pinctrl: sunxi: sunxi-pinctrl fail to load with CONFIG_DEBUG_TEST_DRIVER_REMOVE
From: LABBE Corentin @ 2016-11-07 8:18 UTC (permalink / raw)
To: linux-arm-kernel
Hello
With CONFIG_DEBUG_TEST_DRIVER_REMOVE=y pinctrl-sunxi fail to load on the second try.
[ 3.900061] sun8i-h3-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver
[ 3.916251] gpio gpiochip1: GPIO integer space overlap, cannot add chip
[ 3.923016] gpiochip_add_data: GPIOs 0..223 (1c20800.pinctrl) failed to register
[ 3.931099] sun8i-h3-pinctrl: probe of 1c20800.pinctrl failed with error -16
[ 3.944709] sun8i-h3-r-pinctrl 1f02c00.pinctrl: initialized sunXi PIO driver
[ 3.960796] gpio gpiochip2: GPIO integer space overlap, cannot add chip
[ 3.967594] gpiochip_add_data: GPIOs 352..383 (1f02c00.pinctrl) failed to register
[ 3.975633] sun8i-h3-r-pinctrl: probe of 1f02c00.pinctrl failed with error -16
Without it, all subsequent drivers fail to load.
Tested on Orange PI PC board.
Regards
^ permalink raw reply
* Memory range end be inclusive or exclusive? Re: [PATCH v1 1/4] kexec: (bugfix) calc correct end address of memory ranges in device tree
From: Simon Horman @ 2016-11-07 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031085008.GF19531@linaro.org>
Hi Akashi-san,
sorry for the long delay(s).
The patch below seems reasonable to me and I'm happy to apply it.
On Mon, Oct 31, 2016 at 05:50:09PM +0900, AKASHI Takahiro wrote:
> Simon,
>
> On Tue, Sep 06, 2016 at 09:29:59AM +0900, AKASHI Takahiro wrote:
> > Simon,
> >
> > What is your opinion on this issue?
>
> Pinged you several times so far.
>
> Can you please give me your comment?
> (attached below is the original patch.)
>
> -Takahiro AKASHI
>
> >
> > On Mon, Aug 01, 2016 at 01:52:40PM +0900, AKASHI Takahiro wrote:
> > > On Fri, Jul 29, 2016 at 06:23:56PM +0100, Russell King - ARM Linux wrote:
> > > > On Fri, Jul 29, 2016 at 10:12:26AM -0700, Geoff Levand wrote:
> > > > > On Fri, 2016-07-29 at 09:27 +0100, Russell King - ARM Linux wrote:
> > > > >
> > > > > > So, these functions are a mess and need fixing.
> > > > >
> > > > > Since this change isn't really related to arm64 support, I'll
> > > > > drop this patch from my series.
> > > >
> > > > Do you have a case which triggers bugs in this code?
> > >
> > > Actually, this patch was necessary when my kdump used "usable-memory"
> > > properties in "memory" nodes, as on ppc64, to limit the usable memory
> > > regions that can be used by crash dump kernel.
> > > Since then, I've moved to the approach of using "mem=" kernel parameter,
> > > then introducing a new property, "linux,usable-memory-range," under /chosen
> > > and now we don't need this patch any more.
> > >
> > > So, we can drop it but I still believe that it is buggy.
> >
> > Due to the discussions[1], I may want to re-enable "usable-memory"
> > property on arm64. In addition, I would like to add a function,
> > dtb_add_usable_memory_properties(), a variant of
> > add_usable_memory_properties(), to kexec/dt-ops.c.
> > So this issue is quite crucial now.
> >
> > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/452685.html
> >
> > -Takahiro AKASHI
> >
> > > Thanks,
> > > -Takahiro AKASHI
> > >
> > > > --
> > > > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > > > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> > > > according to speedtest.net.
> ===8<===
> From: AKASHI Takahiro <takahiro.akashi@linaro.org>
>
> The end address of "reg" attribute in device tree's memory should be
> inclusive.
> ---
> kexec/fs2dt.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/fs2dt.c b/kexec/fs2dt.c
> index 79aa0f3..953f78a 100644
> --- a/kexec/fs2dt.c
> +++ b/kexec/fs2dt.c
> @@ -236,7 +236,8 @@ static void add_dyn_reconf_usable_mem_property__(int fd)
> ranges_size*8);
> }
> ranges[rlen++] = cpu_to_be64(loc_base);
> - ranges[rlen++] = cpu_to_be64(loc_end - loc_base);
> + ranges[rlen++] = cpu_to_be64(loc_end
> + - loc_base + 1);
> rngs_cnt++;
> }
> }
> @@ -350,7 +351,7 @@ static void add_usable_mem_property(int fd, size_t len)
> ranges_size*sizeof(*ranges));
> }
> ranges[rlen++] = cpu_to_be64(loc_base);
> - ranges[rlen++] = cpu_to_be64(loc_end - loc_base);
> + ranges[rlen++] = cpu_to_be64(loc_end - loc_base + 1);
> }
> }
>
> --
> 2.10.0
>
^ permalink raw reply
* [PATCH V2] arm64: Add support of R_AARCH64_PREL32 relocation in purgatory
From: Simon Horman @ 2016-11-07 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3175f823-dd03-07f6-fffe-6ec5487cbf93@infradead.org>
On Fri, Oct 28, 2016 at 11:43:48AM -0700, Geoff Levand wrote:
> On 10/27/2016 09:16 PM, Pratyush Anand wrote:
> > gcc version in fedora koji is 6.2.1-2.fc25. kexec-tools compiled with this
> > gcc produced another relocation error:
> >
> > machine_apply_elf_rel: ERROR Unknown type: 261
> >
> > This patch fixes the above error.
>
> Looks good. Simon, please apply.
>
> Reviewed-by: Geoff Levand <geoff@infradead.org>
Thanks, applied.
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Simon Horman @ 2016-11-07 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2792b205-dfdd-1362-9cf4-d886472a9357@infradead.org>
On Thu, Oct 20, 2016 at 09:37:03AM -0700, Geoff Levand wrote:
> On 10/20/2016 03:43 AM, Catalin Marinas wrote:
> > When compiling the kexec-tools with gcc6, the following additional
> > reolcations are generated in the purgatory.ro file:
> >
> > R_AARCH64_ADR_PREL_PG_HI21
> > R_AARCH64_ADD_ABS_LO12_NC
> > R_AARCH64_LDST64_ABS_LO12_NC
>
> Looks good. Simon, please apply.
>
> Reviewed-by: Geoff Levand <geoff@infradead.org>
Thanks, applied.
^ permalink raw reply
* [PATCH 2/2] clk: sunxi-ng: fix up PLL_CPUX adjusting for A23/A33
From: Maxime Ripard @ 2016-11-07 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-2-icenowy@aosc.xyz>
Hi,
Same remark for the commit title.
On Mon, Nov 07, 2016 at 01:29:32AM +0800, Icenowy Zheng wrote:
> When adjusting PLL_CPUX on A23/A33, the PLL is driven too high, and the
> system stucks.
>
> Add a notifier to avoid this situation.
>
> The code is ported from ccu-sun6i-a31.c.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Patch 4.9-rc too.
> drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 ++++++++++
Have you checked that it was also needed on A23? Not all SoCs are in
this situation.
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/20161107/c6eb2990/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33
From: Maxime Ripard @ 2016-11-07 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-1-icenowy@aosc.xyz>
Hi,
On Mon, Nov 07, 2016 at 01:29:31AM +0800, Icenowy Zheng wrote:
> The CPUX clock of A23/33 CCU driver forgot to add CLK_SET_RATE_PARENT
> flag, which makes its frequency fail to change (as part of cpu thermal
> throttle).
>
> Fix it by add this flag.
Your commit title and log could be better.
The title usually is more about what is done in the patch itself,
something like "clk: sunxi-ng: Allow to change the parent rate for the
CPU clocks" in this case.
And your commit log should explain why it is an issue. Yours is even
wrong here, we could definitely change the rate of these clocks
already. The only thing that was not allowed was to change the rate of
its parents, which is what this patch fixes.
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Patch 4.9-rc too.
I don't see why it should be part of 4.9. No one uses that code in 4.9.
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/20161107/46d235a8/attachment.sig>
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Martin Strbačka @ 2016-11-07 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105212748.vtdprlxxismy5xmk@perseus.defre.kleine-koenig.org>
On 5.11.2016 22:27, Uwe Kleine-K?nig wrote:
>>> Do I need to "register" turris in vendor-prefixes.txt for that?
>> >
>> > Yes please.
> OK, will wait for Martin to comment what we want there. cznic or turris.
Hello,
please use CZ.NIC in this case. Turris Omnia is a model name.
Thanks for your work!
Martin
--
Martin Strbacka CZ.NIC, z.s.p.o. tel. +420 604 217 854
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/cee2ad06/attachment.sig>
^ permalink raw reply
* [PATCH v7 1/2] soc: samsung: add exynos chipid driver support
From: Marek Szyprowski @ 2016-11-07 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478347427-28409-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On 2016-11-05 13:03, Pankaj Dubey wrote:
> Exynos SoCs have Chipid, for identification of product IDs
> and SoC revisions. This patch intends to provide initialization
> code for all these functionalities, at the same time it provides some
> sysfs entries for accessing these information to user-space.
>
> This driver uses existing binding for exynos-chipid.
>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> drivers/soc/samsung/Kconfig | 5 ++
> drivers/soc/samsung/Makefile | 1 +
> drivers/soc/samsung/exynos-chipid.c | 148 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 154 insertions(+)
> create mode 100644 drivers/soc/samsung/exynos-chipid.c
>
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2455339..f9ab858 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -14,4 +14,9 @@ config EXYNOS_PM_DOMAINS
> bool "Exynos PM domains" if COMPILE_TEST
> depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>
> +config EXYNOS_CHIPID
> + bool "Exynos Chipid controller driver" if COMPILE_TEST
> + depends on (ARM && ARCH_EXYNOS) || ((ARM || ARM64) && COMPILE_TEST)
> + select SOC_BUS
> +
> endif
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index 3619f2e..2a8a85e 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
> exynos5250-pmu.o exynos5420-pmu.o
> obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_EXYNOS_CHIPID) += exynos-chipid.o
> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> new file mode 100644
> index 0000000..9761e54
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * EXYNOS - CHIP ID support
> + * Author: Pankaj Dubey <pankaj.dubey@samsung.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/io.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/sys_soc.h>
> +
> +#define EXYNOS3250_SOC_ID 0xE3472000
> +#define EXYNOS4210_SOC_ID 0x43210000
> +#define EXYNOS4212_SOC_ID 0x43220000
> +#define EXYNOS4412_SOC_ID 0xE4412000
> +#define EXYNOS4415_SOC_ID 0xE4415000
> +#define EXYNOS5250_SOC_ID 0x43520000
> +#define EXYNOS5260_SOC_ID 0xE5260000
> +#define EXYNOS5410_SOC_ID 0xE5410000
> +#define EXYNOS5420_SOC_ID 0xE5420000
> +#define EXYNOS5440_SOC_ID 0xE5440000
> +#define EXYNOS5800_SOC_ID 0xE5422000
> +
> +#define EXYNOS_SOC_MASK 0xFFFFF000
> +
> +#define EXYNOS4210_REV_0 0x0
> +#define EXYNOS4210_REV_1_0 0x10
> +#define EXYNOS4210_REV_1_1 0x11
EXYNOS4210_REV* defines are not used at all in this driver.
> +
> +#define EXYNOS_SUBREV_MASK (0xF << 4)
> +#define EXYNOS_MAINREV_MASK (0xF << 0)
> +#define EXYNOS_REV_MASK (EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
> +
> +
> +static const char * __init product_id_to_soc_id(unsigned int product_id)
> +{
> + const char *soc_name;
> + unsigned int soc_id = product_id & EXYNOS_SOC_MASK;
> +
> + switch (soc_id) {
> + case EXYNOS3250_SOC_ID:
> + soc_name = "EXYNOS3250";
> + break;
> + case EXYNOS4210_SOC_ID:
> + soc_name = "EXYNOS4210";
> + break;
> + case EXYNOS4212_SOC_ID:
> + soc_name = "EXYNOS4212";
> + break;
> + case EXYNOS4412_SOC_ID:
> + soc_name = "EXYNOS4412";
> + break;
> + case EXYNOS4415_SOC_ID:
> + soc_name = "EXYNOS4415";
> + break;
> + case EXYNOS5250_SOC_ID:
> + soc_name = "EXYNOS5250";
> + break;
> + case EXYNOS5260_SOC_ID:
> + soc_name = "EXYNOS5260";
> + break;
> + case EXYNOS5420_SOC_ID:
> + soc_name = "EXYNOS5420";
> + break;
> + case EXYNOS5440_SOC_ID:
> + soc_name = "EXYNOS5440";
> + break;
> + case EXYNOS5800_SOC_ID:
> + soc_name = "EXYNOS5800";
> + break;
> + default:
> + soc_name = "UNKNOWN";
> + }
> + return soc_name;
> +}
This approach is a bit error prone. You have already missed Exynos5410
and early Exynos 4210 are not detected because of the incorrect SOC MASK.
IMHO you should replace above code and defines with a simple array,
where each ID is present only once, so it will be much easier to add
future SoCs:
static const struct exynos_soc_id {
const char *name;
unsigned int id;
unsigned int mask;
} soc_ids[] = {
{ "EXYNOS3250", 0xE3472000, 0xFFFFF000 },
{ "EXYNOS4210", 0x43200000, 0xFFFE0000 },
{ "EXYNOS4212", 0x43220000, 0xFFFE0000 },
{ "EXYNOS4412", 0xE4412000, 0xFFFE0000 },
{ "EXYNOS4415", 0xE4415000, 0xFFFE0000 },
{ "EXYNOS5250", 0x43520000, 0xFFFFF000 },
{ "EXYNOS5260", 0xE5260000, 0xFFFFF000 },
{ "EXYNOS5410", 0xE5410000, 0xFFFFF000 },
{ "EXYNOS5420", 0xE5420000, 0xFFFFF000 },
{ "EXYNOS5440", 0xE5440000, 0xFFFFF000 },
{ "EXYNOS5800", 0xE5422000, 0xFFFFF000 },
};
static const char * __init product_id_to_soc_id(unsigned int product_id)
{
int i;
for (i = 0; i < ARRAY_SIZE(soc_ids); i++)
if ((product_id & soc_ids[i].mask) == soc_ids[i].id)
return soc_ids[i].name;
return "UNKNOWN";
}
I'm also not sure about Exynos 4415, which has been scheduled for removal.
> +
> +static const struct of_device_id of_exynos_chipid_ids[] = {
> + {
> + .compatible = "samsung,exynos4210-chipid",
> + },
> + {},
> +};
> +
> +/**
> + * exynos_chipid_early_init: Early chipid initialization
> + */
> +int __init exynos_chipid_early_init(void)
> +{
> + struct soc_device_attribute *soc_dev_attr;
> + struct soc_device *soc_dev;
> + struct device_node *root;
> + struct device_node *np;
> + void __iomem *exynos_chipid_base;
> + const struct of_device_id *match;
> + u32 product_id;
> + u32 revision;
> +
> + np = of_find_matching_node_and_match(NULL,
> + of_exynos_chipid_ids, &match);
> + if (!np)
> + return -ENODEV;
> +
> + exynos_chipid_base = of_iomap(np, 0);
> +
> + if (!exynos_chipid_base)
> + return PTR_ERR(exynos_chipid_base);
> +
> + product_id = __raw_readl(exynos_chipid_base);
> + revision = product_id & EXYNOS_REV_MASK;
> + iounmap(exynos_chipid_base);
> +
> + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> + if (!soc_dev_attr)
> + return -ENODEV;
> +
> + soc_dev_attr->family = "Samsung Exynos";
> +
> + root = of_find_node_by_path("/");
> + of_property_read_string(root, "model", &soc_dev_attr->machine);
> + of_node_put(root);
> +
> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%x", revision);
> + soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
> +
> +
> + pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> + product_id_to_soc_id(product_id), revision);
> +
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + kfree(soc_dev_attr->revision);
> + kfree_const(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr);
> + return PTR_ERR(soc_dev);
> + }
> +
> + return 0;
> +}
> +early_initcall(exynos_chipid_early_init);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 1/4] ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
From: Krzysztof Kozlowski @ 2016-11-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <581FF706.3050502@samsung.com>
On Mon, Nov 7, 2016 at 5:37 AM, pankaj.dubey <pankaj.dubey@samsung.com> wrote:
> Hi Krzysztof,
>
> On Saturday 05 November 2016 09:11 PM, Krzysztof Kozlowski wrote:
>> On Fri, Nov 04, 2016 at 09:09:21AM +0530, Pankaj Dubey wrote:
>>> We can safely remove exynos_smp_init_cpus() hook from mach-exynos/platsmp.c,
>>> as all SMP platforms in mach-exynos can rely on DT for CPU core description
>>> instead of determining number of cores from the SCU.
>>>
>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>> ---
>>> arch/arm/mach-exynos/platsmp.c | 31 -------------------------------
>>> 1 file changed, 31 deletions(-)
>>>
>>
>>
>> Thanks, applied. Somehow your patchset did not reach linux-samsung-soc's
>> Parchwork. I don't have a clue why... It is on linux-arm-kernel's
>> Patchwork.
>>
>
> Thanks for looking into this series.
>
> I am also not sure why its not reflecting for you on linux-samsung-soc's
> Patchwork, but I can see this series in linux-samsung-soc Patchwork at
> below links:
Hmmm... it is weird. Why I didn't see them before? It seems that I
even updated their status. Confusing...
> Will you please review other two patches (3/4 and 4/4) in this series?
4/4 is okay but it depends on 3/4 which already has a valid comment -
what will happen when DT node is not present (which first of all will
happen because DTS is applied on separate branch... and anyway the
code must be prepared for different DTSes). Initially I thought there
will be NULL pointer exception on of_iomap() but after looking at the
code it might work, I mean fail in a reasonable way.
Best regards,
Krzysztof
^ permalink raw reply
* [RESEND PATCH v3 2/2] PM/devfreq: rk3399: get devfreq suspend frequency
From: Lin Huang @ 2016-11-07 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478500420-22045-1-git-send-email-hl@rock-chips.com>
We need ddr run a specific frequency when ddr dvfs stop
working. For example: if we enable two monitor, then we will
stop ddr dvfs, but we hope ddr can run in highest frequency
obviously.
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- None
Changes in v3:
- None
drivers/devfreq/rk3399_dmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
index 5a2da95..39f8e27 100644
--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -329,7 +329,7 @@ static int rk3399_dmcfreq_probe(struct platform_device *pdev)
if (IS_ERR(data->devfreq))
return PTR_ERR(data->devfreq);
devm_devfreq_register_opp_notifier(dev, data->devfreq);
-
+ devfreq_opp_get_suspend_opp(dev, data->devfreq);
data->dev = dev;
platform_set_drvdata(pdev, data);
pd_register_notify_to_dmc(data->devfreq);
--
1.9.1
^ permalink raw reply related
* [RESEND PATCH v3 1/2] PM/devfreq: add suspend frequency support
From: Lin Huang @ 2016-11-07 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478500420-22045-1-git-send-email-hl@rock-chips.com>
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- use update_devfreq() instead devfreq_update_status()
Changes in v3:
- fix build error
drivers/devfreq/devfreq.c | 18 ++++++++++++++++--
drivers/devfreq/governor_simpleondemand.c | 9 +++++++++
include/linux/devfreq.h | 8 ++++++++
3 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index da72d97..4c76e79 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -359,8 +359,10 @@ void devfreq_monitor_suspend(struct devfreq *devfreq)
mutex_unlock(&devfreq->lock);
return;
}
-
- devfreq_update_status(devfreq, devfreq->previous_freq);
+ if (devfreq->suspend_freq)
+ update_devfreq(devfreq);
+ else
+ devfreq_update_status(devfreq, devfreq->previous_freq);
devfreq->stop_polling = true;
mutex_unlock(&devfreq->lock);
cancel_delayed_work_sync(&devfreq->work);
@@ -1254,6 +1256,18 @@ struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
}
EXPORT_SYMBOL(devfreq_recommended_opp);
+void devfreq_opp_get_suspend_opp(struct device *dev, struct devfreq *devfreq)
+{
+ struct dev_pm_opp *suspend_opp;
+
+ rcu_read_lock();
+ suspend_opp = dev_pm_opp_get_suspend_opp(dev);
+ if (suspend_opp)
+ devfreq->suspend_freq = dev_pm_opp_get_freq(suspend_opp);
+ rcu_read_unlock();
+}
+EXPORT_SYMBOL(devfreq_opp_get_suspend_opp);
+
/**
* devfreq_register_opp_notifier() - Helper function to get devfreq notified
* for any changes in the OPP availability
diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
index ae72ba5..a3efee0 100644
--- a/drivers/devfreq/governor_simpleondemand.c
+++ b/drivers/devfreq/governor_simpleondemand.c
@@ -29,6 +29,15 @@ static int devfreq_simple_ondemand_func(struct devfreq *df,
struct devfreq_simple_ondemand_data *data = df->data;
unsigned long max = (df->max_freq) ? df->max_freq : UINT_MAX;
+ /*
+ * if devfreq in suspend status and have suspend_freq,
+ * the frequency need to set to suspend_freq
+ */
+ if (df->stop_polling && df->suspend_freq) {
+ *freq = df->suspend_freq;
+ return 0;
+ }
+
err = devfreq_update_stats(df);
if (err)
return err;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 98c6993..1bdd5d3 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -172,6 +172,7 @@ struct devfreq {
struct delayed_work work;
unsigned long previous_freq;
+ unsigned long suspend_freq;
struct devfreq_dev_status last_status;
void *data; /* private data for governors */
@@ -214,6 +215,8 @@ extern int devfreq_resume_device(struct devfreq *devfreq);
/* Helper functions for devfreq user device driver with OPP. */
extern struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
unsigned long *freq, u32 flags);
+extern void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq);
extern int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq);
extern int devfreq_unregister_opp_notifier(struct device *dev,
@@ -315,6 +318,11 @@ static inline struct dev_pm_opp *devfreq_recommended_opp(struct device *dev,
return ERR_PTR(-EINVAL);
}
+static inline void devfreq_opp_get_suspend_opp(struct device *dev,
+ struct devfreq *devfreq)
+{
+}
+
static inline int devfreq_register_opp_notifier(struct device *dev,
struct devfreq *devfreq)
{
--
1.9.1
^ permalink raw reply related
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