* [PATCH v5 13/15] clk: qcom: Add safe switch hook for krait mux clocks
From: Sricharan R @ 2017-12-19 15:54 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A, rjw-LthD3rsA81gm4RdzfppkhA,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA
Cc: sricharan-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1513698900-10638-1-git-send-email-sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
When the Hfplls are reprogrammed during the rate change,
the primary muxes which are sourced from the same hfpll
for higher frequencies, needs to be switched to the 'safe
secondary mux' as the parent for that small window. This
is done by registering a clk notifier for the muxes and
switching to the safe parent in the PRE_RATE_CHANGE notifier
and back to the original parent in the POST_RATE_CHANGE notifier.
Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
drivers/clk/qcom/clk-krait.c | 2 ++
drivers/clk/qcom/clk-krait.h | 3 +++
drivers/clk/qcom/krait-cc.c | 56 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 61 insertions(+)
diff --git a/drivers/clk/qcom/clk-krait.c b/drivers/clk/qcom/clk-krait.c
index 361c701..f9744f1 100644
--- a/drivers/clk/qcom/clk-krait.c
+++ b/drivers/clk/qcom/clk-krait.c
@@ -50,6 +50,8 @@ static int krait_mux_set_parent(struct clk_hw *hw, u8 index)
if (__clk_is_enabled(hw->clk))
__krait_mux_set_sel(mux, sel);
+ mux->reparent = true;
+
return 0;
}
diff --git a/drivers/clk/qcom/clk-krait.h b/drivers/clk/qcom/clk-krait.h
index d5c9c60..6e2d4f4 100644
--- a/drivers/clk/qcom/clk-krait.h
+++ b/drivers/clk/qcom/clk-krait.h
@@ -13,6 +13,9 @@ struct krait_mux_clk {
u32 shift;
u32 en_mask;
bool lpl;
+ u8 safe_sel;
+ u8 old_index;
+ bool reparent;
struct clk_hw hw;
struct notifier_block clk_nb;
diff --git a/drivers/clk/qcom/krait-cc.c b/drivers/clk/qcom/krait-cc.c
index ee864fa..2d82c5f 100644
--- a/drivers/clk/qcom/krait-cc.c
+++ b/drivers/clk/qcom/krait-cc.c
@@ -26,6 +26,49 @@
0,
};
+/*
+ * Notifier function for switching the muxes to safe parent
+ * while the hfpll is getting reprogrammed.
+ */
+static int krait_notifier_cb(struct notifier_block *nb,
+ unsigned long event,
+ void *data)
+{
+ int ret = 0;
+ struct krait_mux_clk *mux = container_of(nb, struct krait_mux_clk,
+ clk_nb);
+ /* Switch to safe parent */
+ if (event == PRE_RATE_CHANGE) {
+ mux->old_index = krait_mux_clk_ops.get_parent(&mux->hw);
+ ret = krait_mux_clk_ops.set_parent(&mux->hw, mux->safe_sel);
+ mux->reparent = false;
+ /*
+ * By the time POST_RATE_CHANGE notifier is called,
+ * clk framework itself would have changed the parent for the new rate.
+ * Only otherwise, put back to the old parent.
+ */
+ } else if (event == POST_RATE_CHANGE) {
+ if (!mux->reparent)
+ ret = krait_mux_clk_ops.set_parent(&mux->hw,
+ mux->old_index);
+ }
+
+ return notifier_from_errno(ret);
+}
+
+static int krait_notifier_register(struct device *dev, struct clk *clk,
+ struct krait_mux_clk *mux)
+{
+ int ret = 0;
+
+ mux->clk_nb.notifier_call = krait_notifier_cb;
+ ret = clk_notifier_register(clk, &mux->clk_nb);
+ if (ret)
+ dev_err(dev, "failed to register clock notifier: %d\n", ret);
+
+ return ret;
+}
+
static int
krait_add_div(struct device *dev, int id, const char *s, unsigned int offset)
{
@@ -70,6 +113,7 @@
krait_add_sec_mux(struct device *dev, int id, const char *s,
unsigned int offset, bool unique_aux)
{
+ int ret;
struct krait_mux_clk *mux;
static const char *sec_mux_list[] = {
"acpu_aux",
@@ -93,6 +137,7 @@
mux->shift = 2;
mux->parent_map = sec_mux_map;
mux->hw.init = &init;
+ mux->safe_sel = 0;
init.name = kasprintf(GFP_KERNEL, "krait%s_sec_mux", s);
if (!init.name)
@@ -108,6 +153,11 @@
clk = devm_clk_register(dev, &mux->hw);
+ ret = krait_notifier_register(dev, clk, mux);
+ if (ret)
+ goto unique_aux;
+
+unique_aux:
if (unique_aux)
kfree(sec_mux_list[0]);
err_aux:
@@ -119,6 +169,7 @@
krait_add_pri_mux(struct device *dev, int id, const char *s,
unsigned int offset)
{
+ int ret;
struct krait_mux_clk *mux;
const char *p_names[3];
struct clk_init_data init = {
@@ -139,6 +190,7 @@
mux->lpl = id >= 0;
mux->parent_map = pri_mux_map;
mux->hw.init = &init;
+ mux->safe_sel = 2;
init.name = kasprintf(GFP_KERNEL, "krait%s_pri_mux", s);
if (!init.name)
@@ -164,6 +216,10 @@
clk = devm_clk_register(dev, &mux->hw);
+ ret = krait_notifier_register(dev, clk, mux);
+ if (ret)
+ goto err_p3;
+err_p3:
kfree(p_names[2]);
err_p2:
kfree(p_names[1]);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 14/15] cpufreq: Add module to register cpufreq on Krait CPUs
From: Sricharan R @ 2017-12-19 15:54 UTC (permalink / raw)
To: robh+dt, mark.rutland, mturquette, sboyd, linux, andy.gross,
david.brown, rjw, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-arm-msm, linux-soc, linux-pm
Cc: sricharan
In-Reply-To: <1513698900-10638-1-git-send-email-sricharan@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Register a cpufreq-generic device whenever we detect that a
"qcom,krait" compatible CPU is present in DT.
Cc: <devicetree@vger.kernel.org>
[Sricharan: updated to use dev_pm_opp_set_prop_name]
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/cpufreq/Kconfig.arm | 9 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +-
drivers/cpufreq/qcom-cpufreq.c | 171 +++++++++++++++++++++++++++++++++++
4 files changed, 183 insertions(+), 1 deletion(-)
create mode 100644 drivers/cpufreq/qcom-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index bdce448..60f28e7 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -100,6 +100,15 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
+config ARM_QCOM_CPUFREQ
+ tristate "Qualcomm based"
+ depends on ARCH_QCOM
+ select PM_OPP
+ help
+ This adds the CPUFreq driver for Qualcomm 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 812f9e0..1496464 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-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) += qcom-cpufreq.o
obj-$(CONFIG_ARM_S3C24XX_CPUFREQ) += s3c24xx-cpufreq.o
obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
obj-$(CONFIG_ARM_S3C2410_CPUFREQ) += s3c2410-cpufreq.o
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index ecc56e2..032ac4f 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -118,7 +118,7 @@
{ .compatible = "ti,am33xx", },
{ .compatible = "ti,am43", },
{ .compatible = "ti,dra7", },
-
+ { .compatible = "qcom,ipq8064", },
{ }
};
@@ -157,6 +157,7 @@ static int __init cpufreq_dt_platdev_init(void)
create_pdev:
of_node_put(np);
+
return PTR_ERR_OR_ZERO(platform_device_register_data(NULL, "cpufreq-dt",
-1, data,
sizeof(struct cpufreq_dt_platform_data)));
diff --git a/drivers/cpufreq/qcom-cpufreq.c b/drivers/cpufreq/qcom-cpufreq.c
new file mode 100644
index 0000000..3e5583d
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq.c
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+
+#include <linux/cpu.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_opp.h>
+#include <linux/slab.h>
+#include "cpufreq-dt.h"
+
+static void __init get_krait_bin_format_a(int *speed, int *pvs, int *pvs_ver)
+{
+ void __iomem *base;
+ u32 pte_efuse;
+
+ *speed = *pvs = *pvs_ver = 0;
+
+ base = ioremap(0x007000c0, 4);
+ if (!base) {
+ pr_warn("Unable to read efuse data. Defaulting to 0!\n");
+ return;
+ }
+
+ pte_efuse = readl_relaxed(base);
+ iounmap(base);
+
+ *speed = pte_efuse & 0xf;
+ if (*speed == 0xf)
+ *speed = (pte_efuse >> 4) & 0xf;
+
+ if (*speed == 0xf) {
+ *speed = 0;
+ pr_warn("Speed bin: Defaulting to %d\n", *speed);
+ } else {
+ pr_info("Speed bin: %d\n", *speed);
+ }
+
+ *pvs = (pte_efuse >> 10) & 0x7;
+ if (*pvs == 0x7)
+ *pvs = (pte_efuse >> 13) & 0x7;
+
+ if (*pvs == 0x7) {
+ *pvs = 0;
+ pr_warn("PVS bin: Defaulting to %d\n", *pvs);
+ } else {
+ pr_info("PVS bin: %d\n", *pvs);
+ }
+}
+
+static void __init get_krait_bin_format_b(int *speed, int *pvs, int *pvs_ver)
+{
+ u32 pte_efuse, redundant_sel;
+ void __iomem *base;
+
+ *speed = 0;
+ *pvs = 0;
+ *pvs_ver = 0;
+
+ base = ioremap(0xfc4b80b0, 8);
+ if (!base) {
+ pr_warn("Unable to read efuse data. Defaulting to 0!\n");
+ return;
+ }
+
+ pte_efuse = readl_relaxed(base);
+ redundant_sel = (pte_efuse >> 24) & 0x7;
+ *speed = pte_efuse & 0x7;
+ /* 4 bits of PVS are in efuse register bits 31, 8-6. */
+ *pvs = ((pte_efuse >> 28) & 0x8) | ((pte_efuse >> 6) & 0x7);
+ *pvs_ver = (pte_efuse >> 4) & 0x3;
+
+ switch (redundant_sel) {
+ case 1:
+ *speed = (pte_efuse >> 27) & 0xf;
+ break;
+ case 2:
+ *pvs = (pte_efuse >> 27) & 0xf;
+ break;
+ }
+
+ /* Check SPEED_BIN_BLOW_STATUS */
+ if (pte_efuse & BIT(3)) {
+ pr_info("Speed bin: %d\n", *speed);
+ } else {
+ pr_warn("Speed bin not set. Defaulting to 0!\n");
+ *speed = 0;
+ }
+
+ /* Check PVS_BLOW_STATUS */
+ pte_efuse = readl_relaxed(base + 0x4) & BIT(21);
+ if (pte_efuse) {
+ pr_info("PVS bin: %d\n", *pvs);
+ } else {
+ pr_warn("PVS bin not set. Defaulting to 0!\n");
+ *pvs = 0;
+ }
+
+ pr_info("PVS version: %d\n", *pvs_ver);
+ iounmap(base);
+}
+
+static int __init qcom_cpufreq_populate_opps(void)
+{
+ int speed, pvs, pvs_ver;
+ struct device_node *np;
+ struct device *dev;
+ int cpu = 0;
+ char pvs_name[] = "speedXX-pvsXX-vXX";
+
+ np = of_find_node_by_name(NULL, "qcom,pvs");
+ if (!np)
+ return -ENODEV;
+
+ if (of_property_read_bool(np, "qcom,pvs-format-a"))
+ get_krait_bin_format_a(&speed, &pvs, &pvs_ver);
+ else if (of_property_read_bool(np, "qcom,pvs-format-b"))
+ get_krait_bin_format_b(&speed, &pvs, &pvs_ver);
+ else
+ return -ENODEV;
+
+ snprintf(pvs_name, sizeof(pvs_name), "speed%d-pvs%d-v%d",
+ speed, pvs, pvs_ver);
+
+ for (cpu = 0; cpu < num_possible_cpus(); cpu++) {
+ dev = get_cpu_device(cpu);
+ if (!dev)
+ return -ENODEV;
+
+ if (IS_ERR(dev_pm_opp_set_prop_name(dev, pvs_name)))
+ pr_warn("failed to add OPP name %s\n", pvs_name);
+ }
+
+ return 0;
+}
+
+static int __init qcom_cpufreq_driver_init(void)
+{
+ struct device *cpu_dev;
+ struct device_node *np;
+ int ret;
+
+ cpu_dev = get_cpu_device(0);
+ if (!cpu_dev)
+ return -ENODEV;
+
+ np = of_node_get(cpu_dev->of_node);
+ if (!np)
+ return -ENOENT;
+
+ if (!of_device_is_compatible(np, "qcom,krait")) {
+ of_node_put(np);
+ return -ENODEV;
+ }
+ of_node_put(np);
+
+ ret = qcom_cpufreq_populate_opps();
+ if (ret)
+ return ret;
+
+ return PTR_ERR(platform_device_register_simple("cpufreq-dt",
+ -1, NULL, 0));
+}
+module_init(qcom_cpufreq_driver_init);
+
+MODULE_DESCRIPTION("Qualcomm CPUfreq driver");
+MODULE_LICENSE("GPL v2");
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs
From: Sricharan R @ 2017-12-19 15:55 UTC (permalink / raw)
To: robh+dt, mark.rutland, mturquette, sboyd, linux, andy.gross,
david.brown, rjw, viresh.kumar, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-arm-msm, linux-soc, linux-pm
Cc: sricharan
In-Reply-To: <1513698900-10638-1-git-send-email-sricharan@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
.../devicetree/bindings/arm/msm/qcom,pvs.txt | 91 ++++++++++++++++++++++
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt b/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
new file mode 100644
index 0000000..260f537
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,pvs.txt
@@ -0,0 +1,91 @@
+Qualcomm Process Voltage Scaling Tables
+
+The node name is required to be "qcom,pvs". There shall only be one
+such node present in the root of the tree.
+
+PROPERTIES
+
+- qcom,pvs-format-a or qcom,pvs-format-b:
+ Usage: required
+ Value type: <empty>
+ Definition: Indicates where and how to read and interpret the efuse registers.
+ Based on that the opp-microvolt-<name> is extended with the right
+ speedXX-PVSXX-versionXX string. The cpu opp-table should be populated
+ with the operating-points-v2 binding and each opp must have the voltage
+ specified for all combinations of opp-microvolt-<speedXX-pvsXX-versionXX>.
+
+Example:
+
+ cpu@0 {
+ compatible = "qcom,krait";
+ enable-method = "qcom,kpss-acc-v1";
+ device_type = "cpu";
+ reg = <0>;
+ qcom,acc = <&acc0>;
+ qcom,saw = <&saw0>;
+ clocks = <&kraitcc 0>;
+ clock-names = "cpu";
+ cpu-supply = <&smb208_s2a>;
+ operating-points-v2 = <&cpu_opp_table>;
+ };
+
+ qcom,pvs {
+ qcom,pvs-format-a;
+ };
+
+
+ cpu_opp_table: opp_table {
+ compatible = "operating-points-v2";
+
+ /*
+ * Missing opp-shared property means CPUs switch DVFS states
+ * independently.
+ */
+
+ opp-1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1250000>;
+ opp-microvolt-speed0-pvs1-v0 = <1175000>;
+ opp-microvolt-speed0-pvs2-v0 = <1125000>;
+ opp-microvolt-speed0-pvs3-v0 = <1050000>;
+
+ };
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1100000>;
+ opp-microvolt-speed0-pvs1-v0 = <1025000>;
+ opp-microvolt-speed0-pvs2-v0 = <995000>;
+ opp-microvolt-speed0-pvs3-v0 = <900000>;
+
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1000000>;
+ opp-microvolt-speed0-pvs1-v0 = <925000>;
+ opp-microvolt-speed0-pvs2-v0 = <875000>;
+ opp-microvolt-speed0-pvs3-v0 = <800000>;
+ };
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1150000>;
+ opp-microvolt-speed0-pvs1-v0 = <1075000>;
+ opp-microvolt-speed0-pvs2-v0 = <1025000>;
+ opp-microvolt-speed0-pvs3-v0 = <950000>;
+
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1050000>;
+ opp-microvolt-speed0-pvs1-v0 = <975000>;
+ opp-microvolt-speed0-pvs2-v0 = <925000>;
+ opp-microvolt-speed0-pvs3-v0 = <850000>;
+ };
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt-speed0-pvs0-v0 = <1200000>;
+ opp-microvolt-speed0-pvs1-v0 = <1125000>;
+ opp-microvolt-speed0-pvs2-v0 = <1075000>;
+ opp-microvolt-speed0-pvs3-v0 = <1000000>;
+ };
+ };
+
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* Re: [PATCH v3 1/1] eeprom: at24: convert magic numbers to structs.
From: Bartosz Golaszewski @ 2017-12-19 15:55 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: Sven Van Asbroeck, Wolfram Sang, nsekhar, Sakari Ailus,
Javier Martinez Canillas, Divagar Mohandass, devicetree,
Linux Kernel Mailing List, linux-i2c
In-Reply-To: <1513621702-6565-2-git-send-email-svenv@arcx.com>
2017-12-18 19:28 GMT+01:00 Sven Van Asbroeck <svenv@arcx.com>:
> From: Sven Van Asbroeck <svendev@arcx.com>
>
> Fundamental properties such as capacity and page size differ
> among at24-type chips. But these chips do not have an id register,
> so this can't be discovered at runtime.
>
> Traditionally, at24-type eeprom properties were determined in two ways:
> - by passing a 'struct at24_platform_data' via platform_data, or
> - by naming the chip type in the devicetree, which passes a
> 'magic number' to probe(), which is then converted to
> a 'struct at24_platform_data'.
>
> Recently a bug was discovered because the magic number rounds down
> all chip sizes to the lowest power of two. This was addressed by
> a work-around, with the wish that magic numbers should over time
> be converted to structs.
> commit 5478e478eee3 ("eeprom: at24: correctly set the size for at24mac402")
>
> This patch replaces the magic numbers with 'struct at24_chip_data'.
>
> Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
OK, this looks better. We still need to fix some formatting issues
though. Please find some remarks below.
> ---
> drivers/misc/eeprom/at24.c | 219 ++++++++++++++++++++-------------------------
> 1 file changed, 99 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index b44a3d2b..afa0f93 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -105,16 +105,6 @@ struct at24_data {
> module_param_named(write_timeout, at24_write_timeout, uint, 0);
> MODULE_PARM_DESC(at24_write_timeout, "Time (in ms) to try writes (default 25)");
>
> -#define AT24_SIZE_BYTELEN 5
> -#define AT24_SIZE_FLAGS 8
> -
> -#define AT24_BITMASK(x) (BIT(x) - 1)
> -
> -/* create non-zero magic value for given eeprom parameters */
> -#define AT24_DEVICE_MAGIC(_len, _flags) \
> - ((1 << AT24_SIZE_FLAGS | (_flags)) \
> - << AT24_SIZE_BYTELEN | ilog2(_len))
> -
> /*
> * Both reads and writes fail if the previous write didn't complete yet. This
> * macro loops a few times waiting at least long enough for one entire page
> @@ -132,113 +122,108 @@ struct at24_data {
> op_time ? time_before(op_time, tout) : true; \
> usleep_range(1000, 1500), op_time = jiffies)
>
> +struct at24_chip_data {
> + /*
> + * these fields mirror their equivalents in
> + * struct at24_platform_data
> + */
> + u32 byte_len;
> + u8 flags;
> +};
> +
> +#define AT24_CHIP_DATA(_name, _len, _flags) \
> + static const struct at24_chip_data _name = { \
> + .byte_len = _len, .flags = _flags, \
> + }
> +
> +/* needs 8 addresses as A0-A2 are ignored */
> +AT24_CHIP_DATA(at24_data_24c00, 128 / 8, AT24_FLAG_TAKE8ADDR);
> +/* old variants can't be handled with this generic entry! */
> +AT24_CHIP_DATA(at24_data_24c01, 1024 / 8, 0);
> +AT24_CHIP_DATA(at24_data_24cs01, 16, AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
When breaking the lines like this, prefer to break after a comma and
having longer lines below - it's more readable that way. In this case
it would be:
AT24_CHIP_DATA(at24_data_24cs01,
AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
The same applies elsewhere as long as it fits the line length of 80 chars.
> +AT24_CHIP_DATA(at24_data_24c02, 2048 / 8, 0);
> +AT24_CHIP_DATA(at24_data_24cs02, 16, AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24mac402, 48 / 8, AT24_FLAG_MAC |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24mac602, 64 / 8, AT24_FLAG_MAC |
> + AT24_FLAG_READONLY);
> +/* spd is a 24c02 in memory DIMMs */
> +AT24_CHIP_DATA(at24_data_spd, 2048 / 8, AT24_FLAG_READONLY |
> + AT24_FLAG_IRUGO);
> +AT24_CHIP_DATA(at24_data_24c04, 4096 / 8, 0);
> +AT24_CHIP_DATA(at24_data_24cs04, 16, AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +/* 24rf08 quirk is handled at i2c-core */
> +AT24_CHIP_DATA(at24_data_24c08, 8192 / 8, 0);
> +AT24_CHIP_DATA(at24_data_24cs08, 16, AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24c16, 16384 / 8, 0);
> +AT24_CHIP_DATA(at24_data_24cs16, 16, AT24_FLAG_SERIAL |
> + AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24c32, 32768 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(at24_data_24cs32, 16, AT24_FLAG_ADDR16 |
> + AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24c64, 65536 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(at24_data_24cs64, 16, AT24_FLAG_ADDR16 |
> + AT24_FLAG_SERIAL | AT24_FLAG_READONLY);
> +AT24_CHIP_DATA(at24_data_24c128, 131072 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(at24_data_24c256, 262144 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(at24_data_24c512, 524288 / 8, AT24_FLAG_ADDR16);
> +AT24_CHIP_DATA(at24_data_24c1024, 1048576 / 8, AT24_FLAG_ADDR16);
> +/* identical to 24c08 ? */
> +AT24_CHIP_DATA(at24_data_INT3499, 8192 / 8, 0);
> +
> static const struct i2c_device_id at24_ids[] = {
> - /* needs 8 addresses as A0-A2 are ignored */
> - { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
> - /* old variants can't be handled with this generic entry! */
> - { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
> - { "24cs01", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c02", AT24_DEVICE_MAGIC(2048 / 8, 0) },
> - { "24cs02", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24mac402", AT24_DEVICE_MAGIC(48 / 8,
> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
> - { "24mac602", AT24_DEVICE_MAGIC(64 / 8,
> - AT24_FLAG_MAC | AT24_FLAG_READONLY) },
> - /* spd is a 24c02 in memory DIMMs */
> - { "spd", AT24_DEVICE_MAGIC(2048 / 8,
> - AT24_FLAG_READONLY | AT24_FLAG_IRUGO) },
> - { "24c04", AT24_DEVICE_MAGIC(4096 / 8, 0) },
> - { "24cs04", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - /* 24rf08 quirk is handled at i2c-core */
> - { "24c08", AT24_DEVICE_MAGIC(8192 / 8, 0) },
> - { "24cs08", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c16", AT24_DEVICE_MAGIC(16384 / 8, 0) },
> - { "24cs16", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_SERIAL | AT24_FLAG_READONLY) },
> - { "24c32", AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16) },
> - { "24cs32", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_ADDR16 |
> - AT24_FLAG_SERIAL |
> - AT24_FLAG_READONLY) },
> - { "24c64", AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16) },
> - { "24cs64", AT24_DEVICE_MAGIC(16,
> - AT24_FLAG_ADDR16 |
> - AT24_FLAG_SERIAL |
> - AT24_FLAG_READONLY) },
> - { "24c128", AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16) },
> - { "24c256", AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16) },
> - { "24c512", AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16) },
> - { "24c1024", AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16) },
> + { "24c00", (kernel_ulong_t)&at24_data_24c00 },
Please separate the two arguments with tabs and align them nicely in
the entire array.
> + { "24c01", (kernel_ulong_t)&at24_data_24c01 },
> + { "24cs01", (kernel_ulong_t)&at24_data_24cs01 },
> + { "24c02", (kernel_ulong_t)&at24_data_24c02 },
> + { "24cs02", (kernel_ulong_t)&at24_data_24cs02 },
> + { "24mac402", (kernel_ulong_t)&at24_data_24mac402 },
> + { "24mac602", (kernel_ulong_t)&at24_data_24mac602 },
> + { "spd", (kernel_ulong_t)&at24_data_spd },
> + { "24c04", (kernel_ulong_t)&at24_data_24c04 },
> + { "24cs04", (kernel_ulong_t)&at24_data_24cs04 },
> + { "24c08", (kernel_ulong_t)&at24_data_24c08 },
> + { "24cs08", (kernel_ulong_t)&at24_data_24cs08 },
> + { "24c16", (kernel_ulong_t)&at24_data_24c16 },
> + { "24cs16", (kernel_ulong_t)&at24_data_24cs16 },
> + { "24c32", (kernel_ulong_t)&at24_data_24c32 },
> + { "24cs32", (kernel_ulong_t)&at24_data_24cs32 },
> + { "24c64", (kernel_ulong_t)&at24_data_24c64 },
> + { "24cs64", (kernel_ulong_t)&at24_data_24cs64 },
> + { "24c128", (kernel_ulong_t)&at24_data_24c128 },
> + { "24c256", (kernel_ulong_t)&at24_data_24c256 },
> + { "24c512", (kernel_ulong_t)&at24_data_24c512 },
> + { "24c1024", (kernel_ulong_t)&at24_data_24c1024 },
> { "at24", 0 },
> { /* END OF LIST */ }
> };
> MODULE_DEVICE_TABLE(i2c, at24_ids);
>
> static const struct of_device_id at24_of_match[] = {
> - {
> - .compatible = "atmel,24c00",
> - .data = (void *)AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR)
> - },
> - {
> - .compatible = "atmel,24c01",
> - .data = (void *)AT24_DEVICE_MAGIC(1024 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c02",
> - .data = (void *)AT24_DEVICE_MAGIC(2048 / 8, 0)
> - },
> - {
> - .compatible = "atmel,spd",
> - .data = (void *)AT24_DEVICE_MAGIC(2048 / 8,
> - AT24_FLAG_READONLY | AT24_FLAG_IRUGO)
> - },
> - {
> - .compatible = "atmel,24c04",
> - .data = (void *)AT24_DEVICE_MAGIC(4096 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c08",
> - .data = (void *)AT24_DEVICE_MAGIC(8192 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c16",
> - .data = (void *)AT24_DEVICE_MAGIC(16384 / 8, 0)
> - },
> - {
> - .compatible = "atmel,24c32",
> - .data = (void *)AT24_DEVICE_MAGIC(32768 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c64",
> - .data = (void *)AT24_DEVICE_MAGIC(65536 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c128",
> - .data = (void *)AT24_DEVICE_MAGIC(131072 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c256",
> - .data = (void *)AT24_DEVICE_MAGIC(262144 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c512",
> - .data = (void *)AT24_DEVICE_MAGIC(524288 / 8, AT24_FLAG_ADDR16)
> - },
> - {
> - .compatible = "atmel,24c1024",
> - .data = (void *)AT24_DEVICE_MAGIC(1048576 / 8, AT24_FLAG_ADDR16)
> - },
> - { },
> + { .compatible = "atmel,24c00", .data = &at24_data_24c00 },
Add tabs here as well, seems like there's enough space in the line.
> + { .compatible = "atmel,24c01", .data = &at24_data_24c01 },
> + { .compatible = "atmel,24c02", .data = &at24_data_24c02 },
> + { .compatible = "atmel,spd", .data = &at24_data_spd },
> + { .compatible = "atmel,24c04", .data = &at24_data_24c04 },
> + { .compatible = "atmel,24c08", .data = &at24_data_24c08 },
> + { .compatible = "atmel,24c16", .data = &at24_data_24c16 },
> + { .compatible = "atmel,24c32", .data = &at24_data_24c32 },
> + { .compatible = "atmel,24c64", .data = &at24_data_24c64 },
> + { .compatible = "atmel,24c128", .data = &at24_data_24c128 },
> + { .compatible = "atmel,24c256", .data = &at24_data_24c256 },
> + { .compatible = "atmel,24c512", .data = &at24_data_24c512 },
> + { .compatible = "atmel,24c1024", .data = &at24_data_24c1024 },
> + { /* END OF LIST */ },
> };
> MODULE_DEVICE_TABLE(of, at24_of_match);
>
> static const struct acpi_device_id at24_acpi_ids[] = {
> - { "INT3499", AT24_DEVICE_MAGIC(8192 / 8, 0) },
> - { }
> + { "INT3499", (kernel_ulong_t)&at24_data_INT3499 },
Same spacing as in the i2c device list.
> + { /* END OF LIST */ }
> };
> MODULE_DEVICE_TABLE(acpi, at24_acpi_ids);
>
> @@ -516,8 +501,8 @@ static unsigned int at24_get_offset_adj(u8 flags, unsigned int byte_len)
>
> static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> - struct at24_platform_data chip;
> - kernel_ulong_t magic = 0;
> + struct at24_platform_data chip = { 0 };
> + const struct at24_chip_data *cd = NULL;
> bool writable;
> struct at24_data *at24;
> int err;
> @@ -535,28 +520,22 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> */
> if (client->dev.of_node &&
> of_match_device(at24_of_match, &client->dev)) {
> - magic = (kernel_ulong_t)
> - of_device_get_match_data(&client->dev);
> + cd = of_device_get_match_data(&client->dev);
> } else if (id) {
> - magic = id->driver_data;
> + cd = (void *)id->driver_data;
> } else {
> const struct acpi_device_id *aid;
>
> aid = acpi_match_device(at24_acpi_ids, &client->dev);
> if (aid)
> - magic = aid->driver_data;
> + cd = (void *)aid->driver_data;
> }
> - if (!magic)
> + if (!cd)
> return -ENODEV;
>
> - chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
> - magic >>= AT24_SIZE_BYTELEN;
> - chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
> -
> + chip.byte_len = cd->byte_len;
> + chip.flags = cd->flags;
> at24_get_pdata(&client->dev, &chip);
> -
> - chip.setup = NULL;
> - chip.context = NULL;
> }
>
> if (!is_power_of_2(chip.byte_len))
> --
> 1.9.1
>
Thanks,
Bartosz
^ permalink raw reply
* [PATCH v7 2/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-19 15:59 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
^ permalink raw reply related
* [PATCH 0/3] pwm: renesas-tpu: Misc Fixes
From: Geert Uytterhoeven @ 2017-12-19 16:02 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
Hi all,
Here are three small fixes related to the Renesas Timer Pulse Unit PWM
driver.
The first patch is meant for Simon's tree.
The other two patches are meant for either the PWM or DT tree.
Thanks!
Geert Uytterhoeven (3):
ARM: dts: r8a7740: Correct TPU register block size
dt-bindings: pwm: renesas-tpu: Correct example TPU register block size
dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family
names
Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 6 +++---
arch/arm/boot/dts/r8a7740.dtsi | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/3] ARM: dts: r8a7740: Correct TPU register block size
From: Geert Uytterhoeven @ 2017-12-19 16:02 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <1513699327-27357-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
The Timer Pulse Unit has registers that lie outside the declared
register block. Enlarge the register block size to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
This was probably based on the old platform code, which also assumed a
register block size of 0x100.
arch/arm/boot/dts/r8a7740.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7740.dtsi b/arch/arm/boot/dts/r8a7740.dtsi
index 95c408b11991fb77..afd3bc5e6cf2e23f 100644
--- a/arch/arm/boot/dts/r8a7740.dtsi
+++ b/arch/arm/boot/dts/r8a7740.dtsi
@@ -317,7 +317,7 @@
tpu: pwm@e6600000 {
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
- reg = <0xe6600000 0x100>;
+ reg = <0xe6600000 0x148>;
clocks = <&mstp3_clks R8A7740_CLK_TPU0>;
power-domains = <&pd_a3sp>;
status = "disabled";
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: pwm: renesas-tpu: Correct example TPU register block size
From: Geert Uytterhoeven @ 2017-12-19 16:02 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <1513699327-27357-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
The Timer Pulse Unit on R-Mobile A1 has registers that lie outside the
declared register block. Enlarge the register block size to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
index 1aadc804dae4e30b..641b5b4c648340ee 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
@@ -22,6 +22,6 @@ Example: R8A7740 (R-Car A1) TPU controller node
tpu: pwm@e6600000 {
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
- reg = <0xe6600000 0x100>;
+ reg = <0xe6600000 0x148>;
#pwm-cells = <3>;
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: pwm: renesas-tpu: Correct SoC part numbers and family names
From: Geert Uytterhoeven @ 2017-12-19 16:02 UTC (permalink / raw)
To: Thierry Reding, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm
Cc: linux-pwm, devicetree, linux-renesas-soc, Geert Uytterhoeven
In-Reply-To: <1513699327-27357-1-git-send-email-geert+renesas@glider.be>
R8A73A4 (not R8A77A4) is R-Mobile APE6,
R8A7740 is R-Mobile (not R-Car) A1.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
index 641b5b4c648340ee..fb633129d845a893 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.txt
@@ -3,7 +3,7 @@
Required Properties:
- compatible: should be one of the following.
- - "renesas,tpu-r8a73a4": for R8A77A4 (R-Mobile APE6) compatible PWM controller.
+ - "renesas,tpu-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible PWM controller.
- "renesas,tpu-r8a7740": for R8A7740 (R-Mobile A1) compatible PWM controller.
- "renesas,tpu-r8a7790": for R8A7790 (R-Car H2) compatible PWM controller.
- "renesas,tpu": for generic R-Car TPU PWM controller.
@@ -18,7 +18,7 @@ Required Properties:
Please refer to pwm.txt in this directory for details of the common PWM bindings
used by client devices.
-Example: R8A7740 (R-Car A1) TPU controller node
+Example: R8A7740 (R-Mobile A1) TPU controller node
tpu: pwm@e6600000 {
compatible = "renesas,tpu-r8a7740", "renesas,tpu";
--
2.7.4
^ permalink raw reply related
* [PATCH] dt-bindings: gpio: rcar: Correct SoC family name for R8A7778
From: Geert Uytterhoeven @ 2017-12-19 16:03 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
R8A7778 is R-Car (not R-Mobile) M1.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
index a7ac460ad6572526..9474138d776ed58d 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -5,7 +5,7 @@ Required Properties:
- compatible: should contain one or more of the following:
- "renesas,gpio-r8a7743": for R8A7743 (RZ/G1M) compatible GPIO controller.
- "renesas,gpio-r8a7745": for R8A7745 (RZ/G1E) compatible GPIO controller.
- - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller.
+ - "renesas,gpio-r8a7778": for R8A7778 (R-Car M1) compatible GPIO controller.
- "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller.
- "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller.
- "renesas,gpio-r8a7791": for R8A7791 (R-Car M2-W) compatible GPIO controller.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Sakari Ailus @ 2017-12-19 16:04 UTC (permalink / raw)
To: Fabio Estevam
Cc: Philippe Ombredanne, Wenyou Yang, Mark Rutland, devicetree,
Jonathan Corbet, linux-kernel, Mauro Carvalho Chehab, Rob Herring,
Hans Verkuil, Songjun Wu, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <CAOMZO5DYWA8O5N=CRm2uR3_7qZ4U1M8u8F-oBU8bJfnKXD4DSA@mail.gmail.com>
On Tue, Dec 19, 2017 at 12:31:46PM -0200, Fabio Estevam wrote:
> On Tue, Dec 19, 2017 at 11:43 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
>
> > Both seem to exist. See e.g. c3a3d1d6b8b363a02234e5564692db3647f183e6 .
>
> This patch fixes .h files to use /* SPDX style comment, which is the
> recommendation.
>
> .c files should use // SPDX style.
Agreed. I reverted the changes.
Thanks.
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* [PATCH] dt-bindings: pinctrl: sh-pfc: Correct SoC family name for R8A7778
From: Geert Uytterhoeven @ 2017-12-19 16:04 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Mark Rutland
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
R8A7778 is R-Car (not R-Mobile) M1.
Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
index bb1790e0b17652e6..dd64dbb4cb0ea98f 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -15,7 +15,7 @@ Required Properties:
- "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller.
- "renesas,pfc-r8a7743": for R8A7743 (RZ/G1M) compatible pin-controller.
- "renesas,pfc-r8a7745": for R8A7745 (RZ/G1E) compatible pin-controller.
- - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller.
+ - "renesas,pfc-r8a7778": for R8A7778 (R-Car M1) compatible pin-controller.
- "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller.
- "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller.
- "renesas,pfc-r8a7791": for R8A7791 (R-Car M2-W) compatible pin-controller.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v8 2/3] dt-bindings: iio: temperature: add MLX90632 device bindings
From: Crt Mori @ 2017-12-19 16:06 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Crt Mori
Add device tree bindings for MLX90632 IR temperature sensor.
Signed-off-by: Crt Mori <cmo-fc6wVz46lShBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../bindings/iio/temperature/mlx90632.txt | 28 ++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
diff --git a/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
new file mode 100644
index 000000000000..0b05812001f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/temperature/mlx90632.txt
@@ -0,0 +1,28 @@
+* Melexis MLX90632 contactless Infra Red temperature sensor
+
+Link to datasheet: https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90632
+
+There are various applications for the Infra Red contactless temperature sensor
+and MLX90632 is most suitable for consumer applications where measured object
+temperature is in range between -20 to 200 degrees Celsius with relative error
+of measurement below 1 degree Celsius in object temperature range for
+industrial applications. Since it can operate and measure ambient temperature
+in range of -20 to 85 degrees Celsius it is suitable also for outdoor use.
+
+Be aware that electronics surrounding the sensor can increase ambient
+temperature. MLX90632 can be calibrated to reduce the housing effect via
+already existing EEPROM parameters.
+
+Since measured object emissivity effects Infra Red energy emitted, emissivity
+should be set before requesting the object temperature.
+
+Required properties:
+ - compatible: should be "melexis,mlx90632"
+ - reg: the I2C address of the sensor (default 0x3a)
+
+Example:
+
+mlx90632@3a {
+ compatible = "melexis,mlx90632";
+ reg = <0x3a>;
+};
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/2] eeprom: at24: write-protect pin support
From: Bartosz Golaszewski @ 2017-12-19 16:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Peter Rosin
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bartosz Golaszewski
AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).
On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.
This series adds support for the write-protect pin split into two
parts. The first patch extends the relevant binding document, while
the second modifies the at24 code to pull the write-protect GPIO
low (if present) during write operations.
Bartosz Golaszewski (2):
dt-bindings: at24: new optional property - write-protect-gpios
eeprom: at24: add support for the write-protect pin
Documentation/devicetree/bindings/eeprom/at24.txt | 4 ++++
drivers/misc/eeprom/at24.c | 12 ++++++++++++
2 files changed, 16 insertions(+)
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] dt-bindings: at24: new optional property - write-protect-gpios
From: Bartosz Golaszewski @ 2017-12-19 16:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Peter Rosin
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bartosz Golaszewski
In-Reply-To: <20171219161432.29809-1-brgl-ARrdPY/1zhM@public.gmane.org>
AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).
On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.
Add a new optional property to the device tree binding document, which
allows to specify the GPIO line to which the write-protect pin is
connected.
Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
---
Documentation/devicetree/bindings/eeprom/at24.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt b/Documentation/devicetree/bindings/eeprom/at24.txt
index a0415b8471bb..e489654c02ae 100644
--- a/Documentation/devicetree/bindings/eeprom/at24.txt
+++ b/Documentation/devicetree/bindings/eeprom/at24.txt
@@ -43,10 +43,14 @@ Optional properties:
eeprom does not automatically roll over reads to the next
slave address. Please consult the manual of your device.
+ - write-protect-gpios: GPIO to which the write-protect pin of the chip is
+ is connected.
+
Example:
eeprom@52 {
compatible = "atmel,24c32";
reg = <0x52>;
pagesize = <32>;
+ write-protect-gpios = <&gpio1 3 0>;
};
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] eeprom: at24: add support for the write-protect pin
From: Bartosz Golaszewski @ 2017-12-19 16:14 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Peter Rosin
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Bartosz Golaszewski
In-Reply-To: <20171219161432.29809-1-brgl-ARrdPY/1zhM@public.gmane.org>
AT24 EEPROMs have a write-protect pin, which - when pulled high -
inhibits writes to the upper quadrant of memory (although it has been
observed that on some chips it disables writing to the entire memory
range).
On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing. On linux this means that we either need to hog the line all
the time, or set the GPIO value before writing from outside of the
at24 driver.
Make the driver check if the write-protect GPIO was defined in the
device tree and pull it low whenever writing to the EEPROM.
Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
---
drivers/misc/eeprom/at24.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index b44a3d2b2b20..8cb0883dd297 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -27,6 +27,7 @@
#include <linux/regmap.h>
#include <linux/platform_data/at24.h>
#include <linux/pm_runtime.h>
+#include <linux/gpio/consumer.h>
/*
* I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
@@ -77,6 +78,8 @@ struct at24_data {
struct nvmem_config nvmem_config;
struct nvmem_device *nvmem;
+ struct gpio_desc *wp_gpio;
+
/*
* Some chips tie up multiple I2C addresses; dummy devices reserve
* them for us, and we'll use them with SMBus calls.
@@ -442,12 +445,14 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
* from this host, but not from other I2C masters.
*/
mutex_lock(&at24->lock);
+ gpiod_set_value_cansleep(at24->wp_gpio, 0);
while (count) {
int status;
status = at24_regmap_write(at24, buf, off, count);
if (status < 0) {
+ gpiod_set_value_cansleep(at24->wp_gpio, 1);
mutex_unlock(&at24->lock);
pm_runtime_put(dev);
return status;
@@ -457,6 +462,7 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
count -= status;
}
+ gpiod_set_value_cansleep(at24->wp_gpio, 1);
mutex_unlock(&at24->lock);
pm_runtime_put(dev);
@@ -604,6 +610,12 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
at24->num_addresses = num_addresses;
at24->offset_adj = at24_get_offset_adj(chip.flags, chip.byte_len);
+ at24->wp_gpio = devm_gpiod_get_optional(&client->dev,
+ "write-protect",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(at24->wp_gpio))
+ return PTR_ERR(at24->wp_gpio);
+
at24->client[0].client = client;
at24->client[0].regmap = devm_regmap_init_i2c(client, ®map_config);
if (IS_ERR(at24->client[0].regmap))
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/4] pci: dwc: pci-dra7xx: Enable errata i870 for both EP and RC mode
From: Lorenzo Pieralisi @ 2017-12-19 16:24 UTC (permalink / raw)
To: Vignesh R, Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, Tony Lindgren, Chris Welch,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171201061311.16691-2-vigneshr-l0cyMroinI0@public.gmane.org>
On Fri, Dec 01, 2017 at 11:43:08AM +0530, Vignesh R wrote:
> Errata i870 is applicable in both EP and RC mode. Therefore rename
> function dra7xx_pcie_ep_unaligned_memaccess(), that implements errata
> workaround, to dra7xx_pcie_unaligned_memaccess() and call it from a
> common place. So, that errata workaround is applied for both modes of
> operation.
>
> Reported-by: Chris Welch <Chris.Welch-ojoHHoaXhABCkLs28/y7ANBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Vignesh R <vigneshr-l0cyMroinI0@public.gmane.org>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
I need Kishon's ACK to apply it, thanks.
Lorenzo
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index e77a4ceed74c..53f721d1cc40 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -546,7 +546,7 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
> };
>
> /*
> - * dra7xx_pcie_ep_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
> + * dra7xx_pcie_unaligned_memaccess: workaround for AM572x/AM571x Errata i870
> * @dra7xx: the dra7xx device where the workaround should be applied
> *
> * Access to the PCIe slave port that are not 32-bit aligned will result
> @@ -556,7 +556,7 @@ static const struct of_device_id of_dra7xx_pcie_match[] = {
> *
> * To avoid this issue set PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE to 1.
> */
> -static int dra7xx_pcie_ep_unaligned_memaccess(struct device *dev)
> +static int dra7xx_pcie_unaligned_memaccess(struct device *dev)
> {
> int ret;
> struct device_node *np = dev->of_node;
> @@ -703,6 +703,10 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev)
> if (dra7xx->link_gen < 0 || dra7xx->link_gen > 2)
> dra7xx->link_gen = 2;
>
> + ret = dra7xx_pcie_unaligned_memaccess(dev);
> + if (ret)
> + goto err_gpio;
> +
> switch (mode) {
> case DW_PCIE_RC_TYPE:
> dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
> @@ -715,10 +719,6 @@ static int __init dra7xx_pcie_probe(struct platform_device *pdev)
> dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
> DEVICE_TYPE_EP);
>
> - ret = dra7xx_pcie_ep_unaligned_memaccess(dev);
> - if (ret)
> - goto err_gpio;
> -
> ret = dra7xx_add_pcie_ep(dra7xx, pdev);
> if (ret < 0)
> goto err_gpio;
> --
> 2.15.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Marc Zyngier @ 2017-12-19 16:36 UTC (permalink / raw)
To: Stefan Wahren, Thomas Gleixner, Jason Cooper, Eric Anholt,
Florian Fainelli, Scott Branden, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, phil-FnsA7b+Nu9XbIbC87yuRow,
Russell King, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d0c81267-8379-d4a1-ec56-fec3492c1df6-eS4NqCHxEME@public.gmane.org>
On 19/12/17 07:02, Stefan Wahren wrote:
> Hi Marc,
>
> Am 11.12.2017 um 21:39 schrieb Stefan Wahren:
>> This patch series implements DT polarity support for the 1st level interrupt
>> controller.
>>
>> Stefan Wahren (3):
>> dt-bindings: bcm2836-l1-intc: add interrupt polarity support
>> irqchip: irq-bcm2836: add support for DT interrupt polarity
>> ARM: dts: bcm283x: Define polarity of per-cpu interrupts
>>
>> .../interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 +-
>> arch/arm/boot/dts/bcm2836.dtsi | 14 +++----
>> arch/arm/boot/dts/bcm2837.dtsi | 12 +++---
>> arch/arm/boot/dts/bcm283x.dtsi | 1 +
>> drivers/irqchip/irq-bcm2836.c | 46 +++++++++++++---------
>> 5 files changed, 44 insertions(+), 33 deletions(-)
>>
>
> is this series okay?
Yes, it does look good. I'll queue that for 4.16.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 4/6] media: i2c: Add TDA1997x HDMI receiver driver
From: Tim Harvey @ 2017-12-19 17:01 UTC (permalink / raw)
To: Hans Verkuil
Cc: devicetree@vger.kernel.org, alsa-devel,
linux-kernel@vger.kernel.org, Hans Verkuil, Mauro Carvalho Chehab,
Philipp Zabel, Steve Longerbeam, Shawn Guo, linux-media
In-Reply-To: <3ae0ee4d-e754-1e97-33ed-d1fedf442dfb@xs4all.nl>
On Tue, Dec 19, 2017 at 3:12 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 16/12/17 19:00, Tim Harvey wrote:
>> +
>> +static int tda1997x_fill_format(struct tda1997x_state *state,
>> + struct v4l2_mbus_framefmt *format)
>> +{
>> + const struct v4l2_bt_timings *bt;
>> + struct v4l2_hdmi_colorimetry c;
>> +
>> + v4l_dbg(1, debug, state->client, "%s\n", __func__);
>> +
>> + if (!state->detected_timings)
>> + return -EINVAL;
>> + bt = &state->detected_timings->bt;
>> + memset(format, 0, sizeof(*format));
>> + c = v4l2_hdmi_rx_colorimetry(&state->avi_infoframe, NULL, bt->height);
>> + format->width = bt->width;
>> + format->height = bt->height;
>> + format->field = (bt->interlaced) ?
>> + V4L2_FIELD_ALTERNATE : V4L2_FIELD_NONE;
>> + format->colorspace = c.colorspace;
>> + format->ycbcr_enc = c.ycbcr_enc;
>> + format->quantization = c.quantization;
>> + format->xfer_func = c.xfer_func;
>
> This is wrong. v4l2_hdmi_rx_colorimetry returns what arrives on the HDMI link,
> that's not the same as is output towards the SoC. You need to take limited/full
> range conversions and 601/709 conversions into account since that's what ends
> up in memory.
>
> Also note: you are still parsing the colorimetry information from avi_infoframe
> in the infoframe parse function. There is no need to do that, just call
> v4l2_hdmi_rx_colorimetry and let that function parse and interpret all this.
>
> Otherwise we still have two places that try to interpret that information.
Hans,
Ok so v4l2_hdmi_rx_colorimetry() handles parsing the source avi
infoframe and deals with enforcing the detailed rules and returns
'v4l2' enums:
tda1997x_parse_infoframe(...)
...
case HDMI_INFOFRAME_TYPE_AVI:
state->avi_infoframe = frame.avi; /* hold on to avi
infoframe for later use in logging etc */
/* parse avi infoframe colorimetry data for v4l2
colorspace/ycbcr_encoding/quantization/xfer_func */
state->hdmi_colorimetry = v4l2_hdmi_rx_colorimetry(&frame.avi,
NULL,
state->timings.bt.height);
Also here I still need to override the quant range passed from the
source avi infoframe per the user control (if not auto) and set per
vic if default:
/* Quantization Range */
switch (state->rgb_quantization_range) {
case V4L2_DV_RGB_RANGE_AUTO:
state->range = frame.avi.quantization_range;
break;
case V4L2_DV_RGB_RANGE_LIMITED:
state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
break;
case V4L2_DV_RGB_RANGE_FULL:
state->range = HDMI_QUANTIZATION_RANGE_FULL;
break;
}
if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
if (frame.avi.video_code <= 1)
state->range = HDMI_QUANTIZATION_RANGE_FULL;
else
state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
}
Then tda1997x_fill_format() then needs to fill in details of what's on
the bus so I should be filling in only width/height/field/colorspace
and use colorspace based on my csc conversion chosen output
(V4L2_COLORSPACE_SRGB|V4L2_COLORSPACE_SMPTE170M|V4L2_COLORSPACE_REC709)
and I don't need to set ycbcr_enc/quantization/xfer_func.
does this sound right?
Thanks,
Tim
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Fabio Estevam @ 2017-12-19 17:03 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Christoph Fritz, Rob Herring,
Christian Hemp, Stefan Christ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513698588-13325-2-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Tue, Dec 19, 2017 at 1:49 PM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> +
> +/ {
> + model = "PHYTEC phyCORE-i.MX 6";
> + compatible = "phytec,imx6qdl-pcm058", "fsl,imx6qdl";
> +
> + aliases {
> + ipu0 = &ipu1;
Is this alias needed?
> + rtc1 = &da9062_rtc;
> + rtc2 = &snvs_rtc;
> + };
> +
> + /*
> + * Set the minimum memory size here and
> + * let the bootloader set the real size.
> + */
> + memory {
memory@10000000 so that you don't get warnings when building with W=1.
Also, please build W=1 and make sure to not introduce any build
warning in this series.
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c3>;
> + clock-frequency = <400000>;
> + status = "okay";
> +
> + eeprom: eeprom@50 {
> + compatible = "cat,24c32";
This compatible is not documented.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/6] ARM: dts: imx6: Add initial support for phyBOARD-Mira
From: Fabio Estevam @ 2017-12-19 17:10 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Christoph Fritz, Rob Herring,
Christian Hemp, Stefan Christ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513698588-13325-3-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Tue, Dec 19, 2017 at 1:49 PM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> + reg_pcie: regulator-pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie_reg>;
> + compatible = "regulator-fixed";
> + regulator-name = "mPCIe_1V5";
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + gpio = <&gpio3 0 GPIO_ACTIVE_HIGH>;
> + regulator-always-on;
Instead of using 'regulator-always-on' here, you could use:
vpcie-supply = <®_pcie>;
under the &pcie node
> + panel {
> + compatible = "auo,g104sn02";
I could not find this compatible in linux-next.
> + i2c_rtc: rtc@68 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rtc_int>;
> + compatible = "mc,rv4162";
I could not find this compatible in linux-next.
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie>;
> + reset-gpio = <&gpio2 25 GPIO_ACTIVE_HIGH>;
The imx driver ignores the polarity and it is active high only when
'reset-gpio-active-high' property is present.
The correct here would be: reset-gpio = <&gpio2 25 GPIO_ACTIVE_LOW>;
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3>;
> + fsl,uart-has-rtscts;
uart-has-rtscts, please.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] phylib: Add device reset delay support
From: Rob Herring @ 2017-12-19 17:12 UTC (permalink / raw)
To: Richard Leitner
Cc: Richard Leitner, Mark Rutland, Fugang Duan, Andrew Lunn,
Florian Fainelli, Frank Rowand, David Miller, Geert Uytterhoeven,
Sergei Shtylyov, Baruch Siach, David Wu, Lukasz Majewski, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1b230e6b-8e8c-28a4-7524-6ce60aa71591-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 18, 2017 at 1:30 AM, Richard Leitner
<richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org> wrote:
> Hi Rob,
>
> On 12/15/2017 11:17 PM, Rob Herring wrote:
>> On Mon, Dec 11, 2017 at 01:16:57PM +0100, Richard Leitner wrote:
>>> From: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>>>
>>> Some PHYs need a minimum time after the reset gpio was asserted and/or
>>> deasserted. To ensure we meet these timing requirements add two new
>>> optional devicetree parameters for the phy: reset-delay-us and
>>> reset-post-delay-us.
>>>
>>> Signed-off-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@public.gmane.org>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++++
>>> drivers/net/phy/mdio_device.c | 13 +++++++++++--
>>> drivers/of/of_mdio.c | 4 ++++
>>> include/linux/mdio.h | 2 ++
>>> 4 files changed, 27 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
>>> index c05479f5ac7c..72860ce7f610 100644
>>> --- a/Documentation/devicetree/bindings/net/phy.txt
>>> +++ b/Documentation/devicetree/bindings/net/phy.txt
>>> @@ -55,6 +55,12 @@ Optional Properties:
>>>
>>> - reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
>>>
>>> +- reset-delay-us: Delay after the reset was asserted in microseconds.
>>> + If this property is missing the delay will be skipped.
>>> +
>>> +- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
>>> + If this property is missing the delay will be skipped.
>>
>> I think these names could be clearer as to exactly what they mean.
>> Looking at existing properties with "reset-delay" there's a mixture of
>> definitions whether it is the assert time or the time after deassert.
>>
>> So I'd call these "reset-assert-us" and "reset-deassert-us".
>
> Ok, that would be fine with me, but are you sure that we should omit the
> "-delay" term completely?
These are just minimum assertion and deassertion times. I think that's
clear enough.
> What would be the best approach to post this change (as the patchset was
> already merged to net-next)? A separate patch or a v6 of the complete
> patchset?
A patch on top of this.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] ARM: dts: imx6: Add support for phyBOARD-Mira i.MX 6Quad/Dual RDK
From: Fabio Estevam @ 2017-12-19 17:12 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Christian Hemp,
Stefan Christ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513698588-13325-4-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Tue, Dec 19, 2017 at 1:49 PM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> +/ {
> + model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with eMMC";
> + compatible = "phytec,imx6q-pbac06-emmc", "phytec,imx6q-pbac06",
> + "phytec,imx6qdl-pcm058", "fsl,imx6q";
> +
> + aliases {
> + ipu1 = &ipu2;
> + };
This alias is not needed as it is part of imx6q.dtsi.
> +/ {
> + model = "PHYTEC phyBOARD-Mira Quad Carrier-Board with NAND";
> + compatible = "phytec,imx6q-pbac06-nand", "phytec,imx6q-pbac06",
> + "phytec,imx6qdl-pcm058", "fsl,imx6q";
> +
> + aliases {
> + ipu1 = &ipu2;
> + };
Ditto.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/6] ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Fabio Estevam @ 2017-12-19 17:14 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Christian Hemp,
Stefan Christ, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513698588-13325-5-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Tue, Dec 19, 2017 at 1:49 PM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> From: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
>
> Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
> with i.MX 6DualLight/Solo with NAND.
>
> Following interfaces are supported:
> - 100 MBit Ethernet
> - USB Host
> - RS232
> - HDMI
>
> Signed-off-by: Christian Hemp <c.hemp-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Christ <s.christ-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 5/6] ARM: dts: imx6: Add support for phyBOARD-Mira with i.MX 6QuadPlus
From: Fabio Estevam @ 2017-12-19 17:15 UTC (permalink / raw)
To: Stefan Riedmueller
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Enrico Scholz, Stefan Lengfeld,
Rob Herring, Christian Hemp,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513698588-13325-6-git-send-email-s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
On Tue, Dec 19, 2017 at 1:49 PM, Stefan Riedmueller
<s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> wrote:
> +/ {
> + model = "PHYTEC phyBOARD-Mira QuadPlus Carrier-Board with NAND";
> + compatible = "phytec,imx6qp-pbac06-nand", "phytec,imx6qp-pbac06",
> + "phytec,imx6qdl-pcm058", "fsl,imx6qp";
> +
> + aliases {
> + ipu1 = &ipu2;
> + };
Same comment as previous patch. You can drop this alias.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox