Devicetree
 help / color / mirror / Atom feed
* [PATCH v2 1/9] drm: bridge: Add LVDS encoder DT bindings
From: Laurent Pinchart @ 2016-11-19  3:48 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, devicetree
In-Reply-To: <1479527302-7674-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

The DT bindings support parallel to LVDS encoders that don't require any
configuration, similarly to the dumb VGA DAC DT bindings.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/display/bridge/lvds-transmitter.txt   | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
new file mode 100644
index 000000000000..fd39ad34c383
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -0,0 +1,64 @@
+Parallel to LVDS Encoder
+------------------------
+
+This binding supports the parallel to LVDS encoders that don't require any
+configuration.
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This binding targets devices compatible with the following
+specifications only.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Those devices have been marketed under the FPD-Link and FlatLink brand names
+among others.
+
+
+Required properties:
+
+- compatible: Must be "lvds-encoder"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+-------
+
+lvds-encoder {
+	compatible = "lvds-encoder";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			lvds_enc_in: endpoint {
+				remote-endpoint = <&display_out_rgb>;
+			};
+		};
+
+		port@1 {
+			reg = <1>;
+
+			lvds_enc_out: endpoint {
+				remote-endpoint = <&lvds_panel_in>;
+			};
+		};
+	};
+};
-- 
Regards,

Laurent Pinchart

^ permalink raw reply related

* [PATCH v2 0/9] R-Car DU: Use drm bridge API
From: Laurent Pinchart @ 2016-11-19  3:48 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, devicetree

Hello,

This patch series replaces the custom external encoders support implementation
in the R-Car DU driver with code based on the DRM bridge API.

While the overall diffstat isn't impressive, the rcar-du-drm driver gets
notably thinner in the process:

	9 files changed, 57 insertions(+), 374 deletions(-)

This is offset by a reusable driver for LVDS encoders along with the
corresponding DT bindings (+ 204 lines).

Patches 1/9 and 2/9 add DT bindings for LVDS encoders with a corresponding
driver. It supports "dumb" LVDS encoders only, similarly to the dumb-vga-dac
driver. One notable difference, though, is that LVDS encoders can't be purely
passive, and thus require at least one power supply (and usually multiple of
them) and have a few control GPIOs (most notably to control reset, power down,
clock polarity and/or LVDS slew rate). However, on many systems those encoders
are integrated in such a way that the control pins are pulled up or down
appropriately and the power supplies are either always on or shared with other
display components that make them operate as if they were always on. For that
reason a common drivers for those systems is useful, with simple DT bindings
that don't try to cover any device-specific control pin or power supply.

To ensure backward compatibility most LVDS encoders should *not* use the
common simple "lvds-encoder" compatible string, but should instead define a
device-specific compatible string that can then be added to the lvds-encoder
driver (patch 4/9). This way, when the need to control pins or supplies will
arise, a new driver can be developed matching on the device-specific
compatible string, which will then be removed from the simple driver. Existing
systems will migrate transparently without requiring a change to their device
tree.

A similar reasoning applies to VGA DACs, leading to the addition of the
"adi,adv7123" compatible string to the dumb-vga-dac driver's OF match table in
patch 3/9.

Patch 5/9 adds a new type field to the drm_bridge structure to inform bridge
users of the bridge type. This is useful for display driver to create a DRM
encoder of the appropriate type without having to resort to heuristics.
Patches 6/9 and 7/9 update all bridge drivers to initialize the new field to
the appropriate value.

Patches 8/9 and 9/9 finally migrate the rcar-du-drm driver to the DRM bridge
API, removing the custom VGA DAC implementation in patch 8/9 and the table of
bridge compatible strings used to find the encoder type in patch 9/9.

Compared to v1,

- The patches have been rebased on top of the "[PATCH v2 00/13] R-Car DU: Add
  support for LVDS mode selection" series.
- The LVDS encoder DT bindings have been split from the LVDS encoder driver
  into a separate patch.
- The wording of the DRM bridge documentation new property has been updated.

Laurent Pinchart (9):
  drm: bridge: Add LVDS encoder DT bindings
  drm: bridge: Add LVDS encoder driver
  drm: bridge: vga-dac: Add adi,adv7123 compatible string
  drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string
  drm: Add encoder_type field to the drm_bridge structure
  drm: bridge: Set bridges' encoder type
  drm: Set on-chip bridges' encoder type
  drm: rcar-du: Replace manual bridge implementation with DRM bridge
  drm: rcar-du: Initialize encoder's type based on the bridge's type

 .../bindings/display/bridge/lvds-transmitter.txt   |  64 +++++++
 drivers/gpu/drm/bridge/Kconfig                     |   8 +
 drivers/gpu/drm/bridge/Makefile                    |   1 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c       |   1 +
 drivers/gpu/drm/bridge/analogix-anx78xx.c          |   1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |   1 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c              |   2 +
 drivers/gpu/drm/bridge/dw-hdmi.c                   |   2 +
 drivers/gpu/drm/bridge/lvds-encoder.c              | 204 +++++++++++++++++++++
 drivers/gpu/drm/bridge/nxp-ptn3460.c               |   2 +
 drivers/gpu/drm/bridge/parade-ps8622.c             |   2 +
 drivers/gpu/drm/bridge/sii902x.c                   |   2 +
 drivers/gpu/drm/bridge/tc358767.c                  |   2 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c            |   2 +
 drivers/gpu/drm/mediatek/mtk_hdmi.c                |   2 +
 drivers/gpu/drm/rcar-du/Kconfig                    |   6 -
 drivers/gpu/drm/rcar-du/Makefile                   |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c          | 103 ++++++-----
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h          |   3 -
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c          | 137 --------------
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h          |  35 ----
 drivers/gpu/drm/rcar-du/rcar_du_kms.c              |  37 +---
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c           |  82 ---------
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h           |  23 ---
 drivers/gpu/drm/sti/sti_dvo.c                      |   2 +
 include/drm/drm_bridge.h                           |   8 +
 26 files changed, 363 insertions(+), 374 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
 create mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
 delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vgacon.h

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v2 03/13] devicetree/bindings: display: Add bindings for two Mitsubishi panels
From: Laurent Pinchart @ 2016-11-19  3:28 UTC (permalink / raw)
  To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479526093-7014-1-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>

The AA104XD12 and AA121TD01 are LVDS display panels. Their bindings are
modelled on the the LVS panel bindings.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
---
 .../display/panel/mitsubishi,aa104xd12.txt         | 47 ++++++++++++++++++++++
 .../display/panel/mitsubishi,aa121td01.txt         | 47 ++++++++++++++++++++++
 2 files changed, 94 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt

diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
new file mode 100644
index 000000000000..ced0121aed7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
@@ -0,0 +1,47 @@
+Mitsubishi AA204XD12 LVDS Display Panel
+=======================================
+
+The AA104XD12 is a 10.4" XGA TFT-LCD display panel.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+
+Required properties:
+
+- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
+  order.
+- vcc-supply: Reference to the regulator powering the panel VCC pins.
+
+
+Example
+-------
+
+panel {
+	compatible = "mitsubishi,aa104xd12", "panel-lvds";
+	vcc-supply = <&vcc_3v3>;
+
+	width-mm = <210>;
+	height-mm = <158>;
+
+	data-mapping = "jeida-24";
+
+	panel-timing {
+		/* 1024x768 @65Hz */
+		clock-frequency = <65000000>;
+		hactive = <1024>;
+		vactive = <768>;
+		hsync-len = <136>;
+		hfront-porch = <20>;
+		hback-porch = <160>;
+		vfront-porch = <3>;
+		vback-porch = <29>;
+		vsync-len = <6>;
+	};
+
+	port {
+		panel_in: endpoint {
+			remote-endpoint = <&lvds_encoder>;
+		};
+	};
+};
diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
new file mode 100644
index 000000000000..d6e1097504fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
@@ -0,0 +1,47 @@
+Mitsubishi AA121TD01 LVDS Display Panel
+=======================================
+
+The AA121TD01 is a 12.1" WXGA TFT-LCD display panel.
+
+These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
+with the following device-specific properties.
+
+
+Required properties:
+
+- compatible: Shall contain "mitsubishi,aa121td01" and "panel-lvds", in that
+  order.
+- vcc-supply: Reference to the regulator powering the panel VCC pins.
+
+
+Example
+-------
+
+panel {
+	compatible = "mitsubishi,aa121td01", "panel-lvds";
+	vcc-supply = <&vcc_3v3>;
+
+	width-mm = <261>;
+	height-mm = <163>;
+
+	data-mapping = "jeida-24";
+
+	panel-timing {
+		/* 1280x800 @60Hz */
+		clock-frequency = <71000000>;
+		hactive = <1280>;
+		vactive = <800>;
+		hsync-len = <70>;
+		hfront-porch = <20>;
+		hback-porch = <70>;
+		vsync-len = <5>;
+		vfront-porch = <3>;
+		vback-porch = <15>;
+	};
+
+	port {
+		panel_in: endpoint {
+			remote-endpoint = <&lvds_encoder>;
+		};
+	};
+};
-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH v2 02/13] devicetree/bindings: display: Add bindings for LVDS panels
From: Laurent Pinchart @ 2016-11-19  3:28 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, Tomi Valkeinen, devicetree
In-Reply-To: <1479526093-7014-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple incompatible data link layers have been used over time to
transmit image data to LVDS panels. This binding supports display panels
compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
specifications.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 .../bindings/display/panel/panel-lvds.txt          | 120 +++++++++++++++++++++
 1 file changed, 120 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
new file mode 100644
index 000000000000..b938269f841e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
@@ -0,0 +1,120 @@
+LVDS Display Panel
+==================
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This bindings supports display panels compatible with the
+following specifications.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Device compatible with those specifications have been marketed under the
+FPD-Link and FlatLink brands.
+
+
+Required properties:
+
+- compatible: Shall contain "panel-lvds" in addition to a mandatory
+  panel-specific compatible string defined in individual panel bindings. The
+  "panel-lvds" value shall never be used on its own.
+- width-mm: See panel-common.txt.
+- height-mm: See panel-common.txt.
+- data-mapping: The color signals mapping order, "jeida-18", "jeida-24"
+  or "vesa-24".
+
+Optional properties:
+
+- label: See panel-common.txt.
+- gpios: See panel-common.txt.
+- backlight: See panel-common.txt.
+- data-mirror: If set, reverse the bit order described in the data mappings
+  below on all data lanes, transmitting bits for slots 6 to 0 instead of
+  0 to 6.
+
+Required nodes:
+
+- panel-timing: See panel-common.txt.
+- ports: See panel-common.txt. These bindings require a single port subnode
+  corresponding to the panel LVDS input.
+
+
+LVDS data mappings are defined as follows.
+
+- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
+  [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
+
+Slot	    0       1       2       3       4       5       6
+	________________                         _________________
+Clock	                \_______________________/
+	  ______  ______  ______  ______  ______  ______  ______
+DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+
+- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
+  specifications. Data are transferred as follows on 4 LVDS lanes.
+
+Slot	    0       1       2       3       4       5       6
+	________________                         _________________
+Clock	                \_______________________/
+	  ______  ______  ______  ______  ______  ______  ______
+DATA0	><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
+DATA1	><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
+DATA2	><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
+DATA3	><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
+- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
+  Data are transferred as follows on 4 LVDS lanes.
+
+Slot	    0       1       2       3       4       5       6
+	________________                         _________________
+Clock	                \_______________________/
+	  ______  ______  ______  ______  ______  ______  ______
+DATA0	><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+DATA1	><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+DATA2	><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+DATA3	><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+
+Control signals are mapped as follows.
+
+CTL0: HSync
+CTL1: VSync
+CTL2: Data Enable
+CTL3: 0
+
+
+Example
+-------
+
+panel {
+	compatible = "mitsubishi,aa121td01", "panel-lvds";
+
+	width-mm = <261>;
+	height-mm = <163>;
+
+	data-mapping = "jeida-24";
+
+	panel-timing {
+		/* 1280x800 @60Hz */
+		clock-frequency = <71000000>;
+		hactive = <1280>;
+		vactive = <800>;
+		hsync-len = <70>;
+		hfront-porch = <20>;
+		hback-porch = <70>;
+		vsync-len = <5>;
+		vfront-porch = <3>;
+		vback-porch = <15>;
+	};
+
+	port {
+		panel_in: endpoint {
+			remote-endpoint = <&lvds_encoder>;
+		};
+	};
+};
-- 
Regards,

Laurent Pinchart

^ permalink raw reply related

* [PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
From: Laurent Pinchart @ 2016-11-19  3:28 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-renesas-soc, Tomi Valkeinen, devicetree
In-Reply-To: <1479526093-7014-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>

Document properties common to several display panels in a central
location that can be referenced by the panel device tree bindings.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 .../bindings/display/panel/panel-common.txt        | 91 ++++++++++++++++++++++
 1 file changed, 91 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt

diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt b/Documentation/devicetree/bindings/display/panel/panel-common.txt
new file mode 100644
index 000000000000..ec52c472c845
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
@@ -0,0 +1,91 @@
+Common Properties for Display Panel
+===================================
+
+This document defines device tree properties common to several classes of
+display panels. It doesn't constitue a device tree binding specification by
+itself but is meant to be referenced by device tree bindings.
+
+When referenced from panel device tree bindings the properties defined in this
+document are defined as follows. The panel device tree bindings are
+responsible for defining whether each property is required or optional.
+
+
+Descriptive Properties
+----------------------
+
+- width-mm,
+- height-mm: The width-mm and height-mm specify the width and height of the
+  physical area where images are displayed. These properties are expressed in
+  millimeters and rounded to the closest unit.
+
+- label: The label property specifies a symbolic name for the panel as a
+  string suitable for use by humans. It typically contains a name inscribed on
+  the system (e.g. as an affixed label) or specified in the system's
+  documentation (e.g. in the user's manual).
+
+  If no such name exists, and unless the property is mandatory according to
+  device tree bindings, it shall rather be omitted than constructed of
+  non-descriptive information. For instance an LCD panel in a system that
+  contains a single panel shall not be labelled "LCD" if that name is not
+  inscribed on the system or used in a descriptive fashion in system
+  documentation.
+
+
+Display Timings
+---------------
+
+- panel-timing: Most display panels are restricted to a single resolution and
+  require specific display timings. The panel-timing subnode expresses those
+  timings as specified in the timing subnode section of the display timing
+  bindings defined in
+  Documentation/devicetree/bindings/display/display-timing.txt.
+
+
+Connectivity
+------------
+
+- ports: Panels receive video data through one or multiple connections. While
+  the nature of those connections is specific to the panel type, the
+  connectivity is expressed in a standard fashion using ports as specified in
+  the device graph bindings defined in
+  Documentation/devicetree/bindings/graph.txt.
+
+- ddc-i2c-bus: Some panels expose EDID information through an I2C-compatible
+  bus such as DDC2 or E-DDC. For such panels the ddc-i2c-bus contains a
+  phandle to the system I2C controller connected to that bus.
+
+
+Control I/Os
+------------
+
+Many display panels can be controlled through pins driven by GPIOs. The nature
+and timing of those control signals are device-specific and left for panel
+device tree bindings to specify. The following GPIO specifiers can however be
+used for panels that implement compatible control signals.
+
+- enable-gpios: Specifier for a GPIO connected to the panel enable control
+  signal. The enable signal is active high and enables operation of the panel.
+  This property can also be used for panels implementing an active low power
+  down signal, which is a negated version of the enable signal. Active low
+  enable signals (or active high power down signals) can be supported by
+  inverting the GPIO specifier polarity flag.
+
+  Note that the enable signal control panel operation only and must not be
+  confused with a backlight enable signal.
+
+- reset-gpios: Specifier for a GPIO coonnected to the panel reset control
+  signal. The reset signal is active low and resets the panel internal logic
+  while active. Active high reset signals can be supported by inverting the
+  GPIO specifier polarity flag.
+
+
+Backlight
+---------
+
+Most display panels include a backlight. Some of them also include a backlight
+controller exposed through a control bus such as I2C or DSI. Others expose
+backlight control through GPIO, PWM or other signals connected to an external
+backlight controller.
+
+- backlight: For panels whose backlight is controlled by an external backlight
+  controller, this property contains a phandle that references the controller.
-- 
Regards,

Laurent Pinchart

^ permalink raw reply related

* [PATCH v2 00/13] R-Car DU: Add support for LVDS mode selection
From: Laurent Pinchart @ 2016-11-19  3:28 UTC (permalink / raw)
  To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
  Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
	devicetree-u79uwXL29TY76Z2rM5mHXA

Hello,

This patch series adds support for LVDS mode selection in the R-Car DU driver.

Compared to v1, the LVDS panel DT bindings (02/13) have been reworked to
document common panel properties in a common file (01/13), with Mitsubishi
panels bindings now properly documented (03/13). Compared to the existing DPI
panel bindings that are currently abused by the R-Car DU driver for LVDS
panel, these new bindings specify the LVDS more explicitly.

The bindings are based on the relevant standards I have been able to find, as
well as on existing LVDS-related code and DT bindings available in the
mainline kernel. Those include

- the LVDS formats MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
  MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
  (Documentation/media/uapi/v4l/subdev-formats.rst)
- iMX display DT bindings available in
  (Documentation/devicetree/bindings/display/imx/ldb.txt)
- the drivers/gpu/drm/imx/ driver

In addition to the three modes specified in the LVDS panel DT bindings, the
Renesas R-Car DU also supports the following two modes.

Slot       0       1       2       3       4       5       6
       ________________                         _________________
Clock                  \_______________________/
         ______  ______  ______  ______  ______  ______  ______
DATA0  ><_CTL0_><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1  ><_CTL1_><__G7__><__G6__><__G5__><__G4__><__G3__><__G2__><
DATA2  ><_CTL2_><__B7__><__B6__><__B5__><__B4__><__B3__><__B2__><
DATA3  ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
         ______  ______  ______  ______  ______  ______  ______
DATA0  ><_CTL0_><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1  ><_CTL1_><__G5__><__G4__><__G3__><__G2__><__G1__><__G0__><
DATA2  ><_CTL2_><__B5__><__B4__><__B3__><__B2__><__B1__><__B0__><
DATA3  ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><

and their mirrored version.

I haven't been able to find any standard defining those data mappings, nor any
panel using them. The control signals positions correspond to DC-balanced LVDS
(see figure 18 on page 19 of http://www.ti.com/lit/ds/symlink/ds90cf388.pdf),
but the R-Car DU doesn't support DC-balanced LVDS as far as I can tell, so
it's not a match. If anyone knows of other devices supporting these data
mappings or of standards defining them I would appreciate the information and
will update the bindings accordingly.

Patches 04/13 to 06/13 add a new DRM panel driver for LVDS panels compatible
with the DT bindings. Patches 07/13 to 09/13 update the device tree of the
R-Car H3 Salvator-X board to add panel backlight support, and patch 10/13
switches two Mitsubishi panels to use the new bindings. This series doesn't
strictly depend on them so they can be merged separately at a later point if
needed.

Patches 11/13 to 13/13 finally move the R-Car DU driver to use the DRM panel
API, and add support for LVDS mode selection.

Laurent Pinchart (13):
  devicetree/bindings: display: Document common panel properties
  devicetree/bindings: display: Add bindings for LVDS panels
  devicetree/bindings: display: Add bindings for two Mitsubishi panels
  drm: Add data mirror bus flag
  drm: panels: Constify device node argument to of_drm_find_panel()
  drm: panels: Add LVDS panel driver
  arm64: dts: r8a7795: Add PWM support
  arm64: dts: r8a7795: salvator-x: Add DU LVDS output endpoint
  arm64: dts: r8a7795: salvator-x: Add panel backlight support
  ARM: shmobile: dts: Switch to panel-lvds bindings for Mitsubishi
    panels
  drm: rcar-du: Switch to encoder .atomic_mode_set() helper function
  drm: rcar-du: Use the DRM panel API
  drm: rcar-du: Add support for LVDS mode selection

 .../display/panel/mitsubishi,aa104xd12.txt         |  47 ++++
 .../display/panel/mitsubishi,aa121td01.txt         |  47 ++++
 .../bindings/display/panel/panel-common.txt        |  91 +++++++
 .../bindings/display/panel/panel-lvds.txt          | 120 +++++++++
 arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi     |   3 +-
 arch/arm/boot/dts/r8a77xx-aa121td01-panel.dtsi     |   3 +-
 arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts |  26 ++
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |  63 +++++
 drivers/gpu/drm/drm_panel.c                        |   2 +-
 drivers/gpu/drm/panel/Kconfig                      |  10 +
 drivers/gpu/drm/panel/Makefile                     |   1 +
 drivers/gpu/drm/panel/panel-lvds.c                 | 284 +++++++++++++++++++++
 drivers/gpu/drm/rcar-du/Kconfig                    |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c          |  50 +++-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h          |   3 +
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c          |   8 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c          |  68 ++---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c          |  11 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h          |  13 +
 include/drm/drm_connector.h                        |   2 +
 include/drm/drm_panel.h                            |   4 +-
 21 files changed, 798 insertions(+), 59 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-common.txt
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-lvds.txt
 create mode 100644 drivers/gpu/drm/panel/panel-lvds.c

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] arm64: dts: qcom: msm8996: Fixup smp2p node
From: Sarangdhar Joshi @ 2016-11-19  1:53 UTC (permalink / raw)
  To: Bjorn Andersson, Andy Gross
  Cc: linux-arm-msm, linux-soc, linux-kernel, linux-arm-kernel,
	devicetree
In-Reply-To: <1479499609-13336-1-git-send-email-bjorn.andersson@linaro.org>

On 11/18/2016 12:06 PM, Bjorn Andersson wrote:
> The SMEM state property name changes between the integration branch and
> mainline, update to use the correct one.
>
> Fixes: 2f45d9fcd531 ("arm64: dts: msm8996: Add SMP2P and APCS nodes")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Thanks for the change and sorry for missing it earlier.

Reviewed-by: Sarangdhar Joshi <spjoshi@codeaurora.org>

^ permalink raw reply

* [PATCH] mfd: cpcap: Add minimal support
From: Tony Lindgren @ 2016-11-19  1:27 UTC (permalink / raw)
  To: Lee Jones, Samuel Ortiz
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Mark Rutland,
	Michael Scott, Rob Herring

Many Motorola phones like droid 4 are using a custom PMIC called CPCAP
or 6556002. We can support it's core features quite easily with regmap_spi
and regmap_irq.

The children of cpcap, such as regulators, ADC and USB, can be just regular
device drivers and defined in the dts file. They get probed as we call
of_platform_populate() at the end of our probe, and then the children
can just call dev_get_regmap(dev.parent, NULL) to get the regmap.

Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
 Documentation/devicetree/bindings/mfd/cpcap.txt |  36 ++++
 drivers/mfd/Kconfig                             |   8 +
 drivers/mfd/Makefile                            |   1 +
 drivers/mfd/cpcap.c                             | 255 ++++++++++++++++++++++++
 include/linux/mfd/cpcap.h                       | 238 ++++++++++++++++++++++
 5 files changed, 538 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/cpcap.txt
 create mode 100644 drivers/mfd/cpcap.c
 create mode 100644 include/linux/mfd/cpcap.h

diff --git a/Documentation/devicetree/bindings/mfd/cpcap.txt b/Documentation/devicetree/bindings/mfd/cpcap.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/cpcap.txt
@@ -0,0 +1,36 @@
+CPCAP PMIC device tree binding
+
+Required properties:
+- compatible		: Motorola device "motorola,cpcap", others "st,6556002"
+- reg			: Chip select and size
+- interrupt-parent	: The parent interrupt controller
+- interrupts		: The interrupt line the device is connected to
+- interrupt-controller	: Marks the device node as an interrupt controller
+- #interrupt-cells	: The number of cells to describe an IRQ, should be 2
+- #address-cells	: Child device offset number of cells, typically 1
+- #size-cells		: Child device size number of cells, typically 1
+- ranges		: Child device register range
+- spi-max-frequency	: Typically set to 3000000
+- spi-cs_high		: SPI chip select direction
+
+Example:
+
+&mcspi1 {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	ranges;
+	cpcap: pmic@0 {
+		compatible = "motorola,cpcap", "st,6556002";
+		reg = <0 0>;	/* cs0, size 0 */
+		interrupt-parent = <&gpio1>;
+		interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0 0x8000>;
+		spi-max-frequency = <3000000>;
+		spi-cs-high;
+	};
+};
+
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -713,6 +713,14 @@ config EZX_PCAP
 	  This enables the PCAP ASIC present on EZX Phones. This is
 	  needed for MMC, TouchScreen, Sound, USB, etc..
 
+config MFD_CPCAP
+	tristate "Support for CPCAP"
+	depends on SPI && OF
+	help
+	  Say yes here if you want to include driver for CPCAP.
+	  It is used on many Motorola phones and tablets as a PMIC.
+	  At least Motorola Droid 4 is known to use CPCAP.
+
 config MFD_VIPERBOARD
         tristate "Nano River Technologies Viperboard"
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_MFD_MC13XXX_I2C)	+= mc13xxx-i2c.o
 obj-$(CONFIG_MFD_CORE)		+= mfd-core.o
 
 obj-$(CONFIG_EZX_PCAP)		+= ezx-pcap.o
+obj-$(CONFIG_MFD_CPCAP)		+= cpcap.o
 
 obj-$(CONFIG_MCP)		+= mcp-core.o
 obj-$(CONFIG_MCP_SA11X0)	+= mcp-sa11x0.o
diff --git a/drivers/mfd/cpcap.c b/drivers/mfd/cpcap.c
new file mode 100644
--- /dev/null
+++ b/drivers/mfd/cpcap.c
@@ -0,0 +1,255 @@
+/*
+ * 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/device.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/regmap.h>
+#include <linux/sysfs.h>
+
+#include <linux/mfd/cpcap.h>
+#include <linux/spi/spi.h>
+
+#define CPCAP_NR_IRQ_BANKS	6
+#define CPCAP_NR_IRQ_DOMAINS	3
+
+struct cpcap_device {
+	struct spi_device *spi;
+	struct device *dev;
+	u16 vendor;
+	u16 revision;
+	const struct cpcap_platform_data *conf;
+	struct regmap_irq *irqs;
+	struct regmap_irq_chip_data *irqdata[CPCAP_NR_IRQ_DOMAINS];
+	const struct regmap_config *regmap_conf;
+	struct regmap *regmap;
+};
+
+static int cpcap_check_revision(struct cpcap_device *cpcap)
+{
+	unsigned int val;
+	int error;
+
+	error = regmap_read(cpcap->regmap, CPCAP_REG_VERSC1, &val);
+	if (error)
+		return error;
+
+	cpcap->vendor = (val >> 6) & 0x0007;
+	cpcap->revision = ((val >> 3) & 0x0007) | ((val << 3) & 0x0038);
+	dev_info(cpcap->dev, "CPCAP vendor: %s rev: %i.%i (%x)\n",
+		 cpcap->vendor ? "TI" : "ST", (cpcap->revision >> 4) + 1,
+		 cpcap->revision & 0xf, cpcap->revision);
+
+	if (cpcap->revision < CPCAP_REVISION_2_1) {
+		dev_info(cpcap->dev,
+			 "Please add old CPCAP revision support as needed\n");
+		return -ENODEV;
+	}
+
+	return 0;
+}
+
+/*
+ * First domain is the two private macro interrupt banks, the third
+ * domain is for banks 1 - 4 and is available for drivers to use.
+ */
+static struct regmap_irq_chip cpcap_irq_chip[CPCAP_NR_IRQ_DOMAINS] = {
+	{
+		.name = "cpcap-m2",
+		.num_regs = 1,
+		.status_base = CPCAP_REG_MI1,
+		.ack_base = CPCAP_REG_MI1,
+		.mask_base = CPCAP_REG_MIM1,
+		.use_ack = true,
+	},
+	{
+		.name = "cpcap-m2",
+		.num_regs = 1,
+		.status_base = CPCAP_REG_MI2,
+		.ack_base = CPCAP_REG_MI2,
+		.mask_base = CPCAP_REG_MIM2,
+		.use_ack = true,
+	},
+	{
+		.name = "cpcap1-4",
+		.num_regs = 4,
+		.status_base = CPCAP_REG_INT1,
+		.ack_base = CPCAP_REG_INT1,
+		.mask_base = CPCAP_REG_INTM1,
+		.type_base = CPCAP_REG_INTS1,
+		.use_ack = true,
+	},
+};
+
+static int cpcap_init_irq_bank(struct cpcap_device *cpcap, int irq_domain,
+			       int irq_start, int nr_irqs)
+{
+	struct regmap_irq_chip *domain = &cpcap_irq_chip[irq_domain];
+	int i, error;
+
+	for (i = irq_start; i < irq_start + nr_irqs; i++) {
+		struct regmap_irq *cpcap_irq = &cpcap->irqs[i];
+
+		cpcap_irq->reg_offset =
+			((i - irq_start) / cpcap->regmap_conf->val_bits) *
+			cpcap->regmap_conf->reg_stride;
+		cpcap_irq->mask = BIT(i % cpcap->regmap_conf->val_bits);
+	}
+	domain->irqs = &cpcap->irqs[irq_start];
+	domain->num_irqs = nr_irqs;
+	domain->irq_drv_data = cpcap;
+
+	error = devm_regmap_add_irq_chip(cpcap->dev, cpcap->regmap,
+					 cpcap->spi->irq,
+					 IRQF_TRIGGER_RISING |
+					 IRQF_SHARED, -1,
+					 domain, &cpcap->irqdata[irq_domain]);
+	if (error) {
+		dev_err(cpcap->dev, "could not add irq domain %i: %i\n",
+			irq_domain, error);
+		return error;
+	}
+
+	return 0;
+}
+
+static int cpcap_init_irq(struct cpcap_device *cpcap)
+{
+	int error;
+
+	cpcap->irqs = devm_kzalloc(cpcap->dev,
+				   sizeof(*cpcap->irqs) *
+				   CPCAP_NR_IRQ_BANKS *
+				   cpcap->regmap_conf->val_bits,
+				   GFP_KERNEL);
+	if (!cpcap->irqs)
+		return -ENOMEM;
+
+	error = cpcap_init_irq_bank(cpcap, 0, 0, 16);
+	if (error)
+		return error;
+
+	error = cpcap_init_irq_bank(cpcap, 1, 16, 16);
+	if (error)
+		return error;
+
+	error = cpcap_init_irq_bank(cpcap, 2, 32, 64);
+	if (error)
+		return error;
+
+	enable_irq_wake(cpcap->spi->irq);
+
+	return 0;
+}
+
+static const struct of_device_id cpcap_of_match[] = {
+	{
+		.compatible = "motorola,cpcap",
+	},
+	{
+		.compatible = "st,6556002",
+	},
+	{},
+};
+MODULE_DEVICE_TABLE(of, cpcap_of_match);
+
+static const struct regmap_config cpcap_regmap_config = {
+	.reg_bits = 16,
+	.reg_stride = 4,
+	.pad_bits = 0,
+	.val_bits = 16,
+	.write_flag_mask = 0x8000,
+	.max_register = CPCAP_REG_ST_TEST2,
+	.cache_type = REGCACHE_NONE,
+	.reg_format_endian = REGMAP_ENDIAN_LITTLE,
+	.val_format_endian = REGMAP_ENDIAN_LITTLE,
+};
+
+static const struct of_device_id cpcap_dt_match_table[] = {
+	{ .compatible = "simple-bus", },
+	{ },
+};
+
+static int cpcap_probe(struct spi_device *spi)
+{
+	const struct of_device_id *match;
+	int error = -EINVAL;
+	struct cpcap_device *cpcap;
+
+	match = of_match_device(of_match_ptr(cpcap_of_match), &spi->dev);
+	if (!match)
+		return -ENODEV;
+
+	cpcap = devm_kzalloc(&spi->dev, sizeof(*cpcap), GFP_KERNEL);
+	if (!cpcap)
+		return -ENOMEM;
+
+	cpcap->conf = match->data;
+	cpcap->spi = spi;
+	cpcap->dev = &spi->dev;
+	spi_set_drvdata(spi, cpcap);
+
+	spi->bits_per_word = 16;
+	spi->mode = SPI_MODE_0 | SPI_CS_HIGH;
+	error = spi_setup(spi);
+	if (error < 0)
+		return error;
+
+	cpcap->regmap_conf = &cpcap_regmap_config;
+	cpcap->regmap = devm_regmap_init_spi(spi, &cpcap_regmap_config);
+	if (IS_ERR(cpcap->regmap)) {
+		error = PTR_ERR(cpcap->regmap);
+		dev_err(cpcap->dev, "Failed to initialize regmap: %d\n",
+			error);
+
+		return error;
+	}
+
+	error = cpcap_check_revision(cpcap);
+	if (error)
+		return error;
+
+	error = cpcap_init_irq(cpcap);
+	if (error)
+		return error;
+
+	error = of_platform_populate(spi->dev.of_node,
+				     cpcap_dt_match_table,
+				     NULL, cpcap->dev);
+	if (error)
+		return error;
+
+	return 0;
+}
+
+static int cpcap_remove(struct spi_device *pdev)
+{
+	struct cpcap_device *cpcap = spi_get_drvdata(pdev);
+
+	of_platform_depopulate(cpcap->dev);
+
+	return 0;
+}
+
+static struct spi_driver cpcap_driver = {
+	.driver = {
+		.name = "cpcap-core",
+		.owner = THIS_MODULE,
+		.of_match_table = cpcap_of_match,
+	},
+	.probe = cpcap_probe,
+	.remove = cpcap_remove,
+};
+module_spi_driver(cpcap_driver);
+
+MODULE_ALIAS("platform:cpcap");
+MODULE_DESCRIPTION("CPCAP driver");
+MODULE_AUTHOR("Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/cpcap.h b/include/linux/mfd/cpcap.h
new file mode 100644
--- /dev/null
+++ b/include/linux/mfd/cpcap.h
@@ -0,0 +1,238 @@
+/*
+ * 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.
+ *
+ * Note that the register defines are based on earlier cpcap.h in
+ * Motorola Linux kernel tree except rewritten for the real register
+ * addresses instead of enumeration so they are usable with regmap.
+ */
+
+#define CPCAP_VENDOR_ST		0
+#define CPCAP_VENDOR_TI		1
+
+#define CPCAP_REVISION_1_0	0x08
+#define CPCAP_REVISION_1_1	0x09
+#define CPCAP_REVISION_2_0	0x10
+#define CPCAP_REVISION_2_1	0x11
+
+/* CPCAP registers */
+#define CPCAP_REG_INT1		0x0000	/* Interrupt 1 */
+#define CPCAP_REG_INT2		0x0004	/* Interrupt 2 */
+#define CPCAP_REG_INT3		0x0008	/* Interrupt 3 */
+#define CPCAP_REG_INT4		0x000c	/* Interrupt 4 */
+#define CPCAP_REG_INTM1		0x0010	/* Interrupt Mask 1 */
+#define CPCAP_REG_INTM2		0x0014	/* Interrupt Mask 2 */
+#define CPCAP_REG_INTM3		0x0018	/* Interrupt Mask 3 */
+#define CPCAP_REG_INTM4		0x001c	/* Interrupt Mask 4 */
+#define CPCAP_REG_INTS1		0x0020	/* Interrupt Sense 1 */
+#define CPCAP_REG_INTS2		0x0024	/* Interrupt Sense 2 */
+#define CPCAP_REG_INTS3		0x0028	/* Interrupt Sense 3 */
+#define CPCAP_REG_INTS4		0x002c	/* Interrupt Sense 4 */
+#define CPCAP_REG_ASSIGN1	0x0030	/* Resource Assignment 1 */
+#define CPCAP_REG_ASSIGN2	0x0034	/* Resource Assignment 2 */
+#define CPCAP_REG_ASSIGN3	0x0038	/* Resource Assignment 3 */
+#define CPCAP_REG_ASSIGN4	0x003c	/* Resource Assignment 4 */
+#define CPCAP_REG_ASSIGN5	0x0040	/* Resource Assignment 5 */
+#define CPCAP_REG_ASSIGN6	0x0044	/* Resource Assignment 6 */
+#define CPCAP_REG_VERSC1	0x0048	/* Version Control 1 */
+#define CPCAP_REG_VERSC2	0x004c	/* Version Control 2 */
+
+#define CPCAP_REG_MI1		0x0200	/* Macro Interrupt 1 */
+#define CPCAP_REG_MIM1		0x0204	/* Macro Interrupt Mask 1 */
+#define CPCAP_REG_MI2		0x0208	/* Macro Interrupt 2 */
+#define CPCAP_REG_MIM2		0x020c	/* Macro Interrupt Mask 2 */
+#define CPCAP_REG_UCC1		0x0210	/* UC Control 1 */
+#define CPCAP_REG_UCC2		0x0214	/* UC Control 2 */
+
+#define CPCAP_REG_PC1		0x021c	/* Power Cut 1 */
+#define CPCAP_REG_PC2		0x0220	/* Power Cut 2 */
+#define CPCAP_REG_BPEOL		0x0224	/* BP and EOL */
+#define CPCAP_REG_PGC		0x0228	/* Power Gate and Control */
+#define CPCAP_REG_MT1		0x022c	/* Memory Transfer 1 */
+#define CPCAP_REG_MT2		0x0230	/* Memory Transfer 2 */
+#define CPCAP_REG_MT3		0x0234	/* Memory Transfer 3 */
+#define CPCAP_REG_PF		0x0238	/* Print Format */
+
+#define CPCAP_REG_SCC		0x0400	/* System Clock Control */
+#define CPCAP_REG_SW1		0x0404	/* Stop Watch 1 */
+#define CPCAP_REG_SW2		0x0408	/* Stop Watch 2 */
+#define CPCAP_REG_UCTM		0x040c	/* UC Turbo Mode */
+#define CPCAP_REG_TOD1		0x0410	/* Time of Day 1 */
+#define CPCAP_REG_TOD2		0x0414	/* Time of Day 2 */
+#define CPCAP_REG_TODA1		0x0418	/* Time of Day Alarm 1 */
+#define CPCAP_REG_TODA2		0x041c	/* Time of Day Alarm 2 */
+#define CPCAP_REG_DAY		0x0420	/* Day */
+#define CPCAP_REG_DAYA		0x0424	/* Day Alarm */
+#define CPCAP_REG_VAL1		0x0428	/* Validity 1 */
+#define CPCAP_REG_VAL2		0x042c	/* Validity 2 */
+
+#define CPCAP_REG_SDVSPLL	0x0600	/* Switcher DVS and PLL */
+#define CPCAP_REG_SI2CC1	0x0604	/* Switcher I2C Control 1 */
+#define CPCAP_REG_Si2CC2	0x0608	/* Switcher I2C Control 2 */
+#define CPCAP_REG_S1C1		0x060c	/* Switcher 1 Control 1 */
+#define CPCAP_REG_S1C2		0x0610	/* Switcher 1 Control 2 */
+#define CPCAP_REG_S2C1		0x0614	/* Switcher 2 Control 1 */
+#define CPCAP_REG_S2C2		0x0618	/* Switcher 2 Control 2 */
+#define CPCAP_REG_S3C		0x061c	/* Switcher 3 Control */
+#define CPCAP_REG_S4C1		0x0620	/* Switcher 4 Control 1 */
+#define CPCAP_REG_S4C2		0x0624	/* Switcher 4 Control 2 */
+#define CPCAP_REG_S5C		0x0628	/* Switcher 5 Control */
+#define CPCAP_REG_S6C		0x062c	/* Switcher 6 Control */
+#define CPCAP_REG_VCAMC		0x0630	/* VCAM Control */
+#define CPCAP_REG_VCSIC		0x0634	/* VCSI Control */
+#define CPCAP_REG_VDACC		0x0638	/* VDAC Control */
+#define CPCAP_REG_VDIGC		0x063c	/* VDIG Control */
+#define CPCAP_REG_VFUSEC	0x0640	/* VFUSE Control */
+#define CPCAP_REG_VHVIOC	0x0644	/* VHVIO Control */
+#define CPCAP_REG_VSDIOC	0x0648	/* VSDIO Control */
+#define CPCAP_REG_VPLLC		0x064c	/* VPLL Control */
+#define CPCAP_REG_VRF1C		0x0650	/* VRF1 Control */
+#define CPCAP_REG_VRF2C		0x0654	/* VRF2 Control */
+#define CPCAP_REG_VRFREFC	0x0658	/* VRFREF Control */
+#define CPCAP_REG_VWLAN1C	0x065c	/* VWLAN1 Control */
+#define CPCAP_REG_VWLAN2C	0x0660	/* VWLAN2 Control */
+#define CPCAP_REG_VSIMC		0x0664	/* VSIM Control */
+#define CPCAP_REG_VVIBC		0x0668	/* VVIB Control */
+#define CPCAP_REG_VUSBC		0x066c	/* VUSB Control */
+#define CPCAP_REG_VUSBINT1C	0x0670	/* VUSBINT1 Control */
+#define CPCAP_REG_VUSBINT2C	0x0674	/* VUSBINT2 Control */
+#define CPCAP_REG_URT		0x0678	/* Useroff Regulator Trigger */
+#define CPCAP_REG_URM1		0x067c	/* Useroff Regulator Mask 1 */
+#define CPCAP_REG_URM2		0x0680	/* Useroff Regulator Mask 2 */
+
+#define CPCAP_REG_VAUDIOC	0x0800	/* VAUDIO Control */
+#define CPCAP_REG_CC		0x0804	/* Codec Control */
+#define CPCAP_REG_CDI		0x0808	/* Codec Digital Interface */
+#define CPCAP_REG_SDAC		0x080c	/* Stereo DAC */
+#define CPCAP_REG_SDACDI	0x0810	/* Stereo DAC Digital Interface */
+#define CPCAP_REG_TXI		0x0814	/* TX Inputs */
+#define CPCAP_REG_TXMP		0x0818	/* TX MIC PGA's */
+#define CPCAP_REG_RXOA		0x081c	/* RX Output Amplifiers */
+#define CPCAP_REG_RXVC		0x0820	/* RX Volume Control */
+#define CPCAP_REG_RXCOA		0x0824	/* RX Codec to Output Amps */
+#define CPCAP_REG_RXSDOA	0x0828	/* RX Stereo DAC to Output Amps */
+#define CPCAP_REG_RXEPOA	0x082c	/* RX External PGA to Output Amps */
+#define CPCAP_REG_RXLL		0x0830	/* RX Low Latency */
+#define CPCAP_REG_A2LA		0x0834	/* A2 Loudspeaker Amplifier */
+#define CPCAP_REG_MIPIS1	0x0838	/* MIPI Slimbus 1 */
+#define CPCAP_REG_MIPIS2	0x083c	/* MIPI Slimbus 2 */
+#define CPCAP_REG_MIPIS3	0x0840	/* MIPI Slimbus 3. */
+#define CPCAP_REG_LVAB		0x0844	/* LMR Volume and A4 Balanced. */
+
+#define CPCAP_REG_CCC1		0x0a00	/* Coulomb Counter Control 1 */
+#define CPCAP_REG_CRM		0x0a04	/* Charger and Reverse Mode */
+#define CPCAP_REG_CCCC2		0x0a08	/* Coincell and Coulomb Ctr Ctrl 2 */
+#define CPCAP_REG_CCS1		0x0a0c	/* Coulomb Counter Sample 1 */
+#define CPCAP_REG_CCS2		0x0a10	/* Coulomb Counter Sample 2 */
+#define CPCAP_REG_CCA1		0x0a14	/* Coulomb Counter Accumulator 1 */
+#define CPCAP_REG_CCA2		0x0a18	/* Coulomb Counter Accumulator 2 */
+#define CPCAP_REG_CCM		0x0a1c	/* Coulomb Counter Mode */
+#define CPCAP_REG_CCO		0x0a20	/* Coulomb Counter Offset */
+#define CPCAP_REG_CCI		0x0a24	/* Coulomb Counter Integrator */
+
+#define CPCAP_REG_ADCC1		0x0c00	/* A/D Converter Configuration 1 */
+#define CPCAP_REG_ADCC2		0x0c04	/* A/D Converter Configuration 2 */
+#define CPCAP_REG_ADCD0		0x0c08	/* A/D Converter Data 0 */
+#define CPCAP_REG_ADCD1		0x0c0c	/* A/D Converter Data 1 */
+#define CPCAP_REG_ADCD2		0x0c10	/* A/D Converter Data 2 */
+#define CPCAP_REG_ADCD3		0x0c14	/* A/D Converter Data 3 */
+#define CPCAP_REG_ADCD4		0x0c18	/* A/D Converter Data 4 */
+#define CPCAP_REG_ADCD5		0x0c1c	/* A/D Converter Data 5 */
+#define CPCAP_REG_ADCD6		0x0c20	/* A/D Converter Data 6 */
+#define CPCAP_REG_ADCD7		0x0c24	/* A/D Converter Data 7 */
+#define CPCAP_REG_ADCAL1	0x0c28	/* A/D Converter Calibration 1 */
+#define CPCAP_REG_ADCAL2	0x0c2c	/* A/D Converter Calibration 2 */
+
+#define CPCAP_REG_USBC1		0x0e00	/* USB Control 1 */
+#define CPCAP_REG_USBC2		0x0e04	/* USB Control 2 */
+#define CPCAP_REG_USBC3		0x0e08	/* USB Control 3 */
+#define CPCAP_REG_UVIDL		0x0e0c	/* ULPI Vendor ID Low */
+#define CPCAP_REG_UVIDH		0x0e10	/* ULPI Vendor ID High */
+#define CPCAP_REG_UPIDL		0x0e14	/* ULPI Product ID Low */
+#define CPCAP_REG_UPIDH		0x0e18	/* ULPI Product ID High */
+#define CPCAP_REG_UFC1		0x0e1c	/* ULPI Function Control 1 */
+#define CPCAP_REG_UFC2		0x0e20	/* ULPI Function Control 2 */
+#define CPCAP_REG_UFC3		0x0e24	/* ULPI Function Control 3 */
+#define CPCAP_REG_UIC1		0x0e28	/* ULPI Interface Control 1 */
+#define CPCAP_REG_UIC2		0x0e2c	/* ULPI Interface Control 2 */
+#define CPCAP_REG_UIC3		0x0e30	/* ULPI Interface Control 3 */
+#define CPCAP_REG_USBOTG1	0x0e34	/* USB OTG Control 1 */
+#define CPCAP_REG_USBOTG2	0x0e38	/* USB OTG Control 2 */
+#define CPCAP_REG_USBOTG3	0x0e3c	/* USB OTG Control 3 */
+#define CPCAP_REG_UIER1		0x0e40	/* USB Interrupt Enable Rising 1 */
+#define CPCAP_REG_UIER2		0x0e44	/* USB Interrupt Enable Rising 2 */
+#define CPCAP_REG_UIER3		0x0e48	/* USB Interrupt Enable Rising 3 */
+#define CPCAP_REG_UIEF1		0x0e4c	/* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIEF2		0x0e50	/* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIEF3		0x0e54	/* USB Interrupt Enable Falling 1 */
+#define CPCAP_REG_UIS		0x0e58	/* USB Interrupt Status */
+#define CPCAP_REG_UIL		0x0e5c	/* USB Interrupt Latch */
+#define CPCAP_REG_USBD		0x0e60	/* USB Debug */
+#define CPCAP_REG_SCR1		0x0e64	/* Scratch 1 */
+#define CPCAP_REG_SCR2		0x0e68	/* Scratch 2 */
+#define CPCAP_REG_SCR3		0x0e6c	/* Scratch 3 */
+
+#define CPCAP_REG_VMC		0x0eac	/* Video Mux Control */
+#define CPCAP_REG_OWDC		0x0eb0	/* One Wire Device Control */
+#define CPCAP_REG_GPIO0		0x0eb4	/* GPIO 0 Control */
+
+#define CPCAP_REG_GPIO1		0x0ebc	/* GPIO 1 Control */
+
+#define CPCAP_REG_GPIO2		0x0ec4	/* GPIO 2 Control */
+
+#define CPCAP_REG_GPIO3		0x0ecc	/* GPIO 3 Control */
+
+#define CPCAP_REG_GPIO4		0x0ed4	/* GPIO 4 Control */
+
+#define CPCAP_REG_GPIO5		0x0edc	/* GPIO 5 Control */
+
+#define CPCAP_REG_GPIO6		0x0ee4	/* GPIO 6 Control */
+
+#define CPCAP_REG_MDLC		0x1000	/* Main Display Lighting Control */
+#define CPCAP_REG_KLC		0x1004	/* Keypad Lighting Control */
+#define CPCAP_REG_ADLC		0x1008	/* Aux Display Lighting Control */
+#define CPCAP_REG_REDC		0x100c	/* Red Triode Control */
+#define CPCAP_REG_GREENC	0x1010	/* Green Triode Control */
+#define CPCAP_REG_BLUEC		0x1014	/* Blue Triode Control */
+#define CPCAP_REG_CFC		0x1018	/* Camera Flash Control */
+#define CPCAP_REG_ABC		0x101c	/* Adaptive Boost Control */
+#define CPCAP_REG_BLEDC		0x1020	/* Bluetooth LED Control */
+#define CPCAP_REG_CLEDC		0x1024	/* Camera Privacy LED Control */
+
+#define CPCAP_REG_OW1C		0x1200	/* One Wire 1 Command */
+#define CPCAP_REG_OW1D		0x1204	/* One Wire 1 Data */
+#define CPCAP_REG_OW1I		0x1208	/* One Wire 1 Interrupt */
+#define CPCAP_REG_OW1IE		0x120c	/* One Wire 1 Interrupt Enable */
+
+#define CPCAP_REG_OW1		0x1214	/* One Wire 1 Control */
+
+#define CPCAP_REG_OW2C		0x1220	/* One Wire 2 Command */
+#define CPCAP_REG_OW2D		0x1224	/* One Wire 2 Data */
+#define CPCAP_REG_OW2I		0x1228	/* One Wire 2 Interrupt */
+#define CPCAP_REG_OW2IE		0x122c	/* One Wire 2 Interrupt Enable */
+
+#define CPCAP_REG_OW2		0x1234	/* One Wire 2 Control */
+
+#define CPCAP_REG_OW3C		0x1240	/* One Wire 3 Command */
+#define CPCAP_REG_OW3D		0x1244	/* One Wire 3 Data */
+#define CPCAP_REG_OW3I		0x1248	/* One Wire 3 Interrupt */
+#define CPCAP_REG_OW3IE		0x124c	/* One Wire 3 Interrupt Enable */
+
+#define CPCAP_REG_OW3		0x1254	/* One Wire 3 Control */
+#define CPCAP_REG_GCAIC		0x1258	/* GCAI Clock Control */
+#define CPCAP_REG_GCAIM		0x125c	/* GCAI GPIO Mode */
+#define CPCAP_REG_LGDIR		0x1260	/* LMR GCAI GPIO Direction */
+#define CPCAP_REG_LGPU		0x1264	/* LMR GCAI GPIO Pull-up */
+#define CPCAP_REG_LGPIN		0x1268	/* LMR GCAI GPIO Pin */
+#define CPCAP_REG_LGMASK	0x126c	/* LMR GCAI GPIO Mask */
+#define CPCAP_REG_LDEB		0x1270	/* LMR Debounce Settings */
+#define CPCAP_REG_LGDET		0x1274	/* LMR GCAI Detach Detect */
+#define CPCAP_REG_LMISC		0x1278	/* LMR Misc Bits */
+#define CPCAP_REG_LMACE		0x127c	/* LMR Mace IC Support */
+
+#define CPCAP_REG_TEST		0x7c00	/* Test */
+
+#define CPCAP_REG_ST_TEST1	0x7d08	/* ST Test1 */
+
+#define CPCAP_REG_ST_TEST2	0x7d18	/* ST Test2 */
-- 
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: specifying order of /dev/mmcblk devices via device-tree?
From: Stefan Agner @ 2016-11-19  1:23 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Tim Harvey,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAPDyKFrpqmvVAKsfQBP1m7vdOjPRx7puVkmmCe3yxe1gVFwgzw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2016-11-16 06:45, Ulf Hansson wrote:
> On 28 October 2016 at 17:37, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>>> Greetings,
>>>
>>> I have an IMX6 board that has the following:
>>> sdhc1: mmc0: sdio radio
>>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>>
>>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>>> registered as /dev/mmcblk1 so that permanent storage is the first
>>> mmcblk device as I think this is more intuitive however currently
>>> these get instanced in the order they appear in the imx6qdl.dtsi
>>> device-tree configuration and are not able to be mapped the way I want
>>> them in my dts file.
>>>
>>> Is there a way, or if not is there a desire for a way, to specify the
>>> order of /dev/mmcblk devices via device-tree?
>>
>> As with many other devices, there is no standard way of controlling the
>> Linux enumeration (and given the ID space is shared with other dynamic
>> devices it's not something that could generally work).
>>
>> These should be refererd to by UUID if possible.
>>
>> If not, we could cosider adding a by-dt-path or something like that.
> 
> So does that mean you think using "DT aliases" would be okay? As
> Javier pointed out, there have been some attempts [1] for that, but
> they didn't make it.
> Perhaps we need to re-consider, and if so please re-review the DT
> bindings patch from that series.

I really would like to see some sort of stable MMC block device
ordering.

by-dt-path solutions requires initramfs, which adds complexity and boot
time. Both not very welcome in simple embedded devices.

PARTUUID is relying on a particular instance of a partition, which is
not the same as to say boot from the second partition of device X.

The main problem I see in my patchset is that it works around the fact
MMC is a bus. Adding the mmc controller number to the block device name
would avoid that issue (mmc0blk0...), not sure if a such a drastic
change would be acceptable.

--
Stefan
--
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: specifying order of /dev/mmcblk devices via device-tree?
From: Stefan Agner @ 2016-11-19  1:18 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Tim Harvey, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Ulf Hansson, Fabio Estevam, Javier Martinez Canillas,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161115235503.GC1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>

On 2016-11-15 15:55, Russell King - ARM Linux wrote:
> On Tue, Nov 15, 2016 at 10:10:02PM +0000, Russell King - ARM Linux wrote:
>> On Tue, Nov 15, 2016 at 01:39:42PM -0800, Tim Harvey wrote:
>> > On Tue, Nov 15, 2016 at 1:35 PM, Russell King - ARM Linux
>> > <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > > On Tue, Nov 15, 2016 at 12:27:53PM -0800, Tim Harvey wrote:
>> > >> On Mon, Nov 14, 2016 at 11:08 AM, Russell King - ARM Linux
>> > >> <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
>> > >> > So, someone merged a patch which makes mmcblk devices follow the
>> > >> > host controller numbering.
>> > >> >
>> > >> > Now my cubox-i fails to boot correctly because the SD card in the
>> > >> > _only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
>> > >> >
>> > >> > USDHC1 is wired to the on-microsom WiFi, and never has anything
>> > >> > remotely near a SD card or eMMC present.  So, this change is
>> > >> > confusing on these platforms.
>> > >> >
>> > >> > Moreover, this is _going_ to break SolidRun distros if people upgrade
>> > >> > their kernels.
>> > >> >
>> > >> > It may be appropriate for eMMC, but it's not appropriate everywhere.
>> > >> >
>> > >> > This is a user visible _regression_ in 4.9-rc.  Whoever did this,
>> > >> > please revert whatever change caused this, and next time limit it
>> > >> > to only eMMC.
>> > >> >
>> > >> > Thanks.
>> > >>
>> > >> I see the same thing on newer kernels, which is why I asked the
>> > >> question. I didn't expect (or even want honestly) a non mmcblk0 boot
>> > >> device and was looking for a way to control that via dt. Now I'm
>> > >> understanding that to avoid this kind of bootloader/kernel dependence
>> > >> issue I should be using UUID's to identify the boot device.
>> > >>
>> > >> >From my testing it looks like the change your looking for occurred
>> > >> some time ago and is somewhere between 4.5 and 4.6 and not a 4.9
>> > >> regression specifically.
>> > >
>> > > That depends how you look at it.  Yes, there's a change in 4.5 to 4.6
>> > > which ties the block device number to the host device index, but that's
>> > > really only part of the story here.
>> > >
>> > > 4.8 definitely identifies the SD card in iMX6 usdhc2 as "mmcblk0".
>> > > 4.9-rc identifies the SD card as "mmcblk1".  This makes it a 4.9 change
>> > > of behaviour - there can be no argument about that.
>> > >
>> > > Now, digging further into this today, it appears that:
>> > >
>> > > v4.8: usdhc2 was probed first, and is given mmc0.
>> > >       usdhc1 is probed second, and is given mmc1.
>> > >
>> > > v4.9-rc: usdhc1 is probed first, and is given mmc0.
>> > >          usdhc2 is probed second, and is given mmc1.
>> > >
>> > > I haven't yet been able to figure out why there's been this change
>> > > of probe order.  There's no change that I can see in the iMX6 DT
>> > > files that would account for this.
>> > >
>> >
>> > I bisected it and the commit your looking for is
>> > 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d
>>
>> No it's not.
>>
>> Let me try and put it plainer:
>>
>> * Commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d ties the mmc block
>>   device number (mmcblkN) to the mmc host interface number (mmcN).
>>   This change happened between 4.5 and 4.6.
>>
>> * The change I'm seeing happened between 4.8 and 4.9-rc.  I'm not
>>   seeing a change of behaviour between 4.5 and 4.6.
>>
>> * The change I'm seeing changes the order of the physical device
>>   associated with the hosts named mmc0 and mmc1 in the kernel.
>>
>> * Because physical devices associated with the mmc0 and mmc1 hosts
>>   swap over, the mmcblkN number changes due to the commit you point
>>   out.
>>
>> * So, the change that I'm seeing between 4.8 and 4.9-rc is not caused
>>   by commit 9aaf3437aa72ed5370bf32c99580a3fa2c330e3d, but by something
>>   else changing the order in which the two usdhc physical hardware
>>   blocks get probed.
>>
>> Does this make it clearer?
> 
> It turns out to be this commit:
> 
> commit 6eb1c9496b81680f2cd2e0eda06c531317e2e28d
> Author: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> Date:   Mon Sep 19 01:16:44 2016 +0900
> 
>     clk: probe common clock drivers earlier
> 
>     Several SoCs implement platform drivers for clocks rather than
>     CLK_OF_DECLARE().  Clocks should come earlier because they are
>     prerequisites for many of other drivers.  It will help to mitigate
>     EPROBE_DEFER issues.
> 
>     Also, drop the comment since it does not carry much value.
> 
>     Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
>     Acked-by: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> 
> which changes the init order.  In 4.8, we get:

Afaik, init order is not guaranteed, it never was. Usually the order
ends up to be in some order of the device tree, but one could also parse
the device tree in reverse order (which would be an interesting
experiment).

If we want to rely on ordering, we need to add alias support.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [PATCH v2] of: Fix issue where code would fall through to error case.
From: Moritz Fischer @ 2016-11-19  0:48 UTC (permalink / raw)
  To: linux-kernel
  Cc: pantelis.antoniou, robh+dt, frowand.list, devicetree, moritz,
	Moritz Fischer

No longer fall through into the error case that prints out
an error if no error (err = 0) occurred.

Fixes d9181b20a83(of: Add back an error message, restructured)
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Frank Rowand <frank.rowand@am.sony.com>
---
Hi Rob,

this is Frank's suggestion. I don't have a strong preference one way or the other.
Feel free to pick one or the other.

Cheers,

Moritz
---
 drivers/of/resolver.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 783bd09..c47404f3 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -358,14 +358,14 @@ int of_resolve_phandles(struct device_node *overlay)
 
 		err = update_usages_of_a_phandle_reference(overlay, prop, phandle);
 		if (err)
-			break;
+			goto err_out;
 	}
-
-err_out:
-	pr_err("overlay phandle fixup failed: %d\n", err);
 out:
 	of_node_put(tree_symbols);
-
 	return err;
+
+err_out:
+	pr_err("overlay phandle fixup failed: %d\n", err);
+	goto out;
 }
 EXPORT_SYMBOL_GPL(of_resolve_phandles);
-- 
2.7.4

^ permalink raw reply related

* [PATCH 4/4] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-11-19  0:32 UTC (permalink / raw)
  To: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, Axel Haslam,
	Bartosz Gołaszewski, Alexandre Bailon, David Lechner,
	Rob Herring
In-Reply-To: <20161119003208.10550-1-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
 .../devicetree/bindings/media/ti,vpif-capture.txt  | 65 ++++++++++++++++++++++
 .../devicetree/bindings/media/ti,vpif.txt          |  8 +++
 2 files changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti,vpif-capture.txt
 create mode 100644 Documentation/devicetree/bindings/media/ti,vpif.txt

diff --git a/Documentation/devicetree/bindings/media/ti,vpif-capture.txt b/Documentation/devicetree/bindings/media/ti,vpif-capture.txt
new file mode 100644
index 000000000000..eaaaa46d3a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,vpif-capture.txt
@@ -0,0 +1,65 @@
+Texas Instruments VPIF Capture
+------------------------------
+
+The TI Video Port InterFace (VPIF) capture component is the primary
+component for video capture on some TI DaVinci family SoCs.
+
+TI Document number reference: SPRUH82C
+
+Required properties:
+- compatible: must be "ti,vpif-capture"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+VPIF capture has a 16-bit parallel bus input, supporting 2 8-bit
+channels or a single 16-bit channel.  It should contain at least one
+port child node with child 'endpoint' node. Please refer to the
+bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+	vpif_capture: video-capture@0x00217000 {
+		compatible = "ti,vpif-capture";
+		reg = <0x00217000 0x1000>;
+		interrupts = <92>;
+
+		port {
+			vpif_ch0: endpoint@0 {
+				  reg = <0>;
+				  bus-width = <8>;
+				  remote-endpoint = <&composite>;
+			};
+
+			vpif_ch1: endpoint@1 {
+				  reg = <1>;
+				  bus-width = <8>;
+				  data-shift = <8>;
+			};
+		};
+	};
+
+[ ... ]
+
+&i2c0 {
+
+	tvp5147@5d {
+		compatible = "ti,tvp5147";
+		reg = <0x5d>;
+		status = "okay";
+
+		port {
+			composite: endpoint {
+				hsync-active = <1>;
+				vsync-active = <1>;
+				pclk-sample = <0>;
+
+				/* VPIF channel 0 (lower 8-bits) */
+				remote-endpoint = <&vpif_ch0>;
+				bus-width = <8>;
+			};
+		};
+	};
+
+};
diff --git a/Documentation/devicetree/bindings/media/ti,vpif.txt b/Documentation/devicetree/bindings/media/ti,vpif.txt
new file mode 100644
index 000000000000..0d5c16531c0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,vpif.txt
@@ -0,0 +1,8 @@
+Texas Instruments VPIF
+----------------------
+
+The Video Port InterFace (VPIF) is the core component for video output
+and capture on TI Davinci family SoCs.
+
+- compatible: must be "ti,vpif"
+- reg: physical base address and length of the registers set for the device;
-- 
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 related

* [PATCH 3/4] [media] davinci: vpif_capture: get subdevs from DT
From: Kevin Hilman @ 2016-11-19  0:32 UTC (permalink / raw)
  To: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, Axel Haslam,
	Bartosz Gołaszewski, Alexandre Bailon, David Lechner
In-Reply-To: <20161119003208.10550-1-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Allow getting of subdevs from DT ports and endpoints.

The _get_pdata() function was larely inspired by (i.e. stolen from)
am437x-vpfe.c

Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
 drivers/media/platform/davinci/vpif_capture.c | 130 +++++++++++++++++++++++++-
 include/media/davinci/vpif_types.h            |   9 +-
 2 files changed, 133 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index becc3e63b472..a0353d13eb92 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -26,6 +26,8 @@
 #include <linux/slab.h>
 
 #include <media/v4l2-ioctl.h>
+#include <media/v4l2-of.h>
+#include <media/i2c/tvp514x.h>
 
 #include "vpif.h"
 #include "vpif_capture.h"
@@ -651,6 +653,10 @@ static int vpif_input_to_subdev(
 
 	vpif_dbg(2, debug, "vpif_input_to_subdev\n");
 
+	if (!chan_cfg)
+		return -1;
+	if (input_index >= chan_cfg->input_count)
+		return -1;
 	subdev_name = chan_cfg->inputs[input_index].subdev_name;
 	if (subdev_name == NULL)
 		return -1;
@@ -658,7 +664,7 @@ static int vpif_input_to_subdev(
 	/* loop through the sub device list to get the sub device info */
 	for (i = 0; i < vpif_cfg->subdev_count; i++) {
 		subdev_info = &vpif_cfg->subdev_info[i];
-		if (!strcmp(subdev_info->name, subdev_name))
+		if (subdev_info && !strcmp(subdev_info->name, subdev_name))
 			return i;
 	}
 	return -1;
@@ -1328,6 +1334,21 @@ static int vpif_async_bound(struct v4l2_async_notifier *notifier,
 {
 	int i;
 
+	for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
+		struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
+		const struct device_node *node = _asd->match.of.node;
+
+		if (node == subdev->of_node) {
+			vpif_obj.sd[i] = subdev;
+			vpif_obj.config->chan_config->inputs[i].subdev_name =
+				(char *)subdev->of_node->full_name;
+			vpif_dbg(2, debug,
+				 "%s: setting input %d subdev_name = %s\n",
+				 __func__, i, subdev->of_node->full_name);
+			return 0;
+		}
+	}
+
 	for (i = 0; i < vpif_obj.config->subdev_count; i++)
 		if (!strcmp(vpif_obj.config->subdev_info[i].name,
 			    subdev->name)) {
@@ -1423,6 +1444,110 @@ static int vpif_async_complete(struct v4l2_async_notifier *notifier)
 	return vpif_probe_complete();
 }
 
+static struct vpif_capture_config *
+vpif_capture_get_pdata(struct platform_device *pdev)
+{
+	struct device_node *endpoint = NULL;
+	struct v4l2_of_endpoint bus_cfg;
+	struct vpif_capture_config *pdata;
+	struct vpif_subdev_info *sdinfo;
+	struct vpif_capture_chan_config *chan;
+	unsigned int i;
+
+	dev_dbg(&pdev->dev, "vpif_get_pdata\n");
+
+	if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+		return pdev->dev.platform_data;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return NULL;
+	pdata->subdev_info =
+		devm_kzalloc(&pdev->dev, sizeof(*pdata->subdev_info) *
+			     VPIF_CAPTURE_MAX_CHANNELS, GFP_KERNEL);
+
+	if (!pdata->subdev_info)
+		return NULL;
+	dev_dbg(&pdev->dev, "%s\n", __func__);
+
+	for (i = 0; ; i++) {
+		struct device_node *rem;
+		unsigned int flags;
+		int err;
+
+		endpoint = of_graph_get_next_endpoint(pdev->dev.of_node,
+						      endpoint);
+		if (!endpoint)
+			break;
+
+		sdinfo = &pdata->subdev_info[i];
+		chan = &pdata->chan_config[i];
+		chan->inputs = devm_kzalloc(&pdev->dev,
+					    sizeof(*chan->inputs) *
+					    VPIF_DISPLAY_MAX_CHANNELS,
+					    GFP_KERNEL);
+
+		chan->input_count++;
+		chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
+		chan->inputs[i].input.std = V4L2_STD_ALL;
+		chan->inputs[i].input.capabilities = V4L2_IN_CAP_STD;
+
+		/* FIXME: need a new property? ch0:composite ch1: s-video */
+		if (i == 0)
+			chan->inputs[i].input_route = INPUT_CVBS_VI2B;
+		else
+			chan->inputs[i].input_route = INPUT_SVIDEO_VI2C_VI1C;
+		chan->inputs[i].output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC;
+
+		err = v4l2_of_parse_endpoint(endpoint, &bus_cfg);
+		if (err) {
+			dev_err(&pdev->dev, "Could not parse the endpoint\n");
+			goto done;
+		}
+		dev_dbg(&pdev->dev, "Endpoint %s, bus_width = %d\n",
+			endpoint->full_name, bus_cfg.bus.parallel.bus_width);
+		flags = bus_cfg.bus.parallel.flags;
+
+		if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+			chan->vpif_if.hd_pol = 1;
+
+		if (flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+			chan->vpif_if.vd_pol = 1;
+
+		chan->vpif_if.if_type = VPIF_IF_BT656;
+		rem = of_graph_get_remote_port_parent(endpoint);
+		if (!rem) {
+			dev_dbg(&pdev->dev, "Remote device at %s not found\n",
+				endpoint->full_name);
+			goto done;
+		}
+
+		dev_dbg(&pdev->dev, "Remote device %s, %s found\n",
+			rem->name, rem->full_name);
+		sdinfo->name = rem->full_name;
+
+		pdata->asd[i] = devm_kzalloc(&pdev->dev,
+					     sizeof(struct v4l2_async_subdev),
+					     GFP_KERNEL);
+		if (!pdata->asd[i]) {
+			of_node_put(rem);
+			pdata = NULL;
+			goto done;
+		}
+
+		pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_OF;
+		pdata->asd[i]->match.of.node = rem;
+		of_node_put(rem);
+	}
+
+done:
+	pdata->asd_sizes[0] = i;
+	pdata->subdev_count = i;
+	pdata->card_name = "DA850/OMAP-L138 Video Capture";
+
+	return pdata;
+}
+
 /**
  * vpif_probe : This function probes the vpif capture driver
  * @pdev: platform device pointer
@@ -1439,6 +1564,7 @@ static __init int vpif_probe(struct platform_device *pdev)
 	int res_idx = 0;
 	int i, err;
 
+	pdev->dev.platform_data = vpif_capture_get_pdata(pdev);
 	if (!pdev->dev.platform_data) {
 		dev_warn(&pdev->dev, "Missing platform data.  Giving up.\n");
 		return -EINVAL;
@@ -1481,7 +1607,7 @@ static __init int vpif_probe(struct platform_device *pdev)
 		goto vpif_unregister;
 	}
 
-	if (!vpif_obj.config->asd_sizes) {
+	if (!vpif_obj.config->asd_sizes[0]) {
 		i2c_adap = i2c_get_adapter(1);
 		for (i = 0; i < subdev_count; i++) {
 			subdevdata = &vpif_obj.config->subdev_info[i];
diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4ee3b41975db 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -65,14 +65,14 @@ struct vpif_display_config {
 
 struct vpif_input {
 	struct v4l2_input input;
-	const char *subdev_name;
+	char *subdev_name;
 	u32 input_route;
 	u32 output_route;
 };
 
 struct vpif_capture_chan_config {
 	struct vpif_interface vpif_if;
-	const struct vpif_input *inputs;
+	struct vpif_input *inputs;
 	int input_count;
 };
 
@@ -83,7 +83,8 @@ struct vpif_capture_config {
 	struct vpif_subdev_info *subdev_info;
 	int subdev_count;
 	const char *card_name;
-	struct v4l2_async_subdev **asd;	/* Flat array, arranged in groups */
-	int *asd_sizes;		/* 0-terminated array of asd group sizes */
+
+	struct v4l2_async_subdev *asd[VPIF_CAPTURE_MAX_CHANNELS];
+	int asd_sizes[VPIF_CAPTURE_MAX_CHANNELS];
 };
 #endif /* _VPIF_TYPES_H */
-- 
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 related

* [PATCH 2/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-11-19  0:32 UTC (permalink / raw)
  To: linux-media, Hans Verkuil
  Cc: devicetree, Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
	Alexandre Bailon, David Lechner
In-Reply-To: <20161119003208.10550-1-khilman@baylibre.com>

Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 drivers/media/platform/davinci/vpif_capture.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 79cef74e164f..becc3e63b472 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -193,12 +193,16 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
 		}
 	}
 
+	spin_unlock_irqrestore(&common->irqlock, flags);
+
 	ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
 	if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
 		vpif_dbg(1, debug, "stream on failed in subdev\n");
 		goto err;
 	}
 
+	spin_lock_irqsave(&common->irqlock, flags);
+
 	/* Call vpif_set_params function to set the parameters and addresses */
 	ret = vpif_set_video_params(vpif, ch->channel_id);
 	if (ret < 0) {
-- 
2.9.3

^ permalink raw reply related

* [PATCH 1/4] [media] davinci: add support for DT init
From: Kevin Hilman @ 2016-11-19  0:32 UTC (permalink / raw)
  To: linux-media, Hans Verkuil
  Cc: devicetree, Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
	Alexandre Bailon, David Lechner

Add basic support for initialization via DT.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 drivers/media/platform/davinci/vpif.c         |  9 +++++++++
 drivers/media/platform/davinci/vpif_capture.c | 14 ++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index 0380cf2e5775..077e328e0281 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -464,8 +464,17 @@ static const struct dev_pm_ops vpif_pm = {
 #define vpif_pm_ops NULL
 #endif
 
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+	{ .compatible = "ti,vpif", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
 static struct platform_driver vpif_driver = {
 	.driver = {
+		.of_match_table = of_match_ptr(vpif_of_match),
 		.name	= "vpif",
 		.pm	= vpif_pm_ops,
 	},
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 5104cc0ee40e..79cef74e164f 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1435,6 +1435,11 @@ static __init int vpif_probe(struct platform_device *pdev)
 	int res_idx = 0;
 	int i, err;
 
+	if (!pdev->dev.platform_data) {
+		dev_warn(&pdev->dev, "Missing platform data.  Giving up.\n");
+		return -EINVAL;
+	}
+
 	vpif_dev = &pdev->dev;
 
 	err = initialize_vpif();
@@ -1618,8 +1623,17 @@ static int vpif_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(vpif_pm_ops, vpif_suspend, vpif_resume);
 
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_capture_of_match[] = {
+	{ .compatible = "ti,vpif-capture", },
+	{ /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_capture_of_match);
+#endif
+
 static __refdata struct platform_driver vpif_driver = {
 	.driver	= {
+		.of_match_table = of_match_ptr(vpif_capture_of_match),
 		.name	= VPIF_DRIVER_NAME,
 		.pm	= &vpif_pm_ops,
 	},
-- 
2.9.3

^ permalink raw reply related

* Re: [PATCH 3/3] ARM64: dts: meson-gxbb: add the USB reset also to the second USB PHY
From: Martin Blumenstingl @ 2016-11-18 22:35 UTC (permalink / raw)
  To: Kevin Hilman
  Cc: p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
	carlo-KA+7E9HrN00dnm+yROfE0A, will.deacon-5wv7dgnIgG8,
	catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <m2twb7w1j6.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Hi Kevin,

On Wed, Nov 16, 2016 at 10:35 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
>
>> When the USB PHY driver was introduced the reset framework did not
>> have support for triggering a reset pulse for shared resets. On GXBB
>> however there is only one reset line for both PHYs (meaning we have a
>> shared reset line). With the latest changes to the reset framework and
>> the corresponding updates to the phy-meson8b-usb2 driver we can now pass
>> the reset to the second PHY as well.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> Applied.
Unfortunately I think I put crucial information only in the
cover-letter's description:
"the dts patch has a runtime-dependency on patch 1 and 2"

So please feel free to keep or drop the patch as it is. In case you
decide drop it I will re-send it for 4.11 (after all the 4.10 stuff is
done).
--
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/5] i2c: designware: Add slave mode as separated driver
From: kbuild test robot @ 2016-11-18 22:27 UTC (permalink / raw)
  Cc: kbuild-all-JC7UmRfGjtg, wsa-z923LK4zBo2bacvFa/9K2g,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	jarkko.nikula-VuQAYsv1563Yd54FQh9/CA,
	andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
	mika.westerberg-VuQAYsv1563Yd54FQh9/CA,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w,
	Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w,
	Joao.Pinto-HKixBCOQz3hWk0Htik3J/w,
	CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <36abadc931ab0814019c9b2214886bcb4e4ce5c1.1479410047.git.lolivei-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 6345 bytes --]

Hi Luis,

[auto build test ERROR on v4.9-rc5]
[also build test ERROR on next-20161117]
[cannot apply to wsa/i2c/for-next]
[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/Luis-Oliveira/i2c-designware-Add-slave-support/20161118-193236
config: x86_64-randconfig-s4-11190538 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/i2c/busses/i2c-designware-slave.c: In function 'i2c_dw_irq_handler_slave':
>> drivers/i2c/busses/i2c-designware-slave.c:295:3: error: implicit declaration of function 'i2c_slave_event' [-Werror=implicit-function-declaration]
      i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
      ^~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:295:31: error: 'I2C_SLAVE_WRITE_REQUESTED' undeclared (first use in this function)
      i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~
   drivers/i2c/busses/i2c-designware-slave.c:295:31: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/i2c/busses/i2c-designware-slave.c:302:6: error: 'I2C_SLAVE_WRITE_RECEIVED' undeclared (first use in this function)
         I2C_SLAVE_WRITE_RECEIVED, &val)) {
         ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:314:7: error: 'I2C_SLAVE_READ_REQUESTED' undeclared (first use in this function)
          I2C_SLAVE_READ_REQUESTED, &val))
          ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:320:36: error: 'I2C_SLAVE_READ_PROCESSED' undeclared (first use in this function)
      if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/i2c/busses/i2c-designware-slave.c:324:31: error: 'I2C_SLAVE_STOP' undeclared (first use in this function)
      i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
                                  ^~~~~~~~~~~~~~
   drivers/i2c/busses/i2c-designware-slave.c: At top level:
>> drivers/i2c/busses/i2c-designware-slave.c:370:2: error: unknown field 'reg_slave' specified in initializer
     .reg_slave = i2c_dw_reg_slave,
     ^
>> drivers/i2c/busses/i2c-designware-slave.c:370:15: warning: excess elements in struct initializer
     .reg_slave = i2c_dw_reg_slave,
                  ^~~~~~~~~~~~~~~~
   drivers/i2c/busses/i2c-designware-slave.c:370:15: note: (near initialization for 'i2c_dw_algo')
>> drivers/i2c/busses/i2c-designware-slave.c:371:2: error: unknown field 'unreg_slave' specified in initializer
     .unreg_slave = i2c_dw_unreg_slave,
     ^
   drivers/i2c/busses/i2c-designware-slave.c:371:17: warning: excess elements in struct initializer
     .unreg_slave = i2c_dw_unreg_slave,
                    ^~~~~~~~~~~~~~~~~~
   drivers/i2c/busses/i2c-designware-slave.c:371:17: note: (near initialization for 'i2c_dw_algo')
   cc1: some warnings being treated as errors

vim +/i2c_slave_event +295 drivers/i2c/busses/i2c-designware-slave.c

   289			dw_readl(dev, DW_IC_CLR_START_DET);
   290		if (stat & DW_IC_INTR_ACTIVITY)
   291			dw_readl(dev, DW_IC_CLR_ACTIVITY);
   292		if (stat & DW_IC_INTR_RX_OVER)
   293			dw_readl(dev, DW_IC_CLR_RX_OVER);
   294		if ((stat & DW_IC_INTR_RX_FULL) && (stat & DW_IC_INTR_STOP_DET))
 > 295			i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_REQUESTED, &val);
   296	
   297		if (slave_activity) {
   298			if (stat & DW_IC_INTR_RD_REQ) {
   299				if (stat & DW_IC_INTR_RX_FULL) {
   300					val = dw_readl(dev, DW_IC_DATA_CMD);
   301					if (!i2c_slave_event(dev->slave,
 > 302					 I2C_SLAVE_WRITE_RECEIVED, &val)) {
   303						dev_dbg(dev->dev, "Byte %X acked! ",
   304						 val);
   305					}
   306					dw_readl(dev, DW_IC_CLR_RD_REQ);
   307					stat = i2c_dw_read_clear_intrbits_slave(dev);
   308				} else {
   309					dw_readl(dev, DW_IC_CLR_RD_REQ);
   310					dw_readl(dev, DW_IC_CLR_RX_UNDER);
   311					stat = i2c_dw_read_clear_intrbits_slave(dev);
   312				}
   313				if (!i2c_slave_event(dev->slave,
 > 314						 I2C_SLAVE_READ_REQUESTED, &val))
   315					dw_writel(dev, val, DW_IC_DATA_CMD);
   316			}
   317		}
   318	
   319		if (stat & DW_IC_INTR_RX_DONE) {
 > 320			if (!i2c_slave_event(dev->slave, I2C_SLAVE_READ_PROCESSED,
   321			 &val))
   322				dw_readl(dev, DW_IC_CLR_RX_DONE);
   323	
 > 324			i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
   325			stat = i2c_dw_read_clear_intrbits_slave(dev);
   326			return true;
   327		}
   328	
   329		if (stat & DW_IC_INTR_RX_FULL) {
   330			val = dw_readl(dev, DW_IC_DATA_CMD);
   331			if (!i2c_slave_event(dev->slave, I2C_SLAVE_WRITE_RECEIVED,
   332			 &val))
   333				dev_dbg(dev->dev, "Byte %X acked! ", val);
   334		} else {
   335			i2c_slave_event(dev->slave, I2C_SLAVE_STOP, &val);
   336			stat = i2c_dw_read_clear_intrbits_slave(dev);
   337		}
   338	
   339		if (stat & DW_IC_INTR_TX_OVER) {
   340			dw_readl(dev, DW_IC_CLR_TX_OVER);
   341			return true;
   342		}
   343		return true;
   344	}
   345	
   346	static irqreturn_t i2c_dw_isr_slave(int this_irq, void *dev_id)
   347	{
   348		struct dw_i2c_dev *dev = dev_id;
   349		u32 stat, enabled, mode;
   350	
   351		enabled = dw_readl(dev, DW_IC_ENABLE);
   352		mode = dw_readl(dev, DW_IC_CON);
   353		stat = dw_readl(dev, DW_IC_RAW_INTR_STAT);
   354	
   355		dev_dbg(dev->dev, "%s: enabled=%#x stat=%#x\n", __func__, enabled,
   356		 stat);
   357		if (!enabled || !(stat & ~DW_IC_INTR_ACTIVITY))
   358			return IRQ_NONE;
   359	
   360		stat = i2c_dw_read_clear_intrbits_slave(dev);
   361		if (!i2c_dw_irq_handler_slave(dev))
   362			return IRQ_NONE;
   363	
   364		complete(&dev->cmd_complete);
   365		return IRQ_HANDLED;
   366	}
   367	
   368	static struct i2c_algorithm i2c_dw_algo = {
   369		.functionality	= i2c_dw_func,
 > 370		.reg_slave	= i2c_dw_reg_slave,
 > 371		.unreg_slave	= i2c_dw_unreg_slave,
   372	};
   373	
   374	void i2c_dw_disable_slave(struct dw_i2c_dev *dev)

---
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: 25799 bytes --]

^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 21:54 UTC (permalink / raw)
  To: Rob Herring, Dinh Nguyen
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
	Mark Rutland,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAL_JsqJv7bBmkWUmd44Ln-=PLLKEch+hbjuD8v8ArhOCZ37jdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



On 11/18/2016 12:03 PM, Rob Herring wrote:
> 
> Sorry, didn't send anything out, but the series is already applied if
> you look at -next or PW.
> 

Thanks!

Dinh
--
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: [v3,2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Jyri Sarha @ 2016-11-18 21:33 UTC (permalink / raw)
  To: Christopher Spinrath, dri-devel, devicetree
  Cc: khilman, tomi.valkeinen, laurent.pinchart, bcousson, bgolaszewski
In-Reply-To: <09499db556b444f9aa88aadf0cae4f2d@rwthex-s1-b.rwth-ad.de>

On 11/18/16 07:00, Christopher Spinrath wrote:
> Hi Jyri,
> 
> On 11/17/2016 02:28 PM, Jyri Sarha wrote:
>> Add very basic ti-ftp410 DVI transmitter driver. The only feature
> 
> s/ftp/tfp ?
> 

My fingers just want type these three letter is that order, wonder why :).

>> separating this from a completely dummy bridge is the EDID read
>> support trough DDC I2C. Even that functionality should be in a
>> separate generic connector driver. However, because of missing DRM
>> infrastructure support the connector is implemented within the bridge
>> driver. Some tfp410 HW specific features may be added later if needed,
>> because there is a set of registers behind i2c if it is connected.
>>
>> This implementation is tested against my new tilcdc bridge support
>> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
>> is also added.
>>
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> 
> Thanks for working on this. I have tested the driver on my Utilite Pro
> which is based on the imx6q SoC and has a tfp410 chip hooked up to its
> parallel rgb24 interface. So you can add my
> 
> Tested-By: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
> 

Thanks, I'll address these comments and resend the corrected patches
before sending a pull request.

> However, I have two more comments below.
> 
>> ---
>>  .../bindings/display/bridge/ti,tfp410.txt          |  40 +++
>>  drivers/gpu/drm/bridge/Kconfig                     |   7 +
>>  drivers/gpu/drm/bridge/Makefile                    |   1 +
>>  drivers/gpu/drm/bridge/ti-tfp410.c                 | 287 +++++++++++++++++++++
>>  4 files changed, 335 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>>  create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>> new file mode 100644
>> index 0000000..6174b18
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> 
> There already is a binding documentation for the tfp410 in
> 
>   Documentation/devicetree/bindings/display/ti/ti,tfp410.txt .
> 
> It is used by the omap drm driver. IMHO you should extend, move or
> deprecate that one. Note that it describes an optional powerdown-gpios
> property.
> 

Good that you noticed that. Guess we need to unify those. Probably to
the new location under bridge directory.

>> @@ -0,0 +1,40 @@
>> +TFP410 DVI bridge bindings
>> +
>> +Required properties:
>> +	- compatible: "ti,tfp410"
>> +
>> +Optional properties
>> +	- reg: I2C address. If and only if present the device node
>> +	  should be placed into the i2c controller node where the
>> +	  tfp410 i2c is connected to.
>> +
>> +Required subnodes:
>> +	- port@0: Video input port node to connect the bridge to a
>> +	  display controller output [1].
>> +	- port@1: Video output port node to connect the bridge to a
>> +	  connector input [1].
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +	hdmi-bridge {
>> +		compatible = "ti,tfp410";
>> +		ports {
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +
>> +			port@0 {
>> +				reg = <0>;
>> +				bridge_in: endpoint {
>> +					remote-endpoint = <&dc_out>;
>> +				};
>> +			};
>> +
>> +			port@1 {
>> +				reg = <1>;
>> +				bridge_out: endpoint {
>> +					remote-endpoint = <&hdmi_in>;
>> +				};
>> +			};
>> +		};
>> +	};
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index bd6acc8..a424e03 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
>>  	---help---
>>  	  Toshiba TC358767 eDP bridge chip driver.
>>  
>> +config DRM_TI_TFP410
>> +	tristate "TI TFP410 DVI/HDMI bridge"
>> +	depends on OF
>> +	select DRM_KMS_HELPER
>> +	---help---
>> +	  Texas Instruments TFP410 DVI/HDMI Transmitter driver
>> +
>>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>>  
>>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
>> index 97ed1a5..8b065d9 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
>>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
>> +obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
>> new file mode 100644
>> index 0000000..64f54e4
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>> @@ -0,0 +1,287 @@
>> +/*
>> + * Copyright (C) 2016 Texas Instruments
>> + * Author: Jyri Sarha <jsarha@ti.com>
>> + *
>> + * 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/module.h>
>> +#include <linux/of_graph.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/i2c.h>
>> +
>> +#include <drm/drmP.h>
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_crtc.h>
>> +#include <drm/drm_crtc_helper.h>
>> +
>> +struct tfp410 {
>> +	struct drm_bridge	bridge;
>> +	struct drm_connector	connector;
>> +
>> +	struct i2c_adapter	*ddc;
>> +
>> +	struct device *dev;
>> +};
>> +
>> +static inline struct tfp410 *
>> +drm_bridge_to_tfp410(struct drm_bridge *bridge)
>> +{
>> +	return container_of(bridge, struct tfp410, bridge);
>> +}
>> +
>> +static inline struct tfp410 *
>> +drm_connector_to_tfp410(struct drm_connector *connector)
>> +{
>> +	return container_of(connector, struct tfp410, connector);
>> +}
>> +
>> +static int tfp410_get_modes(struct drm_connector *connector)
>> +{
>> +	struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>> +	struct edid *edid;
>> +	int ret;
>> +
>> +	if (!dvi->ddc)
>> +		goto fallback;
>> +
>> +	edid = drm_get_edid(connector, dvi->ddc);
>> +	if (!edid) {
>> +		DRM_INFO("EDID read failed. Fallback to standard modes\n");
>> +		goto fallback;
>> +	}
>> +
>> +	drm_mode_connector_update_edid_property(connector, edid);
>> +
>> +	return drm_add_edid_modes(connector, edid);
>> +fallback:
>> +	/* No EDID, fallback on the XGA standard modes */
>> +	ret = drm_add_modes_noedid(connector, 1920, 1200);
>> +
>> +	/* And prefer a mode pretty much anything can handle */
>> +	drm_set_preferred_mode(connector, 1024, 768);
>> +
>> +	return ret;
>> +}
>> +
>> +static const struct drm_connector_helper_funcs tfp410_con_helper_funcs = {
>> +	.get_modes	= tfp410_get_modes,
>> +};
>> +
>> +static enum drm_connector_status
>> +tfp410_connector_detect(struct drm_connector *connector, bool force)
>> +{
>> +	struct tfp410 *dvi = drm_connector_to_tfp410(connector);
>> +
>> +	if (dvi->ddc) {
>> +		if (drm_probe_ddc(dvi->ddc))
>> +			return connector_status_connected;
>> +		else
>> +			return connector_status_disconnected;
>> +	}
> 
> I wonder what happens if a display with none or defect ddc/edid is
> attached? The dumb-vga-dac bridge driver reports
> connector_status_unknown in the case drm_probe_ddc fails.
> 

If there is such a problem with DVI/HDMI device, then the device is
clearly broken. In such a case one can hack a custom dtd file without
ddc-i2c-bus. The situation with VGA is slightly different. There may
still be some perfectly legitimate legacy VGA devices that do not
support ddc.

I do not have a strong opinion about this, but would like to wait if
anybody is bothered about this behaviour and fix it only if there is a
problem.

> Cheers,
> Christopher
> 
>> +
>> +	return connector_status_unknown;
>> +}
>> +
>> +static const struct drm_connector_funcs tfp410_con_funcs = {
>> +	.dpms			= drm_atomic_helper_connector_dpms,
>> +	.detect			= tfp410_connector_detect,
>> +	.fill_modes		= drm_helper_probe_single_connector_modes,
>> +	.destroy		= drm_connector_cleanup,
>> +	.reset			= drm_atomic_helper_connector_reset,
>> +	.atomic_duplicate_state	= drm_atomic_helper_connector_duplicate_state,
>> +	.atomic_destroy_state	= drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +static int tfp410_attach(struct drm_bridge *bridge)
>> +{
>> +	struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
>> +	int ret;
>> +
>> +	if (!bridge->encoder) {
>> +		dev_err(dvi->dev, "Missing encoder\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	drm_connector_helper_add(&dvi->connector,
>> +				 &tfp410_con_helper_funcs);
>> +	ret = drm_connector_init(bridge->dev, &dvi->connector,
>> +				 &tfp410_con_funcs, DRM_MODE_CONNECTOR_HDMIA);
>> +	if (ret) {
>> +		dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	drm_mode_connector_attach_encoder(&dvi->connector,
>> +					  bridge->encoder);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>> +	.attach		= tfp410_attach,
>> +};
>> +
>> +static int tfp410_get_connector_ddc(struct tfp410 *dvi)
>> +{
>> +	struct device_node *ep = NULL, *connector_node = NULL;
>> +	struct device_node *ddc_phandle = NULL;
>> +	int ret = 0;
>> +
>> +	/* port@1 is the connector node */
>> +	ep = of_graph_get_endpoint_by_regs(dvi->dev->of_node, 1, -1);
>> +	if (!ep)
>> +		goto fail;
>> +
>> +	connector_node = of_graph_get_remote_port_parent(ep);
>> +	if (!connector_node)
>> +		goto fail;
>> +
>> +	ddc_phandle = of_parse_phandle(connector_node, "ddc-i2c-bus", 0);
>> +	if (!ddc_phandle)
>> +		goto fail;
>> +
>> +	dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
>> +	if (dvi->ddc)
>> +		dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
>> +	else
>> +		ret = -EPROBE_DEFER;
>> +
>> +fail:
>> +	of_node_put(ep);
>> +	of_node_put(connector_node);
>> +	of_node_put(ddc_phandle);
>> +	return ret;
>> +}
>> +
>> +static int tfp410_init(struct device *dev)
>> +{
>> +	struct tfp410 *dvi;
>> +	int ret;
>> +
>> +	if (!dev->of_node) {
>> +		dev_err(dev, "device-tree data is missing\n");
>> +		return -ENXIO;
>> +	}
>> +
>> +	dvi = devm_kzalloc(dev, sizeof(*dvi), GFP_KERNEL);
>> +	if (!dvi)
>> +		return -ENOMEM;
>> +	dev_set_drvdata(dev, dvi);
>> +
>> +	dvi->bridge.funcs = &tfp410_bridge_funcs;
>> +	dvi->bridge.of_node = dev->of_node;
>> +	dvi->dev = dev;
>> +
>> +	ret = tfp410_get_connector_ddc(dvi);
>> +	if (ret)
>> +		goto fail;
>> +
>> +	ret = drm_bridge_add(&dvi->bridge);
>> +	if (ret) {
>> +		dev_err(dev, "drm_bridge_add() failed: %d\n", ret);
>> +		goto fail;
>> +	}
>> +
>> +	return 0;
>> +fail:
>> +	i2c_put_adapter(dvi->ddc);
>> +	return ret;
>> +}
>> +
>> +static int tfp410_fini(struct device *dev)
>> +{
>> +	struct tfp410 *dvi = dev_get_drvdata(dev);
>> +
>> +	drm_bridge_remove(&dvi->bridge);
>> +
>> +	if (dvi->ddc)
>> +		i2c_put_adapter(dvi->ddc);
>> +
>> +	return 0;
>> +}
>> +
>> +static int tfp410_probe(struct platform_device *pdev)
>> +{
>> +	return tfp410_init(&pdev->dev);
>> +}
>> +
>> +static int tfp410_remove(struct platform_device *pdev)
>> +{
>> +	return tfp410_fini(&pdev->dev);
>> +}
>> +
>> +/* There is currently no i2c functionality. */
>> +static int tfp410_i2c_probe(struct i2c_client *client,
>> +			    const struct i2c_device_id *id)
>> +{
>> +	int reg;
>> +
>> +	if (!client->dev.of_node ||
>> +	    of_property_read_u32(client->dev.of_node, "reg", &reg)) {
>> +		dev_err(&client->dev,
>> +			"Can't get i2c reg property from device-tree\n");
>> +		return -ENXIO;
>> +	}
>> +
>> +	return tfp410_init(&client->dev);
>> +}
>> +
>> +static int tfp410_i2c_remove(struct i2c_client *client)
>> +{
>> +	return tfp410_fini(&client->dev);
>> +}
>> +
>> +static const struct of_device_id tfp410_match[] = {
>> +	{ .compatible = "ti,tfp410" },
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(of, tfp410_match);
>> +
>> +struct platform_driver tfp410_platform_driver = {
>> +	.probe	= tfp410_probe,
>> +	.remove	= tfp410_remove,
>> +	.driver	= {
>> +		.name		= "tfp410-bridge",
>> +		.of_match_table	= tfp410_match,
>> +	},
>> +};
>> +
>> +static const struct i2c_device_id tfp410_i2c_ids[] = {
>> +	{ "tfp410", 0 },
>> +	{ }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, tfp410_i2c_ids);
>> +
>> +static struct i2c_driver tfp410_i2c_driver = {
>> +	.driver = {
>> +		.name	= "tfp410",
>> +		.of_match_table = of_match_ptr(tfp410_match),
>> +	},
>> +	.id_table	= tfp410_i2c_ids,
>> +	.probe		= tfp410_i2c_probe,
>> +	.remove		= tfp410_i2c_remove,
>> +};
>> +
>> +static int __init tfp410_module_init(void)
>> +{
>> +	i2c_add_driver(&tfp410_i2c_driver);
>> +	platform_driver_register(&tfp410_platform_driver);
>> +
>> +	return 0;
>> +}
>> +module_init(tfp410_module_init);
>> +
>> +static void __exit tfp410_module_exit(void)
>> +{
>> +	i2c_del_driver(&tfp410_i2c_driver);
>> +	platform_driver_unregister(&tfp410_platform_driver);
>> +}
>> +module_exit(tfp410_module_exit);
>> +
>> +MODULE_AUTHOR("Jyri Sarha <jsarha@ti.com>");
>> +MODULE_DESCRIPTION("TI TFP410 DVI bridge driver");
>> +MODULE_LICENSE("GPL");
>>
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-18 20:22 UTC (permalink / raw)
  To: Sudeep Holla, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring
  Cc: Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <075d4718-8cd2-e390-b755-bc24e7497eae-5wv7dgnIgG8@public.gmane.org>

On 11/18/16 02:41, Sudeep Holla wrote:
> 
> 
> On 17/11/16 21:00, Frank Rowand wrote:
>> On 11/17/16 07:32, Sudeep Holla wrote:
>>> Currently platforms/drivers needing to get the machine model name are
>>> replicating the same snippet of code. In some case, the OF reference
>>> counting is either missing or incorrect.
>>>
>>> This patch adds support to read the machine model name either using
>>> the "model" or the "compatible" property in the device tree root node
>>> to the core OF/DT code.
>>>
>>> This can be used to remove all the duplicate code snippets doing exactly
>>> same thing later.
>>
>> I find five instances of reading only property "model":
>>
>>   arch/arm/mach-imx/cpu.c
>>   arch/arm/mach-mxs/mach-mxs.c
>>   arch/c6x/kernel/setup.c
>>   arch/mips/cavium-octeon/setup.c
>>   arch/sh/boards/of-generic.c
>>
> 
> Ah sorry you were not Cc-ed in 2/2, but that shows all the instances
> that this will be used for.

I have not seen 2/2.  I do not see it on the devicetree list or on lkml.

I did see a list of drivers in the RFC patch that you sent several hours
before this patch.

In that patch you replaced reading the model name from the _flat_ device
tree with the new function in at least one location.  That is not
correct.


> 
>> I find one instance of reading property "model", then if
>> that does not exist, property "compatible":
>>
>>   arch/mips/generic/proc.c
>>
> 
> Correct as you can check in patch 2/2
> 
>> The proposed patch matches the code used in one place, and thus
>> current usage does not match the patch description.
>>
> 
> Yes, but does it matter ? compatibles are somewhat informative about the
> model IMO.

Yes it does matter.  That is just sloppy and makes devicetree yet harder
to understand.  It hurts clarity.  The new function name says get "model",
not get "model" or "first element of the compatible list".

And using the _first_ element only of the compatible list to determine
model is not a good paradigm.  It is yet another hidden, special case,
undocumented trap to lure in the unwary.

It is extremely unlikely that the change actually changes behavior for an
existing device tree because there is probably no dts that does not
contain the model property but does contain the proper magic value in
the compatible property.  But did you actually check for that?

> 
>> Is my search bad?  Are you planning to add additional instances
>> of reading "model" then "compatible"?
>>
> 
> No, just replacing the existing ones as in patch 2/2
> 

You also ignored Arnd's comment in reply to your RFC patch.

-Frank

--
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] mmc: pwrseq: add support for Marvell SD8787 chip
From: Tony Lindgren @ 2016-11-18 20:19 UTC (permalink / raw)
  To: Matt Ranostay
  Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mmc-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Mark Rutland,
	Srinivas Kandagatla
In-Reply-To: <1479434109-8745-1-git-send-email-matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org>

* Matt Ranostay <matt-sk+viVC6FLCDq+mSdOJa79kegs52MxvZ@public.gmane.org> [161117 17:55]:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.

Good to see this happening:

Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

^ permalink raw reply

* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Christian Lamparter @ 2016-11-18 20:18 UTC (permalink / raw)
  To: Rob Herring
  Cc: Stefan Wahren, John Youn, Felipe Balbi,
	linux-usb-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
	Christian Lamparter
In-Reply-To: <20161118141608.r7jsu7pfc4ztjt33@rob-hp-laptop>

On Friday, November 18, 2016 8:16:08 AM CET Rob Herring wrote:
> On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
> > Hi John,
> > 
> > Am 17.11.2016 um 00:47 schrieb John Youn:
> > > Add the "snps,ahb-burst" binding and read it in.
> > >
> > > This property controls which burst type to perform on the AHB bus as a
> > > master in internal DMA mode. This overrides the legacy param value,
> > > which we need to keep around for now since several platforms use it.
> > >
> > > Some platforms may see better or worse performance based on this
> > > value. The HAPS platform is one example where all INCRx have worse
> > > performance than INCR.
> > >
> > > Other platforms (such as the Canyonlands board) report that the default
> > > value causes system hangs.
> > >
> > > Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> > > Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > > ---
> > >  Documentation/devicetree/bindings/usb/dwc2.txt |  2 +
> > >  drivers/usb/dwc2/core.h                        |  9 +++++
> > >  drivers/usb/dwc2/params.c                      | 56 ++++++++++++++++++++++++++
> > >  3 files changed, 67 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> > > index 6c7c2bce..9e7b4b4 100644
> > > --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> > > +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> > 
> > according to Documentation/devicetree/bindings/submitting-patches.txt
> > this change should be a separate patch.
> > 
> > > @@ -26,6 +26,8 @@ Optional properties:
> > >  Refer to phy/phy-bindings.txt for generic phy consumer properties
> > >  - dr_mode: shall be one of "host", "peripheral" and "otg"
> > >    Refer to usb/generic.txt
> > > +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
> > > +  "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
> > 
> > This doesn't apply in case of the bcm2835. I would prefer this option is
> > ignored in that case with a dev_warn("snps,ahb-burst is not supported on
> > this platform").
> 
> Also, perhaps you should allow that the compatible string can define the 
> default.
> 
I hoped you would say that :).

I've attached a patch (on top of John Youn changes) that does
just that for the amcc,dwc-otg. I put the GAHBCFG_HBSTLEN_INCR
value into the .data, if that's a problem, I can certainly 
respin the patch and put it in a dedicated struct.

Regards

Christian
---
>From 4c31a029dde714828810b1c3e61a5b1412ac939a Mon Sep 17 00:00:00 2001
From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Fri, 18 Nov 2016 21:03:19 +0100
Subject: [PATCH] usb: dwc2: add a default ahb-burst setting for amcc,dwc-otg

This patch adds a of_device_id table which can be used by
existing devices to supply a ahb-burst value for the platform
without having to add a "snps,ahb-burst" entry to the dts.

Note: Adding new devices to this table is discouraged.
      please consider adding the "snps,ahb-burst" property
      with the correct configuration to your device tree
      file instead.

Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/usb/dwc2/params.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index e0fc9aa..51be266 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -1097,6 +1097,22 @@ static const char *const ahb_bursts[] = {
 	[GAHBCFG_HBSTLEN_INCR16]	= "INCR16",
 };
 
+/*
+ * This table provides AHB burst configuration for existing
+ * device tree bindings that work poorly with the default setting.
+ *
+ * Note: Adding new devices to this table is discouraged.
+ *	 please consider adding the "snps,ahb-burst" property
+ *	 with the correct configuration to your device tree
+ *	 file instead.
+ */
+static const struct of_device_id dwc2_compat_ahb_bursts[] = {
+	{
+		.compatible = "amcc,dwc-otg",
+		.data = (void *) GAHBCFG_HBSTLEN_INCR16,
+	},
+};
+
 static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
 {
 	struct device_node *node = hsotg->dev->of_node;
@@ -1107,6 +1123,12 @@ static int dwc2_get_property_ahb_burst(struct dwc2_hsotg *hsotg)
 	ret = device_property_read_string(hsotg->dev,
 					  "snps,ahb-burst", &str);
 	if (ret < 0) {
+		const struct of_device_id *match;
+
+		match = of_match_node(dwc2_compat_ahb_bursts, node);
+		if (match)
+			ret = (int)match->data;
+
 		return ret;
 	} else if (of_device_is_compatible(node, "brcm,bcm2835-usb")) {
 		dev_warn(hsotg->dev,
-- 
2.10.2





--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH] arm64: dts: qcom: msm8996: Fixup smp2p node
From: Bjorn Andersson @ 2016-11-18 20:06 UTC (permalink / raw)
  To: Andy Gross
  Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
	linux-soc-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA

The SMEM state property name changes between the integration branch and
mainline, update to use the correct one.

Fixes: 2f45d9fcd531 ("arm64: dts: msm8996: Add SMP2P and APCS nodes")
Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---

Seems we're still carrying this discrepancy somewhere and I missed it in my
review, sorry about that.

 arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index cde4114bae5a..712d5d043105 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -530,7 +530,7 @@
 
 		adsp_smp2p_out: master-kernel {
 			qcom,entry-name = "master-kernel";
-			#qcom,state-cells = <1>;
+			#qcom,smem-state-cells = <1>;
 		};
 
 		adsp_smp2p_in: slave-kernel {
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH 1/2] of: base: add support to get machine model name
From: Frank Rowand @ 2016-11-18 20:00 UTC (permalink / raw)
  To: Rob Herring, Sudeep Holla
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Arnd Bergmann,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118144651.275xz4gu6jaefhp7@rob-hp-laptop>

On 11/18/16 06:46, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 03:32:54PM +0000, Sudeep Holla wrote:
>> Currently platforms/drivers needing to get the machine model name are
>> replicating the same snippet of code. In some case, the OF reference
>> counting is either missing or incorrect.
>>
>> This patch adds support to read the machine model name either using
>> the "model" or the "compatible" property in the device tree root node
>> to the core OF/DT code.
>>
>> This can be used to remove all the duplicate code snippets doing exactly
>> same thing later.
>>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>>  drivers/of/base.c  | 32 ++++++++++++++++++++++++++++++++
>>  include/linux/of.h |  6 ++++++
>>  2 files changed, 38 insertions(+)
>>
>> Hi Rob,
>>
>> It would be good if we can target this for v4.10, so that we have no
>> dependencies to push PATCH 2/2 in v4.11
> 
> Applied.
> 
> Rob
> 

A little fast on the trigger Rob.

-Frank
--
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 1/3] dt-bindings: firmware: scm: Add MSM8996 DT bindings
From: Bjorn Andersson @ 2016-11-18 19:55 UTC (permalink / raw)
  To: Sarangdhar Joshi
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, linux-arm-msm, linux-soc,
	devicetree, linux-arm-kernel, linux-kernel, Jordan Crouse,
	Stephen Boyd, Trilok Soni
In-Reply-To: <1479259165-1601-2-git-send-email-spjoshi@codeaurora.org>

On Tue 15 Nov 17:19 PST 2016, Sarangdhar Joshi wrote:

> Add SCM DT bindings for Qualcomm's MSM8996 platform.
> 
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>

Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> ---
>  Documentation/devicetree/bindings/firmware/qcom,scm.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> index 3b4436e..20f26fb 100644
> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
> @@ -10,8 +10,10 @@ Required properties:
>   * "qcom,scm-apq8064" for APQ8064 platforms
>   * "qcom,scm-msm8660" for MSM8660 platforms
>   * "qcom,scm-msm8690" for MSM8690 platforms
> + * "qcom,scm-msm8996" for MSM8996 platforms
>   * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
>  - clocks: One to three clocks may be required based on compatible.
> + * No clock required for "qcom,scm-msm8996"
>   * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
>   * Core, iface, and bus clocks required for "qcom,scm"
>  - clock-names: Must contain "core" for the core clock, "iface" for the interface
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox