* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Rob Herring @ 2016-12-19 22:35 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1481841044-4314-2-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
>
> ---
> Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
> drivers/nfc/trf7970a.c | 13 ++++++++++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> index 9dda879..208f045 100644
> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> @@ -21,6 +21,7 @@ Optional SoC Specific Properties:
> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
> where an extra byte is returned by Read Multiple Block commands issued
> to Type 5 tags.
> +- vdd_io_1v8: Set to specify that the trf7970a io voltage should be set to 1.8V
Use the regulator binding and provide a fixed 1.8V supply.
> - crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
>
>
> @@ -45,6 +46,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
> irq-status-read-quirk;
> en2-rf-quirk;
> t5t-rmb-extra-byte-quirk;
> + vdd_io_1v8;
> crystal_27mhz;
> status = "okay";
> };
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-19 22:31 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1481841044-4314-1-git-send-email-glansberry@gmail.com>
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff@kuvee.com>
>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
> drivers/nfc/trf7970a.c | 42 ++++++++++++++++------
> 2 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> index 32b35a0..9dda879 100644
> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> @@ -21,6 +21,8 @@ Optional SoC Specific Properties:
> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
> where an extra byte is returned by Read Multiple Block commands issued
> to Type 5 tags.
> +- crystal_27mhz: Set to specify that the input frequency to the trf7970a is 27.12MHz
> +
Can't you use 'clock-frequency = "27000000";'?
>
> Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>
> @@ -43,6 +45,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
> irq-status-read-quirk;
> en2-rf-quirk;
> t5t-rmb-extra-byte-quirk;
> + crystal_27mhz;
> status = "okay";
> };
> };
^ permalink raw reply
* Re: [PATCH V5 2/8] Documentation: devicetree: thermal: da9062/61 TJUNC temperature binding
From: Rob Herring @ 2016-12-19 22:28 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Eduardo Valentin, LINUX-KERNEL, LINUX-PM,
Mark Rutland, Zhang Rui, Dmitry Torokhov, Guenter Roeck,
LINUX-INPUT, LINUX-WATCHDOG, Lee Jones, Liam Girdwood,
Lukasz Luba, Mark Brown, Support Opensource, Wim Van Sebroeck
In-Reply-To: <ae903f7c3c6325420b90c7f691655d902d137d1f.1481828921.git.stwiss.opensource@diasemi.com>
On Thu, Dec 15, 2016 at 07:08:39PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Device tree binding information for DA9062 and DA9061 thermal junction
> temperature monitor.
>
> Binding descriptions for the DA9061 and DA9062 thermal TJUNC supervisor
> device driver, using a single THERMAL_TRIP_HOT trip-wire and allowing for
> a configurable polling period for over-temperature polling.
>
> This patch also adds two examples, one for DA9062 and one for DA9061. The
> DA9061 example uses a fall-back compatible string for the DA9062.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.9
>
> v4 -> v5
> - Rebased from v4.8 to v4.9
> - Updates from comments by Eduardo Valentin
> - Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
> thermal core polling-delay-passive as part of the device tree
> initialisation
> - Remove Acked-by Rob Herring
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 2/9] doc: DT: venus: binding document for Qualcomm video driver
From: Rob Herring @ 2016-12-19 22:21 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <1481822544-29900-3-git-send-email-stanimir.varbanov@linaro.org>
On Thu, Dec 15, 2016 at 07:22:17PM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> .../devicetree/bindings/media/qcom,venus.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: ehci-omap: remove the unnecessary newline
From: Rob Herring @ 2016-12-19 22:20 UTC (permalink / raw)
To: yegorslists; +Cc: linux-kernel, devicetree, mark.rutland
In-Reply-To: <1481817370-28242-2-git-send-email-yegorslists@googlemail.com>
On Thu, Dec 15, 2016 at 04:56:10PM +0100, yegorslists@googlemail.com wrote:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
> ---
> Documentation/devicetree/bindings/usb/ehci-omap.txt | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
Rob
^ permalink raw reply
* 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
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