* Re: [PATCH 2/2] nvmem: imx-ocotp: add write support
From: Rob Herring @ 2017-04-03 13:18 UTC (permalink / raw)
To: Richard Leitner
Cc: linux-kernel, srinivas.kandagatla, maxime.ripard, mark.rutland,
devicetree, dev
In-Reply-To: <1490621491-28247-2-git-send-email-richard.leitner@skidata.com>
On Mon, Mar 27, 2017 at 03:31:31PM +0200, Richard Leitner wrote:
> Implement write routine for OCOTP controller found in i.MX6 SoC's.
> Furthermore add locking to the read function to prevent race conditions.
> The write routine code is based on the fsl_otp driver from Freescale.
>
> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
> ---
> .../devicetree/bindings/nvmem/imx-ocotp.txt | 4 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nvmem/imx-ocotp.c | 210 ++++++++++++++++++++-
> 2 files changed, 212 insertions(+), 2 deletions(-)
^ permalink raw reply
* RE: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss @ 2017-04-03 13:21 UTC (permalink / raw)
To: Eduardo Valentin, Lee Jones
Cc: LINUX-KERNEL, LINUX-PM, Zhang Rui, DEVICETREE, Dmitry Torokhov,
Guenter Roeck, LINUX-INPUT, LINUX-WATCHDOG, Liam Girdwood,
Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck
In-Reply-To: <20170401195916.GF28514@localhost.localdomain>
On 01 April 2017 @20:59, Eduardo Valentin wrote:
> Subject: Re: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver
>
> On Tue, Mar 28, 2017 at 03:43:33PM +0100, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > Add junction temperature monitoring supervisor device driver, compatible
> > with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
> >
> > If the PMIC's internal junction temperature rises above T_WARN (125 degC)
> > an interrupt is issued. This T_WARN level is defined as the
> > THERMAL_TRIP_HOT trip-wire inside the device driver.
> >
> > The thermal triggering mechanism is interrupt based and happens when the
> > temperature rises above a given threshold level. The component cannot
> > return an exact temperature, it only has knowledge if the temperature is
> > above or below a given threshold value. A status bit must be polled to
> > detect when the temperature falls below that threshold level again. A
> > kernel work queue is configured to repeatedly poll and detect when the
> > temperature falls below this trip-wire, between 1 and 10 second intervals
> > (defaulting at 3 seconds).
> >
> > This scheme is provided as an example. It would be expected that any
> > final implementation will also include a notify() function and any of these
> > settings could be altered to match the application where appropriate.
> >
> > When over-temperature is reached, the interrupt from the DA9061/2 will be
> > repeatedly triggered. The IRQ is therefore disabled when the first
> > over-temperature event happens and the status bit is polled using a
> > work-queue until it becomes false.
> >
> > This strategy is designed to allow the periodic transmission of uevents
> > (HOT trip point) as the first level of temperature supervision method. It
> > is intended for non-invasive temperature control, where the necessary
> > measures for cooling the system down are left to the host software. Once
> > the temperature falls again, the IRQ is re-enabled so a new critical
> > over-temperature event can be detected.
> >
> > Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
> > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> I have had a look on the history of this driver on its previous
> versions, and I do not think I have any other point to request on it.
Thank you.
> Obviously, I still need to state that I do not like its oddness as it is
> not really benefiting much of the thermal control implemented on the
> thermal subsystem.
Agreed.
But, it should be useful in the case of an over-temperature in the system PMIC
when the OS needs to be notified to bring core temperature under control.
> What is the plan for this series? Am I expected to get this driver
> through thermal tree ? Or is this series going into a one shot?
>
> If option 1 is the expected, would the driver need to get its
> mfd parent merged first?
Other components such as the ONKEY and Watchdog have not required the MFD
to be merged first. I don't see any strong dependency for the MFD to exist with this
thermal component.
I'm not sure how much Lee is waiting for Acks to exist before proceeding with the MFD.
I have TO:'d Lee Jones, for this case.
Regards,
Steve
^ permalink raw reply
* Re: [PATCH RFC v4 07/10] dt-bindings: net: add binding for QCA7000 UART
From: Rob Herring @ 2017-04-03 13:23 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <9a094176-ebe7-d906-ca9c-967285e53b07-eS4NqCHxEME@public.gmane.org>
On Tue, Mar 28, 2017 at 06:18:03PM +0200, Stefan Wahren wrote:
> Am 27.03.2017 um 22:30 schrieb Rob Herring:
> > On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> >> This is the serdev binding for the QCA7000 UART driver (Ethernet over UART).
> >>
> >> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> >> ---
> >>
> >> According to this binding are still some questions:
> >>
> >> Where should be the optional hardware flow control defined (at master or slave side)?
> > Probably should be in the slave side. We already have uart-has-rtscts
> > and rts/cts-gpios for the UART. Those mean we have RTS/CTS, but not
> > necessarily that we want to enable them.
> >
> > In many cases, the driver may know what it needs.
>
> Like all the other UART settings the hardware flow control can be
> configured in the QCA7000 firmware and the driver can't detect it.
>
> Property suggestion for the slave side:
>
> use-rtscts
Okay.
> >> Is it okay to have two bindings (qca-qca7000-spi and qca-qca7000-uart) or should they be merged?
> > Are they mutually-exclusive or both are used at the same time?
>
> They are mutually-exclusive because they use the same pins.
>
> > What
> > are the dependencies between the interfaces?
>
> Except they uses the same pins of the QCA7000, i can't see any dependency.
I think they should be a single doc.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] drm/sun4i: Add display backend interrupt to device tree binding
From: Rob Herring @ 2017-04-03 13:24 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, David Airlie, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170327143847.16259-2-wens-jdAy2FN1RRM@public.gmane.org>
On Mon, Mar 27, 2017 at 10:38:46PM +0800, Chen-Yu Tsai wrote:
> The display backend has an interrupt line. Add it to the device tree
> binding.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4 1/4] Documentation: dt-bindings: iio: Add max9611 ADC
From: Rob Herring @ 2017-04-03 13:26 UTC (permalink / raw)
To: Jacopo Mondi
Cc: geert, wsa+renesas, magnus.damm, laurent.pinchart, jic23,
knaack.h, lars, pmeerw, mark.rutland, linux-iio,
linux-renesas-soc, devicetree
In-Reply-To: <1490627578-15938-2-git-send-email-jacopo+renesas@jmondi.org>
On Mon, Mar 27, 2017 at 05:12:55PM +0200, Jacopo Mondi wrote:
> Add device tree bindings documentation for Maxim max9611/max9612 current
> sense amplifier.
"dt-bindings: iio: adc: ..." for the subject.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> .../devicetree/bindings/iio/adc/max9611.txt | 26 ++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/max9611.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/max9611.txt b/Documentation/devicetree/bindings/iio/adc/max9611.txt
> new file mode 100644
> index 0000000..8430d3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/max9611.txt
> @@ -0,0 +1,26 @@
> +* Maxim max9611/max9612 current sense amplifier with 12-bits ADC interface
> +
> +Maxim max9611/max9612 is an high-side current sense amplifier with integrated
> +12-bits ADC communicating over I2c bus.
> +The device node for this driver shall be a child of a I2c controller.
> +
> +Required properties
> + - compatible: Should be "maxim,max9611" or "maxim,max9612"
> + - reg: The 7-bits long I2c address of the device
> + - shunt-resistor-uohm: Value, in uOhm, of the current sense shunt resistor
As Jonathan said.
> +
> +Example:
> +
> +&i2c4 {
> + csa: adc@7c {
> + compatible = "maxim,max9611";
> + reg = <0x7c>;
> +
> + shunt-resistor-uohm = <5000>;
> + };
> +};
> +
> +This device node describes a current sense amplifier sitting on I2c4 bus
> +with address 0x7c (read address is 0xf9, write address is 0xf8).
> +A sense resistor of 0,005 Ohm is installed between RS+ and RS- current-sensing
> +inputs.
> --
> 2.7.4
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] dt-bindings: mtd: Add Cavium SOCs NAND bindings
From: Rob Herring @ 2017-04-03 13:29 UTC (permalink / raw)
To: Jan Glauber
Cc: Boris Brezillon, Richard Weinberger, David Woodhouse,
Brian Norris, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170327160524.29019-2-jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
On Mon, Mar 27, 2017 at 06:05:23PM +0200, Jan Glauber wrote:
> Add device tree binding description for Cavium SOC nand flash controller.
>
> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Signed-off-by: Jan Glauber <jglauber-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/cavium_nand.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/cavium_nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/cavium_nand.txt b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> new file mode 100644
> index 0000000..4698d1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/cavium_nand.txt
> @@ -0,0 +1,32 @@
> +* Cavium NAND controller
> +
> +Required properties:
> +
> +- compatible: should be "cavium,cn8xxx-nand"
Don't use wildcards in compatible strings. For PCI devices, this should
be based on the PCI vendor and device IDs.
> +- reg: PCI devfn
> +- clocks: must contain system clock
> +- #address-cells: <1>
> +- #size-cells: <0>
> +
> +The nand flash controller may contain up to 8 subnodes representing
> +NAND flash chips. Their properties are as follows.
> +
> +Required properties:
> +- compatible: should be "cavium,nandcs"
> +- reg: a single integer representing the chip-select number
> +- nand-ecc-mode: see nand.txt
> +
> +Example:
> +
> +nfc: nand@b,0 {
> + compatible = "cavium,cn8xxx-nand";
> + reg = <0x5800 0 0 0 0>;
> + clocks = <&sclk>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand@1 {
> + compatible = "cavium,nandcs";
> + reg = <1>;
> + nand-ecc-mode = "on-die";
> +};
> --
> 2.9.0.rc0.21.g7777322
>
--
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 v3 1/2] i2c:mux:ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: michael.hennerich @ 2017-04-03 13:31 UTC (permalink / raw)
To: wsa, peda, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel,
Michael Hennerich
From: Michael Hennerich <michael.hennerich@analog.com>
This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
---
Changes since v1:
- Sort makefile entries
- Sort driver includes
- Use proper defines
- Miscellaneous coding style fixups
- Rename mux select callback
- Revise i2c-mux-idle-disconnect handling
- Add ENABLE GPIO handling on error and device removal.
- Remove surplus of_match_device call.
Changes since v2:
- Stop double error reporting (i2c_mux_add_adapter)
- Change subject
- Split dt bindings to separate patch
---
MAINTAINERS | 8 +
drivers/i2c/muxes/Kconfig | 10 +
drivers/i2c/muxes/Makefile | 1 +
drivers/i2c/muxes/i2c-mux-ltc4306.c | 363 ++++++++++++++++++++++++++++++++++++
4 files changed, 382 insertions(+)
create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S: Maintained
F: Documentation/hwmon/ltc4261
F: drivers/hwmon/ltc4261.c
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich <michael.hennerich@analog.com>
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-i2c@vger.kernel.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
LTP (Linux Test Project)
M: Mike Frysinger <vapier@gentoo.org>
M: Cyril Hrubis <chrubis@suse.cz>
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..f501b3b 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,16 @@ config I2C_MUX_GPIO
This driver can also be built as a module. If so, the module
will be called i2c-mux-gpio.
+config I2C_MUX_LTC4306
+ tristate "LTC LTC4306/5 I2C multiplexer"
+ select GPIOLIB
+ help
+ If you say yes here you get support for the LTC LTC4306 or LTC4305
+ I2C mux/switch devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-mux-ltc4306.
+
config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..ff7618c 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE) += i2c-arb-gpio-challenge.o
obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
+obj-$(CONFIG_I2C_MUX_LTC4306) += i2c-mux-ltc4306.o
obj-$(CONFIG_I2C_MUX_MLXCPLD) += i2c-mux-mlxcpld.o
obj-$(CONFIG_I2C_MUX_PCA9541) += i2c-mux-pca9541.o
obj-$(CONFIG_I2C_MUX_PCA954x) += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-mux-ltc4306.c b/drivers/i2c/muxes/i2c-mux-ltc4306.c
new file mode 100644
index 0000000..34ac47d
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-mux-ltc4306.c
@@ -0,0 +1,363 @@
+/*
+ * Linear Technology LTC4306 and LTC4305 I2C multiplexer/switch
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Based on: i2c-mux-pca954x.c
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/4306.pdf
+ */
+
+#include <linux/device.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/i2c-mux.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/slab.h>
+
+#define LTC4305_MAX_NCHANS 2
+#define LTC4306_MAX_NCHANS 4
+
+#define LTC_REG_STATUS 0x0
+#define LTC_REG_CONFIG 0x1
+#define LTC_REG_MODE 0x2
+#define LTC_REG_SWITCH 0x3
+
+#define LTC_DOWNSTREAM_ACCL_EN BIT(6)
+#define LTC_UPSTREAM_ACCL_EN BIT(7)
+
+#define LTC_GPIO_ALL_INPUT 0xC0
+
+enum ltc_type {
+ ltc_4305,
+ ltc_4306,
+};
+
+struct chip_desc {
+ u8 nchans;
+ u8 num_gpios;
+};
+
+struct ltc4306 {
+ struct i2c_client *client;
+ struct gpio_desc *en_gpio;
+ struct gpio_chip gpiochip;
+ const struct chip_desc *chip;
+ u8 regs[LTC_REG_SWITCH + 1];
+};
+
+/* Provide specs for the PCA954x types we know about */
+static const struct chip_desc chips[] = {
+ [ltc_4305] = {
+ .nchans = LTC4305_MAX_NCHANS,
+ },
+ [ltc_4306] = {
+ .nchans = LTC4306_MAX_NCHANS,
+ .num_gpios = 2,
+ },
+};
+
+static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+ int ret = 0;
+
+ if (gpiochip_line_is_open_drain(chip, offset) ||
+ (data->regs[LTC_REG_MODE] & BIT(7 - offset))) {
+ /* Open Drain or Input */
+ ret = i2c_smbus_read_byte_data(data->client, LTC_REG_CONFIG);
+ if (ret < 0)
+ return ret;
+
+ return !!(ret & BIT(1 - offset));
+ } else {
+ return !!(data->regs[LTC_REG_CONFIG] & BIT(5 - offset));
+ }
+}
+
+static void ltc4306_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ if (value)
+ data->regs[LTC_REG_CONFIG] |= BIT(5 - offset);
+ else
+ data->regs[LTC_REG_CONFIG] &= ~BIT(5 - offset);
+
+ i2c_smbus_write_byte_data(data->client, LTC_REG_CONFIG,
+ data->regs[LTC_REG_CONFIG]);
+}
+
+static int ltc4306_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ data->regs[LTC_REG_MODE] |= BIT(7 - offset);
+
+ return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
+ data->regs[LTC_REG_MODE]);
+}
+
+static int ltc4306_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ ltc4306_gpio_set(chip, offset, value);
+ data->regs[LTC_REG_MODE] &= ~BIT(7 - offset);
+
+ return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
+ data->regs[LTC_REG_MODE]);
+}
+
+static int ltc4306_gpio_set_config(struct gpio_chip *chip,
+ unsigned int offset, unsigned long config)
+{
+ struct ltc4306 *data = gpiochip_get_data(chip);
+
+ switch (pinconf_to_config_param(config)) {
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ data->regs[LTC_REG_MODE] &= ~BIT(4 - offset);
+ break;
+ case PIN_CONFIG_DRIVE_PUSH_PULL:
+ data->regs[LTC_REG_MODE] |= BIT(4 - offset);
+ break;
+ default:
+ return -ENOTSUPP;
+ }
+
+ return i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
+ data->regs[LTC_REG_MODE]);
+}
+
+static int ltc4306_gpio_init(struct ltc4306 *data)
+{
+ if (!data->chip->num_gpios)
+ return 0;
+
+ data->gpiochip.label = dev_name(&data->client->dev);
+ data->gpiochip.base = -1;
+ data->gpiochip.ngpio = data->chip->num_gpios;
+ data->gpiochip.parent = &data->client->dev;
+ data->gpiochip.can_sleep = true;
+ data->gpiochip.direction_input = ltc4306_gpio_direction_input;
+ data->gpiochip.direction_output = ltc4306_gpio_direction_output;
+ data->gpiochip.get = ltc4306_gpio_get;
+ data->gpiochip.set = ltc4306_gpio_set;
+ data->gpiochip.set_config = ltc4306_gpio_set_config;
+ data->gpiochip.owner = THIS_MODULE;
+
+ /* gpiolib assumes all GPIOs default input */
+ data->regs[LTC_REG_MODE] |= LTC_GPIO_ALL_INPUT;
+ i2c_smbus_write_byte_data(data->client, LTC_REG_MODE,
+ data->regs[LTC_REG_MODE]);
+
+ return devm_gpiochip_add_data(&data->client->dev,
+ &data->gpiochip, data);
+}
+
+/*
+ * Write to chip register. Don't use i2c_transfer()/i2c_smbus_xfer()
+ * as they will try to lock the adapter a second time.
+ */
+static int ltc4306_reg_write(struct i2c_adapter *adap,
+ struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+
+ if (adap->algo->master_xfer) {
+ struct i2c_msg msg;
+ char buf[2];
+
+ msg.addr = client->addr;
+ msg.flags = 0;
+ msg.len = 2;
+ buf[0] = reg;
+ buf[1] = val;
+ msg.buf = buf;
+ ret = __i2c_transfer(adap, &msg, 1);
+ } else {
+ union i2c_smbus_data data;
+
+ data.byte = val;
+ ret = adap->algo->smbus_xfer(adap, client->addr,
+ client->flags,
+ I2C_SMBUS_WRITE,
+ reg,
+ I2C_SMBUS_BYTE_DATA, &data);
+ }
+
+ return ret;
+}
+
+static int ltc4306_select_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+ struct i2c_client *client = data->client;
+ u8 regval;
+ int ret = 0;
+
+ regval = BIT(7 - chan);
+
+ /* Only select the channel if its different from the last channel */
+ if (data->regs[LTC_REG_SWITCH] != regval) {
+ ret = ltc4306_reg_write(muxc->parent, client,
+ LTC_REG_SWITCH, regval);
+ data->regs[LTC_REG_SWITCH] = ret < 0 ? 0 : regval;
+ }
+
+ return ret;
+}
+
+static int ltc4306_deselect_mux(struct i2c_mux_core *muxc, u32 chan)
+{
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+ struct i2c_client *client = data->client;
+
+ /* Deselect all channels */
+ data->regs[LTC_REG_SWITCH] = 0;
+
+ return ltc4306_reg_write(muxc->parent, client,
+ LTC_REG_SWITCH, data->regs[LTC_REG_SWITCH]);
+}
+
+static const struct i2c_device_id ltc4306_id[] = {
+ { "ltc4305", ltc_4305 },
+ { "ltc4306", ltc_4306 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ltc4306_id);
+
+static const struct of_device_id ltc4306_of_match[] = {
+ { .compatible = "lltc,ltc4305", .data = &chips[ltc_4305] },
+ { .compatible = "lltc,ltc4306", .data = &chips[ltc_4306] },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc4306_of_match);
+
+static int ltc4306_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct i2c_adapter *adap = to_i2c_adapter(client->dev.parent);
+ struct device_node *of_node = client->dev.of_node;
+ bool idle_disconnect_dt = false;
+ struct i2c_mux_core *muxc;
+ struct ltc4306 *data;
+ int num, ret;
+
+ if (!i2c_check_functionality(adap, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -ENODEV;
+
+ if (of_node) {
+ idle_disconnect_dt =
+ of_property_read_bool(of_node,
+ "i2c-mux-idle-disconnect");
+ }
+
+ muxc = i2c_mux_alloc(adap, &client->dev,
+ LTC4306_MAX_NCHANS, sizeof(*data), 0,
+ ltc4306_select_mux, idle_disconnect_dt ?
+ ltc4306_deselect_mux : NULL);
+ if (!muxc)
+ return -ENOMEM;
+ data = i2c_mux_priv(muxc);
+
+ i2c_set_clientdata(client, muxc);
+ data->client = client;
+
+ /* Enable the mux if an enable GPIO is specified. */
+ data->en_gpio = devm_gpiod_get_optional(&client->dev, "enable",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(data->en_gpio))
+ return PTR_ERR(data->en_gpio);
+
+ /*
+ * Write the mux register at addr to verify
+ * that the mux is in fact present. This also
+ * initializes the mux to disconnected state.
+ */
+ if (i2c_smbus_write_byte_data(client, LTC_REG_SWITCH, 0) < 0) {
+ dev_warn(&client->dev, "probe failed\n");
+ ret = -ENODEV;
+ goto gpio_default;
+ }
+
+ if (of_node) {
+ data->chip = of_device_get_match_data(&client->dev);
+
+ if (of_property_read_bool(of_node,
+ "ltc,downstream-accelerators-enable"))
+ data->regs[LTC_REG_CONFIG] |= LTC_DOWNSTREAM_ACCL_EN;
+
+ if (of_property_read_bool(of_node,
+ "ltc,upstream-accelerators-enable"))
+ data->regs[LTC_REG_CONFIG] |= LTC_UPSTREAM_ACCL_EN;
+
+ if (i2c_smbus_write_byte_data(client, LTC_REG_CONFIG,
+ data->regs[LTC_REG_CONFIG]) < 0) {
+ dev_warn(&client->dev, "probe failed\n");
+ ret = -ENODEV;
+ goto gpio_default;
+ }
+ } else {
+ data->chip = &chips[id->driver_data];
+ }
+
+ ret = ltc4306_gpio_init(data);
+ if (ret < 0)
+ goto gpio_default;
+
+ /* Now create an adapter for each channel */
+ for (num = 0; num < data->chip->nchans; num++) {
+ ret = i2c_mux_add_adapter(muxc, 0, num, 0);
+ if (ret)
+ goto add_adapter_failed;
+ }
+
+ dev_info(&client->dev,
+ "registered %d multiplexed busses for I2C switch %s\n",
+ num, client->name);
+
+ return 0;
+
+add_adapter_failed:
+ i2c_mux_del_adapters(muxc);
+gpio_default:
+ gpiod_direction_input(data->en_gpio);
+ return ret;
+}
+
+static int ltc4306_remove(struct i2c_client *client)
+{
+ struct i2c_mux_core *muxc = i2c_get_clientdata(client);
+ struct ltc4306 *data = i2c_mux_priv(muxc);
+
+ i2c_mux_del_adapters(muxc);
+ gpiod_direction_input(data->en_gpio);
+
+ return 0;
+}
+
+static struct i2c_driver ltc4306_driver = {
+ .driver = {
+ .name = "ltc4306",
+ .of_match_table = of_match_ptr(ltc4306_of_match),
+ },
+ .probe = ltc4306_probe,
+ .remove = ltc4306_remove,
+ .id_table = ltc4306_id,
+};
+
+module_i2c_driver(ltc4306_driver);
+
+MODULE_AUTHOR("Michael Hennerich <michael.hennerich@analog.com>");
+MODULE_DESCRIPTION("Linear Technology LTC4306, LTC4305 I2C mux/switch driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] dt-bindings:i2c:mux:ltc4306: Add dt-bindings for I2C multiplexer/switch
From: michael.hennerich @ 2017-04-03 13:31 UTC (permalink / raw)
To: wsa, peda, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel,
Michael Hennerich
In-Reply-To: <1491226297-4970-1-git-send-email-michael.hennerich@analog.com>
From: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-mux-ltc4306.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
new file mode 100644
index 0000000..1e98c6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -0,0 +1,61 @@
+* Linear Technology / Analog Devices I2C bus switch
+
+Required Properties:
+
+ - compatible: Must contain one of the following.
+ "lltc,ltc4305", "lltc,ltc4306"
+ - reg: The I2C address of the device.
+
+ The following required properties are defined externally:
+
+ - Standard I2C mux properties. See i2c-mux.txt in this directory.
+ - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+Optional Properties:
+
+ - enable-gpios: Reference to the GPIO connected to the enable input.
+ - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+ children in idle state. This is necessary for example, if there are several
+ multiplexers on the bus and the devices behind them use same I2C addresses.
+ - gpio-controller: Marks the device node as a GPIO Controller.
+ - #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See ../gpio/gpio.txt for more information.
+ - ltc,downstream-accelerators-enable: Enables the rise time accelerators
+ on the downstream port.
+ - ltc,upstream-accelerators-enable: Enables the rise time accelerators
+ on the upstream port.
+
+Example:
+
+ ltc4306: i2c-mux@4a {
+ compatible = "lltc,ltc4306";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4a>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ eeprom@50 {
+ compatible = "at,24c02";
+ reg = <0x50>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] dt-bindings: arm,nvic: Binding for ARM NVIC interrupt controller on Cortex-M
From: Rob Herring @ 2017-04-03 13:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170327180905.32498-1-kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Mar 27, 2017 at 01:09:05PM -0500, Kumar Gala wrote:
> Signed-off-by: Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> Note: This is a new binding and not used by the linux kernel code right now for
> the nvic. The intent would be to support both the current 'arm,armv7m-nvic'
> compatible and this binding in the code in the future. The 'arm,armv7m-nvic'
> doesnt have any binding spec covering it today.
>
> .../bindings/interrupt-controller/arm,nvic.txt | 37 ++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
> new file mode 100644
> index 0000000..60ee89c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
> @@ -0,0 +1,37 @@
> +* ARM Nested Vector Interrupt Controller (NVIC)
> +
> +The NVIC provides an interrupt controller that is tightly coupled to
> +Cortex-M based processor cores. The NVIC implemented on different SoCs
> +vary in the number of interrupts and priority bits per interrupt.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> + "arm,v6m-nvic"
> + "arm,v7m-nvic"
> + "arm,v8m-nvic"
> + "arm,nvic"
I'd drop this last one.
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The type shall be a <u32> and the value shall be 2.
> +
> + The 1st cell contains the interrupt number for the interrupt type.
> +
> + The 2nd cell is the priority of the interrupt.
No level/edge flags needed?
> +
> +- reg : Specifies base physical address(s) and size of the NVIC registers.
> + This is at a fixed address (0xe000e100) and size (0xc00).
> +
> +- arm,num-irq-priority-bits: The number of priority bits implemented by the
> + given SoC
> +
> +Example:
> +
> + intc: interrupt-controller@e000e100 {
> + compatible = "arm,nvic";
> + #interrupt-cells = <2>;
> + #address-cells = <1>;
> + interrupt-controller;
> + reg = <0xe000e100 0xc00>;
> + arm,num-irq-priority-bits = <4>;
> + };
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-03 13:36 UTC (permalink / raw)
To: Peter Rosin, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <3c61461e-493c-4562-90c9-f30766591de2@axentia.se>
On 03.04.2017 14:03, Peter Rosin wrote:
> On 2017-03-31 17:29, Peter Rosin wrote:
>> Hi!
>>
>> Sorry for my incremental reviewing...
>>
>
> Another incremental...
>
>> On 2017-03-29 12:15, michael.hennerich@analog.com wrote:
>>> +
>>> + /* Now create an adapter for each channel */
>>> + for (num = 0; num < data->chip->nchans; num++) {
>>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>>> + if (ret) {
>>> + dev_err(&client->dev,
>>> + "failed to register multiplexed adapter %d\n",
>>> + num);
>
> Just a heads up, I submitted a series to remove a bunch of dev_err calls
> when i2c_mux_add_adapter fails. See https://lkml.org/lkml/2017/4/3/115
>
> You can remove this one as well.
>
> And please use a subject of the form:
> i2c: mux: ltc4306: <message>
>
> Cheers,
> peda
ok - no problem.
I sent out a new patch. Per Rob's request, I split out the dt-bindings
into a separate patch.
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* [PATCH v3 0/2] drm/panel: Add support for the Sitronix ST7789V
From: Maxime Ripard @ 2017-04-03 13:38 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Thierry Reding
Cc: Daniel Vetter, David Airlie,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
noralf-L59+Z2yzLopAfugRpC6u6w, Maxime Ripard
Hi,
Here is an attempt at supporting the ST7789V LCD controller from Sitronix.
It is controlled through an SPI bus, with a twist, since each byte sent
must be prefixed by a bit, which needs an 9-bits-per-word SPI controller,
which is quite rare. Else, you would need to bitbang it.
Let me know what you think,
Maxime
Changes from v2:
- Added Rob's Acked-by
Changes from v1:
- Added regulator support
- Removed variadic arguments from the functions
- Added test on the success of the SPI transfers
- Used the MIPI DCS defines
- Expanded the Kconfig help, and fixed the option label
Maxime Ripard (2):
dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
drm/panel: Add driver for sitronix ST7789V LCD controller
Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37 ++++++-
drivers/gpu/drm/panel/Kconfig | 7 +-
drivers/gpu/drm/panel/Makefile | 1 +-
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 449 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 494 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7789v.c
base-commit: 62e499ad00e32736b2dd223f442e19d3df5eeed3
--
git-series 0.8.11
--
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 v3 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel
From: Maxime Ripard @ 2017-04-03 13:38 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Thierry Reding
Cc: devicetree, linux-kernel, dri-devel, Daniel Vetter, Maxime Ripard
In-Reply-To: <cover.74614dd427b0214d0ba7ccfe75bdd7506b42e61d.1491226701.git-series.maxime.ripard@free-electrons.com>
The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
can drive 18-bits 240x320 LCD displays.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
new file mode 100644
index 000000000000..c6995dde641b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt
@@ -0,0 +1,37 @@
+Sitronix ST7789V RGB panel with SPI control bus
+
+Required properties:
+ - compatible: "sitronix,st7789v"
+ - reg: Chip select of the panel on the SPI bus
+ - reset-gpios: a GPIO phandle for the reset pin
+ - power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+ - backlight: phandle to the backlight used
+
+The generic bindings for the SPI slaves documented in [1] also applies
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
+[2]: Documentation/devicetree/bindings/graph.txt
+
+Example:
+
+panel@0 {
+ compatible = "sitronix,st7789v";
+ reg = <0>;
+ reset-gpios = <&pio 6 11 GPIO_ACTIVE_LOW>;
+ backlight = <&pwm_bl>;
+ spi-max-frequency = <100000>;
+ spi-cpol;
+ spi-cpha;
+
+ port {
+ panel_input: endpoint {
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+ };
+};
--
git-series 0.8.11
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 2/2] drm/panel: Add driver for sitronix ST7789V LCD controller
From: Maxime Ripard @ 2017-04-03 13:38 UTC (permalink / raw)
To: Mark Rutland, Rob Herring, Thierry Reding
Cc: devicetree, linux-kernel, dri-devel, Daniel Vetter, Maxime Ripard
In-Reply-To: <cover.74614dd427b0214d0ba7ccfe75bdd7506b42e61d.1491226701.git-series.maxime.ripard@free-electrons.com>
The Sitronix ST7789v controller is used to drive 240x320 LCD panels through
various interfaces, including SPI and RGB/Parallel.
The current driver is configuring it for the latter. Support for tinyDRM
can always be added later.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/panel/Kconfig | 7 +-
drivers/gpu/drm/panel/Makefile | 1 +-
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 449 ++++++++++++++++++-
3 files changed, 457 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7789v.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba976e744..eb42dc37e979 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -81,4 +81,11 @@ config DRM_PANEL_SHARP_LS043T1LE01
Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
(540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
+config DRM_PANEL_SITRONIX_ST7789V
+ tristate "Sitronix ST7789V panel"
+ depends on OF && SPI
+ help
+ Say Y here if you want to enable support for the Sitronix
+ ST7789V controller for 240x320 LCD panels
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0236e0..41b245d39984 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
+obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
new file mode 100644
index 000000000000..358c64ef1922
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -0,0 +1,449 @@
+/*
+ * Copyright (C) 2017 Free Electrons
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ */
+
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_panel.h>
+
+#include <video/mipi_display.h>
+
+#define ST7789V_COLMOD_RGB_FMT_18BITS (6 << 4)
+#define ST7789V_COLMOD_CTRL_FMT_18BITS (6 << 0)
+
+#define ST7789V_RAMCTRL_CMD 0xb0
+#define ST7789V_RAMCTRL_RM_RGB BIT(4)
+#define ST7789V_RAMCTRL_DM_RGB BIT(0)
+#define ST7789V_RAMCTRL_MAGIC (3 << 6)
+#define ST7789V_RAMCTRL_EPF(n) (((n) & 3) << 4)
+
+#define ST7789V_RGBCTRL_CMD 0xb1
+#define ST7789V_RGBCTRL_WO BIT(7)
+#define ST7789V_RGBCTRL_RCM(n) (((n) & 3) << 5)
+#define ST7789V_RGBCTRL_VSYNC_HIGH BIT(3)
+#define ST7789V_RGBCTRL_HSYNC_HIGH BIT(2)
+#define ST7789V_RGBCTRL_PCLK_HIGH BIT(1)
+#define ST7789V_RGBCTRL_VBP(n) ((n) & 0x7f)
+#define ST7789V_RGBCTRL_HBP(n) ((n) & 0x1f)
+
+#define ST7789V_PORCTRL_CMD 0xb2
+#define ST7789V_PORCTRL_IDLE_BP(n) (((n) & 0xf) << 4)
+#define ST7789V_PORCTRL_IDLE_FP(n) ((n) & 0xf)
+#define ST7789V_PORCTRL_PARTIAL_BP(n) (((n) & 0xf) << 4)
+#define ST7789V_PORCTRL_PARTIAL_FP(n) ((n) & 0xf)
+
+#define ST7789V_GCTRL_CMD 0xb7
+#define ST7789V_GCTRL_VGHS(n) (((n) & 7) << 4)
+#define ST7789V_GCTRL_VGLS(n) ((n) & 7)
+
+#define ST7789V_VCOMS_CMD 0xbb
+
+#define ST7789V_LCMCTRL_CMD 0xc0
+#define ST7789V_LCMCTRL_XBGR BIT(5)
+#define ST7789V_LCMCTRL_XMX BIT(3)
+#define ST7789V_LCMCTRL_XMH BIT(2)
+
+#define ST7789V_VDVVRHEN_CMD 0xc2
+#define ST7789V_VDVVRHEN_CMDEN BIT(0)
+
+#define ST7789V_VRHS_CMD 0xc3
+
+#define ST7789V_VDVS_CMD 0xc4
+
+#define ST7789V_FRCTRL2_CMD 0xc6
+
+#define ST7789V_PWCTRL1_CMD 0xd0
+#define ST7789V_PWCTRL1_MAGIC 0xa4
+#define ST7789V_PWCTRL1_AVDD(n) (((n) & 3) << 6)
+#define ST7789V_PWCTRL1_AVCL(n) (((n) & 3) << 4)
+#define ST7789V_PWCTRL1_VDS(n) ((n) & 3)
+
+#define ST7789V_PVGAMCTRL_CMD 0xe0
+#define ST7789V_PVGAMCTRL_JP0(n) (((n) & 3) << 4)
+#define ST7789V_PVGAMCTRL_JP1(n) (((n) & 3) << 4)
+#define ST7789V_PVGAMCTRL_VP0(n) ((n) & 0xf)
+#define ST7789V_PVGAMCTRL_VP1(n) ((n) & 0x3f)
+#define ST7789V_PVGAMCTRL_VP2(n) ((n) & 0x3f)
+#define ST7789V_PVGAMCTRL_VP4(n) ((n) & 0x1f)
+#define ST7789V_PVGAMCTRL_VP6(n) ((n) & 0x1f)
+#define ST7789V_PVGAMCTRL_VP13(n) ((n) & 0xf)
+#define ST7789V_PVGAMCTRL_VP20(n) ((n) & 0x7f)
+#define ST7789V_PVGAMCTRL_VP27(n) ((n) & 7)
+#define ST7789V_PVGAMCTRL_VP36(n) (((n) & 7) << 4)
+#define ST7789V_PVGAMCTRL_VP43(n) ((n) & 0x7f)
+#define ST7789V_PVGAMCTRL_VP50(n) ((n) & 0xf)
+#define ST7789V_PVGAMCTRL_VP57(n) ((n) & 0x1f)
+#define ST7789V_PVGAMCTRL_VP59(n) ((n) & 0x1f)
+#define ST7789V_PVGAMCTRL_VP61(n) ((n) & 0x3f)
+#define ST7789V_PVGAMCTRL_VP62(n) ((n) & 0x3f)
+#define ST7789V_PVGAMCTRL_VP63(n) (((n) & 0xf) << 4)
+
+#define ST7789V_NVGAMCTRL_CMD 0xe1
+#define ST7789V_NVGAMCTRL_JN0(n) (((n) & 3) << 4)
+#define ST7789V_NVGAMCTRL_JN1(n) (((n) & 3) << 4)
+#define ST7789V_NVGAMCTRL_VN0(n) ((n) & 0xf)
+#define ST7789V_NVGAMCTRL_VN1(n) ((n) & 0x3f)
+#define ST7789V_NVGAMCTRL_VN2(n) ((n) & 0x3f)
+#define ST7789V_NVGAMCTRL_VN4(n) ((n) & 0x1f)
+#define ST7789V_NVGAMCTRL_VN6(n) ((n) & 0x1f)
+#define ST7789V_NVGAMCTRL_VN13(n) ((n) & 0xf)
+#define ST7789V_NVGAMCTRL_VN20(n) ((n) & 0x7f)
+#define ST7789V_NVGAMCTRL_VN27(n) ((n) & 7)
+#define ST7789V_NVGAMCTRL_VN36(n) (((n) & 7) << 4)
+#define ST7789V_NVGAMCTRL_VN43(n) ((n) & 0x7f)
+#define ST7789V_NVGAMCTRL_VN50(n) ((n) & 0xf)
+#define ST7789V_NVGAMCTRL_VN57(n) ((n) & 0x1f)
+#define ST7789V_NVGAMCTRL_VN59(n) ((n) & 0x1f)
+#define ST7789V_NVGAMCTRL_VN61(n) ((n) & 0x3f)
+#define ST7789V_NVGAMCTRL_VN62(n) ((n) & 0x3f)
+#define ST7789V_NVGAMCTRL_VN63(n) (((n) & 0xf) << 4)
+
+#define ST7789V_TEST(val, func) \
+ do { \
+ if ((val = (func))) \
+ return val; \
+ } while (0)
+
+struct st7789v {
+ struct drm_panel panel;
+ struct spi_device *spi;
+ struct gpio_desc *reset;
+ struct backlight_device *backlight;
+ struct regulator *power;
+};
+
+enum st7789v_prefix {
+ ST7789V_COMMAND = 0,
+ ST7789V_DATA = 1,
+};
+
+static inline struct st7789v *panel_to_st7789v(struct drm_panel *panel)
+{
+ return container_of(panel, struct st7789v, panel);
+}
+
+static int st7789v_spi_write(struct st7789v *ctx, enum st7789v_prefix prefix,
+ u8 data)
+{
+ struct spi_transfer xfer = { };
+ struct spi_message msg;
+ u16 txbuf = ((prefix & 1) << 8) | data;
+
+ spi_message_init(&msg);
+
+ xfer.tx_buf = &txbuf;
+ xfer.bits_per_word = 9;
+ xfer.len = sizeof(txbuf);
+
+ spi_message_add_tail(&xfer, &msg);
+ return spi_sync(ctx->spi, &msg);
+}
+
+static int st7789v_write_command(struct st7789v *ctx, u8 cmd)
+{
+ return st7789v_spi_write(ctx, ST7789V_COMMAND, cmd);
+}
+
+static int st7789v_write_data(struct st7789v *ctx, u8 cmd)
+{
+ return st7789v_spi_write(ctx, ST7789V_DATA, cmd);
+}
+
+static const struct drm_display_mode default_mode = {
+ .clock = 7000,
+ .hdisplay = 240,
+ .hsync_start = 240 + 38,
+ .hsync_end = 240 + 38 + 10,
+ .htotal = 240 + 38 + 10 + 10,
+ .vdisplay = 320,
+ .vsync_start = 320 + 8,
+ .vsync_end = 320 + 8 + 4,
+ .vtotal = 320 + 8 + 4 + 4,
+ .vrefresh = 60,
+};
+
+static int st7789v_get_modes(struct drm_panel *panel)
+{
+ struct drm_connector *connector = panel->connector;
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(panel->drm, &default_mode);
+ if (!mode) {
+ dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
+ return -ENOMEM;
+ }
+
+ drm_mode_set_name(mode);
+
+ mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_probed_add(connector, mode);
+
+ panel->connector->display_info.width_mm = 61;
+ panel->connector->display_info.height_mm = 103;
+
+ return 1;
+}
+
+static int st7789v_prepare(struct drm_panel *panel)
+{
+ struct st7789v *ctx = panel_to_st7789v(panel);
+ int ret;
+
+ ret = regulator_enable(ctx->power);
+ if (ret)
+ return ret;
+
+ gpiod_set_value(ctx->reset, 1);
+ msleep(30);
+ gpiod_set_value(ctx->reset, 0);
+ msleep(120);
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, MIPI_DCS_EXIT_SLEEP_MODE));
+
+ /* We need to wait 120ms after a sleep out command */
+ msleep(120);
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx,
+ MIPI_DCS_SET_ADDRESS_MODE));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx,
+ MIPI_DCS_SET_PIXEL_FORMAT));
+ ST7789V_TEST(ret, st7789v_write_data(ctx,
+ (MIPI_DCS_PIXEL_FMT_18BIT << 4) |
+ (MIPI_DCS_PIXEL_FMT_18BIT)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_PORCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0xc));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0xc));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PORCTRL_IDLE_BP(3) |
+ ST7789V_PORCTRL_IDLE_FP(3)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx,
+ ST7789V_PORCTRL_PARTIAL_BP(3) |
+ ST7789V_PORCTRL_PARTIAL_FP(3)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_GCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_GCTRL_VGLS(5) |
+ ST7789V_GCTRL_VGHS(3)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VCOMS_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0x2b));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_LCMCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_LCMCTRL_XMH |
+ ST7789V_LCMCTRL_XMX |
+ ST7789V_LCMCTRL_XBGR));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VDVVRHEN_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_VDVVRHEN_CMDEN));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VRHS_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0xf));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_VDVS_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0x20));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_FRCTRL2_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, 0xf));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_PWCTRL1_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PWCTRL1_MAGIC));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PWCTRL1_AVDD(2) |
+ ST7789V_PWCTRL1_AVCL(2) |
+ ST7789V_PWCTRL1_VDS(1)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_PVGAMCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP63(0xd)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP1(0xca)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP2(0xe)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP4(8)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP6(9)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP13(7)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP20(0x2d)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP27(0xb) |
+ ST7789V_PVGAMCTRL_VP36(3)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP43(0x3d)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_JP1(3) |
+ ST7789V_PVGAMCTRL_VP50(4)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP57(0xa)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP59(0xa)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP61(0x1b)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_PVGAMCTRL_VP62(0x28)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_NVGAMCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN63(0xd)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN1(0xca)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN2(0xf)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN4(8)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN6(8)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN13(7)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN20(0x2e)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN27(0xc) |
+ ST7789V_NVGAMCTRL_VN36(5)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN43(0x40)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_JN1(3) |
+ ST7789V_NVGAMCTRL_VN50(4)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN57(9)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN59(0xb)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN61(0x1b)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_NVGAMCTRL_VN62(0x28)));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, MIPI_DCS_ENTER_INVERT_MODE));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_RAMCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RAMCTRL_DM_RGB |
+ ST7789V_RAMCTRL_RM_RGB));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RAMCTRL_EPF(3) |
+ ST7789V_RAMCTRL_MAGIC));
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_RGBCTRL_CMD));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RGBCTRL_WO |
+ ST7789V_RGBCTRL_RCM(2) |
+ ST7789V_RGBCTRL_VSYNC_HIGH |
+ ST7789V_RGBCTRL_HSYNC_HIGH |
+ ST7789V_RGBCTRL_PCLK_HIGH));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RGBCTRL_VBP(8)));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RGBCTRL_HBP(20)));
+
+ return 0;
+}
+
+static int st7789v_enable(struct drm_panel *panel)
+{
+ struct st7789v *ctx = panel_to_st7789v(panel);
+
+ if (ctx->backlight) {
+ ctx->backlight->props.state &= ~BL_CORE_FBBLANK;
+ ctx->backlight->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(ctx->backlight);
+ }
+
+ return st7789v_write_command(ctx, MIPI_DCS_SET_DISPLAY_ON);
+}
+
+static int st7789v_disable(struct drm_panel *panel)
+{
+ struct st7789v *ctx = panel_to_st7789v(panel);
+ int ret;
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, MIPI_DCS_SET_DISPLAY_OFF));
+
+ if (ctx->backlight) {
+ ctx->backlight->props.power = FB_BLANK_POWERDOWN;
+ ctx->backlight->props.state |= BL_CORE_FBBLANK;
+ backlight_update_status(ctx->backlight);
+ }
+
+ return 0;
+}
+
+static int st7789v_unprepare(struct drm_panel *panel)
+{
+ struct st7789v *ctx = panel_to_st7789v(panel);
+ int ret;
+
+ ST7789V_TEST(ret, st7789v_write_command(ctx, MIPI_DCS_ENTER_SLEEP_MODE));
+
+ regulator_disable(ctx->power);
+
+ return 0;
+}
+
+static const struct drm_panel_funcs st7789v_drm_funcs = {
+ .disable = st7789v_disable,
+ .enable = st7789v_enable,
+ .get_modes = st7789v_get_modes,
+ .prepare = st7789v_prepare,
+ .unprepare = st7789v_unprepare,
+};
+
+static int st7789v_probe(struct spi_device *spi)
+{
+ struct device_node *backlight;
+ struct st7789v *ctx;
+ int ret;
+
+ ctx = devm_kzalloc(&spi->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ spi_set_drvdata(spi, ctx);
+ ctx->spi = spi;
+
+ ctx->panel.dev = &spi->dev;
+ ctx->panel.funcs = &st7789v_drm_funcs;
+
+ ctx->power = devm_regulator_get(&spi->dev, "power");
+ if (IS_ERR(ctx->power))
+ return PTR_ERR(ctx->power);
+
+ ctx->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ctx->reset)) {
+ dev_err(&spi->dev, "Couldn't get our reset line\n");
+ return PTR_ERR(ctx->reset);
+ }
+
+ backlight = of_parse_phandle(spi->dev.of_node, "backlight", 0);
+ if (backlight) {
+ ctx->backlight = of_find_backlight_by_node(backlight);
+ of_node_put(backlight);
+
+ if (!ctx->backlight)
+ return -EPROBE_DEFER;
+ }
+
+ ret = drm_panel_add(&ctx->panel);
+ if (ret < 0)
+ goto err_free_backlight;
+
+ return 0;
+
+err_free_backlight:
+ if (ctx->backlight)
+ put_device(&ctx->backlight->dev);
+
+ return ret;
+}
+
+static int st7789v_remove(struct spi_device *spi)
+{
+ struct st7789v *ctx = spi_get_drvdata(spi);
+
+ drm_panel_detach(&ctx->panel);
+ drm_panel_remove(&ctx->panel);
+
+ if (ctx->backlight)
+ put_device(&ctx->backlight->dev);
+
+ return 0;
+}
+
+static const struct of_device_id st7789v_of_match[] = {
+ { .compatible = "sitronix,st7789v" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, st7789v_of_match);
+
+static struct spi_driver st7789v_driver = {
+ .probe = st7789v_probe,
+ .remove = st7789v_remove,
+ .driver = {
+ .name = "st7789v",
+ .of_match_table = st7789v_of_match,
+ },
+};
+module_spi_driver(st7789v_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Sitronix st7789v LCD Driver");
+MODULE_LICENSE("GPL v2");
--
git-series 0.8.11
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH V7 3/7] Documentation: devicetree: mfd: da9062/61 MFD binding
From: Lee Jones @ 2017-04-03 13:39 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland, Rob Herring,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-PM,
LINUX-WATCHDOG, Liam Girdwood, Mark Brown, Support Opensource,
Wim Van Sebroeck, Zhang Rui
In-Reply-To: <1c12168d005cec5be6cab78f99c4dce95caa128b.1490712213.git.stwiss.opensource@diasemi.com>
On Tue, 28 Mar 2017, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Extend existing DA9062 binding information to include the DA9061 PMIC for
> MFD core and regulators.
>
> Add a da9062-onkey link to the existing onkey binding file.
>
> Add a da9062-thermal link to the new temperature monitoring binding file.
>
> Delete the da9062-watchdog section and replace it with a link to the new
> DA9061/62 binding information file.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and v4.11-rc3
>
> v6 -> v7
> - NO CODE CHANGE
>
> v5 -> v6
> - NO CODE CHANGE
> - Rebased from v4.9 to v4.11-rc3
>
> v4 -> v5
> - NO CODE CHANGE
> - Rebased from v4.8 to v4.9
>
> v3 -> v4
> - Patch renamed from [PATCH V3 4/9] to [PATCH V4 3/8]
> - Remove double newline spacing in text file
> - Added Acked-by Rob Herring
>
> v2 -> v3
> - Patch renamed from [PATCH V2 04/10] to [PATCH V3 4/9]
> - Ensure binding description concentrates on the device not the
> device driver
> - Separate the DA9061 and DA9062 sub-device tables to distinguish
> the difference between the two devices
> - Update the commit message to describe this change
> - Add e-mail information about associated patches from this set
> without describing them as being explicitly dependent on this
> binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 09/10] to [PATCH V2 04/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
>
> Hi,
>
> Added an Ack from Rob Herring for the PATCH V3 version.
>
> As previously:
> Other information:
> The device driver from this patch set (associated with this binding) is
>
> - [PATCH V5 4/8] mfd: da9061: MFD core support
>
> and also the following binding file changes:
>
> - Binding for onkey (already applied by Dmitry Torokhov)
> - [PATCH V5 1/8] Binding for watchdog
> - [PATCH V5 2/8] Binding for thermal
>
> Regards,
> Steve Twiss, Dialog Semiconductor
>
>
> Documentation/devicetree/bindings/mfd/da9062.txt | 49 +++++++++++++++++-------
> 1 file changed, 36 insertions(+), 13 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
> index 38802b5..c0a418c 100644
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -1,22 +1,39 @@
> * Dialog DA9062 Power Management Integrated Circuit (PMIC)
>
> -DA9062 consists of a large and varied group of sub-devices:
> +Product information for the DA9062 and DA9061 devices can be found here:
> +- http://www.dialog-semiconductor.com/products/da9062
> +- http://www.dialog-semiconductor.com/products/da9061
> +
> +The DA9062 PMIC consists of:
>
> Device Supply Names Description
> ------ ------------ -----------
> da9062-regulator : : LDOs & BUCKs
> da9062-rtc : : Real-Time Clock
> +da9062-onkey : : On Key
> +da9062-watchdog : : Watchdog Timer
> +da9062-thermal : : Thermal
> +
> +The DA9061 PMIC consists of:
> +
> +Device Supply Names Description
> +------ ------------ -----------
> +da9062-regulator : : LDOs & BUCKs
> +da9062-onkey : : On Key
> da9062-watchdog : : Watchdog Timer
> +da9062-thermal : : Thermal
>
> ======
>
> Required properties:
>
> -- compatible : Should be "dlg,da9062".
> +- compatible : Should be
> + "dlg,da9062" for DA9062
> + "dlg,da9061" for DA9061
> - reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> modified to match the chip's OTP settings).
> - interrupt-parent : Specifies the reference to the interrupt controller for
> - the DA9062.
> + the DA9062 or DA9061.
> - interrupts : IRQ line information.
> - interrupt-controller
>
> @@ -25,8 +42,8 @@ further information on IRQ bindings.
>
> Sub-nodes:
>
> -- regulators : This node defines the settings for the LDOs and BUCKs. The
> - DA9062 regulators are bound using their names listed below:
> +- regulators : This node defines the settings for the LDOs and BUCKs.
> + The DA9062 regulators are bound using their names listed below:
>
> buck1 : BUCK_1
> buck2 : BUCK_2
> @@ -37,19 +54,29 @@ Sub-nodes:
> ldo3 : LDO_3
> ldo4 : LDO_4
>
> + The DA9061 regulators are bound using their names listed below:
> +
> + buck1 : BUCK_1
> + buck2 : BUCK_2
> + buck3 : BUCK_3
> + ldo1 : LDO_1
> + ldo2 : LDO_2
> + ldo3 : LDO_3
> + ldo4 : LDO_4
> +
> The component follows the standard regulator framework and the bindings
> details of individual regulator device can be found in:
> Documentation/devicetree/bindings/regulator/regulator.txt
>
> -
> - rtc : This node defines settings required for the Real-Time Clock associated
> with the DA9062. There are currently no entries in this binding, however
> compatible = "dlg,da9062-rtc" should be added if a node is created.
>
> -- watchdog: This node defines the settings for the watchdog driver associated
> - with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
> - if a node is created.
> +- onkey : See ../input/da9062-onkey.txt
> +
> +- watchdog: See ../watchdog/da9062-watchdog.txt
>
> +- thermal : See ../thermal/da9062-thermal.txt
>
> Example:
>
> @@ -64,10 +91,6 @@ Example:
> compatible = "dlg,da9062-rtc";
> };
>
> - watchdog {
> - compatible = "dlg,da9062-watchdog";
> - };
> -
> regulators {
> DA9062_BUCK1: buck1 {
> regulator-name = "BUCK1";
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v8 1/2] media: i2c/ov5645: add the device tree binding document
From: Todor Tomov @ 2017-04-03 14:02 UTC (permalink / raw)
To: mchehab, laurent.pinchart, hans.verkuil, sakari.ailus,
linux-media, linux-kernel, robh+dt, mark.rutland, devicetree
Cc: Todor Tomov
Add the document for ov5645 device tree binding.
Signed-off-by: Todor Tomov <todor.tomov@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../devicetree/bindings/media/i2c/ov5645.txt | 54 ++++++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5645.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov5645.txt b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
new file mode 100644
index 0000000..fd7aec9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5645.txt
@@ -0,0 +1,54 @@
+* Omnivision 1/4-Inch 5Mp CMOS Digital Image Sensor
+
+The Omnivision OV5645 is a 1/4-Inch CMOS active pixel digital image sensor with
+an active array size of 2592H x 1944V. It is programmable through a serial I2C
+interface.
+
+Required Properties:
+- compatible: Value should be "ovti,ov5645".
+- clocks: Reference to the xclk clock.
+- clock-names: Should be "xclk".
+- clock-frequency: Frequency of the xclk clock.
+- enable-gpios: Chip enable GPIO. Polarity is GPIO_ACTIVE_HIGH. This corresponds
+ to the hardware pin PWDNB which is physically active low.
+- reset-gpios: Chip reset GPIO. Polarity is GPIO_ACTIVE_LOW. This corresponds to
+ the hardware pin RESETB.
+- vdddo-supply: Chip digital IO regulator.
+- vdda-supply: Chip analog regulator.
+- vddd-supply: Chip digital core regulator.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ &i2c1 {
+ ...
+
+ ov5645: ov5645@78 {
+ compatible = "ovti,ov5645";
+ reg = <0x78>;
+
+ enable-gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&camera_rear_default>;
+
+ clocks = <&clks 200>;
+ clock-names = "xclk";
+ clock-frequency = <23880000>;
+
+ vdddo-supply = <&camera_dovdd_1v8>;
+ vdda-supply = <&camera_avdd_2v8>;
+ vddd-supply = <&camera_dvdd_1v2>;
+
+ port {
+ ov5645_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ remote-endpoint = <&csi0_ep>;
+ };
+ };
+ };
+ };
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Rob Herring @ 2017-04-03 14:07 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Steve Longerbeam, Mark Rutland, Shawn Guo,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Fabio Estevam,
Russell King, Mauro Carvalho Chehab, Hans Verkuil, Nick Dyer,
markus.heiser-m1Uo1GnMJf0b1SvskN2V4Q, Philipp Zabel,
Laurent Pinchart, Benoit Parrot, Geert Uytterhoeven,
Arnd Bergmann, Sudip Mukherjee, Minghsiu Tsai, tiffany lin,
Jean-Christophe Trotin <jean-christophe.trotin>
In-Reply-To: <70bacfb5-aef1-76d1-37d2-23a524903d45-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Tue, Mar 28, 2017 at 05:35:52PM -0700, Steve Longerbeam wrote:
>
>
> On 03/28/2017 05:21 PM, Rob Herring wrote:
> > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > Add bindings documentation for the i.MX media driver.
> > >
> > > <snip>
> > > +
> > > +mipi_csi2 node
> > > +--------------
> > > +
> > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > +CSI-2 sensors.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> >
> > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > needs to be based on that.
>
> Hi Rob, I'm not sure what you are asking me to do.
>
> I assume if there's another binding doc in progress, it means
> someone is working on another Synopsys DW CSI-2 subdevice driver.
Yes. see http://patchwork.ozlabs.org/patch/736177/
> Unfortunately I don't have the time to contribute and switch to
> this other subdevice, and do test/debug.
>From a DT perspective, I'm not asking that you share the subdevice
driver, only the binding. Simply put, there's 1 h/w block here, so there
should only be 1 binding. The binding is an ABI, so you can't just merge
it and change it later.
The driver side is a decision for the V4L2 maintainers.
> For now I would prefer if this patchset is merged as is, and
> then contribute/switch to another CSI-2 subdev later. It is
> also getting very difficult managing all these patches (39 as
> of this version), and I'd prefer not to spam the lists with
> such large patchsets for too much longer.
Then maybe you should figure out how to split up the series. I've not
looked at it to provide suggestions.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Rob Herring @ 2017-04-03 14:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Andrew-CT Chen (陳智迪),
Minghsiu Tsai, Sakari Ailus, Nick Dyer, Songjun Wu, Hans Verkuil,
Pavel Machek, Robert Jarzmik, devel, markus.heiser,
Laurent Pinchart, shuah, Geert Uytterhoeven, Steve Longerbeam,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
kernel@pengutronix.de, Arnd Bergmann, Mauro Carvalho Chehab,
Benoit Parrot
In-Reply-To: <20170329083904.GZ7909@n2100.armlinux.org.uk>
On Wed, Mar 29, 2017 at 09:39:05AM +0100, Russell King - ARM Linux wrote:
> On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> > On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> > > Add bindings documentation for the i.MX media driver.
> > >
> > > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > > ---
> > > Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
> > > 1 file changed, 74 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> > > new file mode 100644
> > > index 0000000..3059c06
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > > @@ -0,0 +1,74 @@
> > > +Freescale i.MX Media Video Device
> > > +=================================
> > > +
> > > +Video Media Controller node
> > > +---------------------------
> > > +
> > > +This is the media controller node for video capture support. It is a
> > > +virtual device that lists the camera serial interface nodes that the
> > > +media device will control.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,imx-capture-subsystem";
> > > +- ports : Should contain a list of phandles pointing to camera
> > > + sensor interface ports of IPU devices
> > > +
> > > +example:
> > > +
> > > +capture-subsystem {
> > > + compatible = "fsl,imx-capture-subsystem";
> > > + ports = <&ipu1_csi0>, <&ipu1_csi1>;
> > > +};
> > > +
> > > +fim child node
> > > +--------------
> > > +
> > > +This is an optional child node of the ipu_csi port nodes. If present and
> > > +available, it enables the Frame Interval Monitor. Its properties can be
> > > +used to modify the method in which the FIM measures frame intervals.
> > > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > > +Frame Interval Monitor.
> > > +
> > > +Optional properties:
> > > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > > + specified as <chan flags>. The channel number
> > > + must be 0 or 1. The flags can be
> > > + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> > > + IRQ_TYPE_EDGE_BOTH, and specify which input
> > > + capture signal edge will trigger the input
> > > + capture event. If an input capture channel is
> > > + specified, the FIM will use this method to
> > > + measure frame intervals instead of via the EOF
> > > + interrupt. The input capture method is much
> > > + preferred over EOF as it is not subject to
> > > + interrupt latency errors. However it requires
> > > + routing the VSYNC or FIELD output signals of
> > > + the camera sensor to one of the i.MX input
> > > + capture pads (SD1_DAT0, SD1_DAT1), which also
> > > + gives up support for SD1.
> > > +
> > > +
> > > +mipi_csi2 node
> > > +--------------
> > > +
> > > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > > +CSI-2 sensors.
> > > +
> > > +Required properties:
> > > +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
> >
> > As I mentioned in v5, there's a DW CSI2 binding in progress. This
> > needs to be based on that.
>
> Maybe someone can provide some kind of reference to it, and it's
> associated driver?
Let me Google that for you (TM). The reference is in my comments on v5.
Here's a reference to it [1].
[1] https://lkml.org/lkml/2017/3/20/524
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
^ permalink raw reply
* Re: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-03 14:12 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <8987877cc54940358c5b7a65ca003cedc5586f0d.1490712213.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Tue, 28 Mar 2017, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> MFD support for DA9061 is provided as part of the DA9062 device driver.
>
> The registers header file adds two new chip variant IDs defined in DA9061
> and DA9062 hardware. The core header file adds new software enumerations
> for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> for distinguishing between DA9061/62 devices in software.
>
> The core source code adds a new .compatible of_device_id entry. This is
> extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> .data entry now holds a reference to the enumerated device type.
>
> A new regmap_irq_chip model is added for DA9061 and this supports the new
> list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> new sub system components for DA9061. Support is added for a new DA9061
> regmap_config which lists the correct readable, writable and volatile
> ranges for this chip.
>
> The probe function uses the device tree compatible string to switch on the
> da9062_compatible_types and configure the correct mfd cells, irq chip and
> regmap config.
>
> Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> ---
> Acked-for-mfd-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Hi Lee, that Ack was from your earlier posting:
> https://lkml.org/lkml/2017/1/4/328 this was
> Regards, Steve.
>
> This patch applies against linux-next and v4.11-rc3
>
> v6 -> v7
> - Remove compilation warning when casting a void * to an integer on
> ARCH=x86_64 using -Wpointer-to-int-cast.
> - Recommendation uintptr_t cast: https://lkml.org/lkml/2017/3/28/292
> - Compile tested ARCH=x86_64
>
> v5 -> v6
> - Rebased from v4.9 to v4.11-rc3
> - Modify Copyright to match Dialog latest legal statement
> - Fixed "braces {} should be used on all arms" checkpatch warning
>
> v4 -> v5
> - NO CODE CHANGE
> - Rebased from v4.8 to v4.9
>
> v3 -> v4
> - Patch renamed from [PATCH V3 5/9] to [PATCH V4 4/8]
> - Removed DEFINE_RES_NAMED() macros for DA9061 resources and replaced
> them with DEFINE_RES_IRQ_NAMED().
> - Removed whitespace
> - Reverted change for badly defined mfd_cell da9062_devs of_compatible
> string from "dlg,da9062-watchdog" back to "dlg,da9062-wdt"
>
> v2 -> v3
> - NO CODE CHANGE
> - Patch renamed from [PATCH V2 05/10] to [PATCH V3 5/9]
>
> v1 -> v2
> - Patch renamed from [PATCH V1 01/10] to [PATCH V2 05/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Fixed typo in the commit message "readble" to "readable"
> - Removed the explicit cross-check to decide if there is a conflict
> between the device tree compatible string and the hardware definition.
> This patch assumes the device tree is correctly written and therefore
> removes the need for a hardware/DT sanity check.
> - Removed extra semicolon in drivers/mfd/da9062-core.c:877
> - Re-write compatible entries into numerical order
>
> Lee,
>
> Changes as described in the version history above.
>
> As previously:
> This patch adds support for the DA9061 PMIC. This is done as part of the
> existing DA9062 device driver by extending the of_device_id match table.
> This in turn allows new MFD cells, irq chip and regmap definitions to
> support DA9061.
>
> Regards,
> Steve Twiss, Dialog Semiconductor
>
>
> drivers/mfd/Kconfig | 5 +-
> drivers/mfd/da9062-core.c | 427 +++++++++++++++++++++++++++++++++--
> include/linux/mfd/da9062/core.h | 29 ++-
> include/linux/mfd/da9062/registers.h | 5 +-
> 4 files changed, 443 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 55ecdfb..29cc11a 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -263,13 +263,14 @@ config MFD_DA9055
> called "da9055"
>
> config MFD_DA9062
> - tristate "Dialog Semiconductor DA9062 PMIC Support"
> + tristate "Dialog Semiconductor DA9062/61 PMIC Support"
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ
> depends on I2C
> help
> - Say yes here for support for the Dialog Semiconductor DA9062 PMIC.
> + Say yes here for support for the Dialog Semiconductor DA9061 and
> + DA9062 PMICs.
> This includes the I2C driver and core APIs.
> Additional drivers must be enabled in order to use the functionality
> of the device.
> diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c
> index 8f873866..78ab3f4 100644
> --- a/drivers/mfd/da9062-core.c
> +++ b/drivers/mfd/da9062-core.c
[...]
> @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> return -EINVAL;
> }
>
> - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> + switch (chip->chip_type) {
> + case(COMPAT_TYPE_DA9061):
Brackets around the case value?
That's a new one on me.
> + cell = da9061_devs;
> + cell_num = ARRAY_SIZE(da9061_devs);
> + irq_chip = &da9061_irq_chip;
> + config = &da9061_regmap_config;
> + break;
> + case(COMPAT_TYPE_DA9062):
> + cell = da9062_devs;
> + cell_num = ARRAY_SIZE(da9062_devs);
> + irq_chip = &da9062_irq_chip;
> + config = &da9062_regmap_config;
> + break;
> + default:
> + dev_err(chip->dev, "Unrecognised chip type\n");
> + return -ENODEV;
> + }
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 01/39] [media] dt-bindings: Add bindings for video-multiplexer device
From: Rob Herring @ 2017-04-03 14:14 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, pavel, robert.jarzmik, devel, markus.heiser,
laurent.pinchart+renesas, shuah, linux, geert, Sascha Hauer,
linux-media, devicetree, kernel, arnd, mchehab, bparrot,
Steve Longerbeam, horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, p.zabel, fabio.estevam, shawnguo
In-Reply-To: <1490661656-10318-2-git-send-email-steve_longerbeam@mentor.com>
On Mon, Mar 27, 2017 at 05:40:18PM -0700, Steve Longerbeam wrote:
> From: Philipp Zabel <p.zabel@pengutronix.de>
>
> 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>
> ---
> .../bindings/media/video-multiplexer.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/video-multiplexer.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 04/14] GPIO: Add gpio-ingenic driver
From: kbuild test robot @ 2017-04-03 14:15 UTC (permalink / raw)
Cc: kbuild-all, Linus Walleij, Alexandre Courbot, Rob Herring,
Mark Rutland, Ralf Baechle, Boris Brezillon, Thierry Reding,
Bartlomiej Zolnierkiewicz, Maarten ter Huurne, Lars-Peter Clausen,
Paul Burton, james.hogan, linux-gpio, devicetree, linux-kernel,
linux-mips, linux-mmc, linux-mtd, linux-pwm, linux-fbdev,
Paul Cercueil
In-Reply-To: <20170402204244.14216-5-paul@crapouillou.net>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
Hi Paul,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc5 next-20170403]
[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/Paul-Cercueil/Ingenic-JZ4740-JZ4780-pinctrl-driver/20170403-184309
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
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=xtensa
All warnings (new ones prefixed by >>):
warning: (GPIO_INGENIC) selects PINCTRL_INGENIC which has unmet direct dependencies (PINCTRL && (MACH_INGENIC || COMPILE_TEST))
---
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: 49094 bytes --]
^ permalink raw reply
* Re: [PATCH v6 03/39] [media] dt/bindings: Add bindings for OV5640
From: Rob Herring @ 2017-04-03 14:15 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, pavel, robert.jarzmik, devel, markus.heiser,
laurent.pinchart+renesas, shuah, linux, geert, linux-media,
devicetree, kernel, arnd, mchehab, bparrot, Steve Longerbeam,
horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, p.zabel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <1490661656-10318-4-git-send-email-steve_longerbeam@mentor.com>
On Mon, Mar 27, 2017 at 05:40:20PM -0700, Steve Longerbeam wrote:
> Add device tree binding documentation for the OV5640 camera sensor.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> .../devicetree/bindings/media/i2c/ov5640.txt | 45 ++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
I already acked this. Please add acks when posting new versions.
Rob
^ permalink raw reply
* Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Kiran Kumar @ 2017-04-03 14:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
Scott Wood, Rob Herring, Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Xiaobo Xie,
Yang-Leo Li
In-Reply-To: <5159406.HOFrj7pRfW@wuerfel>
[-- Attachment #1.1: Type: text/plain, Size: 8813 bytes --]
Sorry to post in this huge email bunch.
I have most probably hit an errata in Freescale T4240 for
PPC_DISABLE_THREADS. I'm using Rev2 - T4240. Is this Errata required to be
taken care or not? Any quick help is appreciated!
My issue: I'm running line rate of Traffic to T4240 [10G of traffic on each
port of capacity of 10G]; After few hours of running of traffic, My CPU/LMP
gets stuck and goes in for Hard reset. When I searched through the code and
some open forums, I saw the errata listed above. I'm not sure if that
errata works for me or not. I have pasted a snapshot of issue occuring in
my system
============================================
During hang, with Softlock up enabled, I get prints from smp_many ->
showing ‘every processor is waiting for processor 22’ ; I need to know what
happened to processor 22. The processor number keep changing every time
when I run the traffic.
Processor 22 goes into a deadlock state with interrupts disabled or it went
into a deep idle sleep state is the issue i feel.
If its deep idle state -> a NMI should have recovered it.
But if it’s a deadlock issue with interrupt disabled then I need to know
the root cause for the deadlock.
*root@A@0-1-1:~# [ 1602.261011] Current::17 waiting::22 flag::4353 [
1602.720488] Current::14 waiting::22 flag::3585 [ 1602.756404] Current::15
waiting::22 flag::3841 [ 1604.903248] Current::16 waiting::22 flag::4097 [
1619.400917] Current::14 waiting::22 flag::3585 [ 1619.517870] Current::17
waiting::22 flag::4353 [ 1619.749893] Current::15 waiting::22 flag::3841 [
1619.798453] Current::4 waiting::22 flag::1025 [ 1622.177171] Current::16
waiting::22 flag::4097 [ 1622.449412] INFO: rcu_preempt detected stalls on
CPUs/tasks: { 22} (detected by 4, t=21008 jiffies, g=101651, c=101650,
q=4713) [ 1622.460951] Task dump for CPU 22:*
*[ 1622.464275] swapper/22 R running task 0 0 1
0x00000800*
*[ 1622.471355] Call Trace:*
*[ 1622.473820] [c0000001f92b78d0] [000000000000009e] 0x9e (unreliable) [
1622.480119] [c0000001f92b7960] [c0000001f92b7aa0] 0xc0000001f92b7aa0 [
1622.486497] [c0000001f92b79e0] [c000000000a90275] 0xc000000000a90275 [
1622.492878] [c0000001f92b7a60] [c000000000006f64] .do_IRQ+0x184/0x370 [
1622.499344] [c0000001f92b7b10] [c00000000001b93c]
exc_0x500_common+0xfc/0x100 [ 1622.506539] --- Exception: 501 at
0xc000000000a3e200*
*[ 1622.506539] LR = .__check_irq_replay+0x68/0x110*
*[ 1622.516388] [c0000001f92b7e00] [c0000000000bc590]
.cpu_startup_entry+0x1d0/0x350 (unreliable) [ 1622.524950]
[c0000001f92b7ed0] [c000000000a00460] .start_secondary+0x3ec/0x3f4 [
1622.532197] [c0000001f92b7f90] [c00000000000036c]
.start_secondary_prolog+0x10/0x14 [ 1635.237829] Current::3 waiting::5
flag::769 [ 1636.587746] Current::14 waiting::22 flag::3585 [ 1637.082117]
Current::17 waiting::22 flag::4353 [ 1637.224920] Current::4 waiting::22
flag::1025 [ 1637.268789] Current::15 waiting::22 flag::3841 [ 1640.085792]
Current::16 waiting::22 flag::4097 [ 1651.093367] Current::4 waiting::22
flag::1025*
*=============================================================*
Regards,
Kiran
On Thu, May 5, 2016 at 4:40 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote:
> > > -----Original Message-----
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > Sent: Thursday, May 05, 2016 4:32 PM
> > > To: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> > > Cc: Yangbo Lu; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > > linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> > > foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Mark Rutland;
> > > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Russell King; Bhupesh Sharma; Joerg Roedel;
> > > Santosh Shilimkar; Yang-Leo Li; Scott Wood; Rob Herring; Claudiu
> Manoil;
> > > Kumar Gala; Xiaobo Xie; Qiang Zhao
> > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for
> T4240-
> > > R1.0-R2.0
> > >
> > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote:
> > > >
> > > > + fsl_guts_init();
> > > > + svr = fsl_guts_get_svr();
> > > > + if (svr) {
> > > > + esdhc->soc_ver = SVR_SOC_VER(svr);
> > > > + esdhc->soc_rev = SVR_REV(svr);
> > > > + } else {
> > > > + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> > > > + }
> > > > +
> > > >
> > >
> > >
> > > Sorry for jumping in again after not participating in the discussion
> for
> > > the past few versions.
> > >
> > > What happened to my suggestion of making this a platform-independent
> > > interface to avoid the link time dependency?
> > >
> > > Specifically, why not add an exported function to drivers/base/soc.c
> that
> > > uses glob_match() for comparing a string in the device driver to the ID
> > > of the SoC that is set by whatever SoC identifying driver the platform
> > > has?
> >
> > [Lu Yangbo-B47093] I think this has been discussed in v6.
> > You can find Scott's comments about this in below link.
> > https://patchwork.kernel.org/patch/8544501/
>
> Ah, thanks for bearing with me and digging this out again. Let me follow
> up on Scott's older replies here then:
>
> > >> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> > >> even compile on !PPC. It is things like this that prevent sharing the
> > >> driver.
> >
> > The whole point of using the MMIO SVR instead of the PPC SPR is so that
> > it will work on ARM... The guts driver should build on any platform as
> > long as OF is enabled, and if it doesn't find a node to bind to it will
> > return 0 for SVR, and the eSDHC driver will continue (after printing an
> > error that should be removed) without the ability to test for errata
> > based on SVR.
>
> It feels like a bad design to have to come up with a different
> method for each SoC type here when they all do the same thing
> and want to identify some variant of the chip to do device
> specific quirks.
>
> As far as I'm concerned, every driver in drivers/soc that needs to
> export a symbol to be used by a device driver is an indication that
> we don't have the right set of abstractions yet. There are cases
> that are not worth abstracting because the functionality is rather
> obscure and only a couple of drivers for one particular chip
> ever need it.
>
> Finding out the version of the SoC does not look like this case.
>
> > > I think the first four patches take care of building for ARM,
> > > but the problem remains if you want to enable COMPILE_TEST as
> > > we need for certain automated checking.
> >
> > What specific problem is there with COMPILE_TEST?
>
> COMPILE_TEST is solvable here and the way it is implemented in this
> case (selecting FSL_GUTS from the driver) indeed looks like it works
> correctly, but it's still awkward that this means building the
> SoC specific ID stuff into the vmlinux binary for any driver that
> uses something like that for a particular SoC.
>
> > >> Dealing with Si revs is a common problem. We should have a
> > >> common solution. There is soc_device for this purpose.
> > >
> > > Exactly. The last time this came up, I think we agreed to implement a
> > > helper using glob_match() on the soc_device strings. Unfortunately
> > > this hasn't happened then, but I'd still prefer that over yet another
> > > vendor-specific way of dealing with the generic issue.
> >
> > soc_device would require encoding the SVR as a string and then decoding
> > the string, which is more complicated and error prone than having
> > platform-specific code test a platform-specific number.
>
> You already need to encode it as a string to register the soc_device,
> and the driver just needs to pass a glob string, so the only part that
> is missing is the generic function that takes the string from the
> driver and passes that to glob_match for the soc_device.
>
> > And when would it get registered on arm64, which doesn't have
> > platform code?
>
> Whenever the soc driver is loaded, as is the case now. The match
> function can return -EPROBE_DEFER if no SoC device is registered
> yet.
>
> Arnd
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #1.2: Type: text/html, Size: 12997 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/5] irqchip/aspeed-i2c-ic: binding docs for Aspeed I2C Interrupt Controller
From: Rob Herring @ 2017-04-03 14:16 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa-z923LK4zBo2bacvFa/9K2g, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
marc.zyngier-5wv7dgnIgG8, joel-U3u1mxZcP9KHXe+LvDLADg,
vz-ChpfBGZJDbMAvxtiuMwx3w, mouse-Pma6HLj0uuo, clg-Bxea+6Xhats,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <20170328051226.21677-2-brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, Mar 27, 2017 at 10:12:22PM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C Interrupt
> Controller.
>
> Signed-off-by: Brendan Higgins <brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
> Added in v6:
> - Pulled "aspeed_i2c_controller" out into a interrupt controller since that is
> what it actually does.
> ---
> .../interrupt-controller/aspeed,ast2400-i2c-ic.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/aspeed,ast2400-i2c-ic.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-04-03 14:20 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20170403141214.q6ndii6c47pqfqx6@dell>
On 03 April 2017 15:12, Lee Jones wrote:
> > @@ -475,7 +855,25 @@ static int da9062_i2c_probe(struct i2c_client *i2c,
> > return -EINVAL;
> > }
> >
> > - chip->regmap = devm_regmap_init_i2c(i2c, &da9062_regmap_config);
> > + switch (chip->chip_type) {
> > + case(COMPAT_TYPE_DA9061):
>
> Brackets around the case value?
>
> That's a new one on me.
Hm. Do you want me to resend it without braces?
Regards,
Stephen
^ permalink raw reply
* Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Peter Rosin @ 2017-04-03 14:20 UTC (permalink / raw)
To: michael.hennerich, wsa, robh+dt, mark.rutland, linus.walleij
Cc: linux-i2c, devicetree, linux-gpio, linux-kernel
In-Reply-To: <f871f082-3acd-7a28-25c7-dd77d8286ae6@analog.com>
On 2017-04-03 15:36, Michael Hennerich wrote:
> On 03.04.2017 14:03, Peter Rosin wrote:
>> On 2017-03-31 17:29, Peter Rosin wrote:
>>> Hi!
>>>
>>> Sorry for my incremental reviewing...
>>>
>>
>> Another incremental...
>>
>>> On 2017-03-29 12:15, michael.hennerich@analog.com wrote:
>>>> +
>>>> + /* Now create an adapter for each channel */
>>>> + for (num = 0; num < data->chip->nchans; num++) {
>>>> + ret = i2c_mux_add_adapter(muxc, 0, num, 0);
>>>> + if (ret) {
>>>> + dev_err(&client->dev,
>>>> + "failed to register multiplexed adapter %d\n",
>>>> + num);
>>
>> Just a heads up, I submitted a series to remove a bunch of dev_err calls
>> when i2c_mux_add_adapter fails. See https://lkml.org/lkml/2017/4/3/115
>>
>> You can remove this one as well.
>>
>> And please use a subject of the form:
>> i2c: mux: ltc4306: <message>
> ok - no problem.
You managed to drop the spaces after the new colons in the subject.
And maybe there is a problem, because I don't see any reaction to any of
the review comments I made in https://lkml.org/lkml/2017/3/31/525
Was that on purpose? Sure, the gpio "jury" is still out on the bigger
question so maybe you're waiting for that, but there were a few nitpicks
as well. Anyway, sorry again for failing to compile all comments up front.
> I sent out a new patch. Per Rob's request, I split out the dt-bindings
> into a separate patch.
Thanks. I think(?) it is customary to have the bindings first, and then
implement that "specification" in followup patches. No big deal though...
Cheers,
peda
^ 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