* [PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
From: Chen-Yu Tsai @ 2017-05-03 3:16 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170503031658.29299-1-wens-jdAy2FN1RRM@public.gmane.org>
The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.
Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index e9c5a1d9834a..34b2a9249a94 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -6,6 +6,7 @@ Required properties :
- "allwinner,sun6i-a31-ccu"
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
+ - "allwinner,sun8i-a83t-ccu"
- "allwinner,sun8i-h3-ccu"
- "allwinner,sun8i-h3-r-ccu"
- "allwinner,sun8i-v3s-ccu"
@@ -18,6 +19,7 @@ Required properties :
- clocks: phandle to the oscillators feeding the CCU. Two are needed:
- "hosc": the high frequency oscillator (usually at 24MHz)
- "losc": the low frequency oscillator (usually at 32kHz)
+ On the A83T, this is the internal 16MHz oscillator divided by 512
- clock-names: Must contain the clock names described just above
- #clock-cells : must contain 1
- #reset-cells : must contain 1
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/8] clk: sunxi-ng: Add support for A83T CCU
From: Chen-Yu Tsai @ 2017-05-03 3:16 UTC (permalink / raw)
To: Maxime Ripard, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi everyone,
(Resent with devicetree mailing list CC-ed.)
This is v2 of my A83T CCU series. This is for 4.13.
Changes since v1:
- Dropped two patches that were merged
- Added clk core flag to disable caching of clock phases
- Added support for multiple variable pre-dividers
- Merged "pll-periph-ahb1" pre-divider clock into "ahb1" clock
with multiple variable pre-dividers
- Introduced new class of phase clocks that return -ENOTSUPP
when the clock is in new timing mode
- Force mmc2 clock to new timing mode
- Added back mmc2 output and sample clocks
- Fixed bit ops for forcing audio PLL configuration
- Added requirement for "losc" clock in device tree binding
- Stripped leading 0 in device node name
- Updated subject prefixes for various patches
Patch 1 adds a compatible string for the A83T CCU to the sunxi-ccu
bindings.
Patch 2 adds a CLK_GET_PHASE_NOCACHE flag to the clk core, asking it
not to cache clock phase values. This is similar to CLK_GET_RATE_NOCACHE.
Patch 5 has a compile time dependency on this patch, for the flag value.
Patch 3 adds a new class of phase clocks that check the new timing mode
bit, and returns an error if it is set, which indicates the phase delays
no longer apply. This is a clean way to signal which timing mode the mmc
clock is in, without using any custom functions or callbacks. We don't
support runtime switching of modes.
Patch 4 adds support for multiple variable pre-dividers to the sunxi-ng
mux class.
Patch 5 adds the driver for the A83T CCU.
Patch 6 adds the CCU device nodes, and fixes up any existing clock
phandles in the dtsi, without using the macros.
Patch 7 sets the clock accuracy for the main oscillator.
Patch 8 is for the next -rc2, switch the clock indices from raw numbers
to macros we introduced with the driver. This will be updated if more
peripherals are introduced in the same cycle.
Let me know what you think.
Cover letter excerpt from v1:
This is yet another series that adds support for the A83T CCU.
The A83T CCU has a mix of new styled (like the A80) clocks at
old (like A3x) offsets. Some differences include:
- D1/D2 style PLL clocks
- divisible audio module clocks
- new timing mode for mmc2 module clock
Regards
ChenYu
Chen-Yu Tsai (8):
dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
clk: Provide option to query hardware for clk phase
clk: sunxi-ng: Add class of phase clocks supporting MMC new timing
modes
clk: sunxi-ng: Support multiple variable pre-dividers
clk: sunxi-ng: Add driver for A83T CCU
ARM: sun8i: a83t: Add CCU device nodes
ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator
ARM: sun8i: a83t: Switch to CCU device tree binding macros
.../devicetree/bindings/clock/sunxi-ccu.txt | 2 +
arch/arm/boot/dts/sun8i-a83t.dtsi | 19 +-
drivers/clk/clk.c | 6 +-
drivers/clk/sunxi-ng/Kconfig | 10 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 911 +++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-a83t.h | 64 ++
drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-r.c | 10 +-
drivers/clk/sunxi-ng/ccu-sun8i-v3s.c | 10 +-
drivers/clk/sunxi-ng/ccu_mux.c | 15 +-
drivers/clk/sunxi-ng/ccu_mux.h | 13 +-
drivers/clk/sunxi-ng/ccu_phase.c | 47 ++
drivers/clk/sunxi-ng/ccu_phase.h | 16 +
include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 ++++
include/dt-bindings/reset/sun8i-a83t-ccu.h | 98 +++
include/linux/clk-provider.h | 1 +
21 files changed, 1363 insertions(+), 50 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h
--
2.11.0
^ permalink raw reply
* Re: [PATCH RFC] Documentation/devicetree: Add specification for FSI busses
From: Brad Bishop @ 2017-05-03 2:36 UTC (permalink / raw)
To: Jeremy Kerr
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <1493704508-27119-1-git-send-email-jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
> On May 2, 2017, at 1:55 AM, Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org> wrote:
>
> This change introduces a proposed layout for describing FSI busses in
> the device tree. While the bus is probe-able, we'd still like a method
> of describing subordinate (eg i2c) busses that are behind FSI devices.
>
> The FSI core will be responsible for matching probed slaves & engines to
> their device tree nodes, so the FSI device drivers' probe() functions
> will be passed a struct device with the appropriate of_node populated
> where a matching DT node is found.
>
> RFC at this stage, so I'd welcome any feedback.
>
> Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
Acked-by: Brad Bishop <bradleyb-r5pk2Da7Bxt8sGd51Jp2sdBPR1lH4CV8@public.gmane.org>
with some very inconsequential nits...
> ---
> Documentation/devicetree/bindings/fsi/fsi.txt | 144 ++++++++++++++++++++++++++
> 1 file changed, 144 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
>
> diff --git a/Documentation/devicetree/bindings/fsi/fsi.txt b/Documentation/devicetree/bindings/fsi/fsi.txt
> new file mode 100644
> index 0000000..b5e85c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fsi/fsi.txt
> @@ -0,0 +1,144 @@
> +FSI bus & engine generic device tree bindings
> +=============================================
> +
> +The FSI bus is probe-able, so Linux is able to enumerate FSI slaves, and
> +engines within those slaves. However, we have a facility to match devicetree
> +nodes to probed engines. This allows for fsi engines to expose non-probeable
> +busses, which are then exposed by the device tree. For example, a FSI engine
> +that is an I2C master - the I2C bus can be described by the device tree under
> +the engine's device tree node.
> +
> +FSI masters may require their own DT nodes (to describe the master HW itself);
> +that requirement is defined by the master's implementation, and is described by
> +the fsi-master-* binding specifications.
> +
> +Under the masters' nodes, we can describe the bus topology using nodes to
> +represent the FSI slaves and their slave engines. As a basic outline:
> +
> + fsi-master {
an FSI master
> + /* top-level of FSI bus topology, bound to a FSI master driver and
> + * exposes a FSI bus */
an FSI bus
> +
> + fsi-slave@<link,id> {
> + /* this node defines the FSI slave device, and is handled
> + * entirely with FSI core code */
> +
> + fsi-slave-engine@<addr> {
> + /* this node defines the engine endpoint & address range, which
> + * is bound to the relevant fsi device driver */
> + ...
> + };
> +
> + fsi-slave-engine@<addr> {
> + ...
> + };
> +
> + };
> + };
> +
> +Note that since the bus is probe-able, some (or all) of the topology may
> +not be described; this binding only provides an optional facility for
> +adding subordinate device tree nodes as children of FSI engines.
> +
> +FSI masters
> +-----------
> +
> +FSI master nodes declare themselves as such with the "fsi-master" compatible
> +value. It's likely that an implementation-specific compatible value will
> +be needed as well, for example:
> +
> + compatible = "fsi-master-gpio", "fsi-master";
> +
> +Since the master nodes describe the top-level of the FSI topology, they also
> +need to declare the FSI-standard addressing scheme. This requires two cells for
> +addresses (link index and slave ID), and no size:
> +
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> +FSI slaves
> +----------
> +
> +Slaves are identified by a (link-index, slave-id) pair, so require two cells
> +for an address identifier. Since these are not a range, no size cells are
> +required. For an example, a slave on link 1, with ID 2, could be represented
> +as:
> +
> + cfam@1,2 {
> + reg = <1 2>;
> + [...];
> + }
> +
> +Each slave provides an address-space, under which the engines are accessible.
> +That address space has a maximum of 23 bits, so we use one cell to represent
> +addresses and sizes in the slave address space:
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> +
> +FSI engines (devices)
> +---------------------
> +
> +Engines are identified by their address under the slaves' address spaces. We
> +use a single cell for address and size. Engine nodes represent the endpoint
> +FSI device, and are passed to those FSI device drivers' ->probe() functions.
> +
> +For example, for a slave using a single 0x400-byte page starting at address
> +0xc00:
> +
> + engine@c00 {
> + reg = <0xc00 0x400>;
> + };
> +
> +
> +Full example
> +------------
> +
> +Here's an example that illustrates:
> + - a FSI master
an FSI master
> + - connected to a FSI slave
an FSI slave
> + - that contains an engine that is an I2C master
> + - connected to an I2C EEPROM
> +
> +The FSI master may be connected to additional slaves, and slaves may have
> +additional engines, but they don't necessarily need to be describe in the
> +device tree if no extra platform information is required.
> +
> + /* The GPIO-based FSI master node, describing the top level of the
> + * FSI bus
> + */
> + gpio-fsi {
> + compatible = "fsi-master-gpio", "fsi-master";
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + /* A FSI slave (aka. CFAM) at link 0, ID 0. */
> + cfam@0,0 {
> + reg = <0 0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* FSI engine at 0xc00, using a single page. In this example,
> + * it's an I2C master controller, so subnodes describe the
> + * I2C bus.
> + */
> + i2c-controller@c00 {
> + reg = <0xc00 0x400>;
> +
> + /* Engine-specific data. In this case, we're describing an
> + * I2C bus, so we're conforming to the generic I2C binding
> + */
> + compatible = "ibm,fsi-i2c";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* I2C endpoint device: an Atmel EEPROM */
> + eeprom@50 {
> + compatible = "atmel,24c256";
> + reg = <0x50>;
> + pagesize = <64>;
> + };
> + };
> + };
> + };
> --
> 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 v5] media: platform: Renesas IMR driver
From: Laurent Pinchart @ 2017-05-02 21:17 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sergei Shtylyov, Rob Herring, Mark Rutland, Mauro Carvalho Chehab,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Media Mailing List, Linux-Renesas, Konstantin Kozhevnikov
In-Reply-To: <CAMuHMdV5-aMx4KuqShm47XtORJK8rMKzw6FUs2Hjsxia+jPfxg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Wednesday 22 Mar 2017 10:34:16 Geert Uytterhoeven wrote:
> On Thu, Mar 9, 2017 at 9:08 PM, Sergei Shtylyov wrote:
> > --- /dev/null
> > +++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
> > @@ -0,0 +1,27 @@
> > +Renesas R-Car Image Renderer (Distortion Correction Engine)
> > +-----------------------------------------------------------
> > +
> > +The image renderer, or the distortion correction engine, is a drawing
> > processor
> > +with a simple instruction system capable of referencing video capture
> > data or
> > +data in an external memory as 2D texture data and performing texture
> > mapping
> > +and drawing with respect to any shape that is split into triangular
> > objects.
> > +
> > +Required properties:
> > +
> > +- compatible: "renesas,<soctype>-imr-lx4", "renesas,imr-lx4" as a
> > fallback for
> > + the image renderer light extended 4 (IMR-LX4) found in the R-Car gen3
> > SoCs,
> > + where the examples with <soctype> are:
> > + - "renesas,r8a7795-imr-lx4" for R-Car H3,
> > + - "renesas,r8a7796-imr-lx4" for R-Car M3-W.
>
> Laurent: what do you think about the need for SoC-specific compatible
> values for the various IM* blocks?
There's no documented IP core version register, but when dumping all
configuration registers on H3 and M3-W I noticed that register 0x002c, not
documented in the datasheet, reads 0x14060514 on all four IMR instances in H3,
and 0x20150505 on both instances in M3-W.
This looks like a version register to me. If my assumption is correct, we
could do without any SoC-specific compatible string.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 2/4] iio: Documentation: Add max9611 sysfs documentation
From: Geert Uytterhoeven @ 2017-05-02 19:21 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Wolfram Sang, Magnus Damm, Laurent Pinchart, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald, Rob Herring,
Mark Rutland, linux-iio, Linux-Renesas,
devicetree@vger.kernel.org
In-Reply-To: <1491488454-22468-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
> Add documentation for max9611 driver.
> Document attributes describing value of shunt resistor installed between
> RS+ and RS- voltage sense inputs.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611 b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> new file mode 100644
> index 0000000..6d2d2b0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-max9611
> @@ -0,0 +1,17 @@
> +What: /sys/bus/iio/devices/iio:deviceX/in_power_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio@vger.kernel.org
> +Description: The value of the shunt resistor used to compute power drain on
> + common input voltage pin (RS+). In Ohms.
> +
> +What: /sys/bus/iio/devices/iio:deviceX/in_current_shunt_resistor
> +Date: March 2017
> +KernelVersion: 4.12
> +Contact: linux-iio@vger.kernel.org
> +Description: The value of the shunt resistor used to compute current flowing
> + between RS+ and RS- voltage sense inputs. In Ohms.
> +
> +These attributes describe a single physical component, exposed as two distinct
> +attributes as it is used to calculate two different values: power load and
> +current flowing between RS+ and RS- inputs.
On my Salvator-X, the value is "5.000", which matches milli-Ohms?
DT says: "shunt-resistor-micro-ohms = <5000>;"
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
* [PATCH] qcom: ipq4019: fix i2c_0 node
From: Christian Lamparter @ 2017-05-02 19:19 UTC (permalink / raw)
To: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andy Gross, chrisrblake93-Re5JQEeQqe8AvxtiuMwx3w, David Brown
This patch fixes two typos in the i2c_0 node for the ipq4019.
The reg property length is just 0x600. The core clock is
GCC_BLSP1_QUP1_I2C_APPS_CLK. GCC_BLSP1_QUP2_I2C_APPS_CLK is
used by the second i2c.
Fixes: e76b4284b520ba3 ("qcom: ipq4019: add i2c node to ipq4019 SoC and DK01 device tree")
Signed-off-by: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index b7a24af8f47b..4b7d97275c62 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -154,10 +154,10 @@
i2c_0: i2c@78b7000 {
compatible = "qcom,i2c-qup-v2.2.1";
- reg = <0x78b7000 0x6000>;
+ reg = <0x78b7000 0x600>;
interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_AHB_CLK>,
- <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+ <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>;
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 07/23] drivers/fsi: Implement slave initialisation
From: Christopher Bostic @ 2017-05-02 18:58 UTC (permalink / raw)
To: Joel Stanley
Cc: Rob Herring, Mark Rutland, Russell King,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
Greg KH, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jeremy Kerr,
Linux Kernel Mailing List, Andrew Jeffery, Alistair Popple,
Benjamin Herrenschmidt
In-Reply-To: <CACPK8XeQnqD3TV_+38hTjb8Qf4R7Um6Eztuun-T6vTMvigw+cQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 5/2/17 1:24 AM, Joel Stanley wrote:
> On Tue, Apr 11, 2017 at 5:16 AM, Christopher Bostic
> <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
>> From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>>
>> Implement fsi_slave_init: if we can read a chip ID, create fsi_slave
>> devices and register with the driver core.
>>
>> Includes changes from Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>.
>>
>> Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>> ---
>> drivers/fsi/fsi-core.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 64 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
>> index 6e1cfdf..c705ca2 100644
>> --- a/drivers/fsi/fsi-core.c
>> +++ b/drivers/fsi/fsi-core.c
>> @@ -17,9 +17,12 @@
>> #include <linux/fsi.h>
>> #include <linux/idr.h>
>> #include <linux/module.h>
>> +#include <linux/slab.h>
>>
>> #include "fsi-master.h"
>>
>> +#define FSI_SLAVE_SIZE_23b 0x800000
>> +
>> static DEFINE_IDA(master_ida);
>>
>> struct fsi_slave {
>> @@ -114,11 +117,70 @@ static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
>> addr, val, size);
>> }
>>
>> +static void fsi_slave_release(struct device *dev)
>> +{
>> + struct fsi_slave *slave = to_fsi_slave(dev);
>> +
>> + kfree(slave);
>> +}
>> +
>> static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id)
>> {
>> - /* todo: initialise slave device, perform engine scan */
>> + struct fsi_slave *slave;
>> + uint32_t chip_id;
>> + uint8_t crc;
>> + int rc;
>> +
>> + /* Currently, we only support single slaves on a link, and use the
>> + * full 23-bit address range
>> + */
>> + if (id != 0)
>> + return -EINVAL;
>> +
>> + rc = fsi_master_read(master, link, id, 0, &chip_id, sizeof(chip_id));
>> + if (rc) {
>> + dev_warn(&master->dev, "can't read slave %02x:%02x %d\n",
>> + link, id, rc);
> When I boot a system with this driver loaded, I get his warning:
>
> [ 9.740000] usbhid: USB HID core driver
> [ 9.840000] fsi0: can't read slave 00:00 -5
> [ 9.840000] NET: Registered protocol family 10
>
> Two things:
>
> There's a space in front of "fsi0".
Hi Joel,
Will correct.
>
> This warning isn't useful at that point. The slave is not readable as
> the FSI master is not present (the P9 hasn't been turned on). Can we
> avoid printing the warning at boot?
Yes agreed. Will remove the warning in that case.
Thanks,
Chris
>
> Cheers,
>
> Joel
>
>> + return -ENODEV;
>> + }
>> + chip_id = be32_to_cpu(chip_id);
>> +
>> + crc = fsi_crc4(0, chip_id, 32);
>> + if (crc) {
>> + dev_warn(&master->dev, "slave %02x:%02x invalid chip id CRC!\n",
>> + link, id);
>> + return -EIO;
>> + }
>> +
>> + dev_info(&master->dev, "fsi: found chip %08x at %02x:%02x:%02x\n",
>> + chip_id, master->idx, link, id);
>> +
>> + /* We can communicate with a slave; create the slave device and
>> + * register.
>> + */
>> + slave = kzalloc(sizeof(*slave), GFP_KERNEL);
>> + if (!slave)
>> + return -ENOMEM;
>> +
>> + slave->master = master;
>> + slave->dev.parent = &master->dev;
>> + slave->dev.release = fsi_slave_release;
>> + slave->link = link;
>> + slave->id = id;
>> + slave->size = FSI_SLAVE_SIZE_23b;
>> +
>> + dev_set_name(&slave->dev, "slave@%02x:%02x", link, id);
>> + rc = device_register(&slave->dev);
>> + if (rc < 0) {
>> + dev_warn(&master->dev, "failed to create slave device: %d\n",
>> + rc);
>> + put_device(&slave->dev);
>> + return rc;
>> + }
>> +
>> + /* todo: perform engine scan */
>>
>> - return -ENODEV;
>> + return rc;
>> }
>>
>> /* FSI master support */
>> --
>> 1.8.2.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
^ permalink raw reply
* Re: [PATCH v5 4/4] arm64: dts: salvator-x: Add current sense amplifiers
From: Geert Uytterhoeven @ 2017-05-02 18:46 UTC (permalink / raw)
To: Simon Horman
Cc: Jacopo Mondi, Wolfram Sang, Magnus Damm, Laurent Pinchart,
Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Rob Herring, Mark Rutland, linux-iio,
Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <20170420091624.GM3760@verge.net.au>
Hi Simon,
On Thu, Apr 20, 2017 at 11:16 AM, Simon Horman <horms@verge.net.au> wrote:
> On Wed, Apr 19, 2017 at 10:40:21AM +0200, Geert Uytterhoeven wrote:
>> Hi Jacopo,
>>
>> On Thu, Apr 6, 2017 at 4:20 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>> > [PATCH v5 4/4] arm64: dts: salvator-x: Add current sense amplifiers
>>
>> This should be "arm64: dts: r8a7796: salvator-x: Add current sense amplifiers".
>> Perhaps Simon can just fix that himself while applying?
>
> Done :)
Apparently not...
Resending for board breakout compensation...
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 1/2] Input: pwm-vibra: new driver
From: Dmitry Torokhov @ 2017-05-02 18:23 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Tony Lindgren, Rob Herring, linux-input,
linux-omap, devicetree, linux-kernel
In-Reply-To: <20170502162726.11577-2-sebastian.reichel@collabora.co.uk>
Hi Sebastian,
On Tue, May 02, 2017 at 06:27:25PM +0200, Sebastian Reichel wrote:
> Provide a simple driver for PWM controllable vibrators. It
> will be used by Motorola Droid 4.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> ---
> .../devicetree/bindings/input/pwm-vibrator.txt | 60 ++++
> drivers/input/misc/Kconfig | 11 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/pwm-vibra.c | 348 +++++++++++++++++++++
> 4 files changed, 420 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/pwm-vibrator.txt
> create mode 100644 drivers/input/misc/pwm-vibra.c
>
> diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> new file mode 100644
> index 000000000000..c35be4691366
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
> @@ -0,0 +1,60 @@
> +* PWM vibrator device tree bindings
> +
> +Registers a PWM device as vibrator.
> +
> +Required properties:
> +- compatible: should be
> + * "pwm-vibrator"
> + For vibrators controlled using the PWM channel's duty cycle (higher duty means
> + the vibrator becomes stronger).
> + * "motorola,mapphone-pwm-vibrator"
> + For vibrator found in Motorola Droid 4. This vibrator generates a pulse for
> + every rising edge, so its controlled using a duty cycle of 50% and changing
> + the period time.
> +- pwm-names: Should contain "enable" and optionally "direction"
> +- pwms: Should contain a PWM handle for each entry in pwm-names
> +
> +Example from Motorola Droid 4:
> +
> +&omap4_pmx_core {
> + vibrator_direction_pin: pinmux_vibrator_direction_pin {
> + pinctrl-single,pins = <
> + OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */
> + >;
> + };
> +
> + vibrator_enable_pin: pinmux_vibrator_enable_pin {
> + pinctrl-single,pins = <
> + OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */
> + >;
> + };
> +};
> +
> +/ {
> + pwm8: dmtimer-pwm {
> + pinctrl-names = "default";
> + pinctrl-0 = <&vibrator_direction_pin>;
> +
> + compatible = "ti,omap-dmtimer-pwm";
> + #pwm-cells = <3>;
> + ti,timers = <&timer8>;
> + ti,clock-source = <0x01>;
> + };
> +
> + pwm9: dmtimer-pwm {
> + pinctrl-names = "default";
> + pinctrl-0 = <&vibrator_enable_pin>;
> +
> + compatible = "ti,omap-dmtimer-pwm";
> + #pwm-cells = <3>;
> + ti,timers = <&timer9>;
> + ti,clock-source = <0x01>;
> + };
> +
> + vibrator {
> + compatible = "pwm-vibrator";
> + pwms = <&pwm8 0 1000000000 0>,
> + <&pwm9 0 1000000000 0>;
> + pwm-names = "enable", "direction";
> + };
> +};
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 5b6c52210d20..d8e0b25eb217 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -571,6 +571,17 @@ config INPUT_PWM_BEEPER
> To compile this driver as a module, choose M here: the module will be
> called pwm-beeper.
>
> +config INPUT_PWM_VIBRA
> + tristate "PWM vibrator support"
> + depends on PWM
> + help
> + Say Y here to get support for PWM based vibrator devices.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called pwm-vibra.
> +
> config INPUT_GPIO_ROTARY_ENCODER
> tristate "Rotary encoders connected to GPIO pins"
> depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index b10523f2878e..9a6517f5458c 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -58,6 +58,7 @@ obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR) += pm8xxx-vibrator.o
> obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
> obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
> obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
> +obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
> obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
> obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
> obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
> diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> new file mode 100644
> index 000000000000..a7d36d88679a
> --- /dev/null
> +++ b/drivers/input/misc/pwm-vibra.c
> @@ -0,0 +1,348 @@
> +/*
> + * PWM vibrator driver
> + *
> + * Copyright (C) 2017 Collabora Ltd.
> + *
> + * Based on previous work from:
> + * Copyright (C) 2012 Dmitry Torokhov <dmitry.torokhov@gmail.com>
> + *
> + * Based on PWM beeper driver:
> + * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.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.
> + */
> +
> +#define DEBUG
> +
> +#include <linux/input.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +/**
> + * Motorola Droid 4 (also known as mapphone), has a vibrator, which pulses
> + * 1x on rising edge. Increasing the pwm period results in more pulses per
> + * second, but reduces intensity. There is also a second channel to control
> + * the vibrator's rotation direction to increase effect. The following
> + * numbers were determined manually. Going below 12.5 Hz means, clearly
> + * noticeable pauses and at 30 Hz the vibration is just barely noticable
> + * anymore.
> + */
> +#define MAPPHONE_MIN_FREQ 125 /* 12.5 Hz */
> +#define MAPPHONE_MAX_FREQ 300 /* 30.0 Hz */
> +
> +struct pwm_vibrator_hw {
> + void (*setup_pwm)(u16 level, struct pwm_state *);
> + void (*setup_pwm_dir)(u16 level, struct pwm_state *);
> +};
> +
> +struct pwm_vibrator {
> + struct input_dev *input;
> + struct pwm_device *pwm;
> + struct pwm_device *pwm_dir;
> + struct regulator *vcc;
> +
> + struct work_struct play_work;
> + u16 level;
> +
> + const struct pwm_vibrator_hw *hw;
> +};
> +
> +static void pwm_vibrator_setup_generic(u16 level, struct pwm_state *state)
> +{
> + /* period is configured by platform, duty cycle controls strength */
> + pwm_set_relative_duty_cycle(state, level, 0xffff);
> +}
> +
> +static void pwm_vibrator_setup_dir_generic(u16 level, struct pwm_state *state)
> +{
> + /* period is configured by platform, duty cycle controls strength */
> + pwm_set_relative_duty_cycle(state, 50, 100);
> +}
> +
> +static struct pwm_vibrator_hw pwm_vib_hw_generic = {
> + .setup_pwm = pwm_vibrator_setup_generic,
> + .setup_pwm_dir = pwm_vibrator_setup_dir_generic,
> +};
> +
> +static void pwm_vibrator_setup_mapphone(u16 level, struct pwm_state *state)
> +{
> + unsigned int freq;
> +
> + /* convert [0, 0xffff] -> [MAPPHONE_MAX_FREQ, MAPPHONE_MIN_FREQ] */
> + freq = 0xffff - level;
> + freq *= MAPPHONE_MAX_FREQ - MAPPHONE_MIN_FREQ;
> + freq /= 0xffff;
> + freq += MAPPHONE_MIN_FREQ;
> +
> + state->period = DIV_ROUND_CLOSEST_ULL((u64) NSEC_PER_SEC * 10, freq);
> + pwm_set_relative_duty_cycle(state, 50, 100);
> +}
> +
> +static struct pwm_vibrator_hw pwm_vib_hw_mapphone = {
> + .setup_pwm = pwm_vibrator_setup_mapphone,
> + .setup_pwm_dir = pwm_vibrator_setup_mapphone,
> +};
> +
> +static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> +{
> + struct device *pdev = vibrator->input->dev.parent;
> + struct pwm_state state;
> + int err;
> +
> + dev_dbg(pdev, "start vibrator with level=0x%04x", vibrator->level);
> +
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d", err);
> + return err;
> + }
> +
> + pwm_get_state(vibrator->pwm, &state);
> + state.enabled = true;
> +
> + vibrator->hw->setup_pwm(vibrator->level, &state);
> + dev_dbg(pdev, "period=%u", state.period);
> +
> + err = pwm_apply_state(vibrator->pwm, &state);
> + if (err) {
> + dev_err(pdev, "failed to apply pwm state: %d", err);
> + return err;
> + }
> +
> + if (vibrator->pwm_dir) {
> + pwm_get_state(vibrator->pwm_dir, &state);
> + state.enabled = true;
> +
> + /* always control via period */
> + vibrator->hw->setup_pwm_dir(vibrator->level, &state);
> +
> + err = pwm_apply_state(vibrator->pwm_dir, &state);
> + if (err) {
> + dev_err(pdev, "failed to apply dir-pwm state: %d", err);
> + pwm_disable(vibrator->pwm);
> + return err;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
> +{
> + struct device *pdev = vibrator->input->dev.parent;
> +
> + dev_dbg(pdev, "stop vibrator");
> +
> + regulator_disable(vibrator->vcc);
> +
> + if (vibrator->pwm_dir)
> + pwm_disable(vibrator->pwm_dir);
> + pwm_disable(vibrator->pwm);
> +}
> +
> +static void vibra_play_work(struct work_struct *work)
> +{
> + struct pwm_vibrator *vibrator = container_of(work,
> + struct pwm_vibrator, play_work);
> +
> + if (vibrator->level)
> + pwm_vibrator_start(vibrator);
> + else
> + pwm_vibrator_stop(vibrator);
> +}
> +
> +static int pwm_vibrator_play_effect(struct input_dev *dev, void *data,
> + struct ff_effect *effect)
> +{
> + struct pwm_vibrator *vibrator = input_get_drvdata(dev);
> +
> + vibrator->level = effect->u.rumble.strong_magnitude;
> + if (!vibrator->level)
> + vibrator->level = effect->u.rumble.weak_magnitude;
> +
> + schedule_work(&vibrator->play_work);
> +
> + return 0;
> +}
> +
> +static int pwm_vibrator_probe(struct platform_device *pdev)
> +{
> + struct pwm_vibrator *vibrator;
> + struct input_dev *input;
> + struct pwm_state state;
> + int err;
> +
> + vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
> + if (!vibrator)
> + return -ENOMEM;
> +
> + input = devm_input_allocate_device(&pdev->dev);
> + if (!vibrator || !input)
No need to check "!vibrator" here.
> + return -ENOMEM;
> +
> + vibrator->input = input;
> +
> + vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
> + err = PTR_ERR_OR_ZERO(vibrator->vcc);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request regulator: %d",
> + err);
> + return err;
> + }
> +
> + vibrator->pwm = devm_pwm_get(&pdev->dev, "enable");
> + err = PTR_ERR_OR_ZERO(vibrator->pwm);
> + if (err) {
> + if (err != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "Failed to request main pwm: %d",
> + err);
> + return err;
> + }
> +
> + INIT_WORK(&vibrator->play_work, vibra_play_work);
> +
> + /* Sync up PWM state and ensure it is off. */
> + pwm_init_state(vibrator->pwm, &state);
> + state.enabled = false;
> + err = pwm_apply_state(vibrator->pwm, &state);
> + if (err) {
> + dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
> + err);
> + return err;
> + }
> +
> + vibrator->pwm_dir = devm_pwm_get(&pdev->dev, "direction");
> + err = PTR_ERR_OR_ZERO(vibrator->pwm_dir);
> + if (err == -ENODATA) {
> + vibrator->pwm_dir = NULL;
> + } else if (err == -EPROBE_DEFER) {
> + return err;
> + } else if (err) {
> + dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
> + return err;
> + } else {
> + /* Sync up PWM state and ensure it is off. */
> + pwm_init_state(vibrator->pwm_dir, &state);
> + state.enabled = false;
> + err = pwm_apply_state(vibrator->pwm_dir, &state);
> + if (err) {
> + dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
> + err);
> + return err;
> + }
> + }
> +
> + vibrator->hw = of_device_get_match_data(&pdev->dev);
> + if (!vibrator->hw)
> + vibrator->hw = &pwm_vib_hw_generic;
> +
> + input->name = "pwm-vibrator";
> + input->id.bustype = BUS_HOST;
> + input->dev.parent = &pdev->dev;
> +
> + input_set_drvdata(input, vibrator);
> + input_set_capability(input, EV_FF, FF_RUMBLE);
> +
> + err = input_ff_create_memless(input, NULL, pwm_vibrator_play_effect);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't create FF dev: %d", err);
> + return err;
> + }
> +
> + err = input_register_device(input);
> + if (err) {
> + dev_err(&pdev->dev, "Couldn't register input dev: %d", err);
> + return err;
> + }
> +
> + platform_set_drvdata(pdev, vibrator);
> +
> + dev_info(&pdev->dev, "pwm-vibrator probed.");
Please drop, our boot is noisy enough and you should get message from
input core when you register device.
> +
> + return 0;
> +}
> +
> +static int pwm_vibrator_remove(struct platform_device *pdev)
> +{
> + struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
> +
> + cancel_work_sync(&vibrator->play_work);
> + pwm_vibrator_stop(vibrator);
Maybe put it into input->stop() method?
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int pwm_vibrator_suspend(struct device *dev)
__maybe_unused.
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
> + struct input_dev *input = vibrator->input;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&input->event_lock, flags);
> + if (vibrator->level)
> + pwm_vibrator_stop(vibrator);
What about work that might be running?
> + spin_unlock_irqrestore(&input->event_lock, flags);
> +
> + return 0;
> +}
> +
> +static int pwm_vibrator_resume(struct device *dev)
__maybe_unused.
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
> + struct input_dev *input = vibrator->input;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&input->event_lock, flags);
> + if (vibrator->level)
> + pwm_vibrator_start(vibrator);
> + spin_unlock_irqrestore(&input->event_lock, flags);
> +
> + return 0;
> +}
> +#endif
> +
> +static SIMPLE_DEV_PM_OPS(pwm_vibrator_pm_ops,
> + pwm_vibrator_suspend, pwm_vibrator_resume);
> +
> +#ifdef CONFIG_OF
> +
> +#define PWM_VIB_COMPAT(of_compatible, cfg) { \
> + .compatible = of_compatible, \
> + .data = &cfg, \
> +}
> +
> +static const struct of_device_id pwm_vibra_dt_match_table[] = {
> + PWM_VIB_COMPAT("pwm-vibrator", pwm_vib_hw_generic),
> + PWM_VIB_COMPAT("motorola,mapphone-pwm-vibrator", pwm_vib_hw_mapphone),
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, pwm_vibra_dt_match_table);
> +#endif
> +
> +static struct platform_driver pwm_vibrator_driver = {
> + .probe = pwm_vibrator_probe,
> + .remove = pwm_vibrator_remove,
> + .driver = {
> + .name = "pwm-vibrator",
> + .pm = &pwm_vibrator_pm_ops,
> + .of_match_table = of_match_ptr(pwm_vibra_dt_match_table),
> + },
> +};
> +module_platform_driver(pwm_vibrator_driver);
> +
> +MODULE_AUTHOR("Sebastian Reichel <sre@kernel.org>");
> +MODULE_DESCRIPTION("PWM vibrator driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:pwm-vibrator");
> --
> 2.11.0
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v5 4/9] i2c: core: call of_i2c_setup_smbus_alert in i2c_register_adapter
From: kbuild test robot @ 2017-05-02 17:42 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
sre-DgEjT+Ai2ygdnm+yROfE0A, peda-koto5C5qi+TLoDKTGw+V6w,
preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1493628599-30552-5-git-send-email-preid-qgqNFa1JUf/o2iN0hyhwsIdd74u8MsAO@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]
Hi Phil,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11 next-20170501]
[cannot apply to wsa/i2c/for-next battery/master]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Phil-Reid/Add-sbs-manager-with-smbalert-support/20170501-170247
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `nsp_usb3_phy_init':
binder.c:(.text+0x13744): undefined reference to `mdiobus_write'
binder.c:(.text+0x13760): undefined reference to `mdiobus_write'
binder.c:(.text+0x1377c): undefined reference to `mdiobus_write'
binder.c:(.text+0x13798): undefined reference to `mdiobus_write'
binder.c:(.text+0x137b4): undefined reference to `mdiobus_write'
drivers/built-in.o:binder.c:(.text+0x137e8): more undefined references to `mdiobus_write' follow
drivers/built-in.o: In function `i2c_register_adapter':
>> binder.c:(.text+0x21646c): undefined reference to `of_i2c_setup_smbus_alert'
drivers/built-in.o: In function `mdio_module_init':
binder.c:(.init.text+0x7dd4): undefined reference to `mdio_driver_register'
drivers/built-in.o: In function `mdio_module_exit':
binder.c:(.exit.text+0x19c): undefined reference to `mdio_driver_unregister'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61325 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [media] platform: add video-multiplexer subdevice driver
From: Peter Rosin @ 2017-05-02 17:42 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer, Rob Herring,
Sakari Ailus, Pavel Machek, Steve Longerbeam, Vladimir Zapolskiy
In-Reply-To: <1493738491.2391.20.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-05-02 17:21, Philipp Zabel wrote:
> On Sat, 2017-04-29 at 23:42 +0200, Peter Rosin wrote:
>> On 2017-04-29 23:29, Peter Rosin wrote:
>>> On 2017-04-28 16:13, Philipp Zabel wrote:
>>>> This driver can handle SoC internal and external video bus multiplexers,
>>>> controlled by mux controllers provided by the mux controller framework,
>>>> such as MMIO register bitfields or GPIOs. The subdevice passes through
>>>> the mbus configuration of the active input to the output side.
>>>>
>>>> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>> This has been last sent as part of the i.MX media series.
>>>>
>>>> Changes since https://patchwork.kernel.org/patch/9647869/:
>>>> - Split out the actual mux operation to be provided by the mux controller
>>>> framework [1]. GPIO and MMIO control can be provided by individual mux
>>>> controller drivers [2][3].
>>>> [1] https://patchwork.kernel.org/patch/9695837/
>>>> [2] https://patchwork.kernel.org/patch/9695839/
>>>> [3] https://patchwork.kernel.org/patch/9704509/
>>>> - Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
>>>> vidsw with video_mux.
>>>> - Made the mux inactive by default, only activated by user interaction.
>>>> - Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
>>>> - Reuse subdev.entity.num_pads instead of keeping our own count.
>>>> - Removed implicit link disabling. Instead, trying to enable a second
>>>> sink pad link yields -EBUSY.
>>>> - Merged _async_init into _probe.
>>>> - Removed superfluous pad index check from _set_format.
>>>> - Added is_source_pad helper to tell source and sink pads apart.
>>>> - Removed test for status property in endpoint nodes. Disable the remote
>>>> device or sever the endpoint link to disable a sink pad.
>>>> ---
>>>> drivers/media/platform/Kconfig | 6 +
>>>> drivers/media/platform/Makefile | 2 +
>>>> drivers/media/platform/video-mux.c | 341 +++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 349 insertions(+)
>>>> create mode 100644 drivers/media/platform/video-mux.c
>>>>
>>>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>>>> index c9106e105baba..b046a6d39fee5 100644
>>>> --- a/drivers/media/platform/Kconfig
>>>> +++ b/drivers/media/platform/Kconfig
>>>> @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
>>>> To compile this driver as a module, choose M here: the
>>>> module will be called arv.
>>>>
>>>> +config VIDEO_MUX
>>>> + tristate "Video Multiplexer"
>>>> + depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && MULTIPLEXER
>>>> + help
>>>> + This driver provides support for N:1 video bus multiplexers.
>>>> +
>>>> config VIDEO_OMAP3
>>>> tristate "OMAP 3 Camera support"
>>>> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
>>>> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
>>>> index 349ddf6a69da2..fd2735ca3ff75 100644
>>>> --- a/drivers/media/platform/Makefile
>>>> +++ b/drivers/media/platform/Makefile
>>>> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
>>>>
>>>> obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
>>>>
>>>> +obj-$(CONFIG_VIDEO_MUX) += video-mux.o
>>>> +
>>>> obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
>>>> obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
>>>> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
>>>> diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
>>>> new file mode 100644
>>>> index 0000000000000..419541729f67e
>>>> --- /dev/null
>>>> +++ b/drivers/media/platform/video-mux.c
>>>> @@ -0,0 +1,341 @@
>>>> +/*
>>>> + * video stream multiplexer controlled via mux control
>>>> + *
>>>> + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>> + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>>>
>>> 2017?
>>>
>>>> + *
>>>> + * 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.
>>>> + */
>>>> +
>>>> +#include <linux/err.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/mux/consumer.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/of_graph.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <media/v4l2-async.h>
>>>> +#include <media/v4l2-device.h>
>>>> +#include <media/v4l2-subdev.h>
>>>> +#include <media/v4l2-of.h>
>>>> +
>>>> +struct video_mux {
>>>> + struct v4l2_subdev subdev;
>>>> + struct media_pad *pads;
>>>> + struct v4l2_mbus_framefmt *format_mbus;
>>>> + struct v4l2_of_endpoint *endpoint;
>>>> + struct mux_control *mux;
>>>> + int active;
>>>> +};
>>>> +
>>>> +static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
>>>> +{
>>>> + return container_of(sd, struct video_mux, subdev);
>>>> +}
>>>> +
>>>> +static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
>>>> +{
>>>> + return pad == vmux->subdev.entity.num_pads - 1;
>>>> +}
>>>> +
>>>> +static int video_mux_link_setup(struct media_entity *entity,
>>>> + const struct media_pad *local,
>>>> + const struct media_pad *remote, u32 flags)
>>>> +{
>>>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>>>> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
>>>> + int ret;
>>>> +
>>>> + /*
>>>> + * The mux state is determined by the enabled sink pad link.
>>>> + * Enabling or disabling the source pad link has no effect.
>>>> + */
>>>> + if (is_source_pad(vmux, local->index))
>>>> + return 0;
>>>> +
>>>> + dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
>>>> + remote->entity->name, remote->index, local->entity->name,
>>>> + local->index, flags & MEDIA_LNK_FL_ENABLED);
>>>> +
>>>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>>>> + if (vmux->active == local->index)
>>>
>>> Here, you shortcut the mux_control_select_trylock test and return "OK"
>>> based on a driver-local variable that is intended to keep track of mux
>>> ownership.
>>>
>>>> + return 0;
>>>> +
>>>> + if (vmux->active >= 0)
>>>
>>> Here too (and this check is not needed, the situation will be covered by
>>> the mux_control_try_select call).
>>>
>>>> + return -EBUSY;
>>>> +
>>>> + dev_dbg(sd->dev, "setting %d active\n", local->index);
>>>> + ret = mux_control_try_select(vmux->mux, local->index);
>>>> + if (ret < 0)
>>>> + return ret;
>>>> + vmux->active = local->index;
>>>> + } else {
>>>> + if (vmux->active != local->index)
>>>> + return 0;
>>>> +
>>>> + dev_dbg(sd->dev, "going inactive\n");
>>>> + mux_control_deselect(vmux->mux);
>>>
>>> But here you let go of the mux *before* you clear the driver-local
>>> ownership indicator. That looks suspicious. My guess is that this is
>>> "safe" because the upper layers has some serialization, but I don't
>>> know. Anyway, even if there is something saving you in the upper
>>> layers, it looks out of order and unneeded. I would have moved the
>>> below vmux->active = -1; statement up to before the above deselect.
>>>
>>> With that fixed, mux usage looks good to me, so you can add an Acked-
>>> by from me if you wish (goes for the bindings patch as well).
>>
>> Ouch, that was a bit too soon. If there is *no* serialization in the
>> upper layers, this is *not* ok, even with my reordering. There must be
>> only one call to mux_control_deselect, and w/o serialization there
>> is a race where you might get multiple deselect calls when several
>> callers makes it through the active != index check before any of them
>> manages to set active = -1. That race must be taken care of!
>
> Thank you, I've resent a version with a mutex lock around vmux->active.
I had a bunch of ifs in the above message, so I'm not sure it's needed.
I would expect there to be a lock outside somewhere in the media layer.
A cursory look gets me to media-entity.c and media_entity_setup_link()
which does have a mutex. But I'm no media expert, so maybe there are other
ways of getting to video_mux_link_setup that I'm not aware of?
If you do end up relying on external locking, a comment saying so would
be nice. Or even better, some __must_hold markup if possible?
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: add Gateworks Ventana GW5600 support
From: Tim Harvey @ 2017-05-02 17:39 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492197481-16638-1-git-send-email-tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
The Gateworks Ventana GW5600 is a media-centric single-board computer based on
the NXP IMX6 SoC with the following features:
* PoE (emulated 802.3af)
* IMX6 DualLite Soc (supports IMX6S,IMX6DL,IMX6Q)
* 1GiB DDR3 DRAM (supports up to 4GiB)
* 8GB eMMC
* 1x microSD connector
* Gateworks System Controller:
- hardware watchdog
- hardware monitor
- pushbutton controller
- EEPROM storage
- power control
* 1x bi-color USER LED
* 1x front-panel pushbutton
* 1x front-panel GbE
* 2x front panel USB 2.0
* 1x front panel USB OTG
* 1x SIM socket
* 1x miniPCIe socket with SATA (mSATA)
* 1x miniPCIe socket with USB 2.0 (Modem)
* 1x miniPCIe socket with PCIe, USB 2.0, and SIM
* RS232/RS485 serial
- 2x RS232 UARTs (off-board connector)
- 1x RS485 (loading option)
* 4x digital I/O signals (PWM/I2C/GPIO/5V/3.3V options)
* 1x analog input (0 to 5V)
* 1x CAN (loading option)
* off-board LVDS:
- I2C
- 12V
- LED driver (4x 330mA strings)
- matrix keypad controller (8row x 10col)
- I2S
- dual-channel LVDS
- PWM
* off-board video input:
- 16bit parallel / MIPI (IPU1_CSI0)
* GPS (loading option)
* Analog Video Input (CVBS) 3 inputs (1 active at a time)
* Analog Audio Input/Output (2ch Line level, optional MIC/HP drivers)
* HDMI out
* JTAG programmable
* Inertial Module
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
v2:
- use hyphen instead of underscore in node names
- indicate address in memory node name
- drop leading zero's in unit-addresses
- dropped unnecessary container node in iomux
- sort iomux pinctrl nodes alphabetically
- remove extra newlines in pinctrl defines
- use MATRIX_KEY() macro and event codes from input bindings
- removed unused fixed-clock
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-gw560x.dts | 55 +++
arch/arm/boot/dts/imx6q-gw560x.dts | 59 +++
arch/arm/boot/dts/imx6qdl-gw560x.dtsi | 749 ++++++++++++++++++++++++++++++++++
4 files changed, 865 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-gw560x.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw560x.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-gw560x.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 8774143..0ffe732 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -352,6 +352,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw551x.dtb \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
+ imx6dl-gw560x.dtb \
imx6dl-gw5903.dtb \
imx6dl-gw5904.dtb \
imx6dl-hummingboard.dtb \
@@ -397,6 +398,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw551x.dtb \
imx6q-gw552x.dtb \
imx6q-gw553x.dtb \
+ imx6q-gw560x.dtb \
imx6q-gw5903.dtb \
imx6q-gw5904.dtb \
imx6q-h100.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-gw560x.dts b/arch/arm/boot/dts/imx6dl-gw560x.dts
new file mode 100644
index 0000000..21bdfaf
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-gw560x.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-gw560x.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 DualLite/Solo GW560X";
+ compatible = "gw,imx6dl-gw560x", "gw,ventana", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-gw560x.dts b/arch/arm/boot/dts/imx6q-gw560x.dts
new file mode 100644
index 0000000..735f2bb
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-gw560x.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-gw560x.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 Dual/Quad GW560X";
+ compatible = "gw,imx6q-gw560x", "gw,ventana", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-gw560x.dtsi b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
new file mode 100644
index 0000000..d894dde
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-gw560x.dtsi
@@ -0,0 +1,749 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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 file 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ /* these are used by bootloader for disabling nodes */
+ aliases {
+ led0 = &led0;
+ led1 = &led1;
+ led2 = &led2;
+ ssi0 = &ssi1;
+ usb0 = &usbh1;
+ usb1 = &usbotg;
+ };
+
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ backlight-display {
+ compatible = "pwm-backlight";
+ pwms = <&pwm4 0 5000000>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100
+ >;
+ default-brightness-level = <100>;
+ };
+
+ backlight-keypad {
+ compatible = "gpio-backlight";
+ gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ default-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led0: user1 {
+ label = "user1";
+ gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1: user2 {
+ label = "user2";
+ gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
+ default-state = "off";
+ };
+
+ led2: user3 {
+ label = "user3";
+ gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
+ default-state = "off";
+ };
+ };
+
+ memory@10000000 {
+ reg = <0x10000000 0x40000000>;
+ };
+
+ pps {
+ compatible = "pps-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pps>;
+ gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_5p0v: regulator-5p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "5P0V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_12p0v: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "12P0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_1p4v: regulator-vddsoc {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_soc";
+ regulator-min-microvolt = <1400000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usb_otg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "fsl,imx6q-ventana-sgtl5000",
+ "fsl,imx-audio-sgtl5000";
+ model = "sgtl5000-audio";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&sgtl5000>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HP_OUT";
+ mux-int-port = <1>;
+ mux-ext-port = <4>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan>;
+ status = "okay";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ phy-reset-gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ eeprom1: eeprom@50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+
+ eeprom2: eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+
+ eeprom3: eeprom@52 {
+ compatible = "atmel,24c02";
+ reg = <0x52>;
+ pagesize = <16>;
+ };
+
+ eeprom4: eeprom@53 {
+ compatible = "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ };
+
+ pca9555: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ ds1672: rtc@68 {
+ compatible = "dallas,ds1672";
+ reg = <0x68>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ sgtl5000: codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+
+ tca8418: keypad@34 {
+ compatible = "ti,tca8418";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_keypad>;
+ reg = <0x34>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ linux,keymap = < MATRIX_KEY(0x00, 0x01, BTN_0)
+ MATRIX_KEY(0x00, 0x00, BTN_1)
+ MATRIX_KEY(0x01, 0x01, BTN_2)
+ MATRIX_KEY(0x01, 0x00, BTN_3)
+ MATRIX_KEY(0x02, 0x00, BTN_4)
+ MATRIX_KEY(0x00, 0x03, BTN_5)
+ MATRIX_KEY(0x00, 0x02, BTN_6)
+ MATRIX_KEY(0x01, 0x03, BTN_7)
+ MATRIX_KEY(0x01, 0x02, BTN_8)
+ MATRIX_KEY(0x02, 0x02, BTN_9)
+ >;
+ keypad,num-rows = <4>;
+ keypad,num-columns = <4>;
+ };
+
+ ltc3676: pmic@3c {
+ compatible = "lltc,ltc3676";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ reg = <0x3c>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ /* VDD_DDR (1+R1/R2 = 2.105) */
+ reg_vdd_ddr: sw2 {
+ regulator-name = "vddddr";
+ regulator-min-microvolt = <868310>;
+ regulator-max-microvolt = <1684000>;
+ lltc,fb-voltage-divider = <221000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_ARM (1+R1/R2 = 1.931) */
+ reg_vdd_arm: sw3 {
+ regulator-name = "vddarm";
+ regulator-min-microvolt = <796551>;
+ regulator-max-microvolt = <1544827>;
+ lltc,fb-voltage-divider = <243000 261000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ linux,phandle = <®_vdd_arm>;
+ };
+
+ /* VDD_1P8 (1+R1/R2 = 2.505): GPS/VideoIn/ENET-PHY */
+ reg_1p8v: sw4 {
+ regulator-name = "vdd1p8";
+ regulator-min-microvolt = <1033310>;
+ regulator-max-microvolt = <2004000>;
+ lltc,fb-voltage-divider = <301000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_1P0 (1+R1/R2 = 1.39): PCIe/ENET-PHY */
+ reg_1p0v: ldo2 {
+ regulator-name = "vdd1p0";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1050000>;
+ lltc,fb-voltage-divider = <78700 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_AUD_1P8: Audio codec */
+ reg_aud_1p8v: ldo3 {
+ regulator-name = "vdd1p8a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ };
+
+ /* VDD_HIGH (1+R1/R2 = 4.17) */
+ reg_3p0v: ldo4 {
+ regulator-name = "vdd3p0";
+ regulator-min-microvolt = <3023250>;
+ regulator-max-microvolt = <3023250>;
+ lltc,fb-voltage-divider = <634000 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ egalax_ts: touchscreen@4 {
+ compatible = "eeti,egalax_ts";
+ reg = <0x04>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ldb {
+ fsl,dual-channel;
+ status = "okay";
+
+ lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: hsd100pxn1 {
+ clock-frequency = <65000000>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <220>;
+ hfront-porch = <40>;
+ vback-porch = <21>;
+ vfront-porch = <7>;
+ hsync-len = <60>;
+ vsync-len = <10>;
+ };
+ };
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio4 31 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>; /* MX6_DIO1 */
+ status = "disabled";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>; /* MX6_DIO2 */
+ status = "disabled";
+};
+
+&pwm4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm4>;
+ status = "okay";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ uart-has-rtscts;
+ rts-gpios = <&gpio7 1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&uart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <8>;
+ vmmc-supply = <®_3p3v>;
+ non-removable;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ cd-gpios = <&gpio7 0 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_3p3v>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ /* AUD4 */
+ MX6QDL_PAD_DISP0_DAT20__AUD4_TXC 0x130b0
+ MX6QDL_PAD_DISP0_DAT21__AUD4_TXD 0x110b0
+ MX6QDL_PAD_DISP0_DAT22__AUD4_TXFS 0x130b0
+ MX6QDL_PAD_DISP0_DAT23__AUD4_RXD 0x130b0
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0 /* AUD4_MCK */
+ /* AUD6 */
+ MX6QDL_PAD_DI0_PIN2__AUD6_TXD 0x130b0
+ MX6QDL_PAD_DI0_PIN3__AUD6_TXFS 0x130b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x130b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x130b0
+ >;
+ };
+
+ pinctrl_ecspi3: escpi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x100b1
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x4001b0b0 /* PHY_RST# */
+ >;
+ };
+
+ pinctrl_flexcan: flexcangrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b0b1
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x1b0b1
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x4001b0b0 /* CAN_STBY */
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__GPIO4_IO06 0x1b0b0
+ MX6QDL_PAD_KEY_ROW0__GPIO4_IO07 0x1b0b0
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x4001b0b0 /* DIOI2C_DIS# */
+ MX6QDL_PAD_DISP0_DAT18__GPIO5_IO12 0x0001b0b0 /* LVDS_TOUCH_IRQ# */
+ MX6QDL_PAD_DISP0_DAT19__GPIO5_IO13 0x0001b0b0 /* LVDS_BACKEN */
+ >;
+ };
+
+ pinctrl_keypad: keypadgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT17__GPIO5_IO11 0x0001b0b0 /* KEYPAD_IRQ# */
+ MX6QDL_PAD_DISP0_DAT9__GPIO4_IO30 0x0001b0b0 /* KEYPAD_LED_EN */
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT10__GPIO4_IO31 0x1b0b0 /* PCI_RST# */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x4001b0b0 /* PCIESKT_WDIS# */
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0001b0b0 /* PMIC_IRQ# */
+ >;
+ };
+
+ pinctrl_pps: ppsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_RXD1__GPIO1_IO26 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT2__PWM2_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm4: pwm4grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__PWM4_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x4001b0b1 /* TEN */
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL1__UART5_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW1__UART5_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x4001b0b0 /* USBHUB_RST# */
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0 /* PWR_EN */
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0 /* OC */
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170f9
+ MX6QDL_PAD_NANDF_D4__SD2_DATA4 0x170f9
+ MX6QDL_PAD_NANDF_D5__SD2_DATA5 0x170f9
+ MX6QDL_PAD_NANDF_D6__SD2_DATA6 0x170f9
+ MX6QDL_PAD_NANDF_D7__SD2_DATA7 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x17059 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x17059
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x170b9 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x170f9 /* CD */
+ MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170f9
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: omap4-droid4: Add vibrator
From: Sebastian Reichel @ 2017-05-02 16:27 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Tony Lindgren
Cc: Rob Herring, linux-input, linux-omap, devicetree, linux-kernel,
Sebastian Reichel
In-Reply-To: <20170502162726.11577-1-sebastian.reichel@collabora.co.uk>
Add vibrator to Droid4's device tree.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
arch/arm/boot/dts/omap4-droid4-xt894.dts | 38 ++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index 89eb607f4a9e..67d286a53368 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -116,6 +116,32 @@
};
};
+
+ pwm8: dmtimer-pwm-8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vibrator_direction_pin>;
+
+ compatible = "ti,omap-dmtimer-pwm";
+ #pwm-cells = <3>;
+ ti,timers = <&timer8>;
+ ti,clock-source = <0x01>;
+ };
+
+ pwm9: dmtimer-pwm-9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vibrator_enable_pin>;
+
+ compatible = "ti,omap-dmtimer-pwm";
+ #pwm-cells = <3>;
+ ti,timers = <&timer9>;
+ ti,clock-source = <0x01>;
+ };
+
+ vibrator {
+ compatible = "motorola,mapphone-pwm-vibrator";
+ pwms = <&pwm9 0 1000000000 0>, <&pwm8 0 1000000000 0>;
+ pwm-names = "enable", "direction";
+ };
};
&dss {
@@ -453,6 +479,18 @@
OMAP4_IOPAD(0x1c8, PIN_INPUT_PULLUP | MUX_MODE7)
>;
};
+
+ vibrator_direction_pin: pinmux_vibrator_direction_pin {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */
+ >;
+ };
+
+ vibrator_enable_pin: pinmux_vibrator_enable_pin {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */
+ >;
+ };
};
&omap4_pmx_wkup {
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] Input: pwm-vibra: new driver
From: Sebastian Reichel @ 2017-05-02 16:27 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Tony Lindgren
Cc: Rob Herring, linux-input, linux-omap, devicetree, linux-kernel,
Sebastian Reichel
In-Reply-To: <20170502162726.11577-1-sebastian.reichel@collabora.co.uk>
Provide a simple driver for PWM controllable vibrators. It
will be used by Motorola Droid 4.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
---
.../devicetree/bindings/input/pwm-vibrator.txt | 60 ++++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/pwm-vibra.c | 348 +++++++++++++++++++++
4 files changed, 420 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/pwm-vibrator.txt
create mode 100644 drivers/input/misc/pwm-vibra.c
diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
new file mode 100644
index 000000000000..c35be4691366
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-vibrator.txt
@@ -0,0 +1,60 @@
+* PWM vibrator device tree bindings
+
+Registers a PWM device as vibrator.
+
+Required properties:
+- compatible: should be
+ * "pwm-vibrator"
+ For vibrators controlled using the PWM channel's duty cycle (higher duty means
+ the vibrator becomes stronger).
+ * "motorola,mapphone-pwm-vibrator"
+ For vibrator found in Motorola Droid 4. This vibrator generates a pulse for
+ every rising edge, so its controlled using a duty cycle of 50% and changing
+ the period time.
+- pwm-names: Should contain "enable" and optionally "direction"
+- pwms: Should contain a PWM handle for each entry in pwm-names
+
+Example from Motorola Droid 4:
+
+&omap4_pmx_core {
+ vibrator_direction_pin: pinmux_vibrator_direction_pin {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */
+ >;
+ };
+
+ vibrator_enable_pin: pinmux_vibrator_enable_pin {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */
+ >;
+ };
+};
+
+/ {
+ pwm8: dmtimer-pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vibrator_direction_pin>;
+
+ compatible = "ti,omap-dmtimer-pwm";
+ #pwm-cells = <3>;
+ ti,timers = <&timer8>;
+ ti,clock-source = <0x01>;
+ };
+
+ pwm9: dmtimer-pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&vibrator_enable_pin>;
+
+ compatible = "ti,omap-dmtimer-pwm";
+ #pwm-cells = <3>;
+ ti,timers = <&timer9>;
+ ti,clock-source = <0x01>;
+ };
+
+ vibrator {
+ compatible = "pwm-vibrator";
+ pwms = <&pwm8 0 1000000000 0>,
+ <&pwm9 0 1000000000 0>;
+ pwm-names = "enable", "direction";
+ };
+};
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5b6c52210d20..d8e0b25eb217 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -571,6 +571,17 @@ config INPUT_PWM_BEEPER
To compile this driver as a module, choose M here: the module will be
called pwm-beeper.
+config INPUT_PWM_VIBRA
+ tristate "PWM vibrator support"
+ depends on PWM
+ help
+ Say Y here to get support for PWM based vibrator devices.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called pwm-vibra.
+
config INPUT_GPIO_ROTARY_ENCODER
tristate "Rotary encoders connected to GPIO pins"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b10523f2878e..9a6517f5458c 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR) += pm8xxx-vibrator.o
obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
+obj-$(CONFIG_INPUT_PWM_VIBRA) += pwm-vibra.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
new file mode 100644
index 000000000000..a7d36d88679a
--- /dev/null
+++ b/drivers/input/misc/pwm-vibra.c
@@ -0,0 +1,348 @@
+/*
+ * PWM vibrator driver
+ *
+ * Copyright (C) 2017 Collabora Ltd.
+ *
+ * Based on previous work from:
+ * Copyright (C) 2012 Dmitry Torokhov <dmitry.torokhov@gmail.com>
+ *
+ * Based on PWM beeper driver:
+ * Copyright (C) 2010, Lars-Peter Clausen <lars@metafoo.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.
+ */
+
+#define DEBUG
+
+#include <linux/input.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+/**
+ * Motorola Droid 4 (also known as mapphone), has a vibrator, which pulses
+ * 1x on rising edge. Increasing the pwm period results in more pulses per
+ * second, but reduces intensity. There is also a second channel to control
+ * the vibrator's rotation direction to increase effect. The following
+ * numbers were determined manually. Going below 12.5 Hz means, clearly
+ * noticeable pauses and at 30 Hz the vibration is just barely noticable
+ * anymore.
+ */
+#define MAPPHONE_MIN_FREQ 125 /* 12.5 Hz */
+#define MAPPHONE_MAX_FREQ 300 /* 30.0 Hz */
+
+struct pwm_vibrator_hw {
+ void (*setup_pwm)(u16 level, struct pwm_state *);
+ void (*setup_pwm_dir)(u16 level, struct pwm_state *);
+};
+
+struct pwm_vibrator {
+ struct input_dev *input;
+ struct pwm_device *pwm;
+ struct pwm_device *pwm_dir;
+ struct regulator *vcc;
+
+ struct work_struct play_work;
+ u16 level;
+
+ const struct pwm_vibrator_hw *hw;
+};
+
+static void pwm_vibrator_setup_generic(u16 level, struct pwm_state *state)
+{
+ /* period is configured by platform, duty cycle controls strength */
+ pwm_set_relative_duty_cycle(state, level, 0xffff);
+}
+
+static void pwm_vibrator_setup_dir_generic(u16 level, struct pwm_state *state)
+{
+ /* period is configured by platform, duty cycle controls strength */
+ pwm_set_relative_duty_cycle(state, 50, 100);
+}
+
+static struct pwm_vibrator_hw pwm_vib_hw_generic = {
+ .setup_pwm = pwm_vibrator_setup_generic,
+ .setup_pwm_dir = pwm_vibrator_setup_dir_generic,
+};
+
+static void pwm_vibrator_setup_mapphone(u16 level, struct pwm_state *state)
+{
+ unsigned int freq;
+
+ /* convert [0, 0xffff] -> [MAPPHONE_MAX_FREQ, MAPPHONE_MIN_FREQ] */
+ freq = 0xffff - level;
+ freq *= MAPPHONE_MAX_FREQ - MAPPHONE_MIN_FREQ;
+ freq /= 0xffff;
+ freq += MAPPHONE_MIN_FREQ;
+
+ state->period = DIV_ROUND_CLOSEST_ULL((u64) NSEC_PER_SEC * 10, freq);
+ pwm_set_relative_duty_cycle(state, 50, 100);
+}
+
+static struct pwm_vibrator_hw pwm_vib_hw_mapphone = {
+ .setup_pwm = pwm_vibrator_setup_mapphone,
+ .setup_pwm_dir = pwm_vibrator_setup_mapphone,
+};
+
+static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
+{
+ struct device *pdev = vibrator->input->dev.parent;
+ struct pwm_state state;
+ int err;
+
+ dev_dbg(pdev, "start vibrator with level=0x%04x", vibrator->level);
+
+ err = regulator_enable(vibrator->vcc);
+ if (err) {
+ dev_err(pdev, "failed to enable regulator: %d", err);
+ return err;
+ }
+
+ pwm_get_state(vibrator->pwm, &state);
+ state.enabled = true;
+
+ vibrator->hw->setup_pwm(vibrator->level, &state);
+ dev_dbg(pdev, "period=%u", state.period);
+
+ err = pwm_apply_state(vibrator->pwm, &state);
+ if (err) {
+ dev_err(pdev, "failed to apply pwm state: %d", err);
+ return err;
+ }
+
+ if (vibrator->pwm_dir) {
+ pwm_get_state(vibrator->pwm_dir, &state);
+ state.enabled = true;
+
+ /* always control via period */
+ vibrator->hw->setup_pwm_dir(vibrator->level, &state);
+
+ err = pwm_apply_state(vibrator->pwm_dir, &state);
+ if (err) {
+ dev_err(pdev, "failed to apply dir-pwm state: %d", err);
+ pwm_disable(vibrator->pwm);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
+{
+ struct device *pdev = vibrator->input->dev.parent;
+
+ dev_dbg(pdev, "stop vibrator");
+
+ regulator_disable(vibrator->vcc);
+
+ if (vibrator->pwm_dir)
+ pwm_disable(vibrator->pwm_dir);
+ pwm_disable(vibrator->pwm);
+}
+
+static void vibra_play_work(struct work_struct *work)
+{
+ struct pwm_vibrator *vibrator = container_of(work,
+ struct pwm_vibrator, play_work);
+
+ if (vibrator->level)
+ pwm_vibrator_start(vibrator);
+ else
+ pwm_vibrator_stop(vibrator);
+}
+
+static int pwm_vibrator_play_effect(struct input_dev *dev, void *data,
+ struct ff_effect *effect)
+{
+ struct pwm_vibrator *vibrator = input_get_drvdata(dev);
+
+ vibrator->level = effect->u.rumble.strong_magnitude;
+ if (!vibrator->level)
+ vibrator->level = effect->u.rumble.weak_magnitude;
+
+ schedule_work(&vibrator->play_work);
+
+ return 0;
+}
+
+static int pwm_vibrator_probe(struct platform_device *pdev)
+{
+ struct pwm_vibrator *vibrator;
+ struct input_dev *input;
+ struct pwm_state state;
+ int err;
+
+ vibrator = devm_kzalloc(&pdev->dev, sizeof(*vibrator), GFP_KERNEL);
+ if (!vibrator)
+ return -ENOMEM;
+
+ input = devm_input_allocate_device(&pdev->dev);
+ if (!vibrator || !input)
+ return -ENOMEM;
+
+ vibrator->input = input;
+
+ vibrator->vcc = devm_regulator_get(&pdev->dev, "vcc");
+ err = PTR_ERR_OR_ZERO(vibrator->vcc);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to request regulator: %d",
+ err);
+ return err;
+ }
+
+ vibrator->pwm = devm_pwm_get(&pdev->dev, "enable");
+ err = PTR_ERR_OR_ZERO(vibrator->pwm);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "Failed to request main pwm: %d",
+ err);
+ return err;
+ }
+
+ INIT_WORK(&vibrator->play_work, vibra_play_work);
+
+ /* Sync up PWM state and ensure it is off. */
+ pwm_init_state(vibrator->pwm, &state);
+ state.enabled = false;
+ err = pwm_apply_state(vibrator->pwm, &state);
+ if (err) {
+ dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
+ err);
+ return err;
+ }
+
+ vibrator->pwm_dir = devm_pwm_get(&pdev->dev, "direction");
+ err = PTR_ERR_OR_ZERO(vibrator->pwm_dir);
+ if (err == -ENODATA) {
+ vibrator->pwm_dir = NULL;
+ } else if (err == -EPROBE_DEFER) {
+ return err;
+ } else if (err) {
+ dev_err(&pdev->dev, "Failed to request direction pwm: %d", err);
+ return err;
+ } else {
+ /* Sync up PWM state and ensure it is off. */
+ pwm_init_state(vibrator->pwm_dir, &state);
+ state.enabled = false;
+ err = pwm_apply_state(vibrator->pwm_dir, &state);
+ if (err) {
+ dev_err(&pdev->dev, "failed to apply initial PWM state: %d",
+ err);
+ return err;
+ }
+ }
+
+ vibrator->hw = of_device_get_match_data(&pdev->dev);
+ if (!vibrator->hw)
+ vibrator->hw = &pwm_vib_hw_generic;
+
+ input->name = "pwm-vibrator";
+ input->id.bustype = BUS_HOST;
+ input->dev.parent = &pdev->dev;
+
+ input_set_drvdata(input, vibrator);
+ input_set_capability(input, EV_FF, FF_RUMBLE);
+
+ err = input_ff_create_memless(input, NULL, pwm_vibrator_play_effect);
+ if (err) {
+ dev_err(&pdev->dev, "Couldn't create FF dev: %d", err);
+ return err;
+ }
+
+ err = input_register_device(input);
+ if (err) {
+ dev_err(&pdev->dev, "Couldn't register input dev: %d", err);
+ return err;
+ }
+
+ platform_set_drvdata(pdev, vibrator);
+
+ dev_info(&pdev->dev, "pwm-vibrator probed.");
+
+ return 0;
+}
+
+static int pwm_vibrator_remove(struct platform_device *pdev)
+{
+ struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
+
+ cancel_work_sync(&vibrator->play_work);
+ pwm_vibrator_stop(vibrator);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int pwm_vibrator_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
+ struct input_dev *input = vibrator->input;
+ unsigned long flags;
+
+ spin_lock_irqsave(&input->event_lock, flags);
+ if (vibrator->level)
+ pwm_vibrator_stop(vibrator);
+ spin_unlock_irqrestore(&input->event_lock, flags);
+
+ return 0;
+}
+
+static int pwm_vibrator_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct pwm_vibrator *vibrator = platform_get_drvdata(pdev);
+ struct input_dev *input = vibrator->input;
+ unsigned long flags;
+
+ spin_lock_irqsave(&input->event_lock, flags);
+ if (vibrator->level)
+ pwm_vibrator_start(vibrator);
+ spin_unlock_irqrestore(&input->event_lock, flags);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(pwm_vibrator_pm_ops,
+ pwm_vibrator_suspend, pwm_vibrator_resume);
+
+#ifdef CONFIG_OF
+
+#define PWM_VIB_COMPAT(of_compatible, cfg) { \
+ .compatible = of_compatible, \
+ .data = &cfg, \
+}
+
+static const struct of_device_id pwm_vibra_dt_match_table[] = {
+ PWM_VIB_COMPAT("pwm-vibrator", pwm_vib_hw_generic),
+ PWM_VIB_COMPAT("motorola,mapphone-pwm-vibrator", pwm_vib_hw_mapphone),
+ {},
+};
+MODULE_DEVICE_TABLE(of, pwm_vibra_dt_match_table);
+#endif
+
+static struct platform_driver pwm_vibrator_driver = {
+ .probe = pwm_vibrator_probe,
+ .remove = pwm_vibrator_remove,
+ .driver = {
+ .name = "pwm-vibrator",
+ .pm = &pwm_vibrator_pm_ops,
+ .of_match_table = of_match_ptr(pwm_vibra_dt_match_table),
+ },
+};
+module_platform_driver(pwm_vibrator_driver);
+
+MODULE_AUTHOR("Sebastian Reichel <sre@kernel.org>");
+MODULE_DESCRIPTION("PWM vibrator driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:pwm-vibrator");
--
2.11.0
^ permalink raw reply related
* [PATCH 0/2] PWM Vibrator driver
From: Sebastian Reichel @ 2017-05-02 16:27 UTC (permalink / raw)
To: Sebastian Reichel, Dmitry Torokhov, Tony Lindgren
Cc: Rob Herring, linux-input, linux-omap, devicetree, linux-kernel,
Sebastian Reichel
Hi,
The Motorola Droid 4 has a vibrator, that is connected
to two GPIOs. Motorola's stock kernel names them vib_en
and vib_dir, which probably stand for vibrator_enable
and vibrator_direction. In their stock kernel both GPIOs
are toggled using a hrtimer and a custom vibrator "misc"
device is provided to userspace.
Thankfully the hardware designers the used GPIOs can
also be used from OMAP's dmtimers, so that they can
be driven as PWM output instead saving some CPU cycles
(and code).
The driver is loosely based on an old patch from Dmitry,
that I found in the internet(tm) [0]. Note, that I did
not check the generic vibrator stuff. I just kept it in
the driver, since it's probably what other people expect
from a pwm-vibra driver :)
[0] https://lkml.org/lkml/2012/4/10/41
-- Sebastian
Sebastian Reichel (2):
Input: pwm-vibra: new driver
ARM: dts: omap4-droid4: Add vibrator
.../devicetree/bindings/input/pwm-vibrator.txt | 60 ++++
arch/arm/boot/dts/omap4-droid4-xt894.dts | 38 +++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/pwm-vibra.c | 348 +++++++++++++++++++++
5 files changed, 458 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/pwm-vibrator.txt
create mode 100644 drivers/input/misc/pwm-vibra.c
--
2.11.0
^ permalink raw reply
* Re: [PATCH v4 2/7] dt-bindings: media: Add MAX2175 binding description
From: Geert Uytterhoeven @ 2017-05-02 16:16 UTC (permalink / raw)
To: Ramesh Shanmugasundaram
Cc: Rob Herring, Mark Rutland, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus, Antti Palosaari, Chris Paterson, Laurent Pinchart,
Geert Uytterhoeven, Linux Media Mailing List,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20170502132615.42134-3-ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
Hi Ramesh,
On Tue, May 2, 2017 at 3:26 PM, Ramesh Shanmugasundaram
<ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -28,6 +28,7 @@ Electricity
> -ohms : Ohms
> -micro-ohms : micro Ohms
> -microvolt : micro volts
> +-pF : pico farads
All electrical units seem to use long(er) names.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] [media] platform: add video-multiplexer subdevice driver
From: Philipp Zabel @ 2017-05-02 15:21 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Sascha Hauer, Rob Herring,
Sakari Ailus, Pavel Machek, Steve Longerbeam, Vladimir Zapolskiy
In-Reply-To: <df5f38c4-b0e8-64c6-d6ba-c554133f4bbf-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Sat, 2017-04-29 at 23:42 +0200, Peter Rosin wrote:
> On 2017-04-29 23:29, Peter Rosin wrote:
> > On 2017-04-28 16:13, Philipp Zabel wrote:
> >> This driver can handle SoC internal and external video bus multiplexers,
> >> controlled by mux controllers provided by the mux controller framework,
> >> such as MMIO register bitfields or GPIOs. The subdevice passes through
> >> the mbus configuration of the active input to the output side.
> >>
> >> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> >> ---
> >> This has been last sent as part of the i.MX media series.
> >>
> >> Changes since https://patchwork.kernel.org/patch/9647869/:
> >> - Split out the actual mux operation to be provided by the mux controller
> >> framework [1]. GPIO and MMIO control can be provided by individual mux
> >> controller drivers [2][3].
> >> [1] https://patchwork.kernel.org/patch/9695837/
> >> [2] https://patchwork.kernel.org/patch/9695839/
> >> [3] https://patchwork.kernel.org/patch/9704509/
> >> - Shortened 'video-multiplexer' to 'video-mux', replaced all instances of
> >> vidsw with video_mux.
> >> - Made the mux inactive by default, only activated by user interaction.
> >> - Added CONFIG_OF and CONFIG_MULTIPLEXER dependencies.
> >> - Reuse subdev.entity.num_pads instead of keeping our own count.
> >> - Removed implicit link disabling. Instead, trying to enable a second
> >> sink pad link yields -EBUSY.
> >> - Merged _async_init into _probe.
> >> - Removed superfluous pad index check from _set_format.
> >> - Added is_source_pad helper to tell source and sink pads apart.
> >> - Removed test for status property in endpoint nodes. Disable the remote
> >> device or sever the endpoint link to disable a sink pad.
> >> ---
> >> drivers/media/platform/Kconfig | 6 +
> >> drivers/media/platform/Makefile | 2 +
> >> drivers/media/platform/video-mux.c | 341 +++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 349 insertions(+)
> >> create mode 100644 drivers/media/platform/video-mux.c
> >>
> >> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> >> index c9106e105baba..b046a6d39fee5 100644
> >> --- a/drivers/media/platform/Kconfig
> >> +++ b/drivers/media/platform/Kconfig
> >> @@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
> >> To compile this driver as a module, choose M here: the
> >> module will be called arv.
> >>
> >> +config VIDEO_MUX
> >> + tristate "Video Multiplexer"
> >> + depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && MULTIPLEXER
> >> + help
> >> + This driver provides support for N:1 video bus multiplexers.
> >> +
> >> config VIDEO_OMAP3
> >> tristate "OMAP 3 Camera support"
> >> depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> >> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> >> index 349ddf6a69da2..fd2735ca3ff75 100644
> >> --- a/drivers/media/platform/Makefile
> >> +++ b/drivers/media/platform/Makefile
> >> @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
> >>
> >> obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
> >>
> >> +obj-$(CONFIG_VIDEO_MUX) += video-mux.o
> >> +
> >> obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
> >> obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
> >> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
> >> diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
> >> new file mode 100644
> >> index 0000000000000..419541729f67e
> >> --- /dev/null
> >> +++ b/drivers/media/platform/video-mux.c
> >> @@ -0,0 +1,341 @@
> >> +/*
> >> + * video stream multiplexer controlled via mux control
> >> + *
> >> + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >> + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > 2017?
> >
> >> + *
> >> + * 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.
> >> + */
> >> +
> >> +#include <linux/err.h>
> >> +#include <linux/module.h>
> >> +#include <linux/mux/consumer.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_graph.h>
> >> +#include <linux/platform_device.h>
> >> +#include <media/v4l2-async.h>
> >> +#include <media/v4l2-device.h>
> >> +#include <media/v4l2-subdev.h>
> >> +#include <media/v4l2-of.h>
> >> +
> >> +struct video_mux {
> >> + struct v4l2_subdev subdev;
> >> + struct media_pad *pads;
> >> + struct v4l2_mbus_framefmt *format_mbus;
> >> + struct v4l2_of_endpoint *endpoint;
> >> + struct mux_control *mux;
> >> + int active;
> >> +};
> >> +
> >> +static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
> >> +{
> >> + return container_of(sd, struct video_mux, subdev);
> >> +}
> >> +
> >> +static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
> >> +{
> >> + return pad == vmux->subdev.entity.num_pads - 1;
> >> +}
> >> +
> >> +static int video_mux_link_setup(struct media_entity *entity,
> >> + const struct media_pad *local,
> >> + const struct media_pad *remote, u32 flags)
> >> +{
> >> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> >> + struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
> >> + int ret;
> >> +
> >> + /*
> >> + * The mux state is determined by the enabled sink pad link.
> >> + * Enabling or disabling the source pad link has no effect.
> >> + */
> >> + if (is_source_pad(vmux, local->index))
> >> + return 0;
> >> +
> >> + dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
> >> + remote->entity->name, remote->index, local->entity->name,
> >> + local->index, flags & MEDIA_LNK_FL_ENABLED);
> >> +
> >> + if (flags & MEDIA_LNK_FL_ENABLED) {
> >> + if (vmux->active == local->index)
> >
> > Here, you shortcut the mux_control_select_trylock test and return "OK"
> > based on a driver-local variable that is intended to keep track of mux
> > ownership.
> >
> >> + return 0;
> >> +
> >> + if (vmux->active >= 0)
> >
> > Here too (and this check is not needed, the situation will be covered by
> > the mux_control_try_select call).
> >
> >> + return -EBUSY;
> >> +
> >> + dev_dbg(sd->dev, "setting %d active\n", local->index);
> >> + ret = mux_control_try_select(vmux->mux, local->index);
> >> + if (ret < 0)
> >> + return ret;
> >> + vmux->active = local->index;
> >> + } else {
> >> + if (vmux->active != local->index)
> >> + return 0;
> >> +
> >> + dev_dbg(sd->dev, "going inactive\n");
> >> + mux_control_deselect(vmux->mux);
> >
> > But here you let go of the mux *before* you clear the driver-local
> > ownership indicator. That looks suspicious. My guess is that this is
> > "safe" because the upper layers has some serialization, but I don't
> > know. Anyway, even if there is something saving you in the upper
> > layers, it looks out of order and unneeded. I would have moved the
> > below vmux->active = -1; statement up to before the above deselect.
> >
> > With that fixed, mux usage looks good to me, so you can add an Acked-
> > by from me if you wish (goes for the bindings patch as well).
>
> Ouch, that was a bit too soon. If there is *no* serialization in the
> upper layers, this is *not* ok, even with my reordering. There must be
> only one call to mux_control_deselect, and w/o serialization there
> is a race where you might get multiple deselect calls when several
> callers makes it through the active != index check before any of them
> manages to set active = -1. That race must be taken care of!
Thank you, I've resent a version with a mutex lock around vmux->active.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] [media] platform: add video-multiplexer subdevice driver
From: Philipp Zabel @ 2017-05-02 15:09 UTC (permalink / raw)
To: linux-media
Cc: devicetree, Steve Longerbeam, Peter Rosin, Sakari Ailus,
Pavel Machek, Rob Herring, Mark Rutland, Vladimir Zapolskiy,
kernel, Philipp Zabel, Sascha Hauer, Steve Longerbeam
In-Reply-To: <20170502150913.2168-1-p.zabel@pengutronix.de>
This driver can handle SoC internal and external video bus multiplexers,
controlled by mux controllers provided by the mux controller framework,
such as MMIO register bitfields or GPIOs. The subdevice passes through
the mbus configuration of the active input to the output side.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
Changes since v1 [1]:
- Protect vmux->active with a mutex in link_setup and set_format.
s_stream does not need to be locked; it is called when the pipeline
is started and thus the link setup can not be changed anymore.
- Remove the unused g_mbus_config.
This was previously sent as part of Steve's i.MX media series [2].
[1] https://patchwork.kernel.org/patch/9704791/
[2] https://patchwork.kernel.org/patch/9647869/
---
drivers/media/platform/Kconfig | 6 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/video-mux.c | 312 +++++++++++++++++++++++++++++++++++++
3 files changed, 320 insertions(+)
create mode 100644 drivers/media/platform/video-mux.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e105baba..b046a6d39fee5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,12 @@ config VIDEO_M32R_AR_M64278
To compile this driver as a module, choose M here: the
module will be called arv.
+config VIDEO_MUX
+ tristate "Video Multiplexer"
+ depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER && MULTIPLEXER
+ help
+ This driver provides support for N:1 video bus multiplexers.
+
config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 349ddf6a69da2..fd2735ca3ff75 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
+obj-$(CONFIG_VIDEO_MUX) += video-mux.o
+
obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
new file mode 100644
index 0000000000000..a857f5e89deff
--- /dev/null
+++ b/drivers/media/platform/video-mux.c
@@ -0,0 +1,312 @@
+/*
+ * video stream multiplexer controlled via mux control
+ *
+ * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
+ * Copyright (C) 2016-2017 Pengutronix, Philipp Zabel <kernel@pengutronix.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.
+ */
+
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/mux/consumer.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+#include <media/v4l2-async.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+#include <media/v4l2-of.h>
+
+struct video_mux {
+ struct v4l2_subdev subdev;
+ struct media_pad *pads;
+ struct v4l2_mbus_framefmt *format_mbus;
+ struct v4l2_of_endpoint *endpoint;
+ struct mux_control *mux;
+ struct mutex lock;
+ int active;
+};
+
+static inline struct video_mux *v4l2_subdev_to_video_mux(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct video_mux, subdev);
+}
+
+static inline bool is_source_pad(struct video_mux *vmux, unsigned int pad)
+{
+ return pad == vmux->subdev.entity.num_pads - 1;
+}
+
+static int video_mux_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ int ret = 0;
+
+ /*
+ * The mux state is determined by the enabled sink pad link.
+ * Enabling or disabling the source pad link has no effect.
+ */
+ if (is_source_pad(vmux, local->index))
+ return 0;
+
+ dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]",
+ remote->entity->name, remote->index, local->entity->name,
+ local->index, flags & MEDIA_LNK_FL_ENABLED);
+
+ mutex_lock(&vmux->lock);
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (vmux->active == local->index)
+ goto out;
+
+ if (vmux->active >= 0) {
+ ret = -EBUSY;
+ goto out;
+ }
+
+ dev_dbg(sd->dev, "setting %d active\n", local->index);
+ ret = mux_control_try_select(vmux->mux, local->index);
+ if (ret < 0)
+ goto out;
+ vmux->active = local->index;
+ } else {
+ if (vmux->active != local->index)
+ goto out;
+
+ dev_dbg(sd->dev, "going inactive\n");
+ mux_control_deselect(vmux->mux);
+ vmux->active = -1;
+ }
+
+out:
+ mutex_unlock(&vmux->lock);
+ return ret;
+}
+
+static struct media_entity_operations video_mux_ops = {
+ .link_setup = video_mux_link_setup,
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static bool video_mux_endpoint_disabled(struct device_node *ep)
+{
+ struct device_node *rpp = of_graph_get_remote_port_parent(ep);
+
+ return !of_device_is_available(rpp);
+}
+
+static int video_mux_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_subdev *upstream_sd;
+ struct media_pad *pad;
+
+ if (vmux->active == -1) {
+ dev_err(sd->dev, "Can not start streaming on inactive mux\n");
+ return -EINVAL;
+ }
+
+ pad = media_entity_remote_pad(&sd->entity.pads[vmux->active]);
+ if (!pad) {
+ dev_err(sd->dev, "Failed to find remote source pad\n");
+ return -ENOLINK;
+ }
+
+ if (!is_media_entity_v4l2_subdev(pad->entity)) {
+ dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
+ return -ENODEV;
+ }
+
+ upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
+
+ return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
+}
+
+static const struct v4l2_subdev_video_ops video_mux_subdev_video_ops = {
+ .s_stream = video_mux_s_stream,
+};
+
+static struct v4l2_mbus_framefmt *
+__video_mux_get_pad_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, u32 which)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+
+ switch (which) {
+ case V4L2_SUBDEV_FORMAT_TRY:
+ return v4l2_subdev_get_try_format(sd, cfg, pad);
+ case V4L2_SUBDEV_FORMAT_ACTIVE:
+ return &vmux->format_mbus[pad];
+ default:
+ return NULL;
+ }
+}
+
+static int video_mux_get_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ sdformat->format = *__video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+ return 0;
+}
+
+static int video_mux_set_format(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct video_mux *vmux = v4l2_subdev_to_video_mux(sd);
+ struct v4l2_mbus_framefmt *mbusformat;
+
+ mbusformat = __video_mux_get_pad_format(sd, cfg, sdformat->pad,
+ sdformat->which);
+ if (!mbusformat)
+ return -EINVAL;
+
+ mutex_lock(&vmux->lock);
+
+ /* Source pad mirrors active sink pad, no limitations on sink pads */
+ if (is_source_pad(vmux, sdformat->pad) && vmux->active >= 0)
+ sdformat->format = vmux->format_mbus[vmux->active];
+
+ mutex_unlock(&vmux->lock);
+
+ *mbusformat = sdformat->format;
+
+ return 0;
+}
+
+static struct v4l2_subdev_pad_ops video_mux_pad_ops = {
+ .get_fmt = video_mux_get_format,
+ .set_fmt = video_mux_set_format,
+};
+
+static struct v4l2_subdev_ops video_mux_subdev_ops = {
+ .pad = &video_mux_pad_ops,
+ .video = &video_mux_subdev_video_ops,
+};
+
+static int video_mux_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *ep;
+ struct video_mux *vmux;
+ unsigned int num_pads = 0;
+ int ret;
+ int i;
+
+ vmux = devm_kzalloc(dev, sizeof(*vmux), GFP_KERNEL);
+ if (!vmux)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, vmux);
+
+ v4l2_subdev_init(&vmux->subdev, &video_mux_subdev_ops);
+ snprintf(vmux->subdev.name, sizeof(vmux->subdev.name), "%s", np->name);
+ vmux->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ vmux->subdev.dev = dev;
+
+ /*
+ * The largest numbered port is the output port. It determines
+ * total number of pads.
+ */
+ for_each_endpoint_of_node(np, ep) {
+ of_graph_parse_endpoint(ep, &endpoint.base);
+ num_pads = max(num_pads, endpoint.base.port + 1);
+ }
+
+ if (num_pads < 2) {
+ dev_err(dev, "Not enough ports %d\n", num_pads);
+ return -EINVAL;
+ }
+
+ vmux->mux = devm_mux_control_get(dev, NULL);
+ if (IS_ERR(vmux->mux)) {
+ ret = PTR_ERR(vmux->mux);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get mux: %d\n", ret);
+ return ret;
+ }
+
+ mutex_init(&vmux->lock);
+ vmux->active = -1;
+ vmux->pads = devm_kzalloc(dev, sizeof(*vmux->pads) * num_pads,
+ GFP_KERNEL);
+ vmux->format_mbus = devm_kzalloc(dev, sizeof(*vmux->format_mbus) *
+ num_pads, GFP_KERNEL);
+ vmux->endpoint = devm_kzalloc(dev, sizeof(*vmux->endpoint) *
+ (num_pads - 1), GFP_KERNEL);
+
+ for (i = 0; i < num_pads - 1; i++)
+ vmux->pads[i].flags = MEDIA_PAD_FL_SINK;
+ vmux->pads[num_pads - 1].flags = MEDIA_PAD_FL_SOURCE;
+
+ vmux->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
+ ret = media_entity_pads_init(&vmux->subdev.entity, num_pads,
+ vmux->pads);
+ if (ret < 0)
+ return ret;
+
+ vmux->subdev.entity.ops = &video_mux_ops;
+
+ for_each_endpoint_of_node(np, ep) {
+ v4l2_of_parse_endpoint(ep, &endpoint);
+
+ if (video_mux_endpoint_disabled(ep)) {
+ dev_dbg(dev, "port %d disabled\n", endpoint.base.port);
+ continue;
+ }
+
+ vmux->endpoint[endpoint.base.port] = endpoint;
+ }
+
+ return v4l2_async_register_subdev(&vmux->subdev);
+}
+
+static int video_mux_remove(struct platform_device *pdev)
+{
+ struct video_mux *vmux = platform_get_drvdata(pdev);
+ struct v4l2_subdev *sd = &vmux->subdev;
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+
+ return 0;
+}
+
+static const struct of_device_id video_mux_dt_ids[] = {
+ { .compatible = "video-mux", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, video_mux_dt_ids);
+
+static struct platform_driver video_mux_driver = {
+ .probe = video_mux_probe,
+ .remove = video_mux_remove,
+ .driver = {
+ .of_match_table = video_mux_dt_ids,
+ .name = "video-mux",
+ },
+};
+
+module_platform_driver(video_mux_driver);
+
+MODULE_DESCRIPTION("video stream multiplexer");
+MODULE_AUTHOR("Sascha Hauer, Pengutronix");
+MODULE_AUTHOR("Philipp Zabel, Pengutronix");
+MODULE_LICENSE("GPL");
--
2.11.0
^ permalink raw reply related
* [PATCH v2 1/2] [media] dt-bindings: Add bindings for video-multiplexer device
From: Philipp Zabel @ 2017-05-02 15:09 UTC (permalink / raw)
To: linux-media
Cc: devicetree, Steve Longerbeam, Peter Rosin, Sakari Ailus,
Pavel Machek, Rob Herring, Mark Rutland, Vladimir Zapolskiy,
kernel, Philipp Zabel, Sascha Hauer, Steve Longerbeam
Add bindings documentation for the video multiplexer device.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Acked-by: Peter Rosin <peda@axentia.se>
---
No changes since v1 [1].
This was previously sent as part of Steve's i.MX media series [2].
[1] https://patchwork.kernel.org/patch/9704789/
[2] https://patchwork.kernel.org/patch/9647951/
---
.../devicetree/bindings/media/video-mux.txt | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/video-mux.txt
diff --git a/Documentation/devicetree/bindings/media/video-mux.txt b/Documentation/devicetree/bindings/media/video-mux.txt
new file mode 100644
index 0000000000000..63b9dc913e456
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-mux.txt
@@ -0,0 +1,60 @@
+Video Multiplexer
+=================
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding are controlled by a multiplexer controller that is described by
+the bindings in Documentation/devicetree/bindings/mux/mux-controller.txt
+
+Required properties:
+- compatible : should be "video-mux"
+- mux-controls : mux controller node to use for operating the mux
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+ source and sink devices according to of_graph bindings. The last port is
+ the output port, all others are inputs.
+
+Optionally, #address-cells, #size-cells, and port nodes can be grouped under a
+ports node as described in Documentation/devicetree/bindings/graph.txt.
+
+Example:
+
+ mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+
+ mux-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ video-mux {
+ compatible = "video-mux";
+ mux-controls = <&mux>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mux_in0: endpoint {
+ remote-endpoint = <&video_source0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mux_in1: endpoint {
+ remote-endpoint = <&video_source1_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ mux_out: endpoint {
+ remote-endpoint = <&capture_interface_in>;
+ };
+ };
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH] input: edt-ft5x06: increase allowed data range for threshold parameter
From: Martin Kepplinger @ 2017-05-02 15:00 UTC (permalink / raw)
To: dmitry.torokhov, simon.budig, daniel.wagener, mchehab
Cc: linux-input, devicetree, linux-kernel, linux-doc,
Martin Kepplinger, Schoefegger Stefan, Manfred Schlaegl
The datasheet and application note does not mention an allowed range for
the M09_REGISTER_THRESHOLD parameter. One of our customers needs to set
lower values than 20 and they seem to work just fine on EDT EP0xx0M09 with
T5x06 touch.
So, lacking a known lower limit, we increase the range for thresholds,
and set the lower limit to 0. The documentation is updated accordingly.
Signed-off-by: Schoefegger Stefan <stefan.schoefegger@ginzinger.com>
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt | 2 +-
Documentation/input/devices/edt-ft5x06.rst | 2 +-
drivers/input/touchscreen/edt-ft5x06.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 6db2210..025cf8c 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -36,7 +36,7 @@ Optional properties:
control gpios
- threshold: allows setting the "click"-threshold in the range
- from 20 to 80.
+ from 0 to 80.
- gain: allows setting the sensitivity in the range from 0 to
31. Note that lower values indicate higher
diff --git a/Documentation/input/devices/edt-ft5x06.rst b/Documentation/input/devices/edt-ft5x06.rst
index 2032f0b..1ccc94b 100644
--- a/Documentation/input/devices/edt-ft5x06.rst
+++ b/Documentation/input/devices/edt-ft5x06.rst
@@ -15,7 +15,7 @@ It has been tested with the following devices:
The driver allows configuration of the touch screen via a set of sysfs files:
/sys/class/input/eventX/device/device/threshold:
- allows setting the "click"-threshold in the range from 20 to 80.
+ allows setting the "click"-threshold in the range from 0 to 80.
/sys/class/input/eventX/device/device/gain:
allows setting the sensitivity in the range from 0 to 31. Note that
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 8cf8d8d..f872817 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -471,7 +471,7 @@ static EDT_ATTR(gain, S_IWUSR | S_IRUGO, WORK_REGISTER_GAIN,
static EDT_ATTR(offset, S_IWUSR | S_IRUGO, WORK_REGISTER_OFFSET,
M09_REGISTER_OFFSET, 0, 31);
static EDT_ATTR(threshold, S_IWUSR | S_IRUGO, WORK_REGISTER_THRESHOLD,
- M09_REGISTER_THRESHOLD, 20, 80);
+ M09_REGISTER_THRESHOLD, 0, 80);
static EDT_ATTR(report_rate, S_IWUSR | S_IRUGO, WORK_REGISTER_REPORT_RATE,
NO_REGISTER, 3, 14);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
From: Maxime Ripard @ 2017-05-02 14:54 UTC (permalink / raw)
To: Rob Herring
Cc: Chen-Yu Tsai, David Airlie, Mark Rutland,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170428134841.cc5jrqhunh2rxhog@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]
Hi,
On Fri, Apr 28, 2017 at 08:48:41AM -0500, Rob Herring wrote:
> On Fri, Apr 21, 2017 at 04:38:49PM +0800, Chen-Yu Tsai wrote:
> > The Allwinner display pipeline contains many hardware components, some
> > of which can consume data from one of multiple upstream components.
> > The numbering scheme of these components must be encoded into the device
> > tree so the driver can figure out which component out of two or more of
> > the same type it is supposed to use or program.
> >
> > This patch adds the constraint that local endpoint IDs must be the index
> > or number of the remote endpoint's hardware block, for all components
> > in the display pipeline up to the TCONs.
> >
> > Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index 57a8d0610062..7acdbf14ae1c 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline
> > The Allwinner A10 Display pipeline is composed of several components
> > that are going to be documented below:
> >
> > +For the input port of all components up to the TCON in the display
> > +pipeline, if there are multiple components, the local endpoint IDs
> > +must correspond to the index of the upstream block. For example, if
> > +the remote endpoint is Frontend 1, then the local endpoint ID must
> > +be 1.
> > +
> > +Conversely, for the output ports of the same group, the remote endpoint
> > +ID must be the index of the local hardware block. If the local backend
> > +is backend 1, then the remote endpoint ID must be 1.
>
> It would be clearer if you just explicitly listed IDs and their
> connections. From how this is worded, it would not work if you had
> connections like this:
>
> DevA 0
> DevA 1
> DevB 0
> DevB 1
>
> These would need to be endpoints 0-3 in TCON, and that doesn't reflect
> the remote devices' index.
Chen-Yu, can you send a patch to rephrase the doc that way?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-05-02 14:49 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, Heiko Stübner, Neil Armstrong, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC...,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqK8rjvFW=LFb7==Qho-MHVew-O_vAJ+M6wcFJGfVD6r1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 02/05/17 15:13, Rob Herring wrote:
> On Tue, May 2, 2017 at 6:23 AM, Guillaume Tucker
> <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
>> Hi Rob,
>>
>> On 28/04/17 20:27, Rob Herring wrote:
>>>
>>> On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
>>
>>
>>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> new file mode 100644
>>>> index 000000000000..547ddeceb498
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>>> @@ -0,0 +1,82 @@
>>>> +ARM Mali Midgard GPU
>>>> +====================
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible :
>>>> + * Must be one of the following:
>>>> + + "arm,mali-t60x"
>>>> + + "arm,mali-t62x"
>>>
>>>
>>> Don't use wildcards.
>>
>>
>> Sure, old habits die hard... I'll fix it in patch v5.
>>
>>>> + + "arm,mali-t720"
>>>> + + "arm,mali-t760"
>>>> + + "arm,mali-t820"
>>>> + + "arm,mali-t830"
>>>> + + "arm,mali-t860"
>>>> + + "arm,mali-t880"
>>>> + * And, optionally, one of the vendor specific compatible:
>>>
>>>
>>> IMO, these should not be optional.
>>
>>
>> Well, vendor compatible strings are clearly optional for the
>> Utgard GPU series for which the bindings docs were recently
>> merged. It seems that whether these should be optional or not,
>> the documentation should be consistent between at least all
>> similar types of devices like Midgard and Utgard GPUs. They have
>> different architectures but from a device tree point of view,
>> they both have the same kind of SoC-specific integration (clocks,
>> irqs, regulators...).
>
> Clocks should not vary by SoC. There is often variation because clocks
> get driven by same source or are not s/w controlled, but really there
> should not be that variation. I noticed Utgard has 2 clocks. So is
> Midgard really just 1 clock? The DT should have all the clocks listed
> in the TRMs.
I meant to say that the clock sources are different in each SoC,
but yes the same clock input is always needed by the GPU.
The TRM is confidential but to the best of my knowledge and based
on existing device trees and the out-of-tree kernel driver, the
Midgard GPU has only one clock input.
>> So was this was overlooked in the Utgard case and should it
>> ideally be fixed there as well as non-optional? Or, is it OK to
>> keep these optional on a second thought?
>
> Probably should be required in the Utgard case as well.
OK, so I'll make the vendor compatible strings required (for
Midgard) in patch v5.
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Rob Herring @ 2017-05-02 14:13 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Mark Rutland, Heiko Stübner, Neil Armstrong, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC...,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <60b3c062-d4bb-6502-61be-ada830cf58f7-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Tue, May 2, 2017 at 6:23 AM, Guillaume Tucker
<guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
> Hi Rob,
>
> On 28/04/17 20:27, Rob Herring wrote:
>>
>> On Tue, Apr 25, 2017 at 02:16:16PM +0100, Guillaume Tucker wrote:
>
>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> new file mode 100644
>>> index 000000000000..547ddeceb498
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>>> @@ -0,0 +1,82 @@
>>> +ARM Mali Midgard GPU
>>> +====================
>>> +
>>> +Required properties:
>>> +
>>> +- compatible :
>>> + * Must be one of the following:
>>> + + "arm,mali-t60x"
>>> + + "arm,mali-t62x"
>>
>>
>> Don't use wildcards.
>
>
> Sure, old habits die hard... I'll fix it in patch v5.
>
>>> + + "arm,mali-t720"
>>> + + "arm,mali-t760"
>>> + + "arm,mali-t820"
>>> + + "arm,mali-t830"
>>> + + "arm,mali-t860"
>>> + + "arm,mali-t880"
>>> + * And, optionally, one of the vendor specific compatible:
>>
>>
>> IMO, these should not be optional.
>
>
> Well, vendor compatible strings are clearly optional for the
> Utgard GPU series for which the bindings docs were recently
> merged. It seems that whether these should be optional or not,
> the documentation should be consistent between at least all
> similar types of devices like Midgard and Utgard GPUs. They have
> different architectures but from a device tree point of view,
> they both have the same kind of SoC-specific integration (clocks,
> irqs, regulators...).
Clocks should not vary by SoC. There is often variation because clocks
get driven by same source or are not s/w controlled, but really there
should not be that variation. I noticed Utgard has 2 clocks. So is
Midgard really just 1 clock? The DT should have all the clocks listed
in the TRMs.
> So was this was overlooked in the Utgard case and should it
> ideally be fixed there as well as non-optional? Or, is it OK to
> keep these optional on a second thought?
Probably should be required in the Utgard case as well.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v6,10/23] drivers/fsi: Add device read/write/peek API
From: Eddie James @ 2017-05-02 14:11 UTC (permalink / raw)
To: Christopher Bostic
Cc: robh+dt, mark.rutland, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, devicetree,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, andrew,
alistair-Y4h6yKqj69EXC2x5gXVKYQ, linux-kernel, Jeremy Kerr, benh,
joel
In-Reply-To: <d0d2932a-e69e-bda5-5731-f1bd46fca265-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Apr 10, 2017, at 3:46 PM, Christopher Bostic
<cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote:
> From: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
>
> This change introduces the fsi device API: simple read, write and peek
> accessors for the devices' address spaces.
>
> Includes contributions from Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> and Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>.
>
> Signed-off-by: Edward A. James <eajames-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Jeremy Kerr <jk-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Chris Bostic <cbostic-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
> ---
> drivers/fsi/fsi-core.c | 33 +++++++++++++++++++++++++++++++++
> include/linux/fsi.h | 7 ++++++-
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
> index a8faa89..4da0b030 100644
> --- a/drivers/fsi/fsi-core.c
> +++ b/drivers/fsi/fsi-core.c
> @@ -32,6 +32,8 @@
> #define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
> #define FSI_SLAVE_CONF_DATA_BITS 28
>
> +#define FSI_PEEK_BASE 0x410
> +
> static const int engine_page_size = 0x400;
>
> #define FSI_SLAVE_BASE 0x800
> @@ -73,9 +75,40 @@ static int fsi_master_read(struct fsi_master
> *master, int link,
> uint8_t slave_id, uint32_t addr, void *val, size_t size);
> static int fsi_master_write(struct fsi_master *master, int link,
> uint8_t slave_id, uint32_t addr, const void *val, size_t size);
> +static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
> + void *val, size_t size);
> +static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
> + const void *val, size_t size);
>
> /* FSI endpoint-device support */
>
> +int fsi_device_read(struct fsi_device *dev, uint32_t addr, void *val,
> + size_t size)
> +{
> + if (addr > dev->size || size > dev->size || addr > dev->size - size)
> + return -EINVAL;
> +
> + return fsi_slave_read(dev->slave, dev->addr + addr, val, size);
> +}
> +EXPORT_SYMBOL_GPL(fsi_device_read);
> +
> +int fsi_device_write(struct fsi_device *dev, uint32_t addr, const
> void *val,
> + size_t size)
> +{
> + if (addr > dev->size || size > dev->size || addr > dev->size - size)
> + return -EINVAL;
> +
> + return fsi_slave_write(dev->slave, dev->addr + addr, val, size);
> +}
> +EXPORT_SYMBOL_GPL(fsi_device_write);
> +
> +int fsi_device_peek(struct fsi_device *dev, void *val)
> +{
> + uint32_t addr = FSI_PEEK_BASE + ((dev->unit - 2) *
> sizeof(uint32_t));
> +
> + return fsi_slave_read(dev->slave, addr, val, sizeof(uint32_t));
> +}
> +
> static void fsi_device_release(struct device *_device)
> {
> struct fsi_device *device = to_fsi_dev(_device);
> diff --git a/include/linux/fsi.h b/include/linux/fsi.h
> index efa55ba..66bce48 100644
> --- a/include/linux/fsi.h
> +++ b/include/linux/fsi.h
> @@ -27,6 +27,12 @@ struct fsi_device {
> uint32_t size;
> };
>
> +extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
> + void *val, size_t size);
> +extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
> + const void *val, size_t size);
> +extern int fsi_device_peek(struct fsi_device *dev, void *val);
> +
> struct fsi_device_id {
> u8 engine_type;
> u8 version;
> @@ -40,7 +46,6 @@ struct fsi_device_id {
> #define FSI_DEVICE_VERSIONED(t, v) \
> .engine_type = (t), .version = (v),
>
> -
> struct fsi_driver {
> struct device_driver drv;
> const struct fsi_device_id *id_table;
>
I also wrote a driver against this API (an i2c algorithm). Everything
looks good and working well.
Edward (Eddie) James <eajames-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 3/4] net: macb: Add hardware PTP support
From: Rafal Ozieblo @ 2017-05-02 13:57 UTC (permalink / raw)
To: Richard Cochran
Cc: David Miller, nicolas.ferre@atmel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
harinikatakamlinux@gmail.com, harini.katakam@xilinx.com,
Andrei.Pistirica@microchip.com
In-Reply-To: <20170414182850.GB7751@localhost.localdomain>
> From: Richard Cochran [mailto:richardcochran@gmail.com]
> Sent: 14 kwietnia 2017 20:29
> To: Rafal Ozieblo <rafalo@cadence.com>
> Cc: David Miller <davem@davemloft.net>; nicolas.ferre@atmel.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> harinikatakamlinux@gmail.com; harini.katakam@xilinx.com;
> Andrei.Pistirica@microchip.com
> Subject: Re: [PATCH 3/4] net: macb: Add hardware PTP support
>
> On Thu, Apr 13, 2017 at 02:39:23PM +0100, Rafal Ozieblo wrote:
(...)
> > +static int gem_tsu_get_time(struct macb *bp, struct timespec64 *ts)
> > +{
> > + long first, second;
> > + u32 secl, sech;
> > + unsigned long flags;
> > +
> > + if (!bp || !ts)
> > + return -EINVAL;
>
> Useless test.
Sorry for me being too carefulness, I'll remove all tests.
>
(...)
> > +static int gem_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64
> *ts)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !ts)
> > + return -EINVAL;
>
> Useles test.
>
> What is the point of this wrapper function anyhow? Please remove it.
gem_ptp_gettime() is assigned in ptp_clock_info and it has to have
ptp_clock_info pointer as first parameter. gem_tsu_get_time() is used in
the source code but with macb pointer.
Do you want me to do something like:
gem_ptp_gettime(macb->ptp, ts);
and first would be getting macb pointer from ptp ?
struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
>
> > +
> > + gem_tsu_get_time(bp, ts);
> > + return 0;
> > +}
> > +
> > +static int gem_ptp_settime(struct ptp_clock_info *ptp,
> > + const struct timespec64 *ts)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !ts)
> > + return -EINVAL;
>
> Another useless function.
ditto
>
> > + gem_tsu_set_time(bp, ts);
> > + return 0;
> > +}
> > +
> > +static int gem_ptp_enable(struct ptp_clock_info *ptp,
> > + struct ptp_clock_request *rq, int on)
> > +{
> > + struct macb *bp = container_of(ptp, struct macb, ptp_clock_info);
> > +
> > + if (!ptp || !rq)
> > + return -EINVAL;
>
> Sigh.
>
> > +
> > + switch (rq->type) {
> > + case PTP_CLK_REQ_EXTTS: /* Toggle TSU match interrupt */
> > + if (on)
> > + macb_writel(bp, IER, MACB_BIT(TCI));
>
> No locking to protect IER and IDE?
There is no need.
>
> > + else
> > + macb_writel(bp, IDR, MACB_BIT(TCI));
> > + break;
> > + case PTP_CLK_REQ_PEROUT: /* Toggle Periodic output */
> > + return -EOPNOTSUPP;
> > + /* break; */
> > + case PTP_CLK_REQ_PPS: /* Toggle TSU periodic (second)
> interrupt */
> > + if (on)
> > + macb_writel(bp, IER, MACB_BIT(SRI));
> > + else
> > + macb_writel(bp, IDR, MACB_BIT(SRI));
> > + break;
> > + default:
> > + break;
> > + }
> > + return 0;
> > +}
> > +
(...)
> > --
> > 2.4.5
> >
>
> Thanks,
> Richard
^ 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