* [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
* Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2017-04-03 14:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Brendan Higgins, wsa, mark.rutland, tglx, jason, marc.zyngier,
joel, vz, mouse, clg, linux-i2c, devicetree, linux-kernel,
openbmc
In-Reply-To: <1490691283.3177.112.camel@kernel.crashing.org>
On Tue, Mar 28, 2017 at 07:54:43PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote:
> > Added device tree binding documentation for Aspeed I2C busses.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
>
> > + i2c0: i2c-bus@40 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #interrupt-cells = <1>;
> > + reg = <0x40 0x40>;
> > + compatible = "aspeed,ast2400-i2c-bus";
> > + bus = <0>;
> > + clocks = <&clk_apb>;
> > + clock-frequency = <100000>;
>
> For busses it's more traditional to make this "bus-frequency" but
> that's a nit and Linux/fdt has not respected that tradition terribly
> well. If you respin, it might be work changing.
Makes sense, but that's news to me. I'm still new to this DT stuff.
> The clock-frequency tends to be the frequency of the controller itself.
The clock binding has largely replaced that.
Rob
^ permalink raw reply
* Re: [PATCH v6 3/5] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2017-04-03 14:24 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa, mark.rutland, tglx, jason, marc.zyngier, joel, vz, mouse,
clg, linux-i2c, devicetree, linux-kernel, openbmc, benh
In-Reply-To: <20170328051226.21677-4-brendanhiggins@google.com>
On Mon, Mar 27, 2017 at 10:12:24PM -0700, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C busses.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Removed reference to "bus" device tree param
> Changes for v4:
> - None
> Changes for v5:
> - None
> Changes for v6:
> - Replaced the controller property with and interrupt controller, leaving only
> the busses in the I2C documentation.
> ---
> .../devicetree/bindings/i2c/i2c-aspeed.txt | 49 ++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> new file mode 100644
> index 000000000000..fbcc501706b1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
> @@ -0,0 +1,49 @@
> +Device tree configuration for the I2C busses on the AST24XX and AST25XX SoCs.
> +
> +Required Properties:
> +- #address-cells : should be 1
> +- #size-cells : should be 0
> +- reg : address offset and range of bus
> +- compatible : should be "aspeed,ast2400-i2c-bus"
> + or "aspeed,ast2500-i2c-bus"
> +- clocks : root clock of bus, should reference the APB
> + clock
> +- interrupts : interrupt number
> +- interrupt-parent : interrupt controller for bus, should reference a
> + aspeed,ast2400-i2c-ic or aspeed,ast2500-i2c-ic
> + interrupt controller
> +
> +Optional Properties:
> +- clock-frequency : frequency of the bus clock in Hz
> + defaults to 100 kHz when not specified
> +
> +Example:
> +
> +i2c {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x1e78a000 0x1000>;
> +
> + i2c_ic: interrupt-controller@0 {
> + #interrupt-cells = <1>;
> + compatible = "aspeed,ast2400-i2c-ic";
> + reg = <0x0 0x40>;
> + interrupts = <12>;
> + interrupt-controller;
> + };
> +
> + i2c0: i2c-bus@40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #interrupt-cells = <1>;
> + reg = <0x40 0x40>;
> + compatible = "aspeed,ast2400-i2c-bus";
> + bus = <0>;
Not documented and what's it for?
> + clocks = <&clk_apb>;
> + clock-frequency = <100000>;
> + status = "disabled";
Drop status from examples.
> + interrupts = <0>;
> + interrupt-parent = <&i2c_ic>;
> + };
> +};
> --
> 2.12.2.564.g063fe858b8-goog
>
^ permalink raw reply
* Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Rob Herring @ 2017-04-03 14:25 UTC (permalink / raw)
To: Joel Stanley
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Jeremy Kerr,
linux-serial, linux-kernel, openbmc, devicetree,
Benjamin Herrenschmidt
In-Reply-To: <20170328054458.29341-3-joel@jms.id.au>
On Tue, Mar 28, 2017 at 04:14:58PM +1030, Joel Stanley wrote:
> From: Jeremy Kerr <jk@ozlabs.org>
>
> This change adds a driver for the 16550-based Aspeed virtual UART
> device. We use a similar process to the of_serial driver for device
> probe, but expose some VUART-specific functions through sysfs too.
>
> OpenPOWER host firmware doesn't like it when the host-side of the
> VUART's FIFO is not drained. This driver only disables host TX discard
> mode when the port is in use. We set the VUART enabled bit when we bind
> to the device, and clear it on unbind.
>
> We don't want to do this on open/release, as the host may be using this
> bit to configure serial output modes, which is independent of whether
> the devices has been opened by BMC userspace.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> Documentation/devicetree/bindings/serial/8250.txt | 2 +
For the binding:
Acked-by: Rob Herring <robh@kernel.org>
> drivers/tty/serial/Kconfig | 10 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/aspeed-vuart.c | 335 ++++++++++++++++++++++
> 4 files changed, 348 insertions(+)
> create mode 100644 drivers/tty/serial/aspeed-vuart.c
^ permalink raw reply
* Re: [PATCHv6 06/14] atmel-isi: update device tree bindings documentation
From: Rob Herring @ 2017-04-03 14:28 UTC (permalink / raw)
To: Hans Verkuil
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Guennadi Liakhovetski,
Songjun Wu, Sakari Ailus, devicetree-u79uwXL29TY76Z2rM5mHXA,
Hans Verkuil
In-Reply-To: <20170328082347.11159-7-hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Tue, Mar 28, 2017 at 10:23:39AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
>
> The original bindings documentation was incomplete (missing pinctrl-names,
> missing endpoint node properties) and the example was out of date.
>
> Add the missing information and tidy up the text.
>
> Signed-off-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> Acked-by: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> .../devicetree/bindings/media/atmel-isi.txt | 91 +++++++++++++---------
> 1 file changed, 53 insertions(+), 38 deletions(-)
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: [RFC PATCH v2 2/4] iio: adc: sun4i-gpadc-iio: rename A23/A33-specified registers to contain A23
From: Lee Jones @ 2017-04-03 14:28 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Maxime Ripard, Chen-Yu Tsai, Jonathan Cameron, Quentin Schulz,
Zhang Rui, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170402133304.56824-3-icenowy-h8G6r0blFSE@public.gmane.org>
On Sun, 02 Apr 2017, Icenowy Zheng wrote:
> As the H3 SoC, which is also in sun8i line, has totally different
> register map for the thermal sensor (a cut down version of GPADC), we
> should rename A23/A33-specified registers to contain A23, in order to
> prevent obfuscation with H3 registers. Currently these registers are
> only prefixed "SUN8I", not "SUN8I_A23".
>
> Add "_A23" after "SUN8I" on the register names.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> Splited from RFC v1's 2/3.
>
> drivers/iio/adc/sun4i-gpadc-iio.c | 2 +-
> include/linux/mfd/sun4i-gpadc.h | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 74705aa37982..01cf806f47f8 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -88,7 +88,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> + .tp_mode_en = SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN,
> };
>
> struct sun4i_gpadc_iio {
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 139872c2e0fe..d31d962bb7d8 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,9 +38,9 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> -/* TP_CTRL1 bits for sun8i SoCs */
> -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +/* TP_CTRL1 bits for sun8i A23/A33 SoCs */
> +#define SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_A23_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
>
> #define SUN4I_GPADC_CTRL2 0x08
>
--
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 4/6] dt-bindings: tegra: Update compatible strings for Tegra flowctrl
From: Rob Herring @ 2017-04-03 14:29 UTC (permalink / raw)
To: Jon Hunter
Cc: Thierry Reding, Mark Rutland, Russell King, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490704978-22906-5-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Tue, Mar 28, 2017 at 01:42:56PM +0100, Jon Hunter wrote:
> Update the compatible strings for Tegra Flow Control driver to match
> the device-tree source files for Tegra.
>
> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/arm/tegra/nvidia,tegra20-flowctrl.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-03 14:30 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: <6ED8E3B22081A4459DAC7699F3695FB7018CD6B183@SW-EX-MBX02.diasemi.com>
On Mon, 03 Apr 2017, Steve Twiss wrote:
> 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?
Yes please. And a space after the 'case'.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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