* Re: [PATCH v6 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
From: Rob Herring @ 2016-12-12 18:59 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1481292919-26587-8-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
On Fri, Dec 09, 2016 at 03:15:18PM +0100, Benjamin Gaignard wrote:
> Add Timers and it sub-nodes into DT for stm32f429 family.
>
> version 6:
> - split patch in two: one for SoC family and one for stm32f469
> discovery board.
>
> version 5:
> - rename gptimer node to timers
> - re-order timers node par addresses
>
> version 4:
> - remove unwanted indexing in pwm@ and timer@ node name
> - use "reg" instead of additional parameters to set timer
> configuration
>
> version 3:
> - use "st,stm32-timer-trigger" in DT
>
> version 2:
> - use parameters to describe hardware capabilities
> - do not use references for pwm and iio timer subnodes
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 275 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 275 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index bca491d..d0fb9cc 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -355,6 +355,21 @@
> slew-rate = <2>;
> };
> };
> +
> + pwm1_pins: pwm@1 {
No reg prop, so should not have a unit-address. Given the names in the
define below, seems like "timer1" would be appropriate.
> + pins {
> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
> + };
> + };
> +
> + pwm3_pins: pwm@3 {
> + pins {
> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
> + <STM32F429_PB5_FUNC_TIM3_CH2>;
> + };
> + };
> };
>
> rcc: rcc@40023810 {
> @@ -426,6 +441,266 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + timers2: timers@40000000 {
timer@...
It may be more than just a timer, there's not a better generic name.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000000 0x400>;
> + clocks = <&rcc 0 128>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <1>;
> + status = "disabled";
> + };
> + };
> +
> + timers3: timers@40000400 {
ditto
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000400 0x400>;
> + clocks = <&rcc 0 129>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <2>;
> + status = "disabled";
> + };
> + };
> +
> + timers4: timers@40000800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000800 0x400>;
> + clocks = <&rcc 0 130>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <3>;
> + status = "disabled";
> + };
> + };
> +
> + timers5: timers@40000C00 {
timer@...
And use lowercase hex.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40000C00 0x400>;
ditto
> + clocks = <&rcc 0 131>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <4>;
> + status = "disabled";
> + };
> + };
> +
> + timers6: timers@40001000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001000 0x400>;
> + clocks = <&rcc 0 132>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <5>;
> + status = "disabled";
> + };
> + };
> +
> + timers7: timers@40001400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001400 0x400>;
> + clocks = <&rcc 0 133>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <6>;
> + status = "disabled";
> + };
> + };
> +
> + timers12: timers@40001800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001800 0x400>;
> + clocks = <&rcc 0 134>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <9>;
> + status = "disabled";
> + };
> + };
> +
> + timers13: timers@40001C00 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40001C00 0x400>;
> + clocks = <&rcc 0 135>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers14: timers@40002000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40002000 0x400>;
> + clocks = <&rcc 0 136>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers1: timers@40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
> + status = "disabled";
> + };
> + };
> +
> + timers8: timers@40010400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010400 0x400>;
> + clocks = <&rcc 0 161>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <7>;
> + status = "disabled";
> + };
> + };
> +
> + timers9: timers@40014000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014000 0x400>;
> + clocks = <&rcc 0 176>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <8>;
> + status = "disabled";
> + };
> + };
> +
> + timers10: timers@40014400 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014400 0x400>;
> + clocks = <&rcc 0 177>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> +
> + timers11: timers@40014800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40014800 0x400>;
> + clocks = <&rcc 0 178>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + status = "disabled";
> + };
> + };
> };
> };
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v6 1/8] MFD: add bindings for STM32 Timers driver
From: Rob Herring @ 2016-12-12 18:51 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones, mark.rutland, alexandre.torgue, devicetree,
linux-kernel, thierry.reding, linux-pwm, jic23, knaack.h, lars,
pmeerw, linux-iio, linux-arm-kernel, fabrice.gasnier,
gerald.baeza, arnaud.pouliquen, linus.walleij, linaro-kernel,
Benjamin Gaignard
In-Reply-To: <1481292919-26587-2-git-send-email-benjamin.gaignard@st.com>
On Fri, Dec 09, 2016 at 03:15:12PM +0100, Benjamin Gaignard wrote:
> Add bindings information for STM32 Timers
>
> version 6:
> - rename stm32-gtimer to stm32-timers
> - change compatible
> - add description about the IPs
>
> version 2:
> - rename stm32-mfd-timer to stm32-gptimer
> - only keep one compatible string
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/mfd/stm32-timers.txt | 46 ++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> new file mode 100644
> index 0000000..b30868e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
> @@ -0,0 +1,46 @@
> +STM32 Timers driver bindings
> +
> +This IP provides 3 types of timer along with PWM functionality:
> +- advanced-control timers consist of a 16-bit auto-reload counter driven by a programmable
> + prescaler, break input feature, PWM outputs and complementary PWM ouputs channels.
> +- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter driven by a
> + programmable prescaler and PWM outputs.
> +- basic timers consist of a 16-bit auto-reload counter driven by a programmable prescaler.
> +
> +Required parameters:
> +- compatible: must be "st,stm32-timers"
> +
> +- reg: Physical base address and length of the controller's
> + registers.
> +- clock-names: Set to "clk_int".
'clk' is redundant. Also, you don't really need -names when there is
only one of them.
> +- clocks: Phandle to the clock used by the timer module.
> + For Clk properties, please refer to ../clock/clock-bindings.txt
> +
> +Optional parameters:
> +- resets: Phandle to the parent reset controller.
> + See ../reset/st,stm32-rcc.txt
> +
> +Optional subnodes:
> +- pwm: See ../pwm/pwm-stm32.txt
> +- timer: See ../iio/timer/stm32-timer-trigger.txt
> +
> +Example:
> + timers@40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-timers";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm {
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer {
> + compatible = "st,stm32-timer-trigger";
> + reg = <0>;
You don't need reg here as there is only one. In turn, you don't need
#address-cells or #size-cells.
> + };
> + };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v2 04/11] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Rob Herring @ 2016-12-12 18:44 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <20161209110419.28981-5-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, Dec 09, 2016 at 12:04:12PM +0100, Quentin Schulz wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> v2:
> - adding small explanation on AXP223 variation compared to the AXP221,
>
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 5 +++++
> 1 file changed, 5 insertions(+)
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 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
From: Rob Herring @ 2016-12-12 18:43 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Magnus Damm, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdX_Cg6T10pMXe420kOwQn27_PRm-osNb7L4_M==fJnE_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 09, 2016 at 01:52:20PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
> <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> > In the case of Renesas R-Car hardware we know that there are generations of
> > SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
>
> it's
>
> > relationship between IP blocks might be. For example, I believe that
> > r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
> > descendant of the former or vice versa.
> >
> > We can, however, by examining the documentation and behaviour of the
> > hardware at run-time observe that the current driver implementation appears
> > to be compatible with the IP blocks on SoCs within a given generation.
> >
> > For the above reasons and convenience when enabling new SoCs a
> > per-generation fallback compatibility string scheme being adopted for
> > drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> > ---
> > .../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
> > drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +
> > 2 files changed, 26 insertions(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > index 772c550d3b4b..e5a5251be9f5 100644
> > --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> > @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
> >
> > Required properties:
> >
> > -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
> > - as fallback.
> > - Examples with soctypes are:
> > +- compatible:
> > - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
> > - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
> > - "renesas,intc-irqpin-r8a7779" (R-Car H1)
> > - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
> > + - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
>
> Does it make sense to add a new family-specific compatible value to a driver
> that's unlikely to receive more users in the future? More recent SoCs use
> renesas,irqc.
If that's the case, then no. Please don't go crazy with your generic
strings. I don't mind them, but I don't know that I'd call it best
practice.
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] Documentation: ti-syscon-reset: fix header path
From: Rob Herring @ 2016-12-12 18:40 UTC (permalink / raw)
To: yegorslists; +Cc: linux-kernel, p.zabel, devicetree, mark.rutland
In-Reply-To: <1481278287-23842-1-git-send-email-yegorslists@googlemail.com>
On Fri, Dec 09, 2016 at 11:11:27AM +0100, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> 'include' was missing from path.
>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> index 164c7f3..5b20e20 100644
> --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
> @@ -44,7 +44,7 @@ Required properties:
> reset status register
> Cell #7 : Flags used to control reset behavior,
> availible flags defined in the DT include
> - file <dt-bindings/reset/ti-syscon.h>
> + file <include/dt-bindings/reset/ti-syscon.h>
There's pretty much equal mixture of include or not. Not really much
point in fixing 1 instance if there's no clear correct way. Given it is
written with <...>, that matches how you write the include statement.
Rob
^ permalink raw reply
* [PATCH] of/platform: depopulate devices in the reverse order of creation
From: Jason Gunthorpe @ 2016-12-12 18:39 UTC (permalink / raw)
To: Rob Herring, Frank Rowand
Cc: Pawel Moll, Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
If the DT has inter-dependencies, then the devices need to be removed
in the right order to avoid removal problems.
Assuming the DT is constructed so that EPROBE_DEFER doesn't happen
during creating then a good way to avoid removal problems is reversing
the order during depopulation.
Signed-off-by: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
---
drivers/of/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
In my specific case I have a gpio driver, followed by a i2c bitbang
using that driver. So gpiolib prints an error if it the gpio driver is
removed before the gpio client..
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index cd72c0156db2ba..5720fe44f991e9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -568,7 +568,8 @@ static int of_platform_device_destroy(struct device *dev, void *data)
void of_platform_depopulate(struct device *parent)
{
if (parent->of_node && of_node_check_flag(parent->of_node, OF_POPULATED_BUS)) {
- device_for_each_child(parent, NULL, of_platform_device_destroy);
+ device_for_each_child_reverse(parent, NULL,
+ of_platform_device_destroy);
of_node_clear_flag(parent->of_node, OF_POPULATED_BUS);
}
}
--
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 v4 3/5] i2c: designware: Add slave definitions
From: Luis de Oliveira @ 2016-12-12 18:35 UTC (permalink / raw)
To: Rob Herring, Luis Oliveira
Cc: wsa@the-dreams.de, mark.rutland@arm.com,
jarkko.nikula@linux.intel.com, andriy.shevchenko@linux.intel.com,
mika.westerberg@linux.intel.com, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Ramiro.Oliveira@synopsys.com, Joao.Pinto@synopsys.com,
CARLOS.PALMINHA@synopsys.com
In-Reply-To: <20161212170214.4cydp256jsp7srar@rob-hp-laptop>
Hi all,
The slave address could be set by the I2C slave backend so I can't use it to setup the controller.
A boolean property was my initial approach then Andy and Wolfram Sang suggested the use of compatible strings and later It was suggested to use a property to select mode but I can do it again if it's the best way.
Can you please tell me where should it be documented?
Luis
-----Original Message-----
From: Rob Herring [mailto:robh@kernel.org]
Sent: Monday, December 12, 2016 17:02
To: Luis Oliveira <Luis.Oliveira@synopsys.com>
Cc: wsa@the-dreams.de; mark.rutland@arm.com; jarkko.nikula@linux.intel.com; andriy.shevchenko@linux.intel.com; mika.westerberg@linux.intel.com; linux-i2c@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Ramiro.Oliveira@synopsys.com; Joao.Pinto@synopsys.com; CARLOS.PALMINHA@synopsys.com
Subject: Re: [PATCH v4 3/5] i2c: designware: Add slave definitions
On Wed, Dec 07, 2016 at 05:55:50PM +0000, Luis Oliveira wrote:
> - Add slave definitions to i2c-designware-core
> - Changes in Kconfig to auto-enable I2C_SLAVE when compiling the
> modules
> - Add mode property to designware-core.txt that enable the "slave" selection:
> - "mode" is an optional property that could be "slave" or "master"
> - if "mode" is not set the block is considered master by default
>
> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
> ---
> Changes V3->V4: (Andy Shevchenko)
> - created a common property for modes
> - placed the generic dependency first
>
> .../devicetree/bindings/i2c/i2c-designware.txt | 4 ++++
> drivers/i2c/busses/Kconfig | 1 +
> drivers/i2c/busses/i2c-designware-common.c | 6 +++++
> drivers/i2c/busses/i2c-designware-core.h | 26 ++++++++++++++++++++++
> 4 files changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> index fee26dc3e858..8ed2b532cd54 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> @@ -20,6 +20,9 @@ Optional properties :
> - i2c-sda-falling-time-ns : should contain the SDA falling time in nanoseconds.
> This value which is by default 300ns is used to compute the tHIGH period.
>
> + - mode : should be either:
> + - "master" to setup the hardware block as a I2C master
> + - "slave" to setup the hardware block as a I2C slave
This should be documented in a common location. Can't it be a boolean to enable slave mode? Or don't you need to set the slave address? That could be enough to enable slave mode and there's already one example doing that.
Rob
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Brian Norris @ 2016-12-12 18:34 UTC (permalink / raw)
To: Rob Herring
Cc: Benjamin Tissoires, Jiri Kosina, Dmitry Torokhov, Doug Anderson,
Caesar Wang, open list:ARM/Rockchip SoC...,
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland
In-Reply-To: <CAL_JsqJ7t=C4+PgCyNTev66V33-cyPkUHKsTcbnsYgvAaffVfw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi all,
On Mon, Dec 12, 2016 at 08:47:06AM -0600, Rob Herring wrote:
[Snip Benjamin's proposal; I agree we don't really want a multi-level DT
layout purely for making the driver look a little nicer (I'm not sure
this would really be nicer anyway). And I think, as Rob notes here, our
disagreement is smaller than appears. But I might be wrong.]
> Anyway, we're only debating this:
OK, so I think we might have a consensus of sorts? I'll describe it
here, in case I'm wrong. Otherwise, I'll send another rev.
> i2c-hid-dev@2c {
> compatible = "wacom,w9013", "hid-over-i2c";
I plan to document the above, but not treat "wacom,w9013" specially in
the driver, apart from possibly listing it in the driver of_match_table.
This was mentioned by Dmitry earlier, and I didn't see any objection.
(Note that there are problems with module autoload when using multiple
compatible strings like above. May not be supremely relevant to the
documentation, but it *is* practically important.)
> reg = <0x2c>;
> hid-descr-addr = <0x0020>;
> interrupt-parent = <&gpx3>;
> interrupts = <3 2>;
> vdd-supply = <sth>;
Document and support 'vdd-supply', optionally.
> init-delay-ms = <100>;
Per Rob's mention below, support this as 'post-power-on-delay-ms',
optionally.
We can use either of these properties on any device, with the
intention that if there are future needs for divergent bindings, the
aforementioned compatible property can help us differentiate.
> };
>
> vs.
>
> i2c-hid-dev@2c {
> compatible = "hid-over-i2c";
> reg = <0x2c>;
> hid-descr-addr = <0x0020>;
> interrupt-parent = <&gpx3>;
> interrupts = <3 2>;
> vdd-supply = <sth>;
> init-delay-ms = <100>;
> };
>
> My only other nit is use "post-power-on-delay-ms" which is already a
> defined property name rather than "init-delay-ms".
Any objections? Speak now or forever [1] hold your peace.
Brian
[1] Who am I kidding? There's always room for more paint on the
bikeshed.
--
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: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-12 18:23 UTC (permalink / raw)
To: Neil Armstrong, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161212101801.28491-1-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 12/12/2016 11:18 AM, Neil Armstrong wrote:
> The Amlogic Meson GXBB secure monitor uses part of the memory space, this
> patch adds these reserved zones and redefines the usable memory range for
> each boards.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 21 +++++++++++++++++++++
> .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 2 +-
> .../boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 2 +-
> .../boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 2 +-
> .../arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 2 +-
> 11 files changed, 31 insertions(+), 10 deletions(-)
>
I added your patch to next-20161212.
My kernel config is available as
https://github.com/xypron/kernel-odroid-c2/blob/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6/config/config-next-20161212
To build the same kernel just run ./build-dpkg.sh (or make) on
https://github.com/xypron/kernel-odroid-c2/tree/5ec4be0c1b45297bbcbc1ce3d3d787e45dac66b6
Free showed 0x2301000 less total memory available than next-20161209
without the patch.
When git cloning linux-next I got the following error on Hardkernel
Odroid C2:
[ 811.602365] Bad mode in Error handler detected on CPU2, code
0xbf000000 -- SError
[ 811.604205] CPU: 2 PID: 1447 Comm: git Not tainted
4.9.0-next-20161212-r005-arm64 #1
[ 811.611876] Hardware name: Hardkernel ODROID-C2 (DT)
[ 811.616793] task: ffff8000745c5780 task.stack: ffff800072d3c000
[ 811.622660] PC is at 0xaaaad3770f28
[ 811.626107] LR is at 0xffffab54e53c
[ 811.629558] pc : [<0000aaaad3770f28>] lr : [<0000ffffab54e53c>]
pstate: 20000000
[ 811.636888] sp : 0000ffffd3a1d950
[ 811.640166] x29: 0000ffffd3a1d950 x28: 0000ffff9853a050
[ 811.645427] x27: 00000000000ffc5e x26: 0000ffff8fe00020
[ 811.650688] x25: 0000ffffd3a1da98 x24: 0000000000000000
[ 811.655949] x23: 0000aaaad3770f28 x22: 0000000000000010
[ 811.661211] x21: 0000ffff9809bae0 x20: 000000000003de04
[ 811.666472] x19: 0000ffff8fe00010 x18: 0000000023c57c32
[ 811.671733] x17: 0000ffffab58f988 x16: 0000ffffab660008
[ 811.676994] x15: 00000000000006dc x14: 0000000000000000
[ 811.682255] x13: 00000000002549ea x12: 0000000029555c36
[ 811.687517] x11: 00000000002549eb x10: 0000000029555c36
[ 811.692778] x9 : 00000000002549ea x8 : 0000000029555c36
[ 811.698039] x7 : 00000000002549e9 x6 : 0000000029555c36
[ 811.703300] x5 : 0000ffff98d54b40 x4 : 0000ffff8f93c030
[ 811.708562] x3 : 00000000ffffffff x2 : 0000000000000000
[ 811.713823] x1 : 0000ffff9853a050 x0 : 0000ffff9809bae0
[ 811.720561] Internal error: Attempting to execute userspace memory:
8600000f [#1] PREEMPT SMP
[ 811.729004] Modules linked in: meson_rng rng_core ip_tables x_tables
ipv6 realtek
[ 811.736422] CPU: 2 PID: 1447 Comm: git Not tainted
4.9.0-next-20161212-r005-arm64 #1
[ 811.744097] Hardware name: Hardkernel ODROID-C2 (DT)
[ 811.749014] task: ffff8000745c5780 task.stack: ffff800072d3c000
[ 811.754879] PC is at 0xffffab54e53c
[ 811.758328] LR is at 0xffffab54e53c
[ 811.761779] pc : [<0000ffffab54e53c>] lr : [<0000ffffab54e53c>]
pstate: 600003c5
[ 811.769109] sp : ffff800072d3fec0
[ 811.772387] x29: 0000000000000000 x28: ffff8000745c5780
[ 811.777648] x27: 00000000000ffc5e x26: 0000ffff8fe00020
[ 811.782909] x25: 0000ffffd3a1da98 x24: 0000000000000000
[ 811.788171] x23: 0000000020000000 x22: 0000aaaad3770f28
[ 811.793432] x21: ffffffffffffffff x20: 000080006e538000
[ 811.798693] x19: 0000000000000000 x18: 0000000000000010
[ 811.803954] x17: 0000ffffab58f988 x16: 0000ffffab660008
[ 811.809215] x15: 0000000000000006 x14: ffff000088b2eabf
[ 811.814477] x13: ffff000008b2eacd x12: 0000000000000105
[ 811.819738] x11: 0000000000000002 x10: 0000000000000106
[ 811.824999] x9 : ffff800072d3fb40 x8 : 00000000000af8ec
[ 811.830260] x7 : 0000000000000000 x6 : 0000000000000a65
[ 811.835522] x5 : 000000000a660a65 x4 : 0000000000000000
[ 811.840783] x3 : 0000000000000002 x2 : 0000000000000a66
[ 811.846044] x1 : ffff8000745c5780 x0 : 0000000000000000
[ 811.852773] Process git (pid: 1447, stack limit = 0xffff800072d3c000)
[ 811.859156] Stack: (0xffff800072d3fec0 to 0xffff800072d40000)
[ 811.864849] fec0: 0000ffff9809bae0 0000ffff9853a050 0000000000000000
00000000ffffffff
[ 811.872611] fee0: 0000ffff8f93c030 0000ffff98d54b40 0000000029555c36
00000000002549e9
[ 811.880374] ff00: 0000000029555c36 00000000002549ea 0000000029555c36
00000000002549eb
[ 811.888136] ff20: 0000000029555c36 00000000002549ea 0000000000000000
00000000000006dc
[ 811.895898] ff40: 0000ffffab660008 0000ffffab58f988 0000000023c57c32
0000ffff8fe00010
[ 811.903661] ff60: 000000000003de04 0000ffff9809bae0 0000000000000010
0000aaaad3770f28
[ 811.911423] ff80: 0000000000000000 0000ffffd3a1da98 0000ffff8fe00020
00000000000ffc5e
[ 811.919186] ffa0: 0000ffff9853a050 0000ffffd3a1d950 0000ffffab54e53c
0000ffffd3a1d950
[ 811.926949] ffc0: 0000aaaad3770f28 0000000020000000 0000000000000000
ffffffffffffffff
[ 811.934711] ffe0: 0000000000000000 0000000000000000 3136363920746e61
3064613364666464
[ 811.942473] Call trace:
[ 811.944888] Exception stack(0xffff800072d3fcf0 to 0xffff800072d3fe20)
[ 811.951270] fce0: 0000000000000000
0001000000000000
[ 811.959034] fd00: ffff800072d3fec0 0000ffffab54e53c ffff8000731ab640
0000000000000000
[ 811.966796] fd20: 0000000000000004 ffff000008ab9818 ffff8000745c5780
000000000808540c
[ 811.974559] fd40: ffff800072d3fd90 ffff0000080c8858 ffff800072d3fe40
ffff8000745c5780
[ 811.982321] fd60: 0000000000000004 00000000000003c0 ffff800072d3fe40
0000000000000000
[ 811.990084] fd80: 0000ffffd3a1da98 0000ffff8fe00020 0000000000000000
ffff8000745c5780
[ 811.997846] fda0: 0000000000000a66 0000000000000002 0000000000000000
000000000a660a65
[ 812.005609] fdc0: 0000000000000a65 0000000000000000 00000000000af8ec
ffff800072d3fb40
[ 812.013371] fde0: 0000000000000106 0000000000000002 0000000000000105
ffff000008b2eacd
[ 812.021134] fe00: ffff000088b2eabf 0000000000000006 0000ffffab660008
0000ffffab58f988
[ 812.028896] [<0000ffffab54e53c>] 0xffffab54e53c
[ 812.033382] Code: aa1c03e1 aa1503e0 8b16027a d63f02e0 (7100001f)
[ 812.039501] ---[ end trace e791f586be1831bb ]---
--
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/4] dt-bindings: input: Specify the interrupt number of TPS65217 power button
From: Rob Herring @ 2016-12-12 17:27 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren, Arnd Bergmann,
Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209062833.5768-5-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Dec 09, 2016 at 03:28:33PM +0900, Milo Kim wrote:
> Specify the power button interrupt number which is from the datasheet.
>
> Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
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 3/4] dt-bindings: power/supply: Update TPS65217 properties
From: Rob Herring @ 2016-12-12 17:26 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson, Tony Lindgren, Arnd Bergmann, Lee Jones,
Sebastian Reichel, Dmitry Torokhov, linux-omap, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20161209062833.5768-4-woogyom.kim@gmail.com>
On Fri, Dec 09, 2016 at 03:28:32PM +0900, Milo Kim wrote:
> Add interrupt specifiers for USB and AC charger input. Interrupt numbers
> are from the datasheet.
> Fix wrong property for compatible string.
>
> Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> ---
> .../devicetree/bindings/power/supply/tps65217_charger.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: mfd: Remove TPS65217 interrupts
From: Rob Herring @ 2016-12-12 17:25 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren, Arnd Bergmann,
Lee Jones, Sebastian Reichel, Dmitry Torokhov,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161209062833.5768-3-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Dec 09, 2016 at 03:28:31PM +0900, Milo Kim wrote:
> Interrupt numbers are from the datasheet, so no need to keep them in
> the ABI. Use the number in the DT file.
I don't see the purpose of ripping this out. The headers have always
been for convienence, not whether the values come from the datasheet or
not.
> Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 8 +++-----
> include/dt-bindings/mfd/tps65217.h | 26 --------------------------
> 2 files changed, 3 insertions(+), 31 deletions(-)
> delete mode 100644 include/dt-bindings/mfd/tps65217.h
--
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] dt-bindings: Document the hi3660 reset bindings
From: Rob Herring @ 2016-12-12 17:20 UTC (permalink / raw)
To: Zhangfei Gao; +Cc: linux-arm-kernel, devicetree, Arnd Bergmann, Philipp Zabel
In-Reply-To: <1481249504-7942-1-git-send-email-zhangfei.gao@linaro.org>
On Fri, Dec 09, 2016 at 10:11:44AM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC reset controller.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> ---
> .../bindings/reset/hisilicon,hi3660-reset.txt | 43 ++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] iio: misc: add a generic regulator driver
From: Lars-Peter Clausen @ 2016-12-12 17:15 UTC (permalink / raw)
To: Bartosz Golaszewski, Jonathan Cameron
Cc: Hartmut Knaack, Peter Meerwald-Stadler, Rob Herring, Mark Rutland,
linux-iio, linux-devicetree, LKML, Kevin Hilman, Patrick Titiano,
Neil Armstrong, Liam Girdwood, Mark Brown
In-Reply-To: <CAMpxmJVJ+y9tRbRBsVg+i0EJO_6EFuvrypwC=ETnBWbMnxRFyg@mail.gmail.com>
On 12/06/2016 12:12 PM, Bartosz Golaszewski wrote:
> 2016-12-03 10:11 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>> On 30/11/16 10:10, Lars-Peter Clausen wrote:
>>> On 11/29/2016 04:35 PM, Bartosz Golaszewski wrote:
>>>> 2016-11-29 16:30 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>>>>> On 11/29/2016 04:22 PM, Bartosz Golaszewski wrote:
>>>>> [...]
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..147458f
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/iio/misc/iio-regulator.txt
>>>>>> @@ -0,0 +1,18 @@
>>>>>> +Industrial IO regulator device driver
>>>>>> +-------------------------------------
>>>>>> +
>>>>>> +This document describes the bindings for the iio-regulator - a dummy device
>>>>>> +driver representing a physical regulator within the iio framework.
>>>>>
>>>>> No bindings for drivers, only for hardware. So this wont work.
>>>>>
>>>>
>>>> What about exporting regulator attributes analogous to the one in this
>>>> patch from the iio-core when a *-supply property is specified for a
>>>> node?
>>>
>>> The problem with exposing direct control to the regulator is that it allows
>>> to modify the hardware state without the drivers knowledge. If you
>>> power-cycle a device all previous configuration that has been written to the
>>> device is reset. The device driver needs to be aware of this otherwise its
>>> assumed state and the actual device state can divert which will result in
>>> undefined behavior. Also access to the device will fail unexpectedly when
>>> the regulator is turned off. So I think generally the driver should
>>> explicitly control the regulator, power-up when needed, power-down when not.
>> I agree with what Lars has said.
>>
>> There 'may' be some argument to ultimately have a bridge driver from
>> regulators to IIO. That would be for cases where the divide between a regulator
>> and a DAC is blurred. However it would still have to play nicely with the
>> regulator framework and any other devices registered on that regulator.
>> Ultimately the ideal in that case would then be to describe what the DAC is
>> actually being used to do but that's a more complex issue!
>>
>> That doesn't seem to be what you are targeting here.
>>
>> What it sounds like you need is to have the hardware well enough described that
>> the standard runtime power management can disable the regulator just fine when
>> it is not in use. This may mean improving the power management in the relevant
>> drivers.
>>
>> Jonathan
>>
>> p.s. If ever proposing to do something 'unusual' with a regulator you should
>> bring in the regulator framework maintainers in the cc list.
>>>
>>> - Lars
>>>
>>
>
> I wrote the initial patch quickly and didn't give it much of a
> thought. Now I realized I completely missed the point and managed to
> confuse everybody - myself included.
>
> So the problem we have is not power-cycling the adc - it's
> power-cycling the device connected to a probe on which there's an adc.
> What I was trying to do was adding support for the power-switch on
> baylibre-acme[1] probes.
>
> For example: we have a USB probe on which the VBUS signal goes through
> a power load switch and than through the adc. The adc (in this case
> ina226) is always powered on, while the fixed regulator I wanted to
> enable/disable actually drives the power switch to cut/restore power
> to the connected USB device i.e. there's no real regulator - just a
> GPIO driving the power switch.
>
> A typical use case is measuring the power consumption of development
> boards[2]. Rebooting them remotely using acme probes is already done,
> but we're using the obsolete /sys/class/gpio interface.
>
> We're already using libiio to read the measured data from the power
> monitor, that's why we'd like to use the iio framework for
> power-cycling the devices as well. My question is: would bridging the
> regulator framework be the right solution? Should we look for
> something else? Bridge the GPIO framework instead?
I wouldn't necessaries create bridge, but instead just use the GPIO
framework directly.
We now have the GPIO chardev interface which meant to be used to support
application specific logic that control the GPIOs, but where you don't want
to write a kernel driver.
My idea was to add GPIOs and GPIO chips as high level object inside libiio
that can be accessed through the same context as the IIO devices. Similar to
the current IIO API you have a API for gpios that allows to enumerate the
GPIO devices and their pins as well as modify the pin state.
^ permalink raw reply
* Re: [PATCH v2 3/6] Documentation: DT: Add bmi160 imu binding
From: Rob Herring @ 2016-12-12 17:15 UTC (permalink / raw)
To: Marcin Niestroj
Cc: Jonathan Cameron, Peter Meerwald-Stadler, Hartmut Knaack,
Lars-Peter Clausen, Daniel Baluta, Gregor Boirie, Sanchayan Maity,
Mark Rutland, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161208142259.26230-4-m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
On Thu, Dec 08, 2016 at 03:22:56PM +0100, Marcin Niestroj wrote:
> This adds documentation for Bosch BMI160 Inertial Measurement Unit
> device-tree bindings.
>
> Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
> ---
> Changes v1 -> v2 (suggested by Rob):
> * remove "gpio" keyword from interrupts property description
> * describe "INT1" and "INT2" cases for interrupt-names property
>
> .../devicetree/bindings/iio/imu/bmi160.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/bmi160.txt b/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> new file mode 100644
> index 0000000..ae0112c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/imu/bmi160.txt
> @@ -0,0 +1,36 @@
> +Bosch BMI160 - Inertial Measurement Unit with Accelerometer, Gyroscope
> +and externally connectable Magnetometer
> +
> +https://www.bosch-sensortec.com/bst/products/all_products/bmi160
> +
> +Required properties:
> + - compatible : should be "bosch,bmi160"
> + - reg : the I2C address or SPI chip select number of the sensor
> + - spi-max-frequency : set maximum clock frequency (only for SPI)
> +
> +Optional properties:
> + - interrupt-parent : should be the phandle of the interrupt controller
> + - interrupts : interrupt mapping for IRQ, must be IRQ_TYPE_LEVEL_LOW
> + - interrupt-names : set to "INT1" if INT1 pin should be used as interrupt
> + input, set to "INT2" if INT2 pin should be used instead
> +
> +Examples:
> +
> +bmi160@68 {
> + compatible = "bosch,bmi160";
> + reg = <0x68>;
> +
> + interrupt-parent = <&gpio4>;
> + interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "INT1";
> +};
> +
> +bmi160@0 {
> + compatible = "bosch,bmi160";
> + reg = <0>;
> + spi-max-frequency = <10000000>;
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "INT2";
> +};
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
From: Rob Herring @ 2016-12-12 17:14 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA, Adrian Hunter, Ulf Hansson,
Douglas Anderson, devicetree-u79uwXL29TY76Z2rM5mHXA, Al Cooper,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Wahren,
Andrei Pistirica, Wolfram Sang, Mark Rutland, Simon Horman
In-Reply-To: <1481201455-3483-3-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Thu, Dec 08, 2016 at 09:50:55PM +0900, Masahiro Yamada wrote:
> Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.
>
> For SD, it basically relies on the SDHCI standard code.
> For eMMC, this driver provides some callbacks to support the
> hardware part that is specific to this IP design.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Acked-by: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>
> Changes in v5:
> - Fix calculation of the center of the tuned window
>
> Changes in v4:
> - Override mmc_host_ops.execute_tuning instead of the
> .platform_execute_tuning implementation
>
> Changes in v3:
> - Remove unneeded explanation about HRS and SRS from DT binding;
> the offsets to HRS/SRS are fixed for this hardware and this is
> quite normal, like each hardware has a fixed register view except
> the register base. The detailed register map is what the driver
> cares about, so no need to explain it in the binding.
>
> Changes in v2:
> - Remove unnecessary "select MMC_SDHCI_IO_ACCESSORS"
>
> .../devicetree/bindings/mmc/sdhci-cadence.txt | 30 +++
> drivers/mmc/host/Kconfig | 11 +
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-cadence.c | 283 +++++++++++++++++++++
> 4 files changed, 325 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> create mode 100644 drivers/mmc/host/sdhci-cadence.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> new file mode 100644
> index 0000000..750374f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
> @@ -0,0 +1,30 @@
> +* Cadence SD/SDIO/eMMC Host Controller
> +
> +Required properties:
> +- compatible: should be "cdns,sd4hc".
Needs SoC specific compatible strings too.
> +- reg: offset and length of the register set for the device.
> +- interrupts: a single interrupt specifier.
> +- clocks: phandle to the input clock.
> +
> +Optional properties:
> +For eMMC configuration, supported speed modes are not indicated by the SDHCI
> +Capabilities Register. Instead, the following properties should be specified
> +if supported. See mmc.txt for details.
> +- mmc-ddr-1_8v
> +- mmc-ddr-1_2v
> +- mmc-hs200-1_8v
> +- mmc-hs200-1_2v
> +- mmc-hs400-1_8v
> +- mmc-hs400-1_2v
There's now a property to override SDHCI capabilities register. Maybe
you should use that instead? I'll defer to Ulf.
> +
> +Example:
> + emmc: sdhci@5a000000 {
> + compatible = "cdns,sd4hc";
> + reg = <0x5a000000 0x400>;
> + interrupts = <0 78 4>;
> + clocks = <&clk 4>;
> + bus-width = <8>;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + };
--
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 1/2] dt-bindings: zx296718-clk: add compatible for audio clock controller
From: Rob Herring @ 2016-12-12 17:10 UTC (permalink / raw)
To: Shawn Guo
Cc: Michael Turquette, Stephen Boyd, Mark Rutland, Baoyou Xie,
Jun Nie, linux-clk, devicetree, linux-arm-kernel, Shawn Guo
In-Reply-To: <1481189157-8995-1-git-send-email-shawnguo@kernel.org>
On Thu, Dec 08, 2016 at 05:25:56PM +0800, Shawn Guo wrote:
> From: Shawn Guo <shawn.guo@linaro.org>
>
> It adds the compatible string for zx296718 audio clock controller.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> Documentation/devicetree/bindings/clock/zx296718-clk.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/5] Documentation: fsl-quadspi: Add fsl, ls1012a-qspi compatible string
From: Rob Herring @ 2016-12-12 17:09 UTC (permalink / raw)
To: Yuan Yao
Cc: shawnguo, mark.rutland, computersforpeace, dwmw2, devicetree,
yao.yuan, linux-arm-kernel, linux-kernel
In-Reply-To: <1481188984-43683-6-git-send-email-yao.yuan@freescale.com>
On Thu, Dec 08, 2016 at 05:23:04PM +0800, Yuan Yao wrote:
> From: Yuan Yao <yao.yuan@nxp.com>
Same problem in this subject too.
>
> new compatible string: "fsl,ls1012a-qspi".
>
> Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
> ---
> Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/5] Documentation: dt: mtd: add chip support for "jedec, spi-nor"
From: Rob Herring @ 2016-12-12 17:09 UTC (permalink / raw)
To: Yuan Yao
Cc: shawnguo, mark.rutland, computersforpeace, dwmw2, devicetree,
yao.yuan, linux-arm-kernel, linux-kernel
In-Reply-To: <1481188984-43683-4-git-send-email-yao.yuan@freescale.com>
On Thu, Dec 08, 2016 at 05:23:02PM +0800, Yuan Yao wrote:
> From: Yuan Yao <yao.yuan@nxp.com>
The compatible string is wrong in the subject.
>
> "sst25wf040b" and "en25s64" are also chip compatible with SPI NOR flash.
>
> Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
> ---
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> 1 file changed, 2 insertions(+)
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/5] Documentation: fsl: dspi: Add fsl, ls1012a-dspi compatible string
From: Rob Herring @ 2016-12-12 17:08 UTC (permalink / raw)
To: Yuan Yao
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
yao.yuan-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481188984-43683-3-git-send-email-yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On Thu, Dec 08, 2016 at 05:23:01PM +0800, Yuan Yao wrote:
> From: Yuan Yao <yao.yuan-3arQi8VN3Tc@public.gmane.org>
>
> new compatible string: "fsl,ls1012a-dspi".
>
> Signed-off-by: Yuan Yao <yao.yuan-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 1 +
> 1 file changed, 1 insertion(+)
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 2/2] ASoC: cs43130: Add devicetree bindings for CS43130
From: Rob Herring @ 2016-12-12 17:04 UTC (permalink / raw)
To: Li Xu
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA
In-Reply-To: <81e7d974-68d3-41ef-bd75-ce59b3515d9d-k7YZYYsDncjfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>
On Wed, Dec 07, 2016 at 02:17:28PM -0600, Li Xu wrote:
> Add devicetree bindings documentation file for Cirrus
> Logic CS43130 codec.
>
> Signed-off-by: Li Xu <li.xu-jGc1dHjMKG3QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/sound/cs43130.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/cs43130.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/cs43130.txt b/Documentation/devicetree/bindings/sound/cs43130.txt
> new file mode 100644
> index 0000000..9a2a22a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cs43130.txt
> @@ -0,0 +1,41 @@
> +CS43130 DAC
> +
> +Required properties:
> +
> + - compatible : "cirrus,cs43130"
> +
> + - reg : the I2C address of the device for I2C
> +
> + - VA-supply, VP-supply, VL-supply, VCP-supply, VD-supply:
> + power supplies for the device, as covered in
> + Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> +
> +Optional properties:
> +
> + - reset-gpios : gpio used to reset the Device
Please state the active state and set that in the flag cell.
> +
> + - cirrus,xtal-ibias:
> + When external MCLK is generated by external crystal
> + oscillator, CS43130 can be used to provide bias current
> + for external crystal. Amount of bias current sent is
> + set as:
> + 1 = 7.5uA
> + 2 = 12.5uA
> + 3 = 15uA
> +
> +Example:
> +
> +cs43130: cs43130@30 {
audio-codec@30
> + compatible = "cirrus,cs43130";
> + reg = <0x30>;
> + reset-gpios = <&axi_gpio 54 0>;
> + VA-supply = <&dummy_vreg>;
Some whitespace problems here.
> + VP-supply = <&dummy_vreg>;
> + VL-supply = <&dummy_vreg>;
> + VCP-supply = <&dummy_vreg>;
> + VD-supply = <&dummy_vreg>;
> + cirrus,xtal-ibias = <2>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <55 8>;
> +};
> --
> 1.9.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
* Re: [PATCH v4 3/5] i2c: designware: Add slave definitions
From: Rob Herring @ 2016-12-12 17:02 UTC (permalink / raw)
To: Luis Oliveira
Cc: wsa-z923LK4zBo2bacvFa/9K2g, mark.rutland-5wv7dgnIgG8,
jarkko.nikula-VuQAYsv1563Yd54FQh9/CA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <5173a9456c423025d8f15baafa2499440cbe1b51.1481131072.git.lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, Dec 07, 2016 at 05:55:50PM +0000, Luis Oliveira wrote:
> - Add slave definitions to i2c-designware-core
> - Changes in Kconfig to auto-enable I2C_SLAVE when compiling the modules
> - Add mode property to designware-core.txt that enable the "slave" selection:
> - "mode" is an optional property that could be "slave" or "master"
> - if "mode" is not set the block is considered master by default
>
> Signed-off-by: Luis Oliveira <lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> ---
> Changes V3->V4: (Andy Shevchenko)
> - created a common property for modes
> - placed the generic dependency first
>
> .../devicetree/bindings/i2c/i2c-designware.txt | 4 ++++
> drivers/i2c/busses/Kconfig | 1 +
> drivers/i2c/busses/i2c-designware-common.c | 6 +++++
> drivers/i2c/busses/i2c-designware-core.h | 26 ++++++++++++++++++++++
> 4 files changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> index fee26dc3e858..8ed2b532cd54 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
> @@ -20,6 +20,9 @@ Optional properties :
> - i2c-sda-falling-time-ns : should contain the SDA falling time in nanoseconds.
> This value which is by default 300ns is used to compute the tHIGH period.
>
> + - mode : should be either:
> + - "master" to setup the hardware block as a I2C master
> + - "slave" to setup the hardware block as a I2C slave
This should be documented in a common location. Can't it be a boolean to
enable slave mode? Or don't you need to set the slave address? That
could be enough to enable slave mode and there's already one example
doing that.
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 v5 2/4] drm: bridge: add support for TI ths8135
From: Laurent Pinchart @ 2016-12-12 16:49 UTC (permalink / raw)
To: Rob Herring
Cc: Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen, David Airlie,
Kevin Hilman, Michael Turquette, Sekhar Nori, Frank Rowand,
Mark Rutland, Peter Ujfalusi, Russell King, LKML, arm-soc,
linux-drm, linux-devicetree
In-Reply-To: <20161212164547.jw5ejbums6nwwtw2@rob-hp-laptop>
Hello,
On Monday 12 Dec 2016 10:45:47 Rob Herring wrote:
> On Wed, Dec 07, 2016 at 11:42:43AM +0100, Bartosz Golaszewski wrote:
> > THS8135 is a configurable video DAC. Add DT bindings for this chip and
> > use the dumb-vga-dac driver for now as no configuration is required to
> > make it work.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> > ---
> >
> > .../bindings/display/bridge/ti,ths8135.txt | 52 +++++++++++++++++
> > drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
> > 2 files changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> But one nit below:
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new
> > file mode 100644
> > index 0000000..23cd8ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> > @@ -0,0 +1,52 @@
> > +THS8135 Video DAC
> > +-----------------
> > +
> > +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> > +
> > +Required properties:
> > +
> > +- compatible: Must be "ti,ths8135"
> > +
> > +Required nodes:
> > +
> > +This device has two video ports. Their connections are modelled using the
> > OF +graph bindings specified in
> > Documentation/devicetree/bindings/graph.txt. +
> > +- Video port 0 for RGB input
> > +- Video port 1 for VGA output
> > +
> > +Example
> > +-------
> > +
> > +vga-bridge {
> > + compatible = "ti,ths8135";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + vga_bridge_in: endpoint@0 {
> > + reg = <0>;
>
> You don't need reg here.
In which case the endpoint node should be named endpoint, not endpoint@0. You
could then also remove the #address-cells and #size-cells properties from the
port@0 node. Same for port@1 below.
> > + remote-endpoint = <&lcdc_out_vga>;
> > + };
> > + };
> > +
> > + port@1 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <1>;
> > +
> > + vga_bridge_out: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&vga_con_in>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > b/drivers/gpu/drm/bridge/dumb-vga-dac.c index afec232..498fa75 100644
> > --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device
> > *pdev)
> >
> > static const struct of_device_id dumb_vga_match[] = {
> > { .compatible = "dumb-vga-dac" },
> > + { .compatible = "ti,ths8135" },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, dumb_vga_match);
--
Regards,
Laurent Pinchart
--
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 1/2] iio: light: add DT bindings for Capella CM3605
From: Rob Herring @ 2016-12-12 16:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Capella Microsystems,
Kevin Tsai
In-Reply-To: <1481118558-8016-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Dec 07, 2016 at 02:49:18PM +0100, Linus Walleij wrote:
> This adds device tree bindings for the Capella Microsystems CM3605
> ambient light sensor and short range proximity sensor.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Capella Microsystems <capellamicro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Kevin Tsai <ktsai-GubuWUlQtMwciDkP5Hr2oA@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/iio/light/cm3605.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/cm3605.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/cm3605.txt b/Documentation/devicetree/bindings/iio/light/cm3605.txt
> new file mode 100644
> index 000000000000..f0152559bdb9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/cm3605.txt
> @@ -0,0 +1,41 @@
> +Capella Microsystems CM3605
> +Ambient Light and Short Distance Proximity Sensor
> +
> +The CM3605 is an entirely analog part which however require quite a bit of
> +software logic to interface a host operating system.
> +
> +This ALS and proximity sensor was one of the very first deployed in mobile
> +handsets, notably it is used in the very first Nexus One Android phone from
> +2010.
> +
> +Required properties:
> +- compatible: must be: "capella,cm3605"
> +- aset-gpios: GPIO line controlling the ASET line (drive low
> + to activate the ALS, should be flagged GPIO_ACTIVE_LOW)
> +- interrupts: the IRQ line (such as a GPIO) that is connected to
> + the POUT (proximity sensor out) line. The edge detection must
> + be set to IRQ_TYPE_EDGE_BOTH so as to detect movements toward
> + and away from the proximity sensor.
> +- io-channels: the ADC channel used for converting the voltage from
> + AOUT to a digital representation.
> +- io-channel-names: must be "aout"
> +
> +Optional properties:
> +- vdd-supply: regulator supplying VDD power to the component.
> +- capella,aset-resistance: the sensitivity calibration resistance,
Add a '-ohms' suffix. With that,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> + in Ohms. Valid values are: 50000, 100000, 300000 and 600000,
> + as these are the resistance values that we are supplied with
> + calibration curves for. If not supplied, 100 kOhm will be assumed
> + but it is strongly recommended to supply this.
> +
> +Example:
> +
> +cm3605 {
> + compatible = "capella,cm3605";
> + vdd-supply = <&foo_reg>;
> + aset-gpios = <&foo_gpio 1 GPIO_ACTIVE_LOW>;
> + capella,aset-resistance = <100000>; // Ohms
> + interrupts = <1 IRQ_TYPE_EDGE_BOTH>;
> + io-channels = <&adc 0x01>;
> + io-channel-names = "aout";
> +};
> --
> 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
--
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 2/4] drm: bridge: add support for TI ths8135
From: Rob Herring @ 2016-12-12 16:45 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Jyri Sarha, Tomi Valkeinen, David Airlie, Kevin Hilman,
Michael Turquette, Sekhar Nori, Frank Rowand, Mark Rutland,
Laurent Pinchart, Peter Ujfalusi, Russell King, LKML, arm-soc,
linux-drm, linux-devicetree
In-Reply-To: <1481107365-24839-3-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Dec 07, 2016 at 11:42:43AM +0100, Bartosz Golaszewski wrote:
> THS8135 is a configurable video DAC. Add DT bindings for this chip and
> use the dumb-vga-dac driver for now as no configuration is required to
> make it work.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/display/bridge/ti,ths8135.txt | 52 ++++++++++++++++++++++
> drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 +
> 2 files changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
But one nit below:
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> new file mode 100644
> index 0000000..23cd8ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> @@ -0,0 +1,52 @@
> +THS8135 Video DAC
> +-----------------
> +
> +This is the binding for Texas Instruments THS8135 Video DAC bridge.
> +
> +Required properties:
> +
> +- compatible: Must be "ti,ths8135"
> +
> +Required nodes:
> +
> +This device has two video ports. Their connections are modelled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for RGB input
> +- Video port 1 for VGA output
> +
> +Example
> +-------
> +
> +vga-bridge {
> + compatible = "ti,ths8135";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint@0 {
> + reg = <0>;
You don't need reg here.
> + remote-endpoint = <&lcdc_out_vga>;
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> index afec232..498fa75 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -204,6 +204,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>
> static const struct of_device_id dumb_vga_match[] = {
> { .compatible = "dumb-vga-dac" },
> + { .compatible = "ti,ths8135" },
> {},
> };
> MODULE_DEVICE_TABLE(of, dumb_vga_match);
> --
> 2.9.3
>
--
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