* [PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
Export pm_power_off_prepare. It is needed to implement power off on
Freescale/NXP iMX6 based boards with external power management
integrated circuit (PMIC).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
kernel/reboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index e4ced883d8de..83810d726f3e 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -49,6 +49,7 @@ int reboot_force;
*/
void (*pm_power_off_prepare)(void);
+EXPORT_SYMBOL_GPL(pm_power_off_prepare);
/**
* emergency_restart - reboot the system
--
2.17.0
^ permalink raw reply related
* [PATCH v7 4/6] regulator: pfuze100: add fsl,pmic-stby-poweroff property
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
Document the new optional "fsl,pmic-stby-poweroff" property.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/regulator/pfuze100.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index c6dd3f5e485b..91fec1a0785d 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -4,6 +4,13 @@ Required properties:
- compatible: "fsl,pfuze100", "fsl,pfuze200", "fsl,pfuze3000"
- reg: I2C slave address
+Optional properties:
+- fsl,pmic-stby-poweroff: if present, configure the PMIC to shutdown all
+ power rails when PMIC_STBY_REQ line is asserted during the power off sequence.
+ Use this option if the SoC should be powered off by external power
+ management IC (PMIC) on PMIC_STBY_REQ signal.
+ As opposite to PMIC_STBY_REQ boards can implement PMIC_ON_REQ signal.
+
Required child node:
- regulators: This is the list of child nodes that specify the regulator
initialization data for defined regulators. Please refer to below doc
--
2.17.0
^ permalink raw reply related
* [PATCH v7 5/6] regulator: pfuze100-regulator: provide pm_power_off_prepare handler
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
On some boards the SoC can use one pin "PMIC_STBY_REQ" to notify th PMIC
about state changes. In this case internal state of PMIC must be
preconfigured for upcomming state change.
It works fine with the current regulator framework, except with the
power-off case.
This patch is providing an optional pm_power_off_prepare handler
which will configure standby state of the PMIC to disable all power lines.
In my power consumption test on RIoTBoard, I got the following results:
power off without this patch: 320 mA
power off with this patch: 2 mA
suspend to ram: 40 mA
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/regulator/pfuze100-regulator.c | 92 ++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/drivers/regulator/pfuze100-regulator.c b/drivers/regulator/pfuze100-regulator.c
index 63922a2167e5..f6c276ed91d8 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -28,6 +28,7 @@
#include <linux/regulator/pfuze100.h>
#include <linux/i2c.h>
#include <linux/slab.h>
+#include <linux/kallsyms.h>
#include <linux/regmap.h>
#define PFUZE_NUMREGS 128
@@ -42,11 +43,17 @@
#define PFUZE100_COINVOL 0x1a
#define PFUZE100_SW1ABVOL 0x20
+#define PFUZE100_SW1ABMODE 0x23
#define PFUZE100_SW1CVOL 0x2e
+#define PFUZE100_SW1CMODE 0x31
#define PFUZE100_SW2VOL 0x35
+#define PFUZE100_SW2MODE 0x38
#define PFUZE100_SW3AVOL 0x3c
+#define PFUZE100_SW3AMODE 0x3f
#define PFUZE100_SW3BVOL 0x43
+#define PFUZE100_SW3BMODE 0x46
#define PFUZE100_SW4VOL 0x4a
+#define PFUZE100_SW4MODE 0x4d
#define PFUZE100_SWBSTCON1 0x66
#define PFUZE100_VREFDDRCON 0x6a
#define PFUZE100_VSNVSVOL 0x6b
@@ -57,6 +64,13 @@
#define PFUZE100_VGEN5VOL 0x70
#define PFUZE100_VGEN6VOL 0x71
+#define PFUZE100_SWxMODE_MASK 0xf
+#define PFUZE100_SWxMODE_APS_APS 0x8
+#define PFUZE100_SWxMODE_APS_OFF 0x4
+
+#define PFUZE100_VGENxLPWR BIT(6)
+#define PFUZE100_VGENxSTBY BIT(5)
+
enum chips { PFUZE100, PFUZE200, PFUZE3000 = 3 };
struct pfuze_regulator {
@@ -489,6 +503,69 @@ static inline struct device_node *match_of_node(int index)
}
#endif
+static struct pfuze_chip *syspm_pfuze_chip;
+
+static void pfuze_power_off_prepare(void)
+{
+ dev_info(syspm_pfuze_chip->dev, "Configure standy mode for power off");
+
+ /* Switch from default mode: APS/APS to APS/Off */
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1ABMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW1CMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW2MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3AMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW3BMODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_SW4MODE,
+ PFUZE100_SWxMODE_MASK, PFUZE100_SWxMODE_APS_OFF);
+
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN1VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN2VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN3VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN4VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN5VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+ regmap_update_bits(syspm_pfuze_chip->regmap, PFUZE100_VGEN6VOL,
+ PFUZE100_VGENxLPWR | PFUZE100_VGENxSTBY,
+ PFUZE100_VGENxSTBY);
+}
+
+static int pfuze_power_off_prepare_init(struct pfuze_chip *pfuze_chip)
+{
+ if (pfuze_chip->chip_id != PFUZE100) {
+ dev_warn(pfuze_chip->dev, "Requested pm_power_off_prepare handler for not supported chip\n");
+ return -ENODEV;
+ }
+
+ if (pm_power_off_prepare) {
+ dev_warn(pfuze_chip->dev, "pm_power_off_prepare is already registered.\n");
+ return -EBUSY;
+ }
+
+ if (syspm_pfuze_chip) {
+ dev_warn(pfuze_chip->dev, "syspm_pfuze_chip is already set.\n");
+ return -EBUSY;
+ }
+
+ syspm_pfuze_chip = pfuze_chip;
+ pm_power_off_prepare = pfuze_power_off_prepare;
+
+ return 0;
+}
+
static int pfuze_identify(struct pfuze_chip *pfuze_chip)
{
unsigned int value;
@@ -659,6 +736,20 @@ static int pfuze100_regulator_probe(struct i2c_client *client,
}
}
+ if (of_property_read_bool(client->dev.of_node,
+ "fsl,pmic-stby-poweroff"))
+ return pfuze_power_off_prepare_init(pfuze_chip);
+
+ return 0;
+}
+
+static int pfuze100_regulator_remove(struct i2c_client *client)
+{
+ if (syspm_pfuze_chip) {
+ syspm_pfuze_chip = NULL;
+ pm_power_off_prepare = NULL;
+ }
+
return 0;
}
@@ -669,6 +760,7 @@ static struct i2c_driver pfuze_driver = {
.of_match_table = pfuze_dt_ids,
},
.probe = pfuze100_regulator_probe,
+ .remove = pfuze100_regulator_remove,
};
module_i2c_driver(pfuze_driver);
--
2.17.0
^ permalink raw reply related
* [PATCH v7 6/6] ARM: dts: imx6: RIoTboard provide standby on power off option
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
This board, as well as some other boards with i.MX6 and a PMIC, uses a
"PMIC_STBY_REQ" line to notify the PMIC about a state change.
The PMIC is programmed for a specific state change before triggering the
line.
In this case, PMIC_STBY_REQ can be used for stand by, sleep
and power off modes.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/boot/dts/imx6dl-riotboard.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
index 2e98c92adff7..a0e9753ee767 100644
--- a/arch/arm/boot/dts/imx6dl-riotboard.dts
+++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
@@ -90,6 +90,10 @@
status = "okay";
};
+&clks {
+ fsl,pmic-stby-poweroff;
+};
+
&fec {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
@@ -170,6 +174,7 @@
reg = <0x08>;
interrupt-parent = <&gpio5>;
interrupts = <16 8>;
+ fsl,pmic-stby-poweroff;
regulators {
reg_vddcore: sw1ab { /* VDDARM_IN */
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: kbuild test robot @ 2018-05-17 5:58 UTC (permalink / raw)
Cc: kbuild-all, niklas.soderlund, laurent.pinchart, horms, geert,
magnus.damm, robh+dt, Jacopo Mondi, linux-renesas-soc, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1526478129-16465-3-git-send-email-jacopo+renesas@jmondi.org>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
Hi Jacopo,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to renesas/next v4.17-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jacopo-Mondi/arm64-dts-Draak-Enable-video-inputs-and-VIN4/20180517-102013
base: git://linuxtv.org/media_tree.git master
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/renesas/r8a77995-draak.dts:266.1-6 Label or path vin4 not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 37440 bytes --]
^ permalink raw reply
* [PATCH] PM / devfreq: Add support for QCOM devfreq FW
From: Saravana Kannan @ 2018-05-17 6:02 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi, Rob Herring,
Mark Rutland
Cc: linux-pm, devicetree, linux-kernel
The firmware present in some QCOM chipsets offloads the steps necessary for
changing the frequency of some devices (Eg: L3). This driver implements the
devfreq interface for this firmware so that various governors could be used
to scale the frequency of these devices.
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
---
.../bindings/devfreq/devfreq-qcom-fw.txt | 31 ++
drivers/devfreq/Kconfig | 14 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq_qcom_fw.c | 326 +++++++++++++++++++++
4 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
create mode 100644 drivers/devfreq/devfreq_qcom_fw.c
diff --git a/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
new file mode 100644
index 0000000..5e1aecf
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/devfreq-qcom-fw.txt
@@ -0,0 +1,31 @@
+QCOM Devfreq FW device
+
+Some Qualcomm Technologies, Inc. (QTI) chipsets have a FW that offloads the
+steps for frequency switching. The qcom,devfreq-fw represents this FW as a
+device. Sometimes, multiple entities want to vote on the frequency request
+that is sent to the FW. The qcom,devfreq-fw-voter represents these voters as
+child devices of the corresponding qcom,devfreq-fw device.
+
+Required properties:
+- compatible: Must be "qcom,devfreq-fw" or "qcom,devfreq-fw-voter"
+Only for qcom,devfreq-fw:
+- reg: Pairs of physical base addresses and region sizes of
+ memory mapped registers.
+- reg-names: Names of the bases for the above registers. Expected
+ bases are: "en-base", "lut-base" and "perf-base".
+
+Example:
+
+ qcom,devfreq-l3 {
+ compatible = "qcom,devfreq-fw";
+ reg-names = "en-base", "lut-base", "perf-base";
+ reg = <0x18321000 0x4>, <0x18321110 0x600>, <0x18321920 0x4>;
+
+ qcom,cpu0-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+
+ qcom,cpu4-l3 {
+ compatible = "qcom,devfreq-fw-voter";
+ };
+ };
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6a172d3..8503018 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -113,6 +113,20 @@ config ARM_RK3399_DMC_DEVFREQ
It sets the frequency for the memory controller and reads the usage counts
from hardware.
+config ARM_QCOM_DEVFREQ_FW
+ bool "Qualcomm Technologies Inc. DEVFREQ FW driver"
+ depends on ARCH_QCOM
+ select DEVFREQ_GOV_PERFORMANCE
+ select DEVFREQ_GOV_POWERSAVE
+ select DEVFREQ_GOV_USERSPACE
+ default n
+ help
+ The firmware present in some QCOM chipsets offloads the steps
+ necessary for changing the frequency of some devices (Eg: L3). This
+ driver implements the devfreq interface for this firmware so that
+ various governors could be used to scale the frequency of these
+ devices.
+
source "drivers/devfreq/event/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 32b8d4d..f1cc8990 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra-devfreq.o
+obj-$(CONFIG_ARM_QCOM_DEVFREQ_FW) += devfreq_qcom_fw.o
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/devfreq_qcom_fw.c b/drivers/devfreq/devfreq_qcom_fw.c
new file mode 100644
index 0000000..3e85f76
--- /dev/null
+++ b/drivers/devfreq/devfreq_qcom_fw.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.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/list.h>
+#include <linux/devfreq.h>
+#include <linux/pm_opp.h>
+
+#define INIT_RATE 300000000UL
+#define XO_RATE 19200000UL
+#define LUT_MAX_ENTRIES 40U
+#define LUT_ROW_SIZE 32
+
+struct devfreq_qcom_fw {
+ void __iomem *perf_base;
+ struct devfreq_dev_profile dp;
+ struct list_head voters;
+ struct list_head voter;
+ unsigned int index;
+};
+
+static DEFINE_SPINLOCK(voter_lock);
+
+static int devfreq_qcom_fw_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct devfreq_qcom_fw *d = dev_get_drvdata(dev), *pd, *v;
+ struct devfreq_dev_profile *p = &d->dp;
+ unsigned int index;
+ unsigned long lflags;
+ struct dev_pm_opp *opp;
+ void __iomem *perf_base = d->perf_base;
+
+ opp = devfreq_recommended_opp(dev, freq, flags);
+ if (!IS_ERR(opp))
+ dev_pm_opp_put(opp);
+ else
+ return PTR_ERR(opp);
+
+ for (index = 0; index < p->max_state; index++)
+ if (p->freq_table[index] == *freq)
+ break;
+
+ if (index >= p->max_state) {
+ dev_err(dev, "Unable to find index for freq (%lu)!\n", *freq);
+ return -EINVAL;
+ }
+
+ d->index = index;
+
+ spin_lock_irqsave(&voter_lock, lflags);
+ /* Voter */
+ if (!perf_base) {
+ pd = dev_get_drvdata(dev->parent);
+ list_for_each_entry(v, &pd->voters, voter)
+ index = max(index, v->index);
+ perf_base = pd->perf_base;
+ }
+
+ writel_relaxed(index, perf_base);
+ spin_unlock_irqrestore(&voter_lock, lflags);
+
+ return 0;
+}
+
+static int devfreq_qcom_fw_get_cur_freq(struct device *dev,
+ unsigned long *freq)
+{
+ struct devfreq_qcom_fw *d = dev_get_drvdata(dev);
+ struct devfreq_dev_profile *p = &d->dp;
+ unsigned int index;
+
+ /* Voter */
+ if (!d->perf_base) {
+ index = d->index;
+ } else {
+ index = readl_relaxed(d->perf_base);
+ index = min(index, p->max_state - 1);
+ }
+ *freq = p->freq_table[index];
+
+ return 0;
+}
+
+static int devfreq_qcom_populate_opp(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ u32 data, src, lval, i;
+ unsigned long freq, prev_freq;
+ struct resource *res;
+ void __iomem *lut_base;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lut-base");
+ if (!res) {
+ dev_err(dev, "Unable to find lut-base!\n");
+ return -EINVAL;
+ }
+
+ lut_base = devm_ioremap(dev, res->start, resource_size(res));
+ if (!lut_base) {
+ dev_err(dev, "Unable to map lut-base\n");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+ data = readl_relaxed(lut_base + i * LUT_ROW_SIZE);
+ src = ((data & GENMASK(31, 30)) >> 30);
+ lval = (data & GENMASK(7, 0));
+ freq = src ? XO_RATE * lval : INIT_RATE;
+
+ /*
+ * Two of the same frequencies with the same core counts means
+ * end of table.
+ */
+ if (i > 0 && prev_freq == freq)
+ break;
+
+ dev_pm_opp_add(&pdev->dev, freq, 0);
+
+ prev_freq = freq;
+ }
+
+ devm_iounmap(dev, lut_base);
+
+ return 0;
+}
+
+static int devfreq_qcom_init_hw(struct platform_device *pdev)
+{
+ struct devfreq_qcom_fw *d;
+ struct resource *res;
+ struct device *dev = &pdev->dev;
+ int ret = 0;
+ void __iomem *en_base;
+
+ d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return -ENOMEM;
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "en-base");
+ if (!res) {
+ dev_err(dev, "Unable to find en-base!\n");
+ return -EINVAL;
+ }
+
+ en_base = devm_ioremap(dev, res->start, resource_size(res));
+ if (!en_base) {
+ dev_err(dev, "Unable to map en-base\n");
+ return -ENOMEM;
+ }
+
+ /* FW should be enabled state to proceed */
+ if (!(readl_relaxed(en_base) & 1)) {
+ dev_err(dev, "FW not enabled\n");
+ return -ENODEV;
+ }
+
+ devm_iounmap(dev, en_base);
+
+ ret = devfreq_qcom_populate_opp(pdev);
+ if (ret) {
+ dev_err(dev, "Failed to read LUT\n");
+ return ret;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "perf-base");
+ if (!res) {
+ dev_err(dev, "Unable to find perf-base!\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ d->perf_base = devm_ioremap(dev, res->start, resource_size(res));
+ if (!d->perf_base) {
+ dev_err(dev, "Unable to map perf-base\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ INIT_LIST_HEAD(&d->voters);
+ dev_set_drvdata(dev, d);
+
+out:
+ if (ret)
+ dev_pm_opp_remove_table(dev);
+ return ret;
+}
+
+static int devfreq_qcom_copy_opp(struct device *src_dev, struct device *dst_dev)
+{
+ unsigned long freq;
+ int i, cnt, ret = 0;
+ struct dev_pm_opp *opp;
+
+ if (!src_dev)
+ return -ENODEV;
+
+ cnt = dev_pm_opp_get_opp_count(src_dev);
+ if (!cnt)
+ return -EINVAL;
+
+ for (i = 0, freq = 0; i < cnt; i++, freq++) {
+ opp = dev_pm_opp_find_freq_ceil(src_dev, &freq);
+ if (IS_ERR(opp)) {
+ ret = -EINVAL;
+ break;
+ }
+ dev_pm_opp_put(opp);
+
+ ret = dev_pm_opp_add(dst_dev, freq, 0);
+ if (ret)
+ break;
+ }
+
+ if (ret)
+ dev_pm_opp_remove_table(dst_dev);
+ return ret;
+}
+
+static int devfreq_qcom_init_voter(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device *par_dev = dev->parent;
+ struct devfreq_qcom_fw *d, *pd = dev_get_drvdata(par_dev);
+ int ret = 0;
+
+ d = devm_kzalloc(dev, sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return -ENOMEM;
+
+ ret = devfreq_qcom_copy_opp(dev->parent, dev);
+ if (ret) {
+ dev_err(dev, "Failed to copy parent OPPs\n");
+ return ret;
+ }
+
+ list_add(&d->voter, &pd->voters);
+ dev_set_drvdata(dev, d);
+
+ return 0;
+}
+
+static int devfreq_qcom_fw_driver_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ int ret = 0;
+ struct devfreq_qcom_fw *d;
+ struct devfreq_dev_profile *p;
+ struct devfreq *df;
+
+ if (!of_device_get_match_data(dev))
+ ret = devfreq_qcom_init_voter(pdev);
+ else
+ ret = devfreq_qcom_init_hw(pdev);
+ if (ret) {
+ dev_err(dev, "Unable to probe device!\n");
+ return ret;
+ }
+
+ /*
+ * If device has voter children, do no register directly with devfreq
+ */
+ if (of_get_available_child_count(dev->of_node)) {
+ of_platform_populate(dev->of_node, NULL, NULL, dev);
+ dev_info(dev, "Devfreq QCOM FW parent device initialized.\n");
+ return 0;
+ }
+
+ d = dev_get_drvdata(dev);
+ p = &d->dp;
+ p->polling_ms = 50;
+ p->target = devfreq_qcom_fw_target;
+ p->get_cur_freq = devfreq_qcom_fw_get_cur_freq;
+
+ df = devm_devfreq_add_device(dev, p, "performance", NULL);
+ if (IS_ERR(df)) {
+ dev_err(dev, "Unable to register Devfreq QCOM FW device!\n");
+ return PTR_ERR(df);
+ }
+
+ dev_info(dev, "Devfreq QCOM FW device registered.\n");
+
+ return 0;
+}
+
+static const struct of_device_id match_table[] = {
+ { .compatible = "qcom,devfreq-fw", .data = (void *) 1 },
+ { .compatible = "qcom,devfreq-fw-voter", .data = (void *) 0 },
+ {}
+};
+
+static struct platform_driver devfreq_qcom_fw_driver = {
+ .probe = devfreq_qcom_fw_driver_probe,
+ .driver = {
+ .name = "devfreq-qcom-fw",
+ .of_match_table = match_table,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init devfreq_qcom_fw_init(void)
+{
+ return platform_driver_register(&devfreq_qcom_fw_driver);
+}
+subsys_initcall(devfreq_qcom_fw_init);
+
+static void __exit devfreq_qcom_fw_exit(void)
+{
+ platform_driver_unregister(&devfreq_qcom_fw_driver);
+}
+module_exit(devfreq_qcom_fw_exit);
+
+MODULE_DESCRIPTION("Devfreq QCOM FW");
+MODULE_LICENSE("GPL v2");
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [v4 2/6] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
From: Vinod @ 2018-05-17 6:04 UTC (permalink / raw)
To: Wen He
Cc: vinod.koul, dmaengine, robh+dt, devicetree, leoyang.li,
jiafei.pan, jiaheng.fan
In-Reply-To: <20180514120307.15592-2-wen.he_1@nxp.com>
On 14-05-18, 20:03, Wen He wrote:
> +
> +/* Registers for bit and genmask */
> +#define FSL_QDMA_CQIDR_SQT 0x8000
BIT() ?
> +#define QDMA_CCDF_MASK GENMASK(28, 20)
> +#define QDMA_CCDF_FOTMAT BIT(29)
> +#define QDMA_CCDF_SER BIT(30)
> +#define QDMA_SG_FIN BIT(30)
> +#define QDMA_SG_EXT BIT(31)
> +#define QDMA_SG_LEN_MASK GENMASK(29, 0)
> +
> +#define QDMA_CCDF_STATUS 20
> +#define QDMA_CCDF_OFFSET 20
> +#define FSL_QDMA_BCQIER_CQTIE 0x8000
> +#define FSL_QDMA_BCQIER_CQPEIE 0x800000
> +#define FSL_QDMA_BSQICR_ICEN 0x80000000
here and few other places as well
> +
> +u64 pre_addr, pre_queue;
why do we have a global?
> +static void fsl_qdma_comp_fill_memcpy(struct fsl_qdma_comp *fsl_comp,
> + dma_addr_t dst, dma_addr_t src, u32 len)
> +{
> + struct fsl_qdma_format *ccdf, *csgf_desc, *csgf_src, *csgf_dest;
> + struct fsl_qdma_sdf *sdf;
> + struct fsl_qdma_ddf *ddf;
> +
> + ccdf = (struct fsl_qdma_format *)fsl_comp->virt_addr;
Cast are not required to/away from void
> + csgf_desc = (struct fsl_qdma_format *)fsl_comp->virt_addr + 1;
> + csgf_src = (struct fsl_qdma_format *)fsl_comp->virt_addr + 2;
> + csgf_dest = (struct fsl_qdma_format *)fsl_comp->virt_addr + 3;
> + sdf = (struct fsl_qdma_sdf *)fsl_comp->virt_addr + 4;
> + ddf = (struct fsl_qdma_ddf *)fsl_comp->virt_addr + 5;
> +
> + memset(fsl_comp->virt_addr, 0, FSL_QDMA_BASE_BUFFER_SIZE);
> + /* Head Command Descriptor(Frame Descriptor) */
> + qdma_desc_addr_set64(ccdf, fsl_comp->bus_addr + 16);
> + qdma_ccdf_set_format(ccdf, qdma_ccdf_get_offset(ccdf));
> + qdma_ccdf_set_ser(ccdf, qdma_ccdf_get_status(ccdf));
> +
> + /* Status notification is enqueued to status queue. */
> + /* Compound Command Descriptor(Frame List Table) */
> + qdma_desc_addr_set64(csgf_desc, fsl_comp->bus_addr + 64);
> + /* It must be 32 as Compound S/G Descriptor */
> + qdma_csgf_set_len(csgf_desc, 32);
> + qdma_desc_addr_set64(csgf_src, src);
> + qdma_csgf_set_len(csgf_src, len);
> + qdma_desc_addr_set64(csgf_dest, dst);
> + qdma_csgf_set_len(csgf_dest, len);
> + /* This entry is the last entry. */
> + qdma_csgf_set_f(csgf_dest, len);
> + /* Descriptor Buffer */
> + sdf->cmd = cpu_to_le32(
> + FSL_QDMA_CMD_RWTTYPE << FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + ddf->cmd = cpu_to_le32(
> + FSL_QDMA_CMD_RWTTYPE << FSL_QDMA_CMD_RWTTYPE_OFFSET);
> + ddf->cmd |= cpu_to_le32(
> + FSL_QDMA_CMD_LWC << FSL_QDMA_CMD_LWC_OFFSET);
> +}
> +
> +/*
> + * Pre-request full command descriptor for enqueue.
> + */
> +static int fsl_qdma_pre_request_enqueue_desc(struct fsl_qdma_queue *queue)
> +{
> + struct fsl_qdma_comp *comp_temp;
> + int i;
> +
> + for (i = 0; i < queue->n_cq; i++) {
> + comp_temp = kzalloc(sizeof(*comp_temp), GFP_KERNEL);
> + if (!comp_temp)
> + return -ENOMEM;
where is the previous allocations freed? Return of this function is not even
checked??
> + comp_temp->virt_addr = dma_pool_alloc(queue->comp_pool,
> + GFP_KERNEL,
> + &comp_temp->bus_addr);
> + if (!comp_temp->virt_addr)
> + return -ENOMEM;
and here too
> + list_add_tail(&comp_temp->list, &queue->comp_free);
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * Request a command descriptor for enqueue.
> + */
> +static struct fsl_qdma_comp *fsl_qdma_request_enqueue_desc(
> + struct fsl_qdma_chan *fsl_chan,
> + unsigned int dst_nents,
> + unsigned int src_nents)
> +{
> + struct fsl_qdma_comp *comp_temp;
> + struct fsl_qdma_sg *sg_block;
> + struct fsl_qdma_queue *queue = fsl_chan->queue;
> + unsigned long flags;
> + unsigned int dst_sg_entry_block, src_sg_entry_block, sg_entry_total, i;
> +
> + spin_lock_irqsave(&queue->queue_lock, flags);
> + if (list_empty(&queue->comp_free)) {
> + spin_unlock_irqrestore(&queue->queue_lock, flags);
> + comp_temp = kzalloc(sizeof(*comp_temp), GFP_KERNEL);
> + if (!comp_temp)
> + return NULL;
> + comp_temp->virt_addr = dma_pool_alloc(queue->comp_pool,
> + GFP_KERNEL,
> + &comp_temp->bus_addr);
> + if (!comp_temp->virt_addr) {
> + kfree(comp_temp);
> + return NULL;
> + }
> +
> + } else {
> + comp_temp = list_first_entry(&queue->comp_free,
> + struct fsl_qdma_comp,
> + list);
> + list_del(&comp_temp->list);
> + spin_unlock_irqrestore(&queue->queue_lock, flags);
> + }
> +
> + if (dst_nents != 0)
> + dst_sg_entry_block = dst_nents /
> + (FSL_QDMA_EXPECT_SG_ENTRY_NUM - 1) + 1;
DIV_ROUND_UP()?
> + else
> + dst_sg_entry_block = 0;
> +
> + if (src_nents != 0)
> + src_sg_entry_block = src_nents /
> + (FSL_QDMA_EXPECT_SG_ENTRY_NUM - 1) + 1;
> + else
> + src_sg_entry_block = 0;
> +
> + sg_entry_total = dst_sg_entry_block + src_sg_entry_block;
> + if (sg_entry_total) {
> + sg_block = kzalloc(sizeof(*sg_block) *
> + sg_entry_total,
> + GFP_KERNEL);
kcalloc?
> + if (!sg_block) {
> + dma_pool_free(queue->comp_pool,
> + comp_temp->virt_addr,
> + comp_temp->bus_addr);
> + return NULL;
> + }
> + comp_temp->sg_block = sg_block;
> + for (i = 0; i < sg_entry_total; i++) {
> + sg_block->virt_addr = dma_pool_alloc(queue->sg_pool,
> + GFP_KERNEL,
> + &sg_block->bus_addr);
no check if this succeeded?
> + memset(sg_block->virt_addr, 0,
> + FSL_QDMA_EXPECT_SG_ENTRY_NUM * 16);
why FSL_QDMA_EXPECT_SG_ENTRY_NUM * 16? and not what you allocated?
> +static struct fsl_qdma_queue *fsl_qdma_alloc_queue_resources(
> + struct platform_device *pdev,
> + unsigned int queue_num)
> +{
> + struct fsl_qdma_queue *queue_head, *queue_temp;
> + int ret, len, i;
> + unsigned int queue_size[FSL_QDMA_QUEUE_MAX];
> +
> + if (queue_num > FSL_QDMA_QUEUE_MAX)
> + queue_num = FSL_QDMA_QUEUE_MAX;
> + len = sizeof(*queue_head) * queue_num;
> + queue_head = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> + if (!queue_head)
> + return NULL;
> +
> + ret = device_property_read_u32_array(&pdev->dev, "queue-sizes",
> + queue_size, queue_num);
> + if (ret) {
> + dev_err(&pdev->dev, "Can't get queue-sizes.\n");
> + return NULL;
> + }
> +
> + for (i = 0; i < queue_num; i++) {
> + if (queue_size[i] > FSL_QDMA_CIRCULAR_DESC_SIZE_MAX
> + || queue_size[i] < FSL_QDMA_CIRCULAR_DESC_SIZE_MIN) {
> + dev_err(&pdev->dev, "Get wrong queue-sizes.\n");
> + return NULL;
> + }
> + queue_temp = queue_head + i;
> + queue_temp->cq = dma_alloc_coherent(&pdev->dev,
> + sizeof(struct fsl_qdma_format) *
> + queue_size[i],
> + &queue_temp->bus_addr,
> + GFP_KERNEL);
> + if (!queue_temp->cq)
> + return NULL;
> + queue_temp->n_cq = queue_size[i];
> + queue_temp->id = i;
> + queue_temp->virt_head = queue_temp->cq;
> + queue_temp->virt_tail = queue_temp->cq;
> + /*
> + * The dma pool for queue command buffer
> + */
> + queue_temp->comp_pool = dma_pool_create("comp_pool",
> + &pdev->dev,
> + FSL_QDMA_BASE_BUFFER_SIZE,
> + 16, 0);
> + if (!queue_temp->comp_pool)
> + goto err_free_comp;
> +
> + /*
> + * The dma pool for queue command buffer
same comment as prev?
> +static int fsl_qdma_queue_transfer_complete(struct fsl_qdma_engine *fsl_qdma)
> +{
> + struct fsl_qdma_queue *fsl_queue = fsl_qdma->queue;
> + struct fsl_qdma_queue *fsl_status = fsl_qdma->status;
> + struct fsl_qdma_queue *temp_queue;
> + struct fsl_qdma_comp *fsl_comp;
> + struct fsl_qdma_format *status_addr;
> + struct fsl_qdma_format *csgf_src;
> + void __iomem *block = fsl_qdma->block_base;
> + u32 reg, i;
> + bool duplicate, duplicate_handle;
> +
> + while (1) {
> + duplicate = 0;
> + duplicate_handle = 0;
> + reg = qdma_readl(fsl_qdma, block + FSL_QDMA_BSQSR);
> + if (reg & FSL_QDMA_BSQSR_QE)
> + return 0;
> + status_addr = fsl_status->virt_head;
> + if (qdma_ccdf_get_queue(status_addr) == pre_queue &&
> + qdma_ccdf_addr_get64(status_addr) == pre_addr)
> + duplicate = 1;
> + i = qdma_ccdf_get_queue(status_addr);
> + pre_queue = qdma_ccdf_get_queue(status_addr);
> + pre_addr = qdma_ccdf_addr_get64(status_addr);
> + temp_queue = fsl_queue + i;
> + spin_lock(&temp_queue->queue_lock);
> + if (list_empty(&temp_queue->comp_used)) {
> + if (duplicate)
> + duplicate_handle = 1;
> + else {
> + spin_unlock(&temp_queue->queue_lock);
> + return -1;
-1? really. You are in while(1) wouldn't break make sense here?
> +static enum dma_status fsl_qdma_tx_status(struct dma_chan *chan,
> + dma_cookie_t cookie, struct dma_tx_state *txstate)
> +{
> + struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
why do you need this here, its unused
--
~Vinod
^ permalink raw reply
* Re: [PATCH 1/2] regulator: add QCOM RPMh regulator driver
From: Mark Brown @ 2018-05-17 6:09 UTC (permalink / raw)
To: David Collins
Cc: Stephen Boyd, lgirdwood, mark.rutland, robh+dt, linux-arm-msm,
linux-arm-kernel, devicetree, linux-kernel, rnayak, ilina
In-Reply-To: <d82ef514-b94f-8ed9-6b1e-e07de2a5f455@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Tue, Apr 24, 2018 at 01:46:21PM -0700, David Collins wrote:
> On 04/24/2018 10:41 AM, Mark Brown wrote:
> > If the hardware has full knowledge of all these constraints and enforces
> > them transparently then why does the kernel care that it's doing that?
> > Doesn't it defeat the point of it doing all this stuff if we have to
> > know about it?
> The RPMh hardware is aware of the parent-child connections between
> regulators as well as minimum headroom to ensure stable LDO voltage output
> for subregulated LDOs. The intention of having the headroom be a
> configurable property for processors is to support usecases in which
> subregulated LDO loads are particularly sensitive to noise and require
> additional headroom. Such usecases are board dependent and beyond the
> baseline configurations set in RPMh hardware.
So the hardware implementation is some hard coding stuff that doesn't
really adequately reflect reality? This seems unfortunate. However do
we really need to tell the hardware about the fact that we're adding
extra headroom - are there actual interactions with non-Linux things
here?
> >> XOB managed regulators physically cannot change voltage. Therefore, do
> >> you agree that it is reasonable to use fixed_uV for them? Note that I
> >> removed init_data->constraints.apply_uV manipulation in version 2 of this
> >> patch.
> > If these regulators can't change voltage then surely we know what
> > voltage they have without needing it to be specified in DT?
> In the case of XOB managed LDO regulators, the LDOs physically can be
> configured to different voltages by the bootloader. However, the RPMh
> interface provides no mechanism for the application processor to read or
> change that voltage. Therefore, we need a way to specify such voltages in
> a board specific (as opposed to driver specific) manner (i.e. device tree).
Is the kernel somehow prevented from varying these voltages?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 0/4] Add basic support for Mediatek MT8183 SoC
From: Erin Lo @ 2018-05-17 6:22 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Greg Kroah-Hartman
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, srv_heupstream,
erin.lo-NuS5LvNUpcJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
mars.cheng-NuS5LvNUpcJWk0Htik3J/w,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
MT8183 is a SoC based on 64bit ARMv8 architecture.
It contains 4 CA53 and 4 CA73 cores.
MT8183 share many HW IP with MT65xx series.
This patchset was tested on MT8183 evaluation board, and boot to shell ok.
This series contains document bindings, device tree including interrupt, uart.
Change in v3:
1. Fill out GICC, GICH, GICV regions
2. Update Copyright to 2018
Change in v2:
1. Split dt-bindings into different patches
2. Correct bindings for supported SoCs (mtk-uart.txt)
Ben Ho (1):
arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and
Makefile
Erin Lo (3):
dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
dt-bindings: serial: Add compatible for Mediatek MT8183
Documentation/devicetree/bindings/arm/mediatek.txt | 4 +
.../interrupt-controller/mediatek,sysirq.txt | 1 +
.../devicetree/bindings/serial/mtk-uart.txt | 1 +
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 ++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 182 +++++++++++++++++++++
6 files changed, 220 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/4] dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
From: Erin Lo @ 2018-05-17 6:22 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Greg Kroah-Hartman
Cc: devicetree, srv_heupstream, linux-kernel, linux-serial,
linux-mediatek, linux-arm-kernel, yingjoe.chen, erin.lo,
mars.cheng
In-Reply-To: <1526538126-51497-1-git-send-email-erin.lo@mediatek.com>
This adds dt-binding documentation of cpu for Mediatek MT8183.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
Documentation/devicetree/bindings/arm/mediatek.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
index 7d21ab3..2754535 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -19,6 +19,7 @@ compatible: Must contain one of
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
+ "mediatek,mt8183"
Supported boards:
@@ -73,3 +74,6 @@ Supported boards:
- MTK mt8173 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8173-evb", "mediatek,mt8173";
+- Evaluation board for MT8183:
+ Required root node properties:
+ - compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
--
1.9.1
^ permalink raw reply related
* [PATCH v3 2/4] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
From: Erin Lo @ 2018-05-17 6:22 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Greg Kroah-Hartman
Cc: devicetree, srv_heupstream, linux-kernel, linux-serial,
linux-mediatek, linux-arm-kernel, yingjoe.chen, erin.lo,
mars.cheng
In-Reply-To: <1526538126-51497-1-git-send-email-erin.lo@mediatek.com>
This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC
Platform.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
.../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
index 07bf0b9..5ff48a8 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
@@ -5,6 +5,7 @@ interrupt.
Required properties:
- compatible: should be
+ "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183
"mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173
"mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135
"mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127
--
1.9.1
^ permalink raw reply related
* [PATCH v3 3/4] dt-bindings: serial: Add compatible for Mediatek MT8183
From: Erin Lo @ 2018-05-17 6:22 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Greg Kroah-Hartman
Cc: devicetree, srv_heupstream, linux-kernel, linux-serial,
linux-mediatek, linux-arm-kernel, yingjoe.chen, erin.lo,
mars.cheng
In-Reply-To: <1526538126-51497-1-git-send-email-erin.lo@mediatek.com>
This adds dt-binding documentation of uart for Mediatek MT8183 SoC
Platform.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index f73abff..4783336 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -15,6 +15,7 @@ Required properties:
* "mediatek,mt8127-uart" for MT8127 compatible UARTS
* "mediatek,mt8135-uart" for MT8135 compatible UARTS
* "mediatek,mt8173-uart" for MT8173 compatible UARTS
+ * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS
* "mediatek,mt6577-uart" for MT6577 and all of the above
- reg: The base address of the UART register bank.
--
1.9.1
^ permalink raw reply related
* [PATCH v3 4/4] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Erin Lo @ 2018-05-17 6:22 UTC (permalink / raw)
To: Matthias Brugger, Rob Herring, Mark Rutland, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Greg Kroah-Hartman
Cc: devicetree, srv_heupstream, linux-kernel, linux-serial,
linux-mediatek, linux-arm-kernel, yingjoe.chen, erin.lo,
mars.cheng, Ben Ho
In-Reply-To: <1526538126-51497-1-git-send-email-erin.lo@mediatek.com>
From: Ben Ho <Ben.Ho@mediatek.com>
Add basic chip support for Mediatek 8183
Signed-off-by: Ben Ho <Ben.Ho@mediatek.com>
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 31 +++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 182 ++++++++++++++++++++++++++++
3 files changed, 214 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60..2836261 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -5,3 +5,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 0000000..9b52559
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho <ben.ho@mediatek.com>
+ * Erin Lo <erin.lo@mediatek.com>
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0 0x40000000 0 0x80000000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 0000000..03edf9c
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho <ben.ho@mediatek.com>
+ * Erin Lo <erin.lo@mediatek.com>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "mediatek,mt8183";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x100>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x101>;
+ enable-method = "psci";
+ };
+
+ cpu6: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x102>;
+ enable-method = "psci";
+ };
+
+ cpu7: cpu@103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x103>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ uart_clk: dummy26m {
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ gic: interrupt-controller@0c000000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
+ interrupt-controller;
+ reg = <0 0x0c000000 0 0x40000>, /* GICD */
+ <0 0x0c100000 0 0x200000>; /* GICR */
+ <0 0x0c400000 0 0x2000>; /* GICC */
+ <0 0x0c410000 0 0x1000>; /* GICH */
+ <0 0x0c420000 0 0x2000>; /* GICV */
+
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sysirq: intpol-controller@0c530a80 {
+ compatible = "mediatek,mt8183-sysirq",
+ "mediatek,mt6577-sysirq";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ interrupt-parent = <&gic>;
+ reg = <0 0x0c530a80 0 0x50>;
+ };
+
+ uart0: serial@11002000 {
+ compatible = "mediatek,mt8183-uart",
+ "mediatek,mt6577-uart";
+ reg = <0 0x11002000 0 0x1000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&uart_clk>, <&uart_clk>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+
+ uart1: serial@11003000 {
+ compatible = "mediatek,mt8183-uart",
+ "mediatek,mt6577-uart";
+ reg = <0 0x11003000 0 0x1000>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&uart_clk>, <&uart_clk>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+
+ uart2: serial@11004000 {
+ compatible = "mediatek,mt8183-uart",
+ "mediatek,mt6577-uart";
+ reg = <0 0x11004000 0 0x1000>;
+ interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&uart_clk>, <&uart_clk>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6] gpio: dwapb: Add support for 1 interrupt per port A GPIO
From: Lee Jones @ 2018-05-17 6:25 UTC (permalink / raw)
To: Hoan Tran
Cc: Phil Edworthy, Andy Shevchenko, Hoan Tran, Linus Walleij,
Mark Rutland, Rob Herring, Michel Pollet,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <F70CFA9C-2059-432E-BFD3-3FA6CB618795@amperecomputing.com>
On Wed, 16 May 2018, Hoan Tran wrote:
> Hi Phil,
>
> On 5/11/18, 1:31 AM, "Phil Edworthy" <phil.edworthy@renesas.com> wrote:
>
> The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> per GPIO in port A, but the driver currently only supports 1 interrupt.
> See the DesignWare DW_apb_gpio Databook description of the
> 'GPIO_INTR_IO' parameter.
>
> This change allows the driver to work with up to 32 interrupts, it will
> get as many interrupts as specified in the DT 'interrupts' property.
> It doesn't do anything clever with the different interrupts, it just calls
> the same handler used for single interrupt hardware.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
> One point to mention is that I have made it possible for users to have
> unconnected interrupts by specifying holes in the list of interrupts. This is
> done by supporting the interrupts-extended DT prop.
> However, I have no use for this and had to hack some test case for this.
> Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
>
> v6:
> - Treat DT and ACPI the same as much as possible. Note that we can't use
> platform_get_irq() to get the DT interrupts as they are in the port
> sub-node and hence do not have an associated platform device.
> v5:
> - Rolled ACPI companion code provided by Hoan Tran into this patch.
> v4:
> - Use of_irq_get() instead of of_irq_parse_one()+irq_create_of_mapping()
> v3:
> - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid bisect problems
> v2:
> - Replaced interrupt-mask DT prop with support for the interrupts-extended
> prop. This means replacing the call to irq_of_parse_and_map() with calls
> to of_irq_parse_one() and irq_create_of_mapping().
> ---
> .../devicetree/bindings/gpio/snps-dwapb-gpio.txt | 9 +++-
> drivers/gpio/gpio-dwapb.c | 49 +++++++++++++++-------
> drivers/mfd/intel_quark_i2c_gpio.c | 3 +-
> include/linux/platform_data/gpio-dwapb.h | 3 +-
> 4 files changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> index 4a75da7..3c1118b 100644
> --- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
> @@ -26,8 +26,13 @@ controller.
> the second encodes the triger flags encoded as described in
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> - interrupt-parent : The parent interrupt controller.
> -- interrupts : The interrupt to the parent controller raised when GPIOs
> - generate the interrupts.
> +- interrupts : The interrupts to the parent controller raised when GPIOs
> + generate the interrupts. If the controller provides one combined interrupt
> + for all GPIOs, specify a single interrupt. If the controller provides one
> + interrupt for each GPIO, provide a list of interrupts that correspond to each
> + of the GPIO pins. When specifying multiple interrupts, if any are unconnected,
> + use the interrupts-extended property to specify the interrupts and set the
> + interrupt controller handle for unused interrupts to 0.
> - snps,nr-gpios : The number of pins in the port, a single cell.
> - resets : Reset line for the controller.
>
> Acked-by: Hoan Tran <hoan.tran@amperecomputing.com>
Well that's new. I've never seen a mailer reply like that before.
Which mailer are you using? Might be worth sorting that out.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Lee Jones @ 2018-05-17 6:36 UTC (permalink / raw)
To: Amelie DELAUNAY
Cc: Linus Walleij, Rob Herring, Mark Rutland, Russell King,
Alexandre TORGUE, Maxime Coquelin, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM
In-Reply-To: <b9005dd8-8214-ceab-0f88-ff1a51b44e34@st.com>
On Wed, 16 May 2018, Amelie DELAUNAY wrote:
>
>
> On 05/16/2018 04:20 PM, Linus Walleij wrote:
> > On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> >
> >> Indeed, stmfx has other functions than GPIO. But, after comments done
> >> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
> >> child drivers into a single PINCTRL/GPIO driver because of the following
> >> reasons:
> >> - Other stmfx functions (IDD measurement and TouchScreen controller) are
> >> not used on any of the boards using an stmfx and supported by Linux, so
> >> no way to test these functions, and no need to maintain them while they
> >> are not being used.
> >> - But, in the case a new board will use more than GPIO function on
> >> stmfx, the actual implementation allow to easily extract common init
> >> part of stmfx and put it in an MFD driver.
> >>
> >> So I could remove gpio sub-node and put its contents in stmfx node and
> >> keep single PINCTRL/GPIO driver for the time being.
> >> Please advise,
> >
> > I would normally advice to use the right modeling from the start, create
> > the MFD driver and spawn the devices from there. It is confusing
> > if the layout of the driver(s) doesn't really match the layout of the
> > hardware.
> >
> > I understand that it is a pain to write new MFD drivers to get your
> > things going and it would be "nice to get this working really quick
> > now" but in my experience it is better to do it right from the start.
> >
>
> Hi Linus,
>
> Thanks for your advice. I understand the point.
> So, the right modeling would be to:
> - create an MFD driver with the common init part of stmfx
> - remove all common init part of stmfx-pinctrl driver and keep only all
> gpio/pinctrl functions.
>
> I will not develop the other stmfx functions (IDD measurement driver and
> TouchScreen controller driver) because, as explained ealier, they are
> not used on any of the boards using an stmfx and supported by Linux, so
> no way to test these functions, and no need to maintain them while they
> are not being used.
>
> Lee, are you OK with that ?
I missed a lot of this conversation I think, but from what I've read,
it sounds fine.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v8 09/24] ASoC: qdsp6: q6afe: Add q6afe driver
From: Mark Brown @ 2018-05-17 6:55 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: mark.rutland, devicetree, alsa-devel, bgoswami, rohkumar,
linux-arm-msm, plai, spatakok, lgirdwood, tiwai, david.brown,
robh+dt, linux-arm-kernel, gregkh, andy.gross, linux-kernel
In-Reply-To: <20180509125635.5653-10-srinivas.kandagatla@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 821 bytes --]
On Wed, May 09, 2018 at 01:56:20PM +0100, Srinivas Kandagatla wrote:
> +static struct q6afe_port *afe_find_port(struct q6afe *afe, int token)
> +{
> + struct q6afe_port *p = NULL;
> + struct q6afe_port *ret = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&afe->port_list_lock, flags);
> + list_for_each_entry(p, &afe->port_list, node)
> + if (p->token == token) {
> + ret = p;
> + break;
> + }
> +
> + spin_unlock_irqrestore(&afe->port_list_lock, flags);
> + return ret;
This lock only protects the list, it does nothing to ensure that the
port we look up is still valid by the time we return to the caller.
That means we won't crash during list traversal but does nothing to
ensure we won't crash immediately afterwards if the port is deallocated
just after we look it up. What stops that happening?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: jacopo mondi @ 2018-05-17 7:14 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Jacopo Mondi, laurent.pinchart, horms, geert, magnus.damm,
robh+dt, linux-renesas-soc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20180516222318.GI17948@bigcity.dyn.berto.se>
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
Hi Niklas,
On Thu, May 17, 2018 at 12:23:18AM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connector and ADV7612 HDMI decoder installed on
> > R-Car Gen3 Draak board.
> >
> > The video signal routing to the HDMI decoder to the video input interface
> > VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> > on-board switches SW-49, SW-50, SW-51 and SW-52.
> >
> > As the default board switches configuration connects CVBS input to VIN4,
> > leave the HDMI decoder unconnected in DTS.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> I'm not sure we have a policy about describing hardware which can't be
> used without flipping switches. I have no opinion on if we should do
> that or not I leave that to others, but for the change itself.
>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
Thanks
> I think it's good we describe it as it's part of the Draak board itself
> and not an expansion board which we have seen a lot of :-) Maybe even
> add a commented out line in the adv7612 port@2 which hints which VIN
> this is connected to if the switches are flipped?
The only VIN instance that's on Draak, VIN4.
I can add a comment that describes the switch settings that enables
the HDMI video capture path.
Thanks
j
>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++++++++++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > index 9aba28f..ea99dc9 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> > };
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> > memory@48000000 {
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> > @@ -170,6 +181,33 @@
> > };
> > };
> > };
> > +
> > + hdmi-decoder@4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &i2c1 {
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas Söderlund
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
From: ilialin @ 2018-05-17 7:19 UTC (permalink / raw)
To: 'Amit Kucheria'
Cc: 'Michael Turquette', sboyd, 'Rob Herring',
'Mark Rutland', 'Viresh Kumar', nm, lgirdwood,
broonie, 'Andy Gross', 'David Brown',
catalin.marinas, will.deacon, 'Rafael J. Wysocki',
linux-clk, devicetree, 'LKML', 'Linux PM list',
linux-arm-msm, linux-soc, 'lakml',
'Rajendra Nayak', nicolas.dechesne, celster
In-Reply-To: <CAHLCerOYq4q2GE+m3MQAbMfxM4azPr95XiLKVtoPVG1Kv2Db=A@mail.gmail.com>
> -----Original Message-----
> From: amit.kucheria@verdurent.com <amit.kucheria@verdurent.com> On
> Behalf Of Amit Kucheria
> Sent: Wednesday, May 16, 2018 16:13
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>; sboyd@kernel.org; Rob
> Herring <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Viresh
> Kumar <viresh.kumar@linaro.org>; nm@ti.com; lgirdwood@gmail.com;
> broonie@kernel.org; Andy Gross <andy.gross@linaro.org>; David Brown
> <david.brown@linaro.org>; catalin.marinas@arm.com;
> will.deacon@arm.com; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; LKML <linux-
> kernel@vger.kernel.org>; Linux PM list <linux-pm@vger.kernel.org>; linux-
> arm-msm@vger.kernel.org; linux-soc@vger.kernel.org; lakml <linux-arm-
> kernel@lists.infradead.org>; Rajendra Nayak <rnayak@codeaurora.org>;
> nicolas.dechesne@linaro.org; celster@codeaurora.org;
> tfinkel@codeaurora.org
> Subject: Re: [PATCH v7 12/14] cpufreq: Add Kryo CPU scaling driver
>
> On Tue, May 15, 2018 at 12:13 PM, Ilia Lin <ilialin@codeaurora.org> wrote:
> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
> > processors, the CPU ferequencies subset and voltage value of each OPP
> > varies
>
> s/ferequencies/frequency
>
> > based on the silicon variant in use. Qualcomm Process Voltage Scaling
> > Tables defines the voltage and frequency value based on the msm-id in
> > SMEM and speedbin blown in the efuse combination.
> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the
> > SoC to provide the OPP framework with required information.
> > This is used to determine the voltage and frequency value for each OPP
> > of
> > operating-points-v2 table when it is parsed by the OPP framework.
> >
> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> > ---
> > drivers/cpufreq/Kconfig.arm | 11 +++
> > drivers/cpufreq/Makefile | 1 +
> > drivers/cpufreq/cpufreq-dt-platdev.c | 3 +
> > drivers/cpufreq/qcom-cpufreq-kryo.c | 150
> > +++++++++++++++++++++++++++++++++++
> > 4 files changed, 165 insertions(+)
> > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c
> >
> > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> > index de55c7d..5c16f05 100644
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
> > @@ -124,6 +124,17 @@ config ARM_OMAP2PLUS_CPUFREQ
> > depends on ARCH_OMAP2PLUS
> > default ARCH_OMAP2PLUS
> >
> > +config ARM_QCOM_CPUFREQ_KRYO
> > + bool "Qualcomm Technologies, Inc. Kryo based CPUFreq"
>
> "Qualcomm Kryo CPUFreq support" should be enough. Kconfig isn't the place
> for Trademark compliance :-)
This is mandatory requirement of the QTIs legal.
>
> > + depends on QCOM_QFPROM
> > + depends on QCOM_SMEM
> > + select PM_OPP
> > + help
> > + This adds the CPUFreq driver for
> > + Qualcomm Technologies, Inc. Kryo SoC based boards.
> > +
> > + If in doubt, say N.
> > +
> > config ARM_S3C_CPUFREQ
> > bool
> > help
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile index
> > 8d24ade..fb4a2ec 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -65,6 +65,7 @@ obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-
> cpufreq.o
> > obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ) += omap-cpufreq.o
> > obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
> > obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> > +obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
> > obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
> > obj-$(CONFIG_ARM_S3C2412_CPUFREQ) += s3c2412-cpufreq.o
> > obj-$(CONFIG_ARM_S3C2416_CPUFREQ) += s3c2416-cpufreq.o
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index 3b585e4..77d6ab8 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -118,6 +118,9 @@
> >
> > { .compatible = "nvidia,tegra124", },
> >
> > + { .compatible = "qcom,apq8096", },
> > + { .compatible = "qcom,msm8996", },
> > +
> > { .compatible = "st,stih407", },
> > { .compatible = "st,stih410", },
> >
> > diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> > b/drivers/cpufreq/qcom-cpufreq-kryo.c
> > new file mode 100644
> > index 0000000..10d7236
> > --- /dev/null
> > +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> > @@ -0,0 +1,150 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
>
> Stray space here.
>
> > + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/cpu.h>
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/nvmem-consumer.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/pm_opp.h>
> > +#include <linux/slab.h>
> > +#include <linux/soc/qcom/smem.h>
> > +
> > +#define MSM_ID_SMEM 137
> > +#define SILVER_LEAD 0
> > +#define GOLD_LEAD 2
> > +
> > +enum _msm_id {
> > + MSM8996V3 = 0xF6ul,
> > + APQ8096V3 = 0x123ul,
> > + MSM8996SG = 0x131ul,
> > + APQ8096SG = 0x138ul,
> > +};
> > +
> > +enum _msm8996_version {
> > + MSM8996_V3,
> > + MSM8996_SG,
> > + NUM_OF_MSM8996_VERSIONS,
> > +};
> > +
> > +static enum _msm8996_version __init
> > +qcom_cpufreq_kryo_get_msm_id(void)
> > +{
> > + size_t len;
> > + u32 *msm_id;
> > + enum _msm8996_version version;
> > +
> > + msm_id = qcom_smem_get(QCOM_SMEM_HOST_ANY,
> MSM_ID_SMEM, &len);
> > + /* The first 4 bytes are format, next to them is the actual msm-id */
> > + msm_id++;
> > +
> > + switch ((enum _msm_id)*msm_id) {
> > + case MSM8996V3:
> > + case APQ8096V3:
> > + version = MSM8996_V3;
> > + break;
> > + case MSM8996SG:
> > + case APQ8096SG:
> > + version = MSM8996_SG;
> > + break;
> > + default:
> > + version = NUM_OF_MSM8996_VERSIONS;
> > + }
> > +
> > + return version;
> > +}
> > +
> > +static int __init qcom_cpufreq_kryo_driver_init(void)
> > +{
> > + size_t len;
> > + int ret;
> > + u32 versions;
> > + enum _msm8996_version msm8996_version;
> > + u8 *speedbin;
> > + struct device *cpu_dev;
> > + struct device_node *np;
> > + struct nvmem_cell *speedbin_nvmem;
> > + struct opp_table *opp_temp = NULL;
> > +
> > + cpu_dev = get_cpu_device(SILVER_LEAD);
> > + if (IS_ERR_OR_NULL(cpu_dev))
> > + return PTR_ERR(cpu_dev);
> > +
> > + msm8996_version = qcom_cpufreq_kryo_get_msm_id();
> > + if (NUM_OF_MSM8996_VERSIONS == msm8996_version) {
> > + dev_err(cpu_dev, "Not Snapdragon 820/821!");
> > + return -ENODEV;
> > + }
>
> Use tab instead of spaces.
>
> > +
> > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> > + if (IS_ERR_OR_NULL(np))
> > + return PTR_ERR(np);
> > +
> > + if (!of_device_is_compatible(np, "operating-points-v2-kryo-cpu")) {
> > + ret = -ENOENT;
> > + goto free_np;
> > + }
> > +
> > + speedbin_nvmem = of_nvmem_cell_get(np, NULL);
> > + if (IS_ERR(speedbin_nvmem)) {
> > + ret = PTR_ERR(speedbin_nvmem);
> > + dev_err(cpu_dev, "Could not get nvmem cell: %d\n", ret);
> > + goto free_np;
> > + }
> > +
> > + speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> > +
> > + switch (msm8996_version) {
> > + case MSM8996_V3:
> > + versions = 1 << (unsigned int)(*speedbin);
> > + break;
> > + case MSM8996_SG:
> > + versions = 1 << ((unsigned int)(*speedbin) + 4);
> > + break;
> > + default:
> > + BUG();
> > + break;
> > + }
> > +
> > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > + dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > + if (0 > ret)
>
> Any particular reason to prefer this over (ret < 0) that is generally used? I've
> seen it used to avoid the == vs. = typos, but not for other comparisons.
>
> Suggest sticking to what is commonly used i.e. ret < 0.
>
> > + goto free_opp;
> > +
> > + cpu_dev = get_cpu_device(GOLD_LEAD);
>
> Error check cpu_dev here?
>
> > + ret = PTR_ERR_OR_ZERO(opp_temp =
> > + dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> > + if (0 > ret)
> > + goto free_opp;
> > +
> > +
> > + ret = PTR_ERR_OR_ZERO(platform_device_register_simple("cpufreq-
> dt",
> > + -1,
> > + NULL, 0));
> > +
> > + if (0 == ret)
> > + return 0;
> > +
> > +free_opp:
> > + dev_pm_opp_put_supported_hw(opp_temp);
>
> This is not needed because dev_pm_opp_set_supported_hw will free
> memory in case of failure. This call in only needed in case of a successful get.
>
> > +
> > +free_np:
> > + of_node_put(np);
> > + return ret;
>
>
> Suggest something like this instead:
>
> .
> .
>
> opp_temp = dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> if (IS_ERR(opp_temp)) {
> dev_err(cpu_dev, "Failed to set supported hardware\n");
> ret = PTR_ERR(opp_temp);
> goto free_np;
> }
>
> cpu_dev = get_cpu_device(GOLD_LEAD);
>
> opp_temp = dev_pm_opp_set_supported_hw(cpu_dev,&versions,1));
> if (IS_ERR(opp_temp)) {
> dev_err(cpu_dev, "Failed to set supported hardware\n");
> ret = PTR_ERR(opp_temp);
> goto free_np;
> }
>
> ret = platform_device_register_simple("cpufreq-dt", -1, NULL, 0));
>
> if (!IS_ERR_OR_NULL(ret))
> goto out;
>
> free_np:
> of_node_put(np);
> out:
> return ret;
>
> > +}
> > +late_initcall(qcom_cpufreq_kryo_driver_init);
> > +
> > +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq
> > +driver"); MODULE_LICENSE("GPL v2");
> > --
> > 1.9.1
> >
^ permalink raw reply
* RE: [PATCH v7 10/14] dt-bindings: qcom_spmi: Add support for SAW documentation
From: ilialin @ 2018-05-17 7:24 UTC (permalink / raw)
To: 'Amit Kucheria'
Cc: 'Michael Turquette', sboyd, 'Rob Herring',
'Mark Rutland', 'Viresh Kumar', nm, lgirdwood,
broonie, 'Andy Gross', 'David Brown',
catalin.marinas, will.deacon, 'Rafael J. Wysocki',
linux-clk, devicetree, 'LKML', 'Linux PM list',
linux-arm-msm, linux-soc, 'lakml',
'Rajendra Nayak', nicolas.dechesne, celster
In-Reply-To: <CAHLCerOxcUMTztT75rdkS-rrQWqEEgoVQr45Ueh_JRPE7CCm7Q@mail.gmail.com>
> -----Original Message-----
> From: amit.kucheria@verdurent.com <amit.kucheria@verdurent.com> On
> Behalf Of Amit Kucheria
> Sent: Wednesday, May 16, 2018 16:13
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>; sboyd@kernel.org; Rob
> Herring <robh@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Viresh
> Kumar <viresh.kumar@linaro.org>; nm@ti.com; lgirdwood@gmail.com;
> broonie@kernel.org; Andy Gross <andy.gross@linaro.org>; David Brown
> <david.brown@linaro.org>; catalin.marinas@arm.com;
> will.deacon@arm.com; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; LKML <linux-
> kernel@vger.kernel.org>; Linux PM list <linux-pm@vger.kernel.org>; linux-
> arm-msm@vger.kernel.org; linux-soc@vger.kernel.org; lakml <linux-arm-
> kernel@lists.infradead.org>; Rajendra Nayak <rnayak@codeaurora.org>;
> nicolas.dechesne@linaro.org; celster@codeaurora.org;
> tfinkel@codeaurora.org
> Subject: Re: [PATCH v7 10/14] dt-bindings: qcom_spmi: Add support for SAW
> documentation
>
> On Tue, May 15, 2018 at 12:13 PM, Ilia Lin <ilialin@codeaurora.org> wrote:
> > Add support for SAW controlled regulators.
> > The regulators defined as SAW controlled in the device tree will be
> > controlled through special CPU registers instead of direct SPMI
> > accesses.
> > This is required especially for CPU supply regulators to synchronize
> > with clock scaling and for Automatic Voltage Switching.
> > Document it.
>
> Replace this boiler plate with what this patch actual does. Besides changing
> the subject, it could be, for example,
>
> "Document the DT bindings for the SAW regulators.
>
> The saw-slave property allows ganging (grouping) of several regulators so
> that their outputs can be combined... blah blah.
>
> The saw-leader is the only one that then is configurable in DT"
Actually, I invested some fantasy to write this explanation. But I'll try to revise it.
>
>
> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > ---
> > .../bindings/regulator/qcom,spmi-regulator.txt | 45
> ++++++++++++++++++++++
> > 1 file changed, 45 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > index 57d2c65..406f2e5 100644
> > ---
> > a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
> > +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-
> regulator.
> > +++ txt
> > @@ -110,6 +110,11 @@ Qualcomm SPMI Regulators
> > Definition: Reference to regulator supplying the input pin, as
> > described in the data sheet.
> >
> > +- qcom,saw-reg:
> > + Usage: optional
> > + Value type: <phandle>
> > + Description: Reference to syscon node defining the SAW registers.
> > +
> >
> > The regulator node houses sub-nodes for each regulator within the
> > device. Each sub-node is identified using the node's name, with valid
> > values listed for each @@ -201,6 +206,17 @@ see regulator.txt - with
> additional custom properties described below:
> > 2 = 0.55 uA
> > 3 = 0.75 uA
> >
> > +- qcom,saw-slave:
> > + Usage: optional
> > + Value type: <boo>
> > + Description: SAW controlled gang slave. Will not be configured.
> > +
> > +- qcom,saw-leader:
> > + Usage: optional
> > + Value type: <boo>
> > + Description: SAW controlled gang leader. Will be configured as
> > + SAW regulator.
> > +
> > Example:
> >
> > regulators {
> > @@ -221,3 +237,32 @@ Example:
> >
> > ....
> > };
> > +
> > +Example 2:
> > +
> > + saw3: syscon@9A10000 {
> > + compatible = "syscon";
> > + reg = <0x9A10000 0x1000>;
> > + };
> > +
> > + ...
> > +
> > + spm-regulators {
> > + compatible = "qcom,pm8994-regulators";
> > + qcom,saw-reg = <&saw3>;
> > + s8 {
> > + qcom,saw-slave;
> > + };
> > + s9 {
> > + qcom,saw-slave;
> > + };
> > + s10 {
> > + qcom,saw-slave;
> > + };
> > + pm8994_s11_saw: s11 {
> > + qcom,saw-leader;
> > + regulator-always-on;
> > + regulator-min-microvolt = <900000>;
> > + regulator-max-microvolt = <1140000>;
> > + };
> > + };
> > --
> > 1.9.1
> >
^ permalink raw reply
* Re: [PATCH 1/1] ARM:dts:sunxi: Add Olimex A20-SOM-EVB-eMMC board
From: Stefan Wahren @ 2018-05-17 7:25 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Stefan Mavrodiev, Maxime Ripard,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1526470689-6275-1-git-send-email-stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
Hi Stefan,
> Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org> hat am 16. Mai 2018 um 13:38 geschrieben:
>
>
> With the new rev.E of A20-SOM-EVB, there is option for 16GB eMMC.
> Currently used card is KLMAG2GEND, wired to MMC2 slot.
>
> Signed-off-by: Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> .../arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts | 37 ++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 1db91ec..7f1ee65 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -959,6 +959,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> sun7i-a20-m3.dtb \
> sun7i-a20-mk808c.dtb \
> sun7i-a20-olimex-som-evb.dtb \
> + sun7i-a20-olimex-som-evb-emmc.dtb \
> sun7i-a20-olimex-som204-evb.dtb \
> sun7i-a20-olimex-som204-evb-emmc.dtb \
> sun7i-a20-olinuxino-lime.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
> new file mode 100644
> index 0000000..81ebc97
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device Tree Source for A20-Olimex-SOM-EVB-eMMC Board
> + *
> + * Copyright (C) 2018 Olimex Ltd.
> + * Author: Stefan Mavrodiev <stefan-kyXcfZUBQGPQT0dZR+AlfA@public.gmane.org>
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20-olimex-som-evb.dts"
> +
> +/ {
> +
> + model = "Olimex A20-Olimex-SOM-EVB-eMMC";
> + compatible = "olimex,a20-olimex-som-evb-emmc", "allwinner,sun7i-a20";
the file Documentation/devicetree/bindings/arm/olimex.txt seems to be out of date. I cannot find any recent board compatible.
Didn't checkpatch complain about it?
Regards
Stefan
^ permalink raw reply
* Re: [PATCH 1/1] ARM:dts:sunxi: Add Olimex A20-SOM-EVB-eMMC board
From: Stefan Mavrodiev @ 2018-05-17 7:34 UTC (permalink / raw)
To: Stefan Wahren, Rob Herring, Mark Rutland, Stefan Mavrodiev,
Maxime Ripard, devicetree, linux-kernel, Chen-Yu Tsai,
linux-arm-kernel
Cc: linux-sunxi
In-Reply-To: <96201051.35560.1526541952287@email.1und1.de>
On 05/17/2018 10:25 AM, Stefan Wahren wrote:
> Hi Stefan,
>
>> Stefan Mavrodiev <stefan@olimex.com> hat am 16. Mai 2018 um 13:38 geschrieben:
>>
>>
>> With the new rev.E of A20-SOM-EVB, there is option for 16GB eMMC.
>> Currently used card is KLMAG2GEND, wired to MMC2 slot.
>>
>> Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> .../arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts | 37 ++++++++++++++++++++++
>> 2 files changed, 38 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 1db91ec..7f1ee65 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -959,6 +959,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-m3.dtb \
>> sun7i-a20-mk808c.dtb \
>> sun7i-a20-olimex-som-evb.dtb \
>> + sun7i-a20-olimex-som-evb-emmc.dtb \
>> sun7i-a20-olimex-som204-evb.dtb \
>> sun7i-a20-olimex-som204-evb-emmc.dtb \
>> sun7i-a20-olinuxino-lime.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>> new file mode 100644
>> index 0000000..81ebc97
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts
>> @@ -0,0 +1,37 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Device Tree Source for A20-Olimex-SOM-EVB-eMMC Board
>> + *
>> + * Copyright (C) 2018 Olimex Ltd.
>> + * Author: Stefan Mavrodiev <stefan@olimex.com>
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20-olimex-som-evb.dts"
>> +
>> +/ {
>> +
>> + model = "Olimex A20-Olimex-SOM-EVB-eMMC";
>> + compatible = "olimex,a20-olimex-som-evb-emmc", "allwinner,sun7i-a20";
> the file Documentation/devicetree/bindings/arm/olimex.txt seems to be out of date. I cannot find any recent board compatible.
>
> Didn't checkpatch complain about it?
Yes it did. I didn't get is seriously because neither Olimex A20 based
board is documented in the binding.
>
> Regards
> Stefan
Regards,
Stefan Mavrodiev
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Krzysztof Kozlowski @ 2018-05-17 7:40 UTC (permalink / raw)
To: Stefan Agner
Cc: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel, Marcel Ziswiler,
Lucas Stach
In-Reply-To: <fce1d8c51fc3fd74fe61933fe9b59654@agner.ch>
On Tue, May 15, 2018 at 11:20 PM, Stefan Agner <stefan@agner.ch> wrote:
> On 15.05.2018 16:41, Krzysztof Kozlowski wrote:
>> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
>> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
>> expecting the bootloader to do the fixup of /memory node. However in
>> case it does not happen, let's stay on safe side by limiting the memory
>> to 256 MB for both versions of Colibri-T20.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>>
>> ---
>>
>> RFT:
>> Not tested on 512 MB module as I have only the 256 MB one.
>>
>> Changes since v3:
>> 1. Reduce the memory in existing DTSI instead of creating a new one
>> (suggested by Marcel).
>>
>> Changes since v2:
>> 1. Do not add new compatible but use everywhere existing
>> "toradex,colibri_t20-512" (suggested by Rob).
>>
>> Changes since v1:
>> 1. Fix memory size in tegra20-colibri-256.dtsi (was working fine because
>> my bootloader uses mem= argument).
>> ---
>> arch/arm/boot/dts/tegra20-colibri-512.dtsi | 9 +++++++--
>> arch/arm/boot/dts/tegra20-iris-512.dts | 2 +-
>
> I don't like this variant too much.
>
> Can we not just drop the 512? And while at it, I would prefer to see the
> usual $soc-$module-$carrier schema, as we use with all the other modules
> of the Colibri and Apalis family.
>
> e.g.
> tegra20-colibri-512.dtsi -> tegra20-colibri.dtsi
> tegra20-iris-512.dts -> tegra20-colibri-iris.dts
Sure, let me resend it.
BR,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dmaengine: usb-dmac: Document R8A7799{0,5} bindings
From: Simon Horman @ 2018-05-17 7:40 UTC (permalink / raw)
To: Ulrich Hecht; +Cc: linux-renesas-soc, dmaengine, devicetree, Hiroyuki Yokoyama
In-Reply-To: <1526475979-13891-1-git-send-email-ulrich.hecht+renesas@gmail.com>
On Wed, May 16, 2018 at 03:06:18PM +0200, Ulrich Hecht wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> Renesas R-Car D3 (R8A77995) and E3 (R8A77990) SoCs also have the R-Car
> gen2/3 compatible DMA controllers, so document the SoC specific binding.
>
> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
> [uli: squashed]
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH 2/2] dmaengine: rcar-dmac: Document R8A77990 bindings
From: Simon Horman @ 2018-05-17 7:41 UTC (permalink / raw)
To: Ulrich Hecht; +Cc: linux-renesas-soc, dmaengine, devicetree, Hiroyuki Yokoyama
In-Reply-To: <1526475979-13891-2-git-send-email-ulrich.hecht+renesas@gmail.com>
On Wed, May 16, 2018 at 03:06:19PM +0200, Ulrich Hecht wrote:
> From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
>
> Renesas R-Car E3 (R8A77990) SoC also has the R-Car gen2/3 compatible DMA
> controllers, so document the SoC specific binding.
>
> Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
> Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> index b1ba6395..946229c 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
> @@ -29,6 +29,7 @@ Required Properties:
> - "renesas,dmac-r8a77965" (R-Car M3-N)
> - "renesas,dmac-r8a77970" (R-Car V3M)
> - "renesas,dmac-r8a77980" (R-Car V3H)
> + - "renesas,dmac-r8a77990" (R-Car E3)
> - "renesas,dmac-r8a77995" (R-Car D3)
>
> - reg: base address and length of the registers block for the DMAC
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v5 1/3] ARM: dts: tegra: Remove skeleton.dtsi and fix DTC warnings for /memory
From: Krzysztof Kozlowski @ 2018-05-17 7:45 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
Remove the usage of skeleton.dtsi and add necessary properties to /memory
node to fix the DTC warnings:
arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
/memory: node has a reg or ranges property, but no unit name
The DTB after the change is the same as before except adding
unit-address to /memory node.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v4:
1. None
---
arch/arm/boot/dts/tegra114-dalmore.dts | 3 ++-
arch/arm/boot/dts/tegra114-roth.dts | 3 ++-
arch/arm/boot/dts/tegra114-tn7.dts | 3 ++-
arch/arm/boot/dts/tegra114.dtsi | 4 ++--
arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-apalis.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 3 ++-
arch/arm/boot/dts/tegra124-nyan.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-venice2.dts | 3 ++-
arch/arm/boot/dts/tegra124.dtsi | 2 --
arch/arm/boot/dts/tegra20-colibri-512.dtsi | 3 ++-
arch/arm/boot/dts/tegra20-harmony.dts | 3 ++-
arch/arm/boot/dts/tegra20-paz00.dts | 3 ++-
arch/arm/boot/dts/tegra20-seaboard.dts | 3 ++-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 3 ++-
arch/arm/boot/dts/tegra20-trimslice.dts | 3 ++-
arch/arm/boot/dts/tegra20-ventana.dts | 3 ++-
arch/arm/boot/dts/tegra20.dtsi | 7 +++++--
arch/arm/boot/dts/tegra30-apalis.dtsi | 5 +++++
arch/arm/boot/dts/tegra30-beaver.dts | 3 ++-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 3 ++-
arch/arm/boot/dts/tegra30-colibri.dtsi | 3 ++-
arch/arm/boot/dts/tegra30.dtsi | 7 +++++--
23 files changed, 53 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index eafff16765b4..5cdcedfc19cb 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -23,7 +23,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index 7ed7370ee67a..b4f329a07c60 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -28,7 +28,8 @@
};
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
/* memory >= 0x79600000 is reserved for firmware usage */
reg = <0x80000000 0x79600000>;
};
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts b/arch/arm/boot/dts/tegra114-tn7.dts
index 7fc4a8b31e45..12092d344ce8 100644
--- a/arch/arm/boot/dts/tegra114-tn7.dts
+++ b/arch/arm/boot/dts/tegra114-tn7.dts
@@ -28,7 +28,8 @@
};
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
/* memory >= 0x37e00000 is reserved for firmware usage */
reg = <0x80000000 0x37e00000>;
};
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 0e4a13295d8a..b917784d3f97 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -5,11 +5,11 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra114";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
host1x@50000000 {
compatible = "nvidia,tegra114-host1x", "simple-bus";
diff --git a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
index bb67edb016c5..80b52c612891 100644
--- a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
@@ -15,7 +15,8 @@
compatible = "toradex,apalis-tk1-v1.2", "toradex,apalis-tk1",
"nvidia,tegra124";
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 65a2161b9b8e..3ca7601cafe9 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -50,7 +50,8 @@
model = "Toradex Apalis TK1";
compatible = "toradex,apalis-tk1", "nvidia,tegra124";
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 6dbcf84dafbc..8d9e6ee6c6a7 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -24,7 +24,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index 3609367037a6..15a2b0e3237e 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -13,7 +13,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 89bcc178994d..241cdc4b6600 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 174092bfac90..df1642876a4c 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -7,8 +7,6 @@
#include <dt-bindings/reset/tegra124-car.h>
#include <dt-bindings/thermal/tegra124-soctherm.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra124";
interrupt-parent = <&lic>;
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 5c202b3e3bb1..305efb275b48 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -10,7 +10,8 @@
rtc1 = "/rtc@7000e000";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 628a55a9318b..5009a55ae15c 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 30436969adc0..e794ac5442ef 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -19,7 +19,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 284aae351ff2..6cb832cfa4f3 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 872046d48709..6ceb1228fed3 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -15,7 +15,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index d55c6b240a30..3f94be3da9e5 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index ee3fbf941e79..c897a90289bc 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -18,7 +18,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
+ device_type = "memory";
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 0a7136462a1a..290ebbeb210f 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,11 +4,14 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra20";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
iram@40000000 {
compatible = "mmio-sram";
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index d1d21ec2a844..184f60c720fa 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -10,6 +10,11 @@
model = "Toradex Apalis T30";
compatible = "toradex,apalis_t30", "nvidia,tegra30";
+ memory@0 {
+ device_type = "memory";
+ reg = <0 0>;
+ };
+
pcie@3000 {
avdd-pexa-supply = <&vdd2_reg>;
vdd-pexa-supply = <&vdd2_reg>;
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index ae52a5039506..72369877d284 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -17,7 +17,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x7ff00000>;
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 92a9740c533f..24c04d4c335d 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -40,7 +40,8 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index c44d8c40c410..cc46cedf80b9 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -10,7 +10,8 @@
model = "Toradex Colibri T30";
compatible = "toradex,colibri_t30", "nvidia,tegra30";
- memory {
+ memory@80000000 {
+ device_type = "memory";
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index a110cf84d85f..4383f0fd789d 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -5,11 +5,14 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra30";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
pcie@3000 {
compatible = "nvidia,tegra30-pcie";
--
2.7.4
^ 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