* Re: [PATCH 1/4] input: misc: introduce Atmel PTC driver
From: Alexandre Belloni @ 2017-04-03 15:58 UTC (permalink / raw)
To: Ludovic Desroches
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ludovic Desroches
In-Reply-To: <20170331152250.12758-2-ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
On 31/03/2017 at 17:22:47 +0200, Ludovic Desroches wrote:
> From: Ludovic Desroches <ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
I think you probably want to switch to your microchip email.
Also, this requires a proper commit message.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> +struct atmel_ptc {
> + void __iomem *ppp_regs;
> + void __iomem *firmware;
> + int irq;
> + uint8_t imr;
> + volatile struct atmel_qtm_mailbox __iomem *qtm_mb;
> + struct clk *clk_per;
> + struct clk *clk_int_osc;
> + struct clk *clk_slow;
> + struct device *dev;
> + struct completion ppp_ack;
> + unsigned int button_keycode[ATMEL_PTC_MAX_NODES];
> + struct input_dev *buttons_input;
> + struct input_dev *scroller_input[ATMEL_PTC_MAX_SCROLLERS];
> + bool buttons_registered;
> + bool scroller_registered[ATMEL_PTC_MAX_SCROLLERS];
> + uint32_t button_event[ATMEL_PTC_MAX_NODES/32];
> + uint32_t button_state[ATMEL_PTC_MAX_NODES/32];
> + uint32_t scroller_event;
> + uint32_t scroller_state;
You should use u8, u16 and u32 instead of uint8_t, uint16_t and
uint32_t.
> diff --git a/include/uapi/linux/atmel_ptc.h b/include/uapi/linux/atmel_ptc.h
> new file mode 100644
> index 0000000..d15c4df
> --- /dev/null
> +++ b/include/uapi/linux/atmel_ptc.h
Is there any sample application showing how to configure the PTC?
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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: [PATCHv4 25/29] drm/omap: displays: panel-dpi: Support for handling backlight devices
From: Rob Herring @ 2017-04-03 15:58 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart,
Jyri Sarha, Peter Ujfalusi, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490872529-23084-26-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
On Thu, Mar 30, 2017 at 02:15:25PM +0300, Tomi Valkeinen wrote:
> From: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
>
> The associated backlight device can be configured via DT by providing the
> phandle to the device.
>
> If the backlight device is configured, the driver can manage the backligt
> along with the panel's power state, iow it can turn on the backlight when
> the panel is enabled and turn it off when the panel is disabled.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> .../bindings/display/panel/panel-dpi.txt | 3 ++
> drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 37 ++++++++++++++++++++--
> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> index d4add13e592d..6b203bc4d932 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> @@ -9,6 +9,7 @@ Optional properties:
> - enable-gpios: panel enable gpio
> - reset-gpios: GPIO to control the RESET pin
> - vcc-supply: phandle of regulator that will be used to enable power to the display
> +- backlight: phandle of the backlight device
Any panel can have a backlight, so please add to panel/panel.txt
instead.
>
> Required nodes:
> - "panel-timing" containing video timings
> @@ -22,6 +23,8 @@ lcd0: display@0 {
> compatible = "samsung,lte430wq-f0c", "panel-dpi";
> label = "lcd";
>
> + backlight = <&backlight>;
> +
> port {
> lcd_in: endpoint {
> remote-endpoint = <&dpi_out>;
--
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 V7 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-04-03 15:56 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20170403143049.qyi4dagwi4cdenok@dell>
On 03 April 2017 15:31, Lee Jones wrote:
> Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
>
> On Mon, 03 Apr 2017, Steve Twiss wrote:
> > On 03 April 2017 15:12, Lee Jones wrote:
> >
> > > > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> > > > + switch (chip->chip_type) {
> > > > + case(COMPAT_TYPE_DA9061):
> > >
> > > Brackets around the case value?
> > >
> > > That's a new one on me.
> >
> > Hm. Do you want me to resend it without braces?
>
> Yes please. And a space after the 'case'.
Hi Lee,
I have resent PATCH V7 to change "case(X):" to be "case X:".
- Removed brackets surrounding case statements for
case COMPAT_TYPE_DA9061:
case COMPAT_TYPE_DA9062:
New patch is here:
https://lkml.org/lkml/2017/4/3/462
The patch it is called by the same title "[PATCH V7 4/7] mfd: da9061: MFD core support".
I've not updated the whole patch-set or changed the patch version number from V7.
Regards,
Steve
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Add documentation for GP10B GPU
From: Rob Herring @ 2017-04-03 15:55 UTC (permalink / raw)
To: Alexandre Courbot
Cc: Thierry Reding, Jonathan Hunter, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, gnurou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170330092644.11890-1-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Mar 30, 2017 at 06:26:44PM +0900, Alexandre Courbot wrote:
> GP10B's definition is mostly similar to GK20A's and GM20B's. The only
> noticeable difference is the use of power domains instead of a regulator
> for power supply.
>
> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> Changes since v1:
> - It's much better when it compiles.
>
> .../devicetree/bindings/gpu/nvidia,gk20a.txt | 25 +++++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* [PATCH] of: irq: Export of_irq_count()
From: Thierry Reding @ 2017-04-03 15:55 UTC (permalink / raw)
To: Rob Herring
Cc: Frank Rowand, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
of_irq_count() is handy for obtaining the number of interrupts assigned
to a device tree node. It is reasonable to want to access this function
from loadable modules, so export the symbol to allow that.
Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Hi Rob, Frank,
This patch is required for the new Tegra186 GPIO driver I'm trying to
get merged for v4.12. It'd be great if I could get an Acked-by from you
so that the patch can be merged through the GPIO tree along with a few
other prerequisites for the new driver.
Potential for conflicts is rather minimal given the line count.
Thanks,
Thierry
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 7c56b72d1dc6..3deaada2ff29 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -458,6 +458,7 @@ int of_irq_count(struct device_node *dev)
return nr;
}
+EXPORT_SYMBOL_GPL(of_irq_count);
/**
* of_irq_to_resource_table - Fill in resource table with node's IRQ info
--
2.12.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
* Re: [PATCH 1/5 v3] iio: xoadc: augment DT bindings a bit
From: Rob Herring @ 2017-04-03 15:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330080541.4065-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Mar 30, 2017 at 10:05:41AM +0200, Linus Walleij wrote:
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be fine to augment
> them before we actually start using it in drivers and device trees.
>
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v2->v3:
> - Drop leading zeroes on unit addresses.
> ChangeLog v1->v2:
> - Name nodes with <01 02> in a foo@0102 pattern.
> - Minor spelling nits.
> - Delete flimsy leftover docs from an interrim development path.
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 76 ++++++++++++----------
> 1 file changed, 42 insertions(+), 34 deletions(-)
Other than the few typos mentioned,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] Input: silead - list all supported compatible strings in binding document
From: Javier Martinez Canillas @ 2017-04-03 15:51 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, devicetree, Robert Dolca, Hans de Goede,
Dmitry Torokhov, linux-input, Mark Rutland
In-Reply-To: <20170403152543.im7tbkhfc3lj7lyt@rob-hp-laptop>
Hello Rob,
On 04/03/2017 11:25 AM, Rob Herring wrote:
> On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote:
>> The driver contains compatible strings for different models, but the DT
>> binding doc only lists one of them. Add the remaining to the document.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> .../devicetree/bindings/input/touchscreen/silead_gsl1680.txt | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> "dt-bindings: input: ..." is preferred for the subject, but no need to
> respin just for that.
>
Can we document it in Documentation/devicetree/bindings/submitting-patches.txt?
I'm asking because is true that at the beginning we used "dt-bindings: foo" for
all DT bindings patches but then many (most?) maintainers started asking for the
subsystem subject line to be used for both drivers and DT bindings docs since
they would be merging both and also they could miss the DT bindings patches if
their subsystem prefix was not used.
> Acked-by: Rob Herring <robh@kernel.org>
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH V5 2/2] thermal: broadcom: add Northstar thermal driver
From: Rafał Miłecki @ 2017-04-03 15:48 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin
Cc: Rob Herring, Mark Rutland, Stephen Warren, Lee Jones, Eric Anholt,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, linux-pm, devicetree, linux-rpi-kernel,
linux-arm-kernel, Rafał Miłecki, Jon Mason
In-Reply-To: <20170403154829.29780-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Northstar is a SoC family commonly used in home routers. This commit
adds a driver for checking CPU temperature. As Northstar Plus seems to
also have this IP block this new symbol gets ARCH_BCM_IPROC dependency.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
V2: Make it iProc specific as NSP can also use this driver
Select proper symbols in config ARCH_BCM_IPROC
Define PVTMON register bits
Update code selecting temperature monitor mode
Thank you Jon!
V3: More details in help message for BCM_NS_THERMAL
Use slope & offset
Drop arch code change (I'll be submitted using a proper tree)
Thank you Eduardo!
V4: Comment operations on PVTMON_CONTROL0 register
---
drivers/thermal/Kconfig | 5 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/broadcom/Kconfig | 8 +++
drivers/thermal/broadcom/Makefile | 1 +
drivers/thermal/broadcom/ns-thermal.c | 105 ++++++++++++++++++++++++++++++++++
5 files changed, 120 insertions(+)
create mode 100644 drivers/thermal/broadcom/Kconfig
create mode 100644 drivers/thermal/broadcom/Makefile
create mode 100644 drivers/thermal/broadcom/ns-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 3bd24063375e..ac7301703d03 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -392,6 +392,11 @@ config MTK_THERMAL
Enable this option if you want to have support for thermal management
controller present in Mediatek SoCs
+menu "Broadcom thermal drivers"
+depends on ARCH_BCM || COMPILE_TEST
+source "drivers/thermal/broadcom/Kconfig"
+endmenu
+
menu "Texas Instruments thermal drivers"
depends on ARCH_HAS_BANDGAP || COMPILE_TEST
depends on HAS_IOMEM
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index f23cde05dac6..6b7706b9f27c 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -27,6 +27,7 @@ thermal_sys-$(CONFIG_CLOCK_THERMAL) += clock_cooling.o
thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
# platform thermal drivers
+obj-y += broadcom/
obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
new file mode 100644
index 000000000000..f0dea8a8e002
--- /dev/null
+++ b/drivers/thermal/broadcom/Kconfig
@@ -0,0 +1,8 @@
+config BCM_NS_THERMAL
+ tristate "Northstar thermal driver"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ help
+ Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
+ BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
+ with a thermal sensor that allows checking CPU temperature. This
+ driver provides support for it.
diff --git a/drivers/thermal/broadcom/Makefile b/drivers/thermal/broadcom/Makefile
new file mode 100644
index 000000000000..059df9a0ed69
--- /dev/null
+++ b/drivers/thermal/broadcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
diff --git a/drivers/thermal/broadcom/ns-thermal.c b/drivers/thermal/broadcom/ns-thermal.c
new file mode 100644
index 000000000000..eab96b3572b9
--- /dev/null
+++ b/drivers/thermal/broadcom/ns-thermal.c
@@ -0,0 +1,105 @@
+/*
+ * Copyright (C) 2017 Rafał Miłecki <rafal@milecki.pl>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/thermal.h>
+
+#define PVTMON_CONTROL0 0x00
+#define PVTMON_CONTROL0_SEL_MASK 0x0000000e
+#define PVTMON_CONTROL0_SEL_TEMP_MONITOR 0x00000000
+#define PVTMON_CONTROL0_SEL_TEST_MODE 0x0000000e
+#define PVTMON_STATUS 0x08
+
+struct ns_thermal {
+ struct thermal_zone_device *tz;
+ void __iomem *pvtmon;
+};
+
+static int ns_thermal_get_temp(void *data, int *temp)
+{
+ struct ns_thermal *ns_thermal = data;
+ int offset = thermal_zone_get_offset(ns_thermal->tz);
+ int slope = thermal_zone_get_slope(ns_thermal->tz);
+ u32 val;
+
+ val = readl(ns_thermal->pvtmon + PVTMON_CONTROL0);
+ if ((val & PVTMON_CONTROL0_SEL_MASK) != PVTMON_CONTROL0_SEL_TEMP_MONITOR) {
+ /* Clear current mode selection */
+ val &= ~PVTMON_CONTROL0_SEL_MASK;
+
+ /* Set temp monitor mode (it's the default actually) */
+ val |= PVTMON_CONTROL0_SEL_TEMP_MONITOR;
+
+ writel(val, ns_thermal->pvtmon + PVTMON_CONTROL0);
+ }
+
+ val = readl(ns_thermal->pvtmon + PVTMON_STATUS);
+ *temp = slope * val + offset;
+
+ return 0;
+}
+
+const struct thermal_zone_of_device_ops ns_thermal_ops = {
+ .get_temp = ns_thermal_get_temp,
+};
+
+static int ns_thermal_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ns_thermal *ns_thermal;
+
+ ns_thermal = devm_kzalloc(dev, sizeof(*ns_thermal), GFP_KERNEL);
+ if (!ns_thermal)
+ return -ENOMEM;
+
+ ns_thermal->pvtmon = of_iomap(dev_of_node(dev), 0);
+ if (WARN_ON(!ns_thermal->pvtmon))
+ return -ENOENT;
+
+ ns_thermal->tz = devm_thermal_zone_of_sensor_register(dev, 0,
+ ns_thermal,
+ &ns_thermal_ops);
+ if (IS_ERR(ns_thermal->tz)) {
+ iounmap(ns_thermal->pvtmon);
+ return PTR_ERR(ns_thermal->tz);
+ }
+
+ platform_set_drvdata(pdev, ns_thermal);
+
+ return 0;
+}
+
+static int ns_thermal_remove(struct platform_device *pdev)
+{
+ struct ns_thermal *ns_thermal = platform_get_drvdata(pdev);
+
+ iounmap(ns_thermal->pvtmon);
+
+ return 0;
+}
+
+static const struct of_device_id ns_thermal_of_match[] = {
+ { .compatible = "brcm,ns-thermal", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ns_thermal_of_match);
+
+static struct platform_driver ns_thermal_driver = {
+ .probe = ns_thermal_probe,
+ .remove = ns_thermal_remove,
+ .driver = {
+ .name = "ns-thermal",
+ .of_match_table = ns_thermal_of_match,
+ },
+};
+module_platform_driver(ns_thermal_driver);
+
+MODULE_DESCRIPTION("Northstar thermal driver");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH V5 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Rafał Miłecki @ 2017-04-03 15:48 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin
Cc: Rob Herring, Mark Rutland, Stephen Warren, Lee Jones, Eric Anholt,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rafał Miłecki
In-Reply-To: <20170331201124.656-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This commit documents binding for thermal used in Northstar family SoCs.
There isn't any known Northstar device with active cooling system so DT
example has empty cooling-maps node. There is also no support for CPU
frequency throttling so I put only a critical trip in the example.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V3: Add thermal-zones to the example
V5: Extend example by including trips and cooling-maps. Update commit message
---
.../devicetree/bindings/thermal/brcm,ns-thermal | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/brcm,ns-thermal
diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
new file mode 100644
index 000000000000..68e047170039
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
@@ -0,0 +1,37 @@
+* Broadcom Northstar Thermal
+
+This binding describes thermal sensor that is part of Northstar's DMU (Device
+Management Unit).
+
+Required properties:
+- compatible : Must be "brcm,ns-thermal"
+- reg : iomem address range of PVTMON registers
+- #thermal-sensor-cells : Should be <0>
+
+Example:
+
+thermal: thermal@1800c2c0 {
+ compatible = "brcm,ns-thermal";
+ reg = <0x1800c2c0 0x10>;
+ #thermal-sensor-cells = <0>;
+};
+
+thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <1000>;
+ coefficients = <(-556) 418000>;
+ thermal-sensors = <&thermal>;
+
+ trips {
+ cpu-crit {
+ temperature = <125000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ };
+ };
+};
--
2.11.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
* Re: [PATCH v3 5/7] mfd: Add Device Tree bindings document for TI tps6105x chip
From: Javier Martinez Canillas @ 2017-04-03 15:47 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, devicetree, Rob Herring, Mark Rutland
In-Reply-To: <20170403111540.7k3rjucvcxe5cunf@dell>
Hello Lee,
On 04/03/2017 07:15 AM, Lee Jones wrote:
[snip]
>> +
>> +The TP61050/TPS61052 is a high-power "white LED driver". This boost converter
>> +is also used for other things than white LEDs, and also contains a GPIO pin.
>
> What functions does it offer?
>
Same comment than before, I'm not really familiar with this driver. But I'll
look what are the MFD cell instantiated to better understand dev functions
and expand this documentation accordingly.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 16/37] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Rob Herring @ 2017-04-03 15:46 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Mark Rutland, Boris Brezillon, Richard Weinberger, Marek Vasut,
Artem Bityutskiy, Cyrille Pitchen, linux-kernel, Dinh Nguyen,
devicetree, linux-mtd, Masami Hiramatsu, Chuanxiao Dong,
Jassi Brar, Brian Norris, Enrico Jorns, David Woodhouse,
Graham Moore
In-Reply-To: <1490856383-31560-17-git-send-email-yamada.masahiro@socionext.com>
On Thu, Mar 30, 2017 at 03:46:02PM +0900, Masahiro Yamada wrote:
> Add two compatible strings for UniPhier SoCs.
>
> "socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4,
> Pro4, sLD8 SoCs.
>
> "socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2,
> LD6b, LD11, LD20 SoCs.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Changes in v3: None
> Changes in v2:
> - Change the compatible strings
> - Fix the ecc_strength_capability
> - Override revision number for the newer one
>
> .../devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
> drivers/mtd/nand/denali_dt.c | 23 ++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-03 15:45 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, devicetree, Rob Herring
In-Reply-To: <20170403111502.lotjpd746vkhekkg@dell>
Hello Lee,
On 04/03/2017 07:15 AM, Lee Jones wrote:
[snip]
>>
>> +static const struct of_device_id retu_of_match[] = {
>> + { .compatible = "nokia,retu-mfd" },
>> + { .compatible = "nokia,tahvo-mfd" },
>
> Please drop the "-mfd".
>
Yes, I also didn't like it but I didn't want to change it since that would
mean that backward compatiblity and bisect-ability will be broken by this
change.
In other words, just adding a vendor prefix won't cause an issue if patches
are merged independently since if DTS patches are merged before, the driver
will still lookup using the I2C device ID table. And if the drivers patches
are picked before, the DTS will match using the OF device ID table.
But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
pick all patches and also that the DTS and drivers changes will have to be
done in the same patch. If you are OK with that, then I can change in the
next version.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 0/4] tty/serial: meson_uart: add support for core clock handling
From: Kevin Hilman @ 2017-04-03 15:44 UTC (permalink / raw)
To: Helmut Klein
Cc: devicetree, linux-kernel, linux-serial, linux-amlogic, linux-clk,
linux-arm-kernel
In-Reply-To: <20170331165437.26227-1-hgkr.klein@gmail.com>
Helmut Klein <hgkr.klein@gmail.com> writes:
> To be able to use the three none AO uarts of the meson gx SoCs (uart_A,
s/none/non/
> uart_B & uart_C), the core clock has to be enabled (see chapter 22.3 of
> the public s905 data sheet).
> At least the u-boot of my s905 based media player (netxeon minimx-g)
> doesn't do this. so the driver must enable the clock.
FYI: even if a booloader enablesq clocks, it's important that the kernel
enable clocks that it uses so the kernel can be independent of any
bootloader.
> This patch set does:
> - exposes the UART clock ids to the dtb
> - adds documentation for the dt-bindings of meson_uart
> - adds the core clock handling to the driver
> - adds the core clock handling to meson-gxbb.dtsi and meson-gxl.dtsi
>
> The patchset is based on the branch "master" of the repository in [1]
The master branch in my tree just tracks mainline master branch.
To avoid conflicts with other on-going DT changes, the DT patches should
probably be based on top of my v4.12/dt64 branch.
Kevin
^ permalink raw reply
* Re: [RFC PATCH 4/5] dt-bindings: soc/fsl: Update reserved memory binding for QBMan
From: Rob Herring @ 2017-04-03 15:42 UTC (permalink / raw)
To: Roy Pledge
Cc: devicetree, madalin.bucur, robin.murphy, oss, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1490822037-6752-5-git-send-email-roy.pledge@nxp.com>
On Wed, Mar 29, 2017 at 05:13:56PM -0400, Roy Pledge wrote:
> Updates the QMan and BMan device tree bindings for reserved memory
> nodes. This makes the reserved memory allocation compatiable with
s/compatiable/compatible/
> the shared-dma-pool usage.
This change is not backwards compatible. Please state that and explain
why that is okay. If PPC needs to not change, then the old strings and
properties should remain, but deprecated.
>
> Signed-off-by: Roy Pledge <roy.pledge@nxp.com>
> ---
> Documentation/devicetree/bindings/soc/fsl/bman.txt | 10 +++++-----
> Documentation/devicetree/bindings/soc/fsl/qman.txt | 16 +++++++++-------
> 2 files changed, 14 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/7] mfd: Add Device Tree bindings document for retu/tahvo ASIC chips
From: Javier Martinez Canillas @ 2017-04-03 15:40 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-kernel, devicetree, Rob Herring, Mark Rutland
In-Reply-To: <20170403111301.52hm4wsplimviqso@dell>
Hello Lee,
Thanks a lot for your feedback.
On 04/03/2017 07:13 AM, Lee Jones wrote:
> On Sat, 01 Apr 2017, Javier Martinez Canillas wrote:
>
>> There are Device Tree source files defining a device node for the
>> retu/tahvo I2C chip, but there isn't a DT binding document for it.
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> Documentation/devicetree/bindings/mfd/retu.txt | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/retu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/retu.txt b/Documentation/devicetree/bindings/mfd/retu.txt
>> new file mode 100644
>> index 000000000000..2309e599a731
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/retu.txt
>> @@ -0,0 +1,19 @@
>> +* Device tree bindings for Nokia Retu and Tahvo multi-function device
>> +
>> +Retu and Tahvo are a multi-function devices found on Nokia Internet
>> +Tablets (770, N800 and N810).
>
> More information please. What functions to they serve?
>
I'm not really familiar with these drivers, I'm just doing this as a part
of the bigger work to fix the I2C core to report a proper OF modaliases.
So I took the information I could find in the driver Kconfig and headers,
but I'll see if I can find more information in the driver or if there is
documentation about these online.
>> +Required properties:
>> +- compatible: "nokia,retu-mfd" or "nokia,tahvo-mfd"
>> +- reg: Specifies the I2C slave address of the ASIC chip
>> +
>> +Example:
>> +
>> +i2c0 {
>> + retu_mfd: retu@1 {
>
> Please avoid the term MFD at all times when using Device Tree. DT is
> meant to be OS agnostic and MFD is a Linuxisum.
>
Yes, sorry. I just copied the DT snippet from a DTS that used this, I'll
remove it on the next version.
>> + compatible = "nokia,retu-mfd";
>> + interrupt-parent = <&gpio4>;
>> + interrupts = <12 IRQ_TYPE_EDGE_RISING>;
>> + reg = <0x1>;
>> + };
>> +};
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
From: Rob Herring @ 2017-04-03 15:33 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170329194613.55548-2-icenowy-h8G6r0blFSE@public.gmane.org>
On Thu, Mar 30, 2017 at 03:46:03AM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Allwinner "Display Engine 2.0" contains some clock controls in it.
>
> In order to add them as clock drivers, we need a device tree binding.
> Add the binding here.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Changes in v3:
> - Fill the address space length of DE2 CCU to 0x100000, just reach the start of mixer0.
Why? You waste virtual memory space making this bigger than it needs to
be. Not an issue so much for 64-bit.
>
> .../devicetree/bindings/clock/sun8i-de2.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/sun8i-de2.txt b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
> new file mode 100644
> index 000000000000..34cf79c05f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/sun8i-de2.txt
> @@ -0,0 +1,31 @@
> +Allwinner Display Engine 2.0 Clock Control Binding
> +--------------------------------------------------
> +
> +Required properties :
> +- compatible: must contain one of the following compatibles:
> + - "allwinner,sun8i-a83t-de2-clk"
> + - "allwinner,sun50i-a64-de2-clk"
> + - "allwinner,sun50i-h5-de2-clk"
> +
> +- reg: Must contain the registers base address and length
> +- clocks: phandle to the clocks feeding the display engine subsystem.
> + Three are needed:
> + - "mod": the display engine module clock
> + - "bus": the bus clock for the whole display engine subsystem
> +- clock-names: Must contain the clock names described just above
> +- resets: phandle to the reset control for the display engine subsystem.
> +- #clock-cells : must contain 1
> +- #reset-cells : must contain 1
> +
> +Example:
> +de2_clocks: clock@01000000 {
Drop the leading 0s. dtc in linux-next will now warn on this with W=1
compile. Looks like sunxi has a lot of them. Please fix so we don't keep
repeating this same copy-n-paste.
> + compatible = "allwinner,sun50i-a64-de2-clk";
> + reg = <0x01000000 0x100000>;
> + clocks = <&ccu CLK_DE>,
> + <&ccu CLK_BUS_DE>;
> + clock-names = "mod",
> + "bus";
> + resets = <&ccu RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> +};
> --
> 2.12.0
>
^ permalink raw reply
* Re: [PATCH] Input: silead - list all supported compatible strings in binding document
From: Rob Herring @ 2017-04-03 15:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Dolca, Hans de Goede,
Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170329182531.17349-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote:
> The driver contains compatible strings for different models, but the DT
> binding doc only lists one of them. Add the remaining to the document.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> .../devicetree/bindings/input/touchscreen/silead_gsl1680.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
"dt-bindings: input: ..." is preferred for the subject, but no need to
respin just for that.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v4 12/23] drivers/fsi: Add documentation for GPIO bindings
From: Rob Herring @ 2017-04-03 15:24 UTC (permalink / raw)
To: Christopher Bostic
Cc: mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
joel-U3u1mxZcP9KHXe+LvDLADg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-zrmu5oMJ5Fs, alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <20170329174340.89109-13-cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 29, 2017 at 12:43:29PM -0500, Christopher Bostic wrote:
> From: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>
> Add fsi master gpio device tree binding documentation
>
> Signed-off-by: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> .../devicetree/bindings/fsi/fsi-master-gpio.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
But what happened to the bus description? There's never a need to
describe slave devices (even discoverable buses like USB and PCI still
need them sometimes)? As it stands now, I have no idea what FSI is from
reading bindings/fsi/*.
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 v3 2/7] dt-bindings: rtc: document the rtc-sh bindings
From: Rob Herring @ 2017-04-03 15:16 UTC (permalink / raw)
To: Chris Brandt
Cc: Alessandro Zummo, Alexandre Belloni, Mark Rutland, Simon Horman,
Geert Uytterhoeven, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170329173035.67477-3-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Mar 29, 2017 at 10:30:30AM -0700, Chris Brandt wrote:
> Add the binding documentation for rtc-sh which is an RTC for
> SuperH and RZ/A SoCs.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> v3:
> * remove 'power-domains' from example
> * update commit message subject and body
> v2:
> * added interrupt-names and clock-names
> * clocks now include counting sources
> * changed 'is a RTC' to 'is an RTC' in commit message
> ---
> Documentation/devicetree/bindings/rtc/rtc-sh.txt | 28 ++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-sh.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 1/2] power: supply: ltc2941-battery-gauge: Add vendor to compatibles in binding
From: Rob Herring @ 2017-04-03 15:15 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel
In-Reply-To: <20170329160057.8298-1-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On Wed, Mar 29, 2017 at 12:00:56PM -0400, Javier Martinez Canillas wrote:
> The DT binding document for LTC2941 and LTC2943 battery gauges did not use
> a vendor prefix in the listed compatible strings. The driver says that the
> manufacturer is Linear Technology which is "lltc" in vendor-prefixes.txt.
>
> There isn't an upstream Device Tree source file that has nodes defined for
> these devices, so there's no need to keep the old compatible strings.
>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/power/supply/ltc2941.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Russell King - ARM Linux @ 2017-04-03 15:15 UTC (permalink / raw)
To: Rob Herring
Cc: Steve Longerbeam, Steve Longerbeam, Mark Rutland, Shawn Guo,
kernel@pengutronix.de, Fabio Estevam, Mauro Carvalho Chehab,
Hans Verkuil, Nick Dyer, markus.heiser, Philipp Zabel,
Laurent Pinchart, Benoit Parrot, Geert Uytterhoeven,
Arnd Bergmann, Sudip Mukherjee, Minghsiu Tsai, tiffany lin,
Jean-Christophe Trotin <jean-christo>
In-Reply-To: <20170403140743.trxep36s4z4piyl3@rob-hp-laptop>
On Mon, Apr 03, 2017 at 09:07:43AM -0500, Rob Herring wrote:
> On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
> > I assume if there's another binding doc in progress, it means
> > someone is working on another Synopsys DW CSI-2 subdevice driver.
>
> Yes. see http://patchwork.ozlabs.org/patch/736177/
>
> > Unfortunately I don't have the time to contribute and switch to
> > this other subdevice, and do test/debug.
>
> >From a DT perspective, I'm not asking that you share the subdevice
> driver, only the binding. Simply put, there's 1 h/w block here, so there
> should only be 1 binding. The binding is an ABI, so you can't just merge
> it and change it later.
I think it would be nice to have some kind of standard base binding
for CSI2 interfaces, but beyond the standard compatible/reg/interrupts
and graph properties, I'm not sure what it would look like.
As far as those properties go, the iMX6 version does better than the
DW version, because we specify the full graph, whereas the DW version
only specifies the downstream link. Once that's done, there's some
properties (like those specifying the output configuration) which
probably ought to be moved to the graph links instead, once they exist.
So, if anything, I think it's the DW version needs to be augmented with
fuller information, and some of the properties moved.
Also, as I've mentioned in my other reply, while they may both appear
to be called "Synopsys DW CSI-2" devices, they appear to be quite
different from the hardware perspective.
The rest
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Russell King - ARM Linux @ 2017-04-03 15:03 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Andrew-CT Chen (陳智迪),
Minghsiu Tsai, Sakari Ailus, Nick Dyer, Songjun Wu, Hans Verkuil,
Pavel Machek, Robert Jarzmik, devel, markus.heiser,
Laurent Pinchart, shuah, Geert Uytterhoeven, Steve Longerbeam,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
kernel@pengutronix.de, Arnd Bergmann, Mauro Carvalho Chehab,
Benoit Parrot
In-Reply-To: <20170403141135.6rwwftkiqqicmn6a@rob-hp-laptop>
On Mon, Apr 03, 2017 at 09:11:35AM -0500, Rob Herring wrote:
> On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> > > > Add bindings documentation for the i.MX media driver.
> > > >
> > > > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > > > ---
> > > > Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
> > > > 1 file changed, 74 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> > > > new file mode 100644
> > > > index 0000000..3059c06
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > > > @@ -0,0 +1,74 @@
> > > > +Freescale i.MX Media Video Device
> > > > +=================================
> > > > +
> > > > +Video Media Controller node
> > > > +---------------------------
> > > > +
> > > > +This is the media controller node for video capture support. It is a
> > > > +virtual device that lists the camera serial interface nodes that the
> > > > +media device will control.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,imx-capture-subsystem";
> > > > +- ports : Should contain a list of phandles pointing to camera
> > > > + sensor interface ports of IPU devices
> > > > +
> > > > +example:
> > > > +
> > > > +capture-subsystem {
> > > > + compatible = "fsl,imx-capture-subsystem";
> > > > + ports = <&ipu1_csi0>, <&ipu1_csi1>;
> > > > +};
> > > > +
> > > > +fim child node
> > > > +--------------
> > > > +
> > > > +This is an optional child node of the ipu_csi port nodes. If present and
> > > > +available, it enables the Frame Interval Monitor. Its properties can be
> > > > +used to modify the method in which the FIM measures frame intervals.
> > > > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > > > +Frame Interval Monitor.
> > > > +
> > > > +Optional properties:
> > > > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > > > + specified as <chan flags>. The channel number
> > > > + must be 0 or 1. The flags can be
> > > > + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> > > > + IRQ_TYPE_EDGE_BOTH, and specify which input
> > > > + capture signal edge will trigger the input
> > > > + capture event. If an input capture channel is
> > > > + specified, the FIM will use this method to
> > > > + measure frame intervals instead of via the EOF
> > > > + interrupt. The input capture method is much
> > > > + preferred over EOF as it is not subject to
> > > > + interrupt latency errors. However it requires
> > > > + routing the VSYNC or FIELD output signals of
> > > > + the camera sensor to one of the i.MX input
> > > > + capture pads (SD1_DAT0, SD1_DAT1), which also
> > > > + gives up support for SD1.
> > > > +
> > > > +
> > > > +mipi_csi2 node
> > > > +--------------
> > > > +
> > > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > > +CSI-2 sensors.
> > > > +
> > > > +Required properties:
> > > > +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> > >
> > > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > > needs to be based on that.
> >
> > Maybe someone can provide some kind of reference to it, and it's
> > associated driver?
>
> Let me Google that for you (TM). The reference is in my comments on v5.
> Here's a reference to it [1].
Looking at the actual driver, it seems to at least have a different
register layout:
register imx6 dw
version 0x000 0x000
n_lanes 0x004 0x004
phy_shutdownz 0x008 -
dphy_resetz 0x00c -
resetn 0x010 0x008
phy_state 0x014 -
data_ids_1 0x018 0x010
data_ids_2 0x01c 0x014
err1 0x020 -
err2 0x024 -
msk1 0x028 -
msk2 0x02c -
phy_tst_ctrl0 0x030 -
phy_tst_ctrl1 0x034 -
sft_reset 0xf00 - (not part of CSI2, but a IMX6 specific
CSI2 to IPU gasket layer, but lives in
CSI2's register region)
The DW version has many more registers than are documented by the iMX6
version. Only the first two registers appear to be common between these
two devices, and maybe five registers exist (I haven't checked whether
their bit layouts are the same though.)
So, I would say that these are two different devices.
As for the bindings, the differences are:
compatible: dw uses "snps,dw-mipi-csi"
imx6 uses "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2"
reg: dw and imx6 both use a single base address
interrupts: dw requires one interrupt, imx6 has up to two interrupts
output-type: relevant for DW, meaningless on imx6 (not documented)
phys: DW seems to specify a separate PHY, on imx6 the PHY
control/status is tightly integrated into the CSI2
register set, and the PHY itself is undocumented except
for some specific programming documented in source code.
resets: DW lists this under "required", but suffixes it with
(optional), so is it optional or is it not?
Meaningless on imx6.
port: imx6 requires this, and must specify all (5) connectivity -
one node to connect to the camera, and four nodes connecting
to the rest of the capture system.
dw specifies only one port node to be connected to the
camera.
dw document is unclear whether this is an optional or
required property. imx6 requires all five nodes.
clocks, imx6 requires the clocks and clock names to be specified,
clock-names: dw requires no clocks. DW binding would need these to be
optional.
So, the only common properties are "reg" and maybe "interrupts".
The DW binding also looks specific to the SoC implementation - the lack
of any specification in it as to how the module relates to other parts
of the capture system _appears_ to mean that its relationship with those
other parts can't be established from DT. That's a problem when it comes
to iMX6, because the CSI2 relationship to the one or two IPU units depends
on the SoC (whether it's a single/dual-lite or dual/quad version.)
Therefore, it does not make sense to (a) use the same compatible, or
(b) use the same binding.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Fabio Estevam @ 2017-04-03 15:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <1468400495-10471-1-git-send-email-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Uwe,
On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> A part of my machine looks as follows (simplified):
>
> ,------------------------.
> | ,---------. |
> | | imx25 o--RX----◁---o---
> | | o--GPIO--' |
> | `---------' |
> `------------------------'
>
> that is, there is a driver on the RX line that must be enabled before
> the UART can be used. (That is necessary because the default mux of the
> RX pad after reset is an output.)
>
> To represent this in the device tree I do:
>
> pinctrl_uart5: uart5 {
> fsl,pins = <
> ...
> MX25_PAD_LBA__UART5_RXD 0x00000000
> MX25_PAD_CS5__GPIO_3_21 0x00002001
> ...
> };
>
> &uart5 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart5>;
>
> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
> ...
> };
>
> This way it's ensured that the gpio is only enabled when the LBA pad is
> muxed as RX (together with the bootloader that sets the GPIO high).
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Since this is not imx serial specific it could be made more generic.
What about extending
Documentation/devicetree/bindings/serial/slave-device.txt to handle
this GPIO, or maybe a regulator?
--
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 V4 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Rafał Miłecki @ 2017-04-03 14:57 UTC (permalink / raw)
To: Jon Mason, Rafał Miłecki
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Scott Branden, Stephen Warren, Ray Jui,
linux-pm, Lee Jones, Eduardo Valentin, Eric Anholt, Rob Herring,
BCM Kernel Feedback, linux-rpi-kernel, Zhang Rui,
linux-arm-kernel
In-Reply-To: <CAC3K-4q4Cfo5Nzpxf3v_MHBJgPFxny5PCEEiBZM-9TBStGS-GQ@mail.gmail.com>
On 04/03/2017 04:54 PM, Jon Mason wrote:
> On Sun, Apr 2, 2017 at 11:07 PM, Jon Mason <jon.mason@broadcom.com> wrote:
>> On Sat, Apr 1, 2017 at 5:50 PM, Rafał Miłecki <zajec5@gmail.com> wrote:
>>> On 04/01/2017 09:51 PM, Eduardo Valentin wrote:
>>>>
>>>> On Fri, Mar 31, 2017 at 10:11:23PM +0200, Rafał Miłecki wrote:
>>>>>
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> This commit documents binding for thermal used in Northstar family SoCs.
>>>>>
>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>> ---
>>>>> V3: Add thermal-zones to the example
>>>>> Rob: Because of this update, I didn't include Acked-by I got for V2
>>>>> ---
>>>>> .../devicetree/bindings/thermal/brcm,ns-thermal | 26
>>>>> ++++++++++++++++++++++
>>>>> 1 file changed, 26 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>>> b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>>> new file mode 100644
>>>>> index 000000000000..c561c7349f17
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>>> @@ -0,0 +1,26 @@
>>>>> +* Broadcom Northstar Thermal
>>>>> +
>>>>> +This binding describes thermal sensor that is part of Northstar's DMU
>>>>> (Device
>>>>> +Management Unit).
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : Must be "brcm,ns-thermal"
>>>>> +- reg : iomem address range of PVTMON registers
>>>>> +- #thermal-sensor-cells : Should be <0>
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +thermal: thermal@1800c2c0 {
>>>>> + compatible = "brcm,ns-thermal";
>>>>> + reg = <0x1800c2c0 0x10>;
>>>>> + #thermal-sensor-cells = <0>;
>>>>> +};
>>>>> +
>>>>> +thermal-zones {
>>>>> + cpu_thermal: cpu-thermal {
>>>>> + polling-delay-passive = <0>;
>>>>> + polling-delay = <1000>;
>>>>> + coefficients = <(-556) 418000>;
>>>>> + thermal-sensors = <&thermal>;
>>>>
>>>>
>>>> You need to define trips and cooling devices here. Otherwise, makes
>>>> little sense to have this device in thermal subsystem. Here is an
>>>> example of minimal set:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=1e2ac9821de6a85d3e8358f238436708d1d46869
>>>>
>>>> The above has no passive action. It is just gonna shutdown the system if
>>>> temperature crosses a threshold.
>>>>
>>>> But, a typical cooling device would be CPU frequency throttling. Do you
>>>> have
>>>> that up and running in your routers?
>>>
>>>
>>> I don't have CPU freq throttling, so shutdown will be the only solution for
>>> critical temp right now.
>>>
>>> I know I should have at least a trip for critical temperature, but the
>>> problem
>>> is I don't know what value to use. There isn't any info about this in public
>>> datasheets. Broadcom's SDK doesn't mention it. Vendors share only the max
>>> environment temp, not the max CPU temp.
>>>
>>> So for now I only meant to provide user space access to reading current CPU
>>> temperature. I could do some stress tests and ask other users to do it as
>>> well.
>>>
>>> Or maybe I could just put in Documentation some round value that makes more
>>> or
>>> less sense and then work on a proper content of real DTS files?
>>>
>>> Unless we can get some hint from Broadcom people. Jon? Florian? Anyone?
>>
>> I'll poke around and see if I can find a datasheet for NS/NSP. Worst
>> case, I can ask one of the HW engineers for NSP, and we can use the
>> same value for NS.
>
> In the NS documentation, under "Absolute Maximum Ratings":
>
> The "Maximum Junction Temperature" is 125 C
> The "Commercial Ambient Temperature (Operating)" range is 0 to 75 C
> The "Industrial Ambient Temperature (Operating)" range is -40 to 85 C
> The "Storage Temperature" range is -40 to 125 C
>
> In the NSP documentation, under "Absolute Maximum Ratings":
>
> The "Maximum Junction Temperature" is 110 C
> The "Commercial Ambient Temperature (Operating)" range is 0 to 75 C
> The "Industrial Ambient Temperature (Operating)" range is -40 to 85 C
> The "Storage Temperature" range is -40 to 125 C
>
> I believe the first one is the number you are looking for.
Thanks a lot for this valuable info! I'll send next version today.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/5] usb: dwc2: Add support for USB OTG on STM32F4x9
From: Alexandre Torgue @ 2017-04-03 14:55 UTC (permalink / raw)
To: Bruno Herrera, robh+dt, mark.rutland, mcoquelin.stm32, johnyoun,
felipe.balbi
Cc: devicetree, linux-usb, linux-arm-kernel
In-Reply-To: <20170201012547.76158-1-bruherrera@gmail.com>
Hi
On 02/01/2017 02:25 AM, Bruno Herrera wrote:
> The STM32F4x9 MCU family has two DWC2 USB OTG cores on it. One core is
> USB OTG FS and other core is USB OTG HS. The USB FS core only works with
> its internal phy whilst the USF HS core can work in HS with external ulpi
> phy or in FS/LS speed with the embedded FS PHY.
>
...
>
> Documentation/devicetree/bindings/usb/dwc2.txt | 4 ++++
> arch/arm/boot/dts/stm32f429-disco.dts | 16 +++++++++++++
> arch/arm/boot/dts/stm32f429.dtsi | 31 ++++++++++++++++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 16 +++++++++++++
> drivers/usb/dwc2/core.h | 5 +++++
> drivers/usb/dwc2/hcd.c | 15 ++++++++++++-
> drivers/usb/dwc2/hw.h | 2 ++
> drivers/usb/dwc2/params.c | 19 ++++++++++++++++
> 8 files changed, 107 insertions(+), 1 deletion(-)
>
Patches 2, 3, 4 & 5 (DT + bindings) applied on stm32-dt-for-v4.12
regards
Alex
^ 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