* Re: [PATCH 1/2] Documentation: omap-usb-host: fix OMAP OHCI/EHCI file names
From: Rob Herring @ 2016-12-19 22:19 UTC (permalink / raw)
To: yegorslists; +Cc: linux-kernel, devicetree, mark.rutland
In-Reply-To: <1481817370-28242-1-git-send-email-yegorslists@googlemail.com>
On Thu, Dec 15, 2016 at 04:56:09PM +0100, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> OMAP related files are actually named ehci-omap.txt and ohci-omap3.txt.
>
> Also add full path to ohci-omap3.txt.
>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH v3] power: supply: bq24735-charger: optionally poll the ac-detect gpio
From: Rob Herring @ 2016-12-19 22:16 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Sebastian Reichel, Mark Rutland, linux-pm,
devicetree
In-Reply-To: <1481794126-5670-1-git-send-email-peda@axentia.se>
On Thu, Dec 15, 2016 at 10:28:46AM +0100, Peter Rosin wrote:
> If the ac-detect gpio does not support interrupts, provide a fallback
> to poll the gpio at a configurable interval.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> v2 -> v3 changes:
> - use device_property_read_u32 instead of of_property_read_u32
>
> v1 -> v2 changes:
> - use poll-interval instead of ti,poll-interval-ms in the bindings
>
> Cheers,
> peda
>
> .../bindings/power/supply/ti,bq24735.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/power/supply/bq24735-charger.c | 49 +++++++++++++++++++---
> 2 files changed, 46 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document the hi3660 clock bindings
From: Rob Herring @ 2016-12-19 22:15 UTC (permalink / raw)
To: Zhangfei Gao
Cc: Stephen Boyd, Arnd Bergmann,
haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A, guodong Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481781493-6188-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Thu, Dec 15, 2016 at 01:58:12PM +0800, Zhangfei Gao wrote:
> Add DT bindings documentation for hi3660 SoC clock.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/clock/hi3660-clock.txt | 42 ++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/hi3660-clock.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/hi3660-clock.txt b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> new file mode 100644
> index 0000000..7296fd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/hi3660-clock.txt
> @@ -0,0 +1,42 @@
> +* Hisilicon Hi3660 Clock Controller
> +
> +The Hi3660 clock controller generates and supplies clock to various
> +controllers within the Hi3660 SoC.
> +
> +Required Properties:
> +
> +- compatible: the compatible should be one of the following strings to
> + indicate the clock controller functionality.
> +
> + - "hisilicon,hi3660-crgctrl"
> + - "hisilicon,hi3660-pctrl"
> + - "hisilicon,hi3660-pmuctrl"
> + - "hisilicon,hi3660-sctrl"
> + - "hisilicon,hi3660-iomcu"
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- #clock-cells: should be 1.
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +
> +All these identifier could be found in <dt-bindings/clock/hi3660-clock.h>.
> +
> +Examples:
> + crg_ctrl: crg_ctrl@fff35000 {
clock-controller@...
> + compatible = "hisilicon,hi3660-crgctrl", "syscon";
> + reg = <0x0 0xfff35000 0x0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + uart0: uart@fdf02000 {
serial@...
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0 0xfdf02000 0x0 0x1000>;
> + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&crg_ctrl HI3660_CLK_MUX_UART0>,
> + <&crg_ctrl HI3660_PCLK>;
> + clock-names = "uartclk", "apb_pclk";
> + status = "disabled";
> + };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog
From: Rob Herring @ 2016-12-19 22:13 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel, linux-watchdog, linux-arm-kernel, devicetree,
kernel, mark, kris, horms+renesas, treding, jonathanh, f.fainelli,
fabio.estevam, kernel, shawnguo, linux, linux, wim, mark.rutland,
damien.riegel, lucile.quirion, olof, arnd, suzuki.poulose,
linus.walleij, will.deacon, yamada.masahiro
In-Reply-To: <20161214231237.17496-7-sebastien.bourdelin@savoirfairelinux.com>
On Wed, Dec 14, 2016 at 06:12:36PM -0500, Sebastien Bourdelin wrote:
> This watchdog is instantiated in a FPGA and can only be access using a
> GPIOs bit-banged bus, called the NBUS by Technologic Systems.
> The watchdog is made of only one register, called the feed register.
> Writing to this register will re-arm the watchdog for a given time (and
> enable it if it was disable). It can be disabled by writing a special
> value into it.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> ---
> .../devicetree/bindings/watchdog/ts4600-wdt.txt | 16 ++
> arch/arm/boot/dts/imx28-ts4600-common.dtsi | 5 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/watchdog/Kconfig | 10 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ts4600_wdt.c | 213 +++++++++++++++++++++
> 5 files changed, 245 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> create mode 100644 drivers/watchdog/ts4600_wdt.c
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: bus: Add documentation for the Technologic Systems NBUS
From: Rob Herring @ 2016-12-19 22:12 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A
In-Reply-To: <20161214231237.17496-4-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Wed, Dec 14, 2016 at 06:12:33PM -0500, Sebastien Bourdelin wrote:
> Add binding documentation for the Technologic Systems NBUS that is used
> to interface with peripherals in the FPGA of the TS-4600 SoM.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> ---
> Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt b/Documentation/devicetree/bindings/bus/ts-nbus.txt
> new file mode 100644
> index 0000000..2f777ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt
> @@ -0,0 +1,50 @@
> +Technologic Systems NBUS
> +
> +The NBUS is a bus used to interface with peripherals in the Technologic
> +Systems FPGA on the TS-4600 SoM.
> +
> +Required properties :
> + - compatible : "technologic,ts-nbus", "simple-bus"
> + - #address-cells : must be 1
> + - #size-cells : must be 0
> + - pws : The PWM pin connected to the clock line on the FPGA
Using PWM binding?
> + - data-gpios : The GPIO pin connected to the data line on the FPGA
> + - csn-gpios : The GPIO pin connected to the csn line on the FPGA
> + - txrx-gpios : The GPIO pin connected to the txrx line on the FPGA
> + - strobe-gpios : The GPIO pin connected to the stobe line on the FPGA
> + - ale-gpios : The GPIO pin connected to the ale line on the FPGA
> + - rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
These all need vendor prefix.
This is not any sort of standard bus?
> +
> +Child nodes:
> +
> +The NBUS node can contain zero or more child nodes representing peripherals
> +on the bus.
> +
> +Example:
> +
> + nbus {
> + compatible = "technologic,ts-nbus", "simple-bus";
I don't think simple-bus is really valid here. Don't you need the nbus
driver before the devices are usable?
> + pinctrl-0 = <&nbus_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pwms = <&pwm 2 83>;
> + data-gpios = <&gpio0 0 GPIO_ACTIVE_HIGH
> + &gpio0 1 GPIO_ACTIVE_HIGH
> + &gpio0 2 GPIO_ACTIVE_HIGH
> + &gpio0 3 GPIO_ACTIVE_HIGH
> + &gpio0 4 GPIO_ACTIVE_HIGH
> + &gpio0 5 GPIO_ACTIVE_HIGH
> + &gpio0 6 GPIO_ACTIVE_HIGH
> + &gpio0 7 GPIO_ACTIVE_HIGH>;
> + csn-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
> + txrx-gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
> + strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
> + ale-gpios = <&gpio0 26 GPIO_ACTIVE_HIGH>;
> + rdy-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> +
> + wdt@2a {
watchdog@...
> + compatible = "...";
> +
> + /* ... */
> + };
> + };
> --
> 2.10.2
>
> --
> 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 linux-watchdog" 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/6] of: documentation: add bindings documentation for TS-4600
From: Rob Herring @ 2016-12-19 22:05 UTC (permalink / raw)
To: Sebastien Bourdelin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
mark-L1vi/lXTdtvnC/t2CciAbw, kris-L1vi/lXTdtvnC/t2CciAbw,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
treding-DDmLM1+adcrQT0dZR+AlfA, jonathanh-DDmLM1+adcrQT0dZR+AlfA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, fabio.estevam-3arQi8VN3Tc,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-0h96xk9xTtrk1uMJSBkQmQ,
wim-IQzOog9fTRqzQB+pC5nmwQ, mark.rutland-5wv7dgnIgG8,
damien.riegel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
lucile.quirion-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
olof-nZhT3qVonbNeoWH0uzbU5w, arnd-r2nGTMty4D4,
suzuki.poulose-5wv7dgnIgG8, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
will.deacon-5wv7dgnIgG8, yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A
In-Reply-To: <20161214231237.17496-2-sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Wed, Dec 14, 2016 at 06:12:31PM -0500, Sebastien Bourdelin wrote:
> This adds the documentation for the TS-4600 by Technologic Systems.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
> ---
> Documentation/devicetree/bindings/arm/technologic.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 3/3] Bluetooth: btusb: Configure Marvel to use one of the pins for oob wakeup
From: Rob Herring @ 2016-12-19 22:04 UTC (permalink / raw)
To: Rajat Jain
Cc: Mark Rutland, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
Amitkumar Karwar, Wei-Ning Huang, Xinming Hu, netdev, devicetree,
linux-bluetooth, Brian Norris, rajatxjain
In-Reply-To: <1481742779-15105-3-git-send-email-rajatja@google.com>
On Wed, Dec 14, 2016 at 11:12:59AM -0800, Rajat Jain wrote:
> The Marvell devices may have many gpio pins, and hence for wakeup
> on these out-of-band pins, the chip needs to be told which pin is
> to be used for wakeup, using an hci command.
>
> Thus, we read the pin number etc from the device tree node and send
> a command to the chip.
>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> ---
> Note that while I would have liked to name the compatible string as more
> like "marvell, usb8997-bt", the devicetrees/bindings/usb/usb-device.txt
> requires the compatible property to be of the form "usbVID,PID".
>
> .../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 25 ++++++++-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/bluetooth/btusb.c | 59 ++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (76%)
^ permalink raw reply
* Re: [PATCH v3 1/2] iio: adc: hx711: Add DT binding for avia,hx711
From: Rob Herring @ 2016-12-19 22:01 UTC (permalink / raw)
To: Andreas Klinger
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <20161214161640.GA13885@andreas>
On Wed, Dec 14, 2016 at 05:16:40PM +0100, Andreas Klinger wrote:
> Add DT bindings for avia,hx711
> Add vendor avia to vendor list
>
> Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 16 ++++++++++++++++
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 2 files changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
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 v3 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Jonathan Cameron @ 2016-12-19 20:49 UTC (permalink / raw)
To: Andreas Klinger, devicetree, linux-iio
Cc: linux-kernel, robh+dt, pawel.moll, mark.rutland, ijc+devicetree,
galak, knaack.h, lars, pmeerw
In-Reply-To: <20161214161740.GA13896@andreas>
On 14/12/16 16:17, Andreas Klinger wrote:
> This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> cells.
>
> The protocol is quite simple and using GPIOs:
> One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
Youch. Controlling the next conversion via the number of clocks is hideous!
Oh well, guess it's one solution that limits the number of wires needed.
Still not as hideous as some ;) (sht15 I'm looking at you :)
Few comments inline.
Jonathan
>
> The raw value read from the chip is delivered.
> To get a weight one needs to subtract the zero offset and scale it.
>
> Signed-off-by: Andreas Klinger <ak@it-klinger.de>
> ---
> drivers/iio/adc/Kconfig | 18 +++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/hx711.c | 292 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 311 insertions(+)
> create mode 100644 drivers/iio/adc/hx711.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 932de1f9d1e7..918f582288c9 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -205,6 +205,24 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>
> +config HX711
> + tristate "AVIA HX711 ADC for weight cells"
> + depends on GPIOLIB
> + help
> + If you say yes here you get support for AVIA HX711 ADC which is used
> + for weight cells
Typically just called weigh cells rather than weight cells.
One of those ugly bits of English.
> +
> + This driver uses two GPIOs, one for setting the clock and the other
> + one for getting the data
This driver uses two GPIOs, one acts as the clock and controls the channel
selection and gain, the other is used for the measurement data
(or something like that).
> +
> + Currently the raw value is read from the chip and delivered.
> + For getting an actual weight one needs to subtract the
To get an actual weight...
> + zero offset and multiply by a scale factor.
> + This should be done in userspace.
> +
> + This driver can also be built as a module. If so, the module will be
> + called hx711.
> +
> config INA2XX_ADC
> tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> depends on I2C && !SENSORS_INA2XX
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index b1aa456e6af3..d46e289900ef 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_HX711) += hx711.o
> obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> new file mode 100644
> index 000000000000..700281932ff0
> --- /dev/null
> +++ b/drivers/iio/adc/hx711.c
> @@ -0,0 +1,292 @@
> +/*
> + * HX711: analog to digital converter for weight sensor module
> + *
> + * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
No need for this blank line.
> + */
> +#include <linux/err.h>
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/property.h>
> +#include <linux/slab.h>
> +#include <linux/sched.h>
> +#include <linux/delay.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define HX711_GAIN_32 2 /* gain = 32 for channel B */
> +#define HX711_GAIN_64 3 /* gain = 64 for channel A */
> +#define HX711_GAIN_128 1 /* gain = 128 for channel A */
> +
> +struct hx711_data {
> + struct device *dev;
> + struct gpio_desc *gpiod_sck;
> + struct gpio_desc *gpiod_dout;
> + int gain_pulse;
> + struct mutex lock;
> +};
> +
> +static int hx711_reset(struct hx711_data *hx711_data)
> +{
> + int i, val;
> +
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (val) {
> + gpiod_set_value(hx711_data->gpiod_sck, 1);
> + udelay(80);
a comment here on why 80 would be good (it's bigger than 60?)
> + gpiod_set_value(hx711_data->gpiod_sck, 0);
> +
> + for (i = 0; i < 1000; i++) {
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + if (!val)
> + break;
> + /* sleep at least 1 ms */
> + msleep(1);
> + }
> + }
> +
> + return val;
> +}
> +
> +static int hx711_cycle(struct hx711_data *hx711_data)
> +{
> + int val;
> +
/*
* if pre...
> + /* if preempted for more then 60us while SCK is high:
> + * hx711 is going in reset
> + * ==> measuring is false
> + */
> + preempt_disable();
> + gpiod_set_value(hx711_data->gpiod_sck, 1);
I'm reading the datasheet as suggesting you need to wait at least 0.1 microsecs
here...
> + val = gpiod_get_value(hx711_data->gpiod_dout);
> + gpiod_set_value(hx711_data->gpiod_sck, 0);
> + preempt_enable();
> +
> + return val;
> +}
> +
> +static int hx711_read(struct hx711_data *hx711_data)
> +{
> + int i, ret;
> + int value = 0;
> +
> + mutex_lock(&hx711_data->lock);
> +
> + if (hx711_reset(hx711_data)) {
> + dev_err(hx711_data->dev, "reset failed!");
> + mutex_unlock(&hx711_data->lock);
> + return -1;
> + }
> +
> + for (i = 0; i < 24; i++) {
> + value <<= 1;
> + ret = hx711_cycle(hx711_data);
> + if (ret)
> + value++;
> + }
> +
> + value ^= 0x800000;
> +
> + for (i = 0; i < hx711_data->gain_pulse; i++)
> + ret = hx711_cycle(hx711_data);
> +
> + mutex_unlock(&hx711_data->lock);
> +
> + return value;
> +}
> +
> +static int hx711_read_raw(struct iio_dev *iio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct hx711_data *hx711_data = iio_priv(iio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + switch (chan->type) {
> + case IIO_VOLTAGE:
> + *val = hx711_read(hx711_data);
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static ssize_t hx711_gain_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> + int val;
> +
> + switch (hx711_data->gain_pulse) {
> + case HX711_GAIN_32:
> + val = 32;
> + break;
> + case HX711_GAIN_64:
> + val = 64;
> + break;
> + default:
> + val = 128;
> + }
> +
> + return sprintf(buf, "%d\n", val);
> +}
> +
> +static ssize_t hx711_gain_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct hx711_data *hx711_data = iio_priv(dev_to_iio_dev(dev));
> + int ret, val;
> + int gain_save = hx711_data->gain_pulse;
> +
> + ret = kstrtoint((const char *) buf, 10, &val);
> + if (ret)
> + return -EINVAL;
> +
> + switch (val) {
> + case 32:
> + hx711_data->gain_pulse = HX711_GAIN_32;
> + break;
> + case 64:
> + hx711_data->gain_pulse = HX711_GAIN_64;
> + break;
> + case 128:
> + hx711_data->gain_pulse = HX711_GAIN_128;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + dev_dbg(hx711_data->dev, "gain_pulse: %d\n", hx711_data->gain_pulse);
> +
> + /* if gain has changed do a fake read for the new gain to be set
> + * for the next read
> + */
> + if (gain_save != hx711_data->gain_pulse)
> + hx711_read(hx711_data);
> +
> + return len;
> +}
> +
> +static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
> + hx711_gain_show, hx711_gain_store, 0);
> +
> +static struct attribute *hx711_attributes[] = {
> + &iio_dev_attr_gain.dev_attr.attr,
> + NULL,
> +};
> +
As Lars suggested, please use standard ABI (easier if you use the info_mask
elements and do it through read raw...
> +static struct attribute_group hx711_attribute_group = {
> + .attrs = hx711_attributes,
> +};
> +
> +static const struct iio_info hx711_iio_info = {
> + .driver_module = THIS_MODULE,
> + .read_raw = hx711_read_raw,
> + .attrs = &hx711_attribute_group,
> +};
> +
> +static const struct iio_chan_spec hx711_chan_spec[] = {
> + {
new line here is slightly nicer to read.
>.type = IIO_VOLTAGE,
> + .info_mask_separate =
> + BIT(IIO_CHAN_INFO_RAW),
> + },
> +};
> +
> +static int hx711_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct hx711_data *hx711_data = NULL;
> + struct iio_dev *iio;
> + int ret = 0;
> +
> + iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
> + if (!iio) {
> + dev_err(dev, "failed to allocate IIO device\n");
> + return -ENOMEM;
> + }
> +
> + hx711_data = iio_priv(iio);
> + hx711_data->dev = dev;
> +
> + mutex_init(&hx711_data->lock);
> +
> + hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
> + if (IS_ERR(hx711_data->gpiod_sck)) {
> + dev_err(dev, "failed to get sck-gpiod: err=%ld\n",
> + PTR_ERR(hx711_data->gpiod_sck));
> + return PTR_ERR(hx711_data->gpiod_sck);
> + }
> +
> + hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
If there is a reason for getting an input as an output then it wants a comment!
> + if (IS_ERR(hx711_data->gpiod_dout)) {
> + dev_err(dev, "failed to get dout-gpiod: err=%ld\n",
> + PTR_ERR(hx711_data->gpiod_dout));
> + return PTR_ERR(hx711_data->gpiod_dout);
> + }
> +
> + ret = gpiod_direction_input(hx711_data->gpiod_dout);
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
Doesn't the flag above already mean we are in output mode for this pin?
> + if (ret < 0) {
> + dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, iio);
> +
> + iio->name = pdev->name;
> + iio->dev.parent = &pdev->dev;
> + iio->info = &hx711_iio_info;
> + iio->modes = INDIO_DIRECT_MODE;
> + iio->channels = hx711_chan_spec;
> + iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
> +
> + return devm_iio_device_register(dev, iio);
> +}
> +
> +static const struct of_device_id of_hx711_match[] = {
> + { .compatible = "avia,hx711", },
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, of_hx711_match);
> +
> +static struct platform_driver hx711_driver = {
> + .probe = hx711_probe,
> + .driver = {
> + .name = "hx711-gpio",
> + .of_match_table = of_hx711_match,
> + },
> +};
> +
> +module_platform_driver(hx711_driver);
> +
> +MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
> +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hx711-gpio");
> +
>
^ permalink raw reply
* Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support
From: Pierre-Hugues Husson @ 2016-12-19 20:06 UTC (permalink / raw)
To: Liam Girdwood
Cc: Lee Jones, Rob Herring, Mark Rutland, devicetree, linux-kernel,
Mark Brown
In-Reply-To: <20161109140258.25miftfbklwo3apz@sirena.org.uk>
Hi all,
I believe this hasn't been merged.
Is there anything preventing the merge of this patch?
Thanks,
2016-11-09 15:02 GMT+01:00 Mark Brown <broonie@kernel.org>:
> On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote:
>> Extend the driver to support Ricoh RC5T619.
>> Support the additional regulators and slightly different voltage ranges.
>
> Acked-by: Mark Brown <broonie@kernel.org>
^ permalink raw reply
* Re: [PATCH pci/next] PCI: rcar: Add compatible string for r8a7796
From: Yoshihiro Kaneko @ 2016-12-19 19:27 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-pci, Bjorn Helgaas, Simon Horman, Magnus Damm,
Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdVOUUM3hZ0sfTcs5PFqfvrYR9Sk3egibpuxb-4a80U02A@mail.gmail.com>
Hi Geert-san,
Thanks for your review.
2016-12-19 18:49 GMT+09:00 Geert Uytterhoeven <geert@linux-m68k.org>:
> Hi Kaneko-san,
>
> On Sun, Dec 18, 2016 at 1:27 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
>> From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>>
>> This patch adds support for r8a7796.
>>
>> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>> ---
>>
>> This patch is based on the next branch of the pci tree.
>>
>> Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
>> drivers/pci/host/pcie-rcar.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> index eee518d..34712d6 100644
>> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
>> @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
>> "renesas,pcie-r8a7791" for the R8A7791 SoC;
>> "renesas,pcie-r8a7793" for the R8A7793 SoC;
>> "renesas,pcie-r8a7795" for the R8A7795 SoC;
>> + "renesas,pcie-r8a7796" for the R8A7796 SoC;
>> "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
>> "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>>
>> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
>> index aca85be..02e5777 100644
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>> @@ -1078,6 +1078,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
>> { .compatible = "renesas,pcie-rcar-gen2",
>> .data = rcar_pcie_hw_init_gen2 },
>> { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
>> + { .compatible = "renesas,pcie-r8a7796", .data = rcar_pcie_hw_init },
>> { .compatible = "renesas,pcie-rcar-gen3", .data = rcar_pcie_hw_init },
>> {},
>
> Given the driver already matches against "renesas,pcie-rcar-gen3",
> and mainline arch/arm64/boot/dts/renesas/r8a7796.dtsi doesn't have pcie
> nodes yet, I think there's no need to update the driver, only the bindings.
I agree with you.
>
> Hence if you drop the last chunk, you can add my
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I will do it.
Thanks,
kaneko
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v10 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2016-12-19 19:15 UTC (permalink / raw)
To: Peter Chen
Cc: gregkh, stern, ulf.hansson, broonie, sre, robh+dt, shawnguo, rjw,
dbaryshkov, heiko, linux-arm-kernel, p.zabel, devicetree,
pawel.moll, mark.rutland, linux-usb, arnd, s.hauer, mail,
troy.kisky, festevam, oscar, stephen.boyd, linux-pm,
stillcompiling, linux-kernel, mka, vaibhav.hiremath, gary.bisson
In-Reply-To: <1479087359-7547-1-git-send-email-peter.chen@nxp.com>
On Mon, Nov 14, 2016 at 09:35:51AM +0800, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
> Changes for v10:
> - Improve the kernel-doc for power sequence core, including exported APIs and
> main structure. [Patch 2/8]
> - Change Kconfig, and let the user choose power sequence. [Patch 2/8]
> - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not
> be intended to export currently. [Patch 2/8]
> - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8]
Hi Peter,
It is great that you continued the work on this.
I saw (in some previous mails) your repo mentioned:
https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/
Does it contain the recent version of this patchset?
I want to build on top of it fixes for usb3503 on Odroid U3 board.
Best regards,
Krzysztof
>
> Changes for v9:
> - Add Vaibhav Hiremath's reviewed-by [Patch 4/8]
> - Rebase to v4.9-rc1
>
> Changes for v8:
> - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid
> preallocate instances problem which the number of instance is decided at
> compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8]
> - Delete pwrseq_compatible_sample.c which is the demo purpose to show compatible
> match method. [Patch 2/8]
> - Add Maciej S. Szmigiero's tested-by. [Patch 7/8]
>
> Changes for v7:
> - Create kinds of power sequence instance at postcore_initcall, and match
> the instance with node using compatible string, the beneit of this is
> the host driver doesn't need to consider which pwrseq instance needs
> to be used, and pwrseq core will match it, however, it eats some memories
> if less power sequence instances are used. [Patch 2/8]
> - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> use device_node for parameters at pwrseq_on. [Patch 2/8]
> - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> - Tested three pwrseq instances together using both specific compatible string and
> generic libraries.
>
> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
> the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
> at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
> layer's at core's probe
>
> Joshua Clayton (2):
> ARM: dts: imx6qdl: Enable usb node children with <reg>
> ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
> binding-doc: power: pwrseq-generic: add binding doc for generic power
> sequence library
> power: add power sequence library
> binding-doc: usb: usb-device: add optional properties for power
> sequence
> usb: core: add power sequence handling for USB devices
> usb: chipidea: let chipidea core device of_node equal's glue layer
> device of_node
> ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++++
> .../devicetree/bindings/usb/usb-device.txt | 10 +-
> MAINTAINERS | 9 +
> arch/arm/boot/dts/imx6q-evi.dts | 25 +--
> arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-
> arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 21 ++
> drivers/power/pwrseq/Makefile | 2 +
> drivers/power/pwrseq/core.c | 237 +++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 183 ++++++++++++++++
> drivers/usb/Kconfig | 1 +
> drivers/usb/chipidea/core.c | 27 ++-
> drivers/usb/core/hub.c | 41 +++-
> drivers/usb/core/hub.h | 1 +
> include/linux/power/pwrseq.h | 60 ++++++
> 17 files changed, 658 insertions(+), 41 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Rob Herring @ 2016-12-19 18:55 UTC (permalink / raw)
To: Hoegeun Kwon
Cc: thierry.reding, kgene, krzk, devicetree, linux-samsung-soc,
Donghwa Lee, linux-kernel, dri-devel, Hyungwon Hwang
In-Reply-To: <1481695445-13088-2-git-send-email-hoegeun.kwon@samsung.com>
On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756 +++++++++++++++++++++
> 4 files changed, 815 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 0000000..1f41f24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,52 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: core voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin
> + - enable-gpios: a GPIO spec for the panel enable pin
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio pin
Need to specify the GPIOs as active high or low.
> +
> +Optional properties:
> + - display-timings: timings for the connected panel as described by [1]
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + panel@0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
reg doesn't really work here unless this node is a child of the DSI
controller node. But if it is a child node, then you don't need the OF
graph.
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + display-timings {
> + timing-0 {
> + clock-frequency = <0>;
> + hactive = <1440>;
> + vactive = <2560>;
> + hfront-porch = <1>;
> + hback-porch = <1>;
> + hsync-len = <1>;
> + vfront-porch = <1>;
> + vback-porch = <15>;
> + vsync-len = <1>;
> + };
> + };
> +
> + port {
> + dsi_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
From: Rob Herring @ 2016-12-19 18:45 UTC (permalink / raw)
To: Caesar Wang; +Cc: devicetree, linux-kernel, dri-devel, dianders
In-Reply-To: <1481685596-15608-1-git-send-email-wxt@rock-chips.com>
On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote:
> The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel.
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string
From: Rob Herring @ 2016-12-19 18:44 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Adrian Hunter, Ulf Hansson, devicetree, linux-kernel,
Mark Rutland
In-Reply-To: <1481681446-29832-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, Dec 14, 2016 at 11:10:46AM +0900, Masahiro Yamada wrote:
> Add a Socionext SoC specific compatible (suggested by Rob Herring).
>
> No SoC specific data are associated with the compatible strings for
> now, but other SoC vendors may use this IP and want to differentiate
> IP variants in the future.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Changes in v2:
> - Add "uniphier" to the compatible to make it more SoC-specific
>
> Documentation/devicetree/bindings/mmc/sdhci-cadence.txt | 6 ++++--
> drivers/mmc/host/sdhci-cadence.c | 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level
From: Rob Herring @ 2016-12-19 18:38 UTC (permalink / raw)
To: Subhash Jadavani
Cc: Vinayak Holikatti, jejb, Martin K. Petersen, linux-scsi,
Mark Rutland, Hannes Reinecke, Yaniv Gardi, Joao Pinto,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <b326fb4217bb894295e83fe252aa7bf1@codeaurora.org>
On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani
<subhashj@codeaurora.org> wrote:
> On 2016-12-13 12:04, Rob Herring wrote:
>>
>> On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote:
>>>
>>> UFS device and link can be put in multiple different low power modes
>>> hence
>>> UFS driver supports multiple different low power modes. By default UFS
>>> driver selects the default (optimal) low power mode (which gives moderate
>>> power savings and have relatively less enter and exit latencies) but
>>> we might have to tune this default power mode for different chipset
>>> platforms to meet the low power requirements/goals. Hence this patch
>>> adds option to change default UFS low power mode (level).
>>>
>>> Reviewed-by: Yaniv Gardi <ygardi@codeaurora.org>
>>> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
>>> ---
>>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 ++++++
>>> drivers/scsi/ufs/ufshcd-pltfrm.c | 14 ++++++++
>>> drivers/scsi/ufs/ufshcd.c | 39
>>> ++++++++++++++++++++++
>>> drivers/scsi/ufs/ufshcd.h | 4 +--
>>> 4 files changed, 65 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> index a99ed55..c3836c5 100644
>>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>>> @@ -41,6 +41,14 @@ Optional properties:
>>> -lanes-per-direction : number of lanes available per direction -
>>> either 1 or 2.
>>> Note that it is assume same number of lanes is
>>> used both
>>> directions at once. If not specified, default
>>> is 2 lanes per direction.
>>> +- rpm-level : UFS Runtime power management level. Following
>>> PM levels are supported:
>>> + 0 - Both UFS device and Link in active state
>>> (Highest power consumption)
>>> + 1 - UFS device in active state but Link in
>>> Hibern8 state
>>> + 2 - UFS device in Sleep state but Link in
>>> active state
>>> + 3 - UFS device in Sleep state and Link in
>>> hibern8 state (default PM level)
>>> + 4 - UFS device in Power-down state and Link in
>>> Hibern8 state
>>> + 5 - UFS device in Power-down state and Link in
>>> OFF state (Lowest power consumption)
>>> +- spm-level : UFS System power management level. Allowed PM
>>> levels are same as rpm-level.
>>
>>
>> This looks like you are putting policy for Linux into DT.
>>
>> What I would expect to see here is disabling of states that don't work
>> due to some h/w limitation. Otherwise, it is a user decision for what
>> modes to go into. Also, I think link and device states should be
>> separate.
>
>
> Yes, generally default level (3) is good enough (and recommended) for all
> platforms and most likely user is only expected to change this if they see
> issues (most H/W) on their platform or they want even more aggressive power
> state (level-4 or level-5) and ready to take the performance hit associated
> with resume latencies.
What latencies can be tolerated is going to depend on the application
and could vary while running, so putting in DT doesn't make sense. I
would break down settings like this:
broken h/w -> DT
user tuning/config -> sysfs
sensible defaults -> driver
> Also, I think it is better to keep Link and device states tied, one reason
> is that we can't keep device in sleep/active state when Link is in OFF
> state.
The driver can tie the states to together if needed. Just document
what's broken in DT and let the driver make decisions.
Rob
^ permalink raw reply
* [PATCH] gpio: of: Add support for multiple GPIOs in a single GPIO hog
From: Geert Uytterhoeven @ 2016-12-19 18:21 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland
Cc: linux-gpio, devicetree, Geert Uytterhoeven
When listing multiple GPIOs in the "gpios" property of a GPIO hog, only
the first GPIO is affected. The user is left clueless about the
disfunctioning of the other GPIOs specified.
Fix this by adding and documenting support for specifying multiple
GPIOs in a single GPIO hog.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
Documentation/devicetree/bindings/gpio/gpio.txt | 8 +++----
drivers/gpio/gpiolib-of.c | 31 ++++++++++++++++---------
2 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 68d28f62a6f48eca..84ede036f73d09f8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -187,10 +187,10 @@ gpio-controller's driver probe function.
Each GPIO hog definition is represented as a child node of the GPIO controller.
Required properties:
-- gpio-hog: A property specifying that this child node represent a GPIO hog.
-- gpios: Store the GPIO information (id, flags, ...). Shall contain the
- number of cells specified in its parent node (GPIO controller
- node).
+- gpio-hog: A property specifying that this child node represents a GPIO hog.
+- gpios: Store the GPIO information (id, flags, ...) for each GPIO to
+ affect. Shall contain an integer multiple of the number of cells
+ specified in its parent node (GPIO controller node).
Only one of the following properties scanned in the order shown below.
This means that when multiple properties are present they will be searched
in the order presented below and the first match is taken as the intended
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index 92b185f19232f7fc..975b9f6cf4082dfc 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -160,6 +160,7 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
* of_parse_own_gpio() - Get a GPIO hog descriptor, names and flags for GPIO API
* @np: device node to get GPIO from
* @chip: GPIO chip whose hog is parsed
+ * @idx: Index of the GPIO to parse
* @name: GPIO line name
* @lflags: gpio_lookup_flags - returned from of_find_gpio() or
* of_parse_own_gpio()
@@ -170,7 +171,7 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
*/
static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
struct gpio_chip *chip,
- const char **name,
+ unsigned int idx, const char **name,
enum gpio_lookup_flags *lflags,
enum gpiod_flags *dflags)
{
@@ -178,6 +179,7 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
enum of_gpio_flags xlate_flags;
struct of_phandle_args gpiospec;
struct gpio_desc *desc;
+ unsigned int i;
u32 tmp;
int ret;
@@ -196,9 +198,12 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
gpiospec.np = chip_np;
gpiospec.args_count = tmp;
- ret = of_property_read_u32_array(np, "gpios", gpiospec.args, tmp);
- if (ret)
- return ERR_PTR(ret);
+ for (i = 0; i < tmp; i++) {
+ ret = of_property_read_u32_index(np, "gpios", idx * tmp + i,
+ &gpiospec.args[i]);
+ if (ret)
+ return ERR_PTR(ret);
+ }
desc = of_xlate_and_get_gpiod_flags(chip, &gpiospec, &xlate_flags);
if (IS_ERR(desc))
@@ -240,20 +245,24 @@ static int of_gpiochip_scan_gpios(struct gpio_chip *chip)
const char *name;
enum gpio_lookup_flags lflags;
enum gpiod_flags dflags;
+ unsigned int i;
int ret;
for_each_available_child_of_node(chip->of_node, np) {
if (!of_property_read_bool(np, "gpio-hog"))
continue;
- desc = of_parse_own_gpio(np, chip, &name, &lflags, &dflags);
- if (IS_ERR(desc))
- continue;
+ for (i = 0;; i++) {
+ desc = of_parse_own_gpio(np, chip, i, &name, &lflags,
+ &dflags);
+ if (IS_ERR(desc))
+ break;
- ret = gpiod_hog(desc, name, lflags, dflags);
- if (ret < 0) {
- of_node_put(np);
- return ret;
+ ret = gpiod_hog(desc, name, lflags, dflags);
+ if (ret < 0) {
+ of_node_put(np);
+ return ret;
+ }
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ASoC: cs43130: Add devicetree bindings for CS43130
From: Rob Herring @ 2016-12-19 18:13 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: <12f0babd-017e-4aef-b04c-07e783a84c64-k7YZYYsDncjfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>
On Tue, Dec 13, 2016 at 11:47:07AM -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
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 v2 2/2] ASoC: cs35l35: Add device tree documentation for CS35L35
From: Rob Herring @ 2016-12-19 18:10 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: <7900b605-6715-4c95-ac44-381b0f7bc95d-XU/xxMRwCJnfk+Ne4bZl5AC/G2K4zDHf@public.gmane.org>
On Tue, Dec 13, 2016 at 10:26:44AM -0600, Li Xu wrote:
> Add device tree documentation for Cirrus Logic CS35L35
> speaker amplifier
>
> Signed-off-by: Li Xu <li.xu-jGc1dHjMKG3QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/sound/cs35l35.txt | 172 +++++++++++++++++++++
> 1 file changed, 172 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/cs35l35.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/cs35l35.txt b/Documentation/devicetree/bindings/sound/cs35l35.txt
> new file mode 100644
> index 0000000..8b13f67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cs35l35.txt
> @@ -0,0 +1,172 @@
> +CS35L35 Speaker Amplifier
> +
> +Required properties:
> +
> + - compatible : "cirrus,cs35l35"
> +
> + - reg : the I2C address of the device for I2C
> +
> + - VA-supply, VP-supply : power supplies for the device,
> + as covered in
> + Documentation/devicetree/bindings/regulator/regulator.txt.
> +
> + - interrupt-parent : Specifies the phandle of the interrupt controller to
> + which the IRQs from CS35L35 are delivered to.
> + - interrupts : IRQ line info CS35L35.
> + (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> + for further information relating to interrupt properties)
> +
> +Optional properties:
> + - cirrus,reset-gpios : Active low GPIO used to reset the amplifier
You can drop cirrus here. reset-gpios is pretty standard.
> +
> + - cirrus,stereo-config : Boolean to determine if there are 2 AMPs for a
> + Stereo configuration
The example shows this as a node. I prefer a property.
> + - cirrus,audio-channel : Set Location of Audio Signal on Serial Port
> + 0 = Data Packet received on Left I2S Channel
> + 1 = Data Packet received on Right I2S Channel
> +
> + - cirrus,advisory-channel : Set Location of Advisory Signal on Serial Port
> + 0 = Data Packet received on Left I2S Channel
> + 1 = Data Packet received on Right I2S Channel
> +
> + - cirrus,shared-boost : Boolean to enable ClassH tracking of Advisory Signal
> + if 2 Devices share Boost BST_CTL
> +
> + - cirrus,sp-drv-strength : Value for setting the Serial Port drive strength
> + Table 3-10 of the datasheet lists drive-strength specifications
> + 0 = 1x (Default)
> + 1 = .5x
> +
> + - cirrus,bst-pdn-fet-on : Boolean to determine if the Boost PDN control
> + powers down with a rectification FET On or Off. If VSPK is supplied
> + externally then FET is off.
> +
> + - cirrus,boost-ctl-millivolt : Boost Converter control word. Step Size of 100mV
> + 0x00 = (Default) VP
> + 0x01 = 2600mV
> + 0x41 = 9000mV
> +
> + - cirrus,boost-ipk-milliamp : Boost-converter peak current limit.
> + Configures the peak current by monitoring the current through the boost FET.
> + Step size: 112mA
> + 0x00 = 1680mA
> + 0x19 = 4480mA
Either make the values be actual mV or mA (actually, uV and uA are the
standard, see property-units.txt) or drop the unit suffix.
> +
> + - cirrus,amp-gain-zc : Boolean to determine if to use Amplifier gain-change
> + zero-cross
> +
> +Optional H/G Algorithm sub-node:
> +
> + The cs35l35 node can have a single "cirrus,classh-internal-algo" sub-node
> + that will disable automatic control of the internal H/G Algorithm.
> +
> + It is strongly recommended that the Datasheet be referenced when adjusting
> + or using these Class H Algorithm controls over the internal Algorithm.
> + Serious damage can occur to the Device and surrounding components.
> +
> + - cirrus,classh-internal-algo : Sub-node for the Internal Class H Algorithm
> + See Section 4.3 Internal Class H Algorithm in the Datasheet.
> + If not used, the device manages the ClassH Algorithm internally.
> +
> +Optional properties for the "cirrus,classh-internal-algo" Sub-node
> +
> + Section 7.29 Class H Control
> + - cirrus,classh-bst-overide : Boolean
> + - cirrus,classh-bst-max-limit
> + - cirrus,classh-mem-depth
> +
> + Section 7.30 Class H Headroom Control
> + - cirrus,classh-headroom
> +
> + Section 7.31 Class H Release Rate
> + - cirrus,classh-release-rate
> +
> + Section 7.32 Class H Weak FET Drive Control
> + - cirrus,classh-wk-fet-disable
> + - cirrus,classh-wk-fet-delay
> + - cirrus,classh-wk-fet-thld
> +
> + Section 7.34 Class H VP Control
> + - cirrus,classh-vpch-auto
> + - cirrus,classh-vpch-rate
> + - cirrus,classh-vpch-man
> +
> +Optional Monitor Signal Format sub-node:
> +
> + The cs35l35 node can have a single "cirrus,monitor-signal-format" sub-node
> + for adjusting the Depth, Location and Frame of the Monitoring Signals
> + for Algorithms.
> +
> + See Sections 4.8.2 through 4.8.4 Serial-Port Control in the Datasheet
> +
> + -cirrus,monitor-signal-format : Sub-node for the Monitor Signaling Formating
> + on the I2S Port. Each of the 3 8 bit values in the array contain the settings
> + for depth, location, and frame.
> +
> + If not used, the defaults for the 6 monitor signals is used.
> +
> + Sections 7.44 - 7.53 lists values for the depth, location, and frame
> + for each monitoring signal.
> +
> + - cirrus,imon : 3 8 bit values to set the depth, location, and frame
> + of the IMON monitor signal.
> +
> + - cirrus,vmon : 3 8 bit values to set the depth, location, and frame
> + of the VMON monitor signal.
> +
> + - cirrus,vpmon : 3 8 bit values to set the depth, location, and frame
> + of the VPMON monitor signal.
> +
> + - cirrus,vbstmon : 3 8 bit values to set the depth, location, and frame
> + of the VBSTMON monitor signal
> +
> + - cirrus,vpbrstat : 3 8 bit values to set the depth, location, and frame
> + of the VPBRSTAT monitor signal
> +
> + - cirrus,zerofill : 3 8 bit values to set the depth, location, and frame\
stray \
> + of the ZEROFILL packet in the monitor signal
> +
> +Example:
> +
> +cs35l35: audio-codec@20 {
> + compatible = "cirrus,cs35l35";
> + reg = <0x20>;
> + VA-supply = <&dummy_vreg>;
> + VP-supply = <&dummy_vreg>;
> + reset-gpios = <&axi_gpio 54 1>;
> + interrupt-parent = <&gpio8>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> + cirrus,boost-ctl = <0x41>;
> +
> + cirrus,stereo-config {
> + cirrus,audio-channel = <0x00>;
> + cirrus,advisory-channel = <0x01>;
> + cirrus,shared-boost;
> + };
> +
> + cirrus,classh-internal-algo {
> + cirrus,classh-bst-overide;
> + cirrus,classh-bst-max-limit = <0x01>;
> + cirrus,classh-mem-depth = <0x01>;
> + cirrus,classh-release-rate = <0x08>;
> + cirrus,classh-headroom-millivolt = <0x0B>;
> + cirrus,classh-wk-fet-disable = <0x01>;
> + cirrus,classh-wk-fet-delay = <0x04>;
> + cirrus,classh-wk-fet-thld = <0x01>;
> + cirrus,classh-vpch-auto = <0x01>;
> + cirrus,classh-vpch-rate = <0x02>;
> + cirrus,classh-vpch-man = <0x05>;
> + };
> +
> + /* Depth, Location, Frame */
> + cirrus,monitor-signal-format {
> + cirrus,imon = /bits/ 8 <0x03 0x00 0x01>;
> + cirrus,vmon = /bits/ 8 <0x03 0x00 0x00>;
> + cirrus,vpmon = /bits/ 8 <0x03 0x04 0x00>;
> + cirrus,vbstmon = /bits/ 8 <0x03 0x04 0x01>;
> + cirrus,vpbrstat = /bits/ 8 <0x00 0x04 0x00>;
> + cirrus,zerofill = /bits/ 8 <0x00 0x00 0x00>;
> + };
> +
> +};
> --
> 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 v6 1/2] Add OV5647 device tree documentation
From: Rob Herring @ 2016-12-19 17:48 UTC (permalink / raw)
To: Ramiro Oliveira
Cc: mchehab, linux-kernel, linux-media, devicetree, davem, gregkh,
geert+renesas, akpm, linux, hverkuil, dheitmueller, slongerbeam,
lars, robert.jarzmik, pavel, pali.rohar, sakari.ailus,
mark.rutland, CARLOS.PALMINHA
In-Reply-To: <c47834c1c9c2a8e23f41a12c8717601f4a901506.1481639091.git.roliveir@synopsys.com>
On Tue, Dec 13, 2016 at 02:32:36PM +0000, Ramiro Oliveira wrote:
> Create device tree bindings documentation.
>
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
> .../devicetree/bindings/media/i2c/ov5647.txt | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5647.txt b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> new file mode 100644
> index 0000000..46e5e30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov5647.txt
> @@ -0,0 +1,35 @@
> +Omnivision OV5647 raw image sensor
> +---------------------------------
> +
> +OV5647 is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
> +and CCI (I2C compatible) control bus.
> +
> +Required properties:
> +
> +- compatible : "ovti,ov5647";
> +- reg : I2C slave address of the sensor;
> +- clocks : Reference to the xclk clock.
> +- clock-names : Should be "xclk".
> +- clock-frequency: Frequency of the xclk clock
> +
> +The common video interfaces bindings (see video-interfaces.txt) should be
> +used to specify link to the image data receiver. The OV5647 device
> +node should contain one 'port' child node with an 'endpoint' subnode.
Would be good to add optional regulator supply properties, but that can
come later.
> +
> +Example:
> +
> + i2c@0x02000 {
No '0x' or leading 0s on unit addresses.
> + ...
> + ov: camera@0x36 {
ditto.
> + compatible = "ovti,ov5647";
> + reg = <0x36>;
> + clocks = <&camera_clk>;
> + clock-names = "xclk";
> + clock-frequency = <30000000>;
> + port {
> + camera_1: endpoint {
> + remote-endpoint = <&csi1_ep1>;
> + };
> + };
> + };
> + };
> --
> 2.10.2
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host
From: Rob Herring @ 2016-12-19 17:38 UTC (permalink / raw)
To: Ramiro Oliveira
Cc: mark.rutland, mchehab, devicetree, linux-kernel, linux-media,
davem, gregkh, geert+renesas, akpm, linux, hverkuil,
laurent.pinchart+renesas, arnd, sudipm.mukherjee, tiffany.lin,
minghsiu.tsai, jean-christophe.trotin, andrew-ct.chen,
simon.horman, songjun.wu, bparrot, CARLOS.PALMINHA
In-Reply-To: <48a46d2d60fff723e322fdbfb29d533c2d0f5637.1481554324.git.roliveir@synopsys.com>
On Mon, Dec 12, 2016 at 03:00:35PM +0000, Ramiro Oliveira wrote:
> Create device tree bindings documentation for Media and Video Device, as well
> as the DW MIPI CSI-2 Host.
>
> Signed-off-by: Ramiro Oliveira <roliveir@synopsys.com>
> ---
> .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 37 ++++++++
> .../devicetree/bindings/media/snps,plat-ipk.txt | 105 +++++++++++++++++++++
> 2 files changed, 142 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> new file mode 100644
> index 0000000..1caa652
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
> @@ -0,0 +1,37 @@
> +Synopsys DesignWare CSI-2 Host controller
> +
> +Description
> +-----------
> +
> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
> +camera.
> +
> +Required properties:
> +- compatible: shall be "snps,dw-mipi-csi"
You don't have to add them, but this will need SoC specific compatible
strings. Please add a note to that effect.
> +- reg : physical base address and size of the device memory mapped
> + registers;
> +- interrupts : CSI-2 Host interrupt
> +- data-lanes : Number of lanes to be used
> +- output-type : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) These
> + values choose which of the Core outputs will be used, it can be Image Data
> + Interface or Image Pixel Interface.
This is output to a parallel camera interface (e.g. an SoC camera
subsystem)?
> +- phys, phy-names: List of one PHY specifier and identifier string (as defined
> + in Documentation/devicetree/bindings/phy/phy-bindings.txt). This PHY is a MIPI
> + DPHY working in RX mode.
phy-names is pointless when there is only 1.
> +
> +Optional properties(if in IPI mode):
> +- ipi-mode : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
> + This property defines if the controller will use the video timings available
> + in the video stream or if it will use pre-defined ones.
"pre-defined" doesn't sound like the same thing as "automatic"?
> +- ipi-color-mode: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
> + This property defines the width of the IPI bus.
> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No). This property defines
> + if the data is automatically flushed in each vsync or if this process is done
> + manually
> +- virtual-channel: Virtual channel where data is present when in IPI mode. This
> + property chooses the virtual channel which IPI will use to retrieve the video
> + stream.
All these properties seem like they should be common properties or are
these interfaces something Synopsys specific? Or perhaps the interface
is Synopsys specific, but determined by the CSI2 mode?
I think you need to define graph ports for the IPI and IDI interfaces
and the connections. Then perhaps these properties become endpoint
properties.
> +
> +The per-board settings:
> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
Wouldn't the port connect to the camera?
> + as described in video-interfaces.txt[1].
> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> new file mode 100644
> index 0000000..50e9279
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
> @@ -0,0 +1,105 @@
> +Synopsys DesignWare CSI-2 Host IPK Media Device
> +
> +The Synopsys DesignWare CSI-2 Host IPK subsystem comprises of multiple
> +sub-devices represented by separate device tree nodes. Currently this includes:
> +plat-ipk, video-device, and dw-mipi-csi.
> +
> +The sub-subdevices are defined as child nodes of the common 'camera' node which
> +also includes common properties of the whole subsystem not really specific to
> +any single sub-device.
But you don't have any properties defined for the camera node.
> +
> +Common 'camera' node
> +--------------------
> +
> +Required properties:
> +
> +- compatible: must be "snps,plat-ipk", "simple-bus"
> +
> +The 'camera' node must include at least one 'video-device' and one 'dw-mipi-csi'
> +child node.
> +
> +'video-device' device nodes
> +-------------------
Is this a separate block? DMA with no registers is strange. I'm having a
hard time understanding a complete block diagram.
> +
> +Required properties:
> +
> +- compatible: "snps,video-device"
Kind of generic. The IP block is called just "video device"?
> +- dmas, dma-names: List of one DMA specifier and identifier string (as defined
> + in Documentation/devicetree/bindings/dma/dma.txt) per port. Each port
> + requires a DMA channel with the identifier string set to "port" followed by
> + the port index.
port is not what you used in the example.
> +
> +Image sensor nodes
> +------------------
> +
> +The sensor device nodes should be added to their control bus controller (e.g.
> +I2C0) nodes and linked to a port node in the dw-mipi-csi,using the common video
> +interfaces bindings, defined in video-interfaces.txt.
> +
> +Example:
> +
> + i2c@0x02000 {
> + compatible = "snps,designware-i2c";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x02000 0x100>;
> + clock-frequency = <400000>;
> + clocks = <&i2cclk>;
> + interrupts =<0>;
> + ov: camera@0x36 {
Drop the '0x' on unit addresses.
> + compatible = "ovti,ov5647";
> + reg = <0x36>;
> + port {
> + camera_1: endpoint {
> + remote-endpoint = <&csi1_ep1>;
> + clock-lanes = <0>;
> + data-lanes = <1 2 >;
> + };
> + };
> + };
> + };
> +
> +
> + camera {
> + compatible = "snps,plat-ipk", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + video_device: video-device@0x10000 {
> + compatible = "snps,video-device";
> + dmas = <&axi_vdma_0 0>;
> + dma-names = "vdma0";
> + };
> +
> +
> + csi2_1: csi2@0x03000 {
> + compatible = "snps,dw-mipi-csi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = < 0x03000 0x7FF>;
> + interrupts = <2>;
> + data-lanes = <2>;
> + output-type = <2>;
> +
> + phys = <&mipi_phy_ctrl1 0>;
> + phy-names = "csi2-dphy";
> +
> + /*IPI Related Configurations*/
> + ipi-mode = <0>;
> + ipi-color-mode = <0>;
> + ipi-auto-flush = <1>;
> + virtual-channel = <0>;
> +
> + /* Camera MIPI CSI-2 (CSI1) */
> + port@1 {
> + reg = <1>;
> + csi1_ep1: endpoint {
> + remote-endpoint = <&camera_1>;
> + data-lanes = <1 2>;
> + };
> + };
> + };
> + };
> + };
> +
> +The dw-mipi-csi device binding is defined in snps,dw-mipi-csi.txt.
> --
> 2.10.2
>
>
^ permalink raw reply
* Re: [PATCH v2] power: reset: add linkstation-reset driver
From: Roger Shimizu @ 2016-12-19 17:37 UTC (permalink / raw)
To: Sebastian Reichel, Rob Herring
Cc: linux-pm, Andrew Lunn, Ryan Tandy, Martin Michlmayr,
Sylver Bruneau, Herbert Valerio Riedel, Mark Rutland, devicetree
In-Reply-To: <20161219153802.vhcish35qyjbpevj@earth>
Dear Sebastian,
Thanks for your review!
On Tue, Dec 20, 2016 at 12:38 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>
>> .../bindings/power/reset/linkstation-reset.txt | 26 ++++
>> drivers/power/reset/Kconfig | 10 ++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/linkstation-common.c | 124 +++++++++++++++
>> drivers/power/reset/linkstation-common.h | 8 +
>> drivers/power/reset/linkstation-reset.c | 172 +++++++++++++++++++++
>> 6 files changed, 341 insertions(+)
>
> With this being its own driver please merge linkstation-common and
> linkstation-reset. The common part is only used by linkstation-reset
> anyways.
I'll add them into To/Cc list.
>> +/* 4-byte magic hello command to UART1-attached microcontroller */
>> +static const unsigned char linkstation_micon_magic[] = {
>> + 0x1b,
>> + 0x00,
>> + 0x07,
>> + 0x00
>> +};
>
> 4-byte magic hello command? Those are used as uart configuration as
> far as I can see. Just move this directly into reset_cfg:
>
> struct reset_cfg {
> u32 baud;
> u8 lcr;
> u8 ier;
> u8 fcr;
> u8 mcr;
> const unsigned char (*cmd)[MICON_CMD_SIZE];
> };
>
>> +static void linkstation_reset(void)
>> +{
>> + const unsigned divisor = ((tclk + (8 * cfg->baud)) / (16 * cfg->baud));
>> +
>> + pr_err("%s: triggering power-off...\n", __func__);
>> +
>> + /* hijack UART1 and reset into sane state */
>> + writel(0x83, UART1_REG(LCR));
>> + writel(divisor & 0xff, UART1_REG(DLL));
>> + writel((divisor >> 8) & 0xff, UART1_REG(DLM));
>> + writel(cfg->magic[0], UART1_REG(LCR));
>> + writel(cfg->magic[1], UART1_REG(IER));
>> + writel(cfg->magic[2], UART1_REG(FCR));
>> + writel(cfg->magic[3], UART1_REG(MCR));
>> +
>> + /* send the power-off command to PIC */
>> + if(cfg->cmd[0][0] == 1 && cfg->cmd[1][0] == 0) {
>> + /* if it's simply one-byte command, send it directly */
>> + writel(cfg->cmd[0][1], UART1_REG(TX));
>> + }
>
> I guess this optimization can be dropped and you can directly
> call the for loop with uart1_micon_send().
Same response regarding above two comments.
The code is extensible because I want to extend in the future.
Current implementation is just for Linkstation Pro / KuroBox Pro to be
able to power-off.
But for some other model of Linkstation, restart also need similar
command via UART1.
Just one example, Linkstation Pro is ARM based, but it was PowerPC based before.
And the device support still exists in kernel tree:
arch/powerpc/platforms/embedded6xx/linkstation.c
arch/powerpc/platforms/embedded6xx/ls_uart.c
It shows sending "C" to restart and sending "E" to power-off for
PowerPC based Linkstation.
I'm not actually interested in PowerPC based Linkstation, it's just an
example to show the reason to be flexible.
If other part is fine, may I send the v3 patch after merging
linkstation-common.c into linkstation-reset.c?
Thank you!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
^ permalink raw reply
* Re: [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
From: Laurent Pinchart @ 2016-12-19 16:54 UTC (permalink / raw)
To: Rob Herring
Cc: dri-devel, open list:MEDIA DRIVERS FOR RENESAS - FCP,
devicetree@vger.kernel.org, Tomi Valkeinen, Laurent Pinchart
In-Reply-To: <CAL_JsqKBoAJFiOqNhMPzF5VXjdXT2jbWHV0zxfX0gdSz0yGZLQ@mail.gmail.com>
Hi Rob,
On Monday 19 Dec 2016 09:38:49 Rob Herring wrote:
> On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
> >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
> >>> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
> >>>> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
> >>>>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> >>>>>> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> >>>>>>> Document properties common to several display panels in a central
> >>>>>>> location that can be referenced by the panel device tree bindings.
> >>>>>>
> >>>>>> Looks good. Just one comment...
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>> +Connectivity
> >>>>>>> +------------
> >>>>>>> +
> >>>>>>> +- ports: Panels receive video data through one or multiple
> >>>>>>> connections. While
> >>>>>>> + the nature of those connections is specific to the panel type,
> >>>>>>> the
> >>>>>>> + connectivity is expressed in a standard fashion using ports as
> >>>>>>> specified in
> >>>>>>> + the device graph bindings defined in
> >>>>>>> + Documentation/devicetree/bindings/graph.txt.
> >>>>>>
> >>>>>> We allow panels to either use graph binding or be a child of the
> >>>>>> display controller.
> >>>>>
> >>>>> I knew that some display controllers use a phandle to the panel (see
> >>>>> the fsl,panel and nvidia,panel properties), but I didn't know we had
> >>>>> panels as children of display controller nodes. I don't think we
> >>>>> should allow that for anything but DSI panels, as the DT hierarchy is
> >>>>> based on control buses. Are you sure we have other panels instantiated
> >>>>> through that mechanism ?
> >>>
> >>> Some panels have no control bus, so were do we place them?
> >>
> >> I'd say under the root node, like all similar control-less devices.
> >>
> >>> I would say the hierarchy is based on buses with a preference for the
> >>> control bus when there are multiple buses. I'm not a fan of just
> >>> sticking things are the top level.
> >>
> >> OK, so much for my comment a few lines up :-)
> >>
> >> The problem with placing non-DSI panels as children of the display
> >> controller and not using OF graph is that the panel bindings become
> >> dependent of the display controller being used. A display controller
> >> using OF graph would require the panel to do the same, while a display
> >> controller expecting a panel child node (with a specific name) would
> >> require DT properties for the panel node.
>
> Not sure I follow.
Sorry, I meant "would not requite DT properties".
> They become dependent on the controller driver to probe the panel, but the
> contents of the panel node would not be controller dependent.
If a display controller uses OF graph then the panel DT node has to declare
ports. If the display controller doesn't use OF graph but instead expects the
panel to be a direct subnode, or points to the panel using a property such as
fsl,panel, then the panel DT node will not have ports.
> >> I'm also not sure the complexity of OF graph is really that prohibitive
> >> if you compare it to panels as child nodes. To get the panel driver to
> >> bind to the panel DT node the display controller driver would need to
> >> create a platform device for the panel and register it. That's not very
> >> difficult, but parsing a single port and endpoint isn't either (and we
> >> could even provide a helper function for that, a version of
> >> of_drm_find_panel() that would take as an argument the display controller
> >> device node instead of the panel device node).
> >
> > Ping ?
> >
> > I'd like to standardize on one model for panel DT bindings, but I'm not
> > sure that can be achieved given that we already have multiple competing
> > models. In any case, is that blocking to merge this patch ? I only
> > describe one connectivity model here as that's what my panel driver
> > needs, but I have no issue adding more models later when needed. I
> > believe this patch is a good step forward already.
>
> It is an improvement which I appreciate, so yes I guess we can address
> it later when needed.
Thank you. Can I get your ack then ? :-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Rob Herring @ 2016-12-19 16:37 UTC (permalink / raw)
To: Anurup M
Cc: mark.rutland, will.deacon, linux-kernel, devicetree,
linux-arm-kernel, anurup.m, zhangshaokun, tanxiaojun, xuwei5,
sanil.kumar, john.garry, gabriele.paoloni, shiju.jose,
wangkefeng.wang, linuxarm, shyju.pv
In-Reply-To: <1481129759-159533-1-git-send-email-anurup.m@huawei.com>
On Wed, Dec 07, 2016 at 11:55:59AM -0500, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache and MN PMU.
> 3) Add child nodes of L3C and MN in djtag bindings example.
>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 25 ++++++
> .../devicetree/bindings/arm/hisilicon/pmu.txt | 98 ++++++++++++++++++++++
> 2 files changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> index 733498e..c885507 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
> scl-id = <0x02>;
>
> /* All connecting components will appear as child nodes */
> +
> + pmul3c0 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hisi-pmu-mn-v1";
> + module-id = <0x0b>;
> + };
> };
>
> Example 2: Djtag for IO die
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..e2160ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,98 @@
> +Hisilicon SoC HiP05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
> +system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
> +PMU devices are independent and have hardware logic to gather statistics and
> +performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
> +4 cpu-cores each.
> +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> +
> +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> +
> +L3 cache
> +---------
> +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
> +L3 cache banks. Each L3 cache bank have separate DT nodes.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hisi-pmu-l3c-v1" for v1 hw in HiP05/06 chips
> + (b) "hisilicon,hisi-pmu-l3c-v2" for v2 hw in HiP07 chip
Use SoC specific compatible strings.
> +
> + - module-id : This property is a combination of two values in the below order.
> + a) Module ID: The module identifier for djtag.
> + b) Instance or Bank ID: This will identify the L3 cache bank
> + or instance.
Needs a vendor prefix.
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt lines used by this L3 cache bank.
How many interrupts and what are they?
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Miscellaneous Node
> +------------------
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
> +for each SCCL.
Similar comments here.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hisi-pmu-mn-v1" for v1 hw in HiP05/06 chips
> + (b) "hisilicon,hisi-pmu-mn-v2" for v2 hw in HiP07 chip
> +
> + - module-id : Module ID to input for djtag.
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt lines used by this PMU.
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Example:
> +
> + djtag0: djtag@80010000 {
> + compatible = "hisilicon,hisi-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + scl-id = <0x02>;
> +
> + pmul3c0 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hisi-pmu-mn-v1";
> + module-id = <0x0b>;
> + };
> + };
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH v2 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Rob Herring @ 2016-12-19 16:31 UTC (permalink / raw)
To: Anurup M
Cc: mark.rutland, will.deacon, linux-kernel, devicetree,
linux-arm-kernel, anurup.m, zhangshaokun, tanxiaojun, xuwei5,
sanil.kumar, john.garry, gabriele.paoloni, shiju.jose,
wangkefeng.wang, linuxarm, shyju.pv
In-Reply-To: <1481129719-159487-1-git-send-email-anurup.m@huawei.com>
On Wed, Dec 07, 2016 at 11:55:19AM -0500, Anurup M wrote:
> From: Tan Xiaojun <tanxiaojun@huawei.com>
>
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>
> Signed-off-by: Tan Xiaojun <tanxiaojun@huawei.com>
> Signed-off-by: Anurup M <anurup.m@huawei.com>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> new file mode 100644
> index 0000000..733498e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -0,0 +1,41 @@
> +The Hisilicon Djtag is an independent component which connects with some other
> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> +in the chip. The djtag controls access to connecting modules of CPU and IO
> +dies.
> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> +are accessed by djtag during real time debugging. In IO die there are connecting
> +components like RSA. These components appear as devices atatched to djtag bus.
> +
> +Hisilicon HiP05/06 djtag for CPU and HiP05 IO die
> +Required properties:
> + - compatible : "hisilicon,hisi-djtag-v1"
These need SoC specific compatible strings. They probably should
also include cpu or io in the compatible string. I would expect there
are things like events, triggers, or component connections for debug
that are SoC specifc.
> + - reg : Register address and size
> + - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Hisilicon HiP06 djtag for IO die and HiP07 djtag for CPU and IO die
> +Required properties:
> + - compatible : "hisilicon,hisi-djtag-v2"
Same here.
> + - reg : Register address and size
> + - scl-id : The Super Cluster ID for CPU or IO die
> +
> +Example 1: Djtag for CPU die
> +
> + /* for Hisilicon HiP05 djtag for CPU Die */
> + djtag0: djtag@80010000 {
> + compatible = "hisilicon,hisi-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + scl-id = <0x02>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> +
> +Example 2: Djtag for IO die
> +
> + /* for Hisilicon HiP05 djtag for IO Die */
> + djtag1: djtag@d0000000 {
> + compatible = "hisilicon,hisi-djtag-v1";
> + reg = <0x0 0xd0000000 0x0 0x10000>;
> + scl-id = <0x01>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> --
> 2.1.4
>
^ 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