* Re: [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eduardo Valentin @ 2016-11-19 4:22 UTC (permalink / raw)
To: kernel-TqfNSX0MhmxHKSADF0wUEw
Cc: Zhang Rui, Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Lee Jones, Eric Anholt, Russell King, Florian Fainelli,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <7957B3CC-0E18-4B27-82EB-EF88B7695E28-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
Hello Martin,
Thanks for your patience to take the time to explain to me how the
firmware/linux split is done in your platform. Still, one thing is not
clear to me.
On Fri, Nov 18, 2016 at 09:32:47AM +0100, kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org wrote:
>
> The way that firmware works on the RPI is quite different from most others I guess.
> in principle you got 2 different CPUs on the bcm2835:
> * ARM, which runs the linux instance
> * VideoCore 4, which runs the firmware (loading from SD initially) and
> then booting the ARM.
>
> So this Firmware on VC4 is the one that I am talking about.
> Without the working firmware linux can not boot on arm.
Given that "without the working firmware linux can not boot on arm",
(...)
> As far as I understand the conversion is continuous (as soon as the HW is
> configured). This case is there primarily to handle the situation where
> we initialize the HW ourselves (see line 226 and below), and we immediately
and around line 226 we have the comment:
+ /*
+ * right now the FW does set up the HW-block, so we are not
+ * touching the configuration registers.
+ * But if the HW is not enabled, then set it up
+ * using "sane" values used by the firmware right now.
+ */
> want to read the ADC value before the first conversion is finished.
>
then, does the firmware initializes the device or not?
What are the cases you would load this driver but still get an
uninitialized device? That looks like some bug workaround hidden
somewhere. Do system integrators/engineers need to be aware of this w/a?
Would the driver work right aways when the subsystem is loaded during
boot? How about module insertion?
Who has the ownership of this device?
> The above mentioned “configuration if not running” reflect the values that
> the FW is currently setting. We should not change those values as long as the
> Firmware is also reading the temperature on its own.
hmm.. that looks like racy to me. Again, How do you synchronize accesses to
this device? What if you configure the device and right after the
firmware updates the configs? How do you make sure the configs you are
writing here are the same used by the firmware? What if the firmware
version changes? What versions of the firmware does this driver support?
Would it make sense to simply always initialize the device? Do you have
a way to tell the firmware that it should not use the device?
Or, if you want to keep the device driver simply being a dummy reader,
would it make sense to simply avoid writing configurations to the
device, and simply retry to check if the firmware gets the device
initialized?
>
> >
> >> So do you need another version of the patchset that uses that new API?
> >
> > I think the API usage is change that can be done together with
> > clarification for the above questions too: on hardware state,
> > firmware loading, maybe a master driver dependency, and the ADC
> > conversion sequence, which are not well clear to me on this driver. As long as
> > this is clarified and documented in the code (can be simple comments so
> > it is clear to whoever reads in the future), then I would be OK with
> > this driver.
>
> So how do you want this to get “documented” in the driver?
> The setup and Firmware is a generic feature of the SOC, so if we would put
> some clarifications in this driver, then we would need to put it in every
> bcm283X driver (which seems unreasonable).
>
I think a simple comment explaining the firmware dependency and the
expected pre-conditions to get this driver working in a sane state would
do it.
A better device initialization would also be appreciated. Based on my
limited understanding of this platform, and your explanations, this
device seams to have a serious race condition with firmware while
accessing this device.
> Thanks,
> Martin
--
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 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", ®)) {
>> + 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox