* [PATCH v2 8/8] ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA bridge
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The Hummingbird A31 board has a RGB-to-VGA bridge which converts RGB
output from the LCD interface to VGA signals.
Enable this part of the display pipeline.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 +++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 9a74637f677f..05a49b2147f1 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -63,6 +63,49 @@
stdout-path = "serial0:115200n8";
};
+ bridge {
+ compatible = "dumb-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 */
@@ -245,6 +288,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd0_rgb888_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 7/8] ARM: dts: sun6i: Add A31 LCD0 RGB888 pins
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The LCD0 controller on the A31 can do RGB output up to 8 bits per
channel. Add the pins for RGB888 output.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 4d2c7786b92a..2e8bf93dcfb2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -540,6 +540,19 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ lcd0_rgb888_pins: lcd0_rgb888 {
+ allwinner,pins = "PD0", "PD1", "PD2", "PD3",
+ "PD4", "PD5", "PD6", "PD7",
+ "PD8", "PD9", "PD10", "PD11",
+ "PD12", "PD13", "PD14", "PD15",
+ "PD16", "PD17", "PD18", "PD19",
+ "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ allwinner,function = "lcd0";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
mmc0_pins_a: mmc0 at 0 {
allwinner,pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/8] ARM: dts: sun6i: Add device nodes for first display pipeline
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The A31 has 2 parallel display pipelines, which can be intermixed.
However the driver currently only supports one of them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 152 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/sun6i-a31s.dtsi | 8 ++
2 files changed, 160 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c1b891e75f18..4d2c7786b92a 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -231,6 +231,11 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun6i-a31-display-engine";
+ allwinner,pipelines = <&fe0>;
+ };
+
soc at 01c00000 {
compatible = "simple-bus";
#address-cells = <1>;
@@ -246,6 +251,44 @@
#dma-cells = <1>;
};
+ tcon0: lcd-controller at 01c0c000 {
+ compatible = "allwinner,sun6i-a31-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&ccu RST_AHB1_LCD0>;
+ reset-names = "lcd";
+ clocks = <&ccu CLK_AHB1_LCD0>,
+ <&ccu CLK_LCD0_CH0>,
+ <&ccu CLK_LCD0_CH1>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon0-pixel-clock";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_drc0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&drc0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc at 01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -799,6 +842,115 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ fe0: display-frontend at 01e00000 {
+ compatible = "allwinner,sun6i-a31-display-frontend";
+ reg = <0x01e00000 0x20000>;
+ interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_FE0>, <&ccu CLK_FE0>,
+ <&ccu CLK_DRAM_FE0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_FE0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe0_out_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend at 01e60000 {
+ compatible = "allwinner,sun6i-a31-display-backend";
+ reg = <0x01e60000 0x10000>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_BE0>, <&ccu CLK_BE0>,
+ <&ccu CLK_DRAM_BE0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_BE0>;
+
+ assigned-clocks = <&ccu CLK_BE0>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ be0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ be0_in_fe0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&fe0_out_be0>;
+ };
+ };
+
+ be0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ be0_out_drc0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&drc0_in_be0>;
+ };
+ };
+ };
+ };
+
+ drc0: drc at 01e70000 {
+ compatible = "allwinner,sun6i-a31-drc";
+ reg = <0x01e70000 0x10000>;
+ interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_AHB1_DRC0>, <&ccu CLK_IEP_DRC0>,
+ <&ccu CLK_DRAM_DRC0>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_DRC0>;
+
+ assigned-clocks = <&ccu CLK_IEP_DRC0>;
+ assigned-clock-rates = <300000000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ drc0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ drc0_in_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&be0_out_drc0>;
+ };
+ };
+
+ drc0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ drc0_out_tcon0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_in_drc0>;
+ };
+ };
+ };
+ };
+
rtc: rtc at 01f00000 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f00000 0x54>;
diff --git a/arch/arm/boot/dts/sun6i-a31s.dtsi b/arch/arm/boot/dts/sun6i-a31s.dtsi
index c17a32771b98..97e2c51d0aea 100644
--- a/arch/arm/boot/dts/sun6i-a31s.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31s.dtsi
@@ -48,6 +48,14 @@
#include "sun6i-a31.dtsi"
+&de {
+ compatible = "allwinner,sun6i-a31s-display-engine";
+};
+
&pio {
compatible = "allwinner,sun6i-a31s-pinctrl";
};
+
+&tcon0 {
+ compatible = "allwinner,sun6i-a31s-tcon";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/8] drm/sun4i: Add compatible strings for A31/A31s display pipelines
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
also has new display enhancement blocks, such as the DRC (Dynamic Range
Controller), the DEU (Display Enhancement Unit), and the CMU (Color
Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
The A31s display pipeline is almost the same, just without MIPI DSI.
Only the TCON seems to be different, due to the missing mux for MIPI
DSI.
Add compatible strings for both of them.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 ++++
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +++
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 15fdca8909f2..b82c00449468 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -91,6 +91,7 @@ system.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-backend
+ * allwinner,sun6i-a31-display-backend
* allwinner,sun8i-a33-display-backend
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the frontend and backend
@@ -121,6 +122,7 @@ deinterlacing and color space conversion.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-frontend
+ * allwinner,sun6i-a31-display-frontend
* allwinner,sun8i-a33-display-frontend
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
@@ -146,6 +148,8 @@ extra node.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-engine
+ * allwinner,sun6i-a31-display-engine
+ * allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
- allwinner,pipelines: list of phandle to the display engine
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 32c0584e3c35..6e6c59a661b6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -408,6 +408,7 @@ static int sun4i_backend_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_backend_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-backend" },
+ { .compatible = "allwinner,sun6i-a31-display-backend" },
{ .compatible = "allwinner,sun8i-a33-display-backend" },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a15c231fbd59..fa6568e1822a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -201,6 +201,7 @@ static const struct component_master_ops sun4i_drv_master_ops = {
static bool sun4i_drv_node_is_frontend(struct device_node *node)
{
return of_device_is_compatible(node, "allwinner,sun5i-a13-display-frontend") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31-display-frontend") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-display-frontend");
}
@@ -324,6 +325,8 @@ static int sun4i_drv_remove(struct platform_device *pdev)
static const struct of_device_id sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-display-engine" },
+ { .compatible = "allwinner,sun6i-a31-display-engine" },
+ { .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
{ }
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/8] drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The A31 TCON has mux controls for how TCON outputs are routed to the
HDMI and MIPI DSI blocks.
Since the A31s does not have MIPI DSI, it only has a mux for the HDMI
controller input.
This patch only adds support for the compatible strings. Actual support
for the mux controls should be added with HDMI and MIPI DSI support.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 10 ++++++++++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 5368961cd727..15fdca8909f2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -28,6 +28,8 @@ The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
Required properties:
- compatible: value must be either:
* allwinner,sun5i-a13-tcon
+ * allwinner,sun6i-a31-tcon
+ * allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
@@ -50,7 +52,7 @@ Required properties:
second the block connected to the TCON channel 1 (usually the TV
encoder)
-On the A13, there is one more clock required:
+On SoCs other than the A33, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
DRC
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 0da9862ad8ed..a15c231fbd59 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -207,6 +207,8 @@ static bool sun4i_drv_node_is_frontend(struct device_node *node)
static bool sun4i_drv_node_is_tcon(struct device_node *node)
{
return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-tcon");
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 7658f0337e0b..c6afb2448655 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -587,12 +587,22 @@ static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
.has_channel_1 = true,
};
+static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
+ .has_channel_1 = true,
+};
+
+static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
+ .has_channel_1 = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
/* nothing is supported */
};
static const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
+ { .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks },
+ { .compatible = "allwinner,sun6i-a31s-tcon", .data = &sun6i_a31s_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ }
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/8] drm/sun4i: tcon: Move SoC specific quirks to a DT matched data structure
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
We already have some differences between the 2 supported SoCs.
More will be added as we support other SoCs. To avoid bloating
the probe function with even more conditionals, move the quirks
to a separate data structure that's tied to the compatible string.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 33 ++++++++++++++++++---------------
drivers/gpu/drm/sun4i/sun4i_tcon.h | 11 +++++++----
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index cadacb517f95..7658f0337e0b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -20,6 +20,7 @@
#include <linux/component.h>
#include <linux/ioport.h>
#include <linux/of_address.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/of_irq.h>
#include <linux/regmap.h>
@@ -62,7 +63,7 @@ void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, int channel)
return;
}
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
SUN4I_TCON1_CTL_TCON_ENABLE, 0);
clk_disable_unprepare(tcon->sclk1);
@@ -80,7 +81,7 @@ void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int channel)
return;
}
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
SUN4I_TCON1_CTL_TCON_ENABLE,
SUN4I_TCON1_CTL_TCON_ENABLE);
@@ -202,7 +203,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
u8 clk_delay;
u32 val;
- WARN_ON(!tcon->has_channel_1);
+ WARN_ON(!tcon->quirks->has_channel_1);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 1);
@@ -266,7 +267,7 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
/*
* FIXME: Undocumented bits
*/
- if (tcon->has_mux)
+ if (tcon->quirks->has_unknown_mux)
regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1);
}
EXPORT_SYMBOL(sun4i_tcon1_mode_set);
@@ -327,7 +328,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
return PTR_ERR(tcon->sclk0);
}
- if (tcon->has_channel_1) {
+ if (tcon->quirks->has_channel_1) {
tcon->sclk1 = devm_clk_get(dev, "tcon-ch1");
if (IS_ERR(tcon->sclk1)) {
dev_err(dev, "Couldn't get the TCON channel 1 clock\n");
@@ -487,14 +488,7 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
drv->tcon = tcon;
tcon->drm = drm;
tcon->dev = dev;
-
- if (of_device_is_compatible(dev->of_node, "allwinner,sun5i-a13-tcon")) {
- tcon->has_mux = true;
- tcon->has_channel_1 = true;
- } else {
- tcon->has_mux = false;
- tcon->has_channel_1 = false;
- }
+ tcon->quirks = of_device_get_match_data(dev);
tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
if (IS_ERR(tcon->lcd_rst)) {
@@ -588,9 +582,18 @@ static int sun4i_tcon_remove(struct platform_device *pdev)
return 0;
}
+static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .has_unknown_mux = true,
+ .has_channel_1 = true,
+};
+
+static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ /* nothing is supported */
+};
+
static const struct of_device_id sun4i_tcon_of_table[] = {
- { .compatible = "allwinner,sun5i-a13-tcon" },
- { .compatible = "allwinner,sun8i-a33-tcon" },
+ { .compatible = "allwinner,sun5i-a13-tcon", .data = &sun5i_a13_quirks },
+ { .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 12bd48925f4d..166064bafe2e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -142,6 +142,11 @@
#define SUN4I_TCON_MAX_CHANNELS 2
+struct sun4i_tcon_quirks {
+ bool has_unknown_mux; /* sun5i has undocumented mux */
+ bool has_channel_1; /* a33 does not have channel 1 */
+};
+
struct sun4i_tcon {
struct device *dev;
struct drm_device *drm;
@@ -160,12 +165,10 @@ struct sun4i_tcon {
/* Reset control */
struct reset_control *lcd_rst;
- /* Platform adjustments */
- bool has_mux;
-
struct drm_panel *panel;
- bool has_channel_1;
+ /* Platform adjustments */
+ const struct sun4i_tcon_quirks *quirks;
};
struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/8] drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
The A31 and A31s also have the DRC as part of the display pipeline.
As we know virtually nothing about them, just add compatible strings
for both SoCs to the stub driver.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
drivers/gpu/drm/sun4i/sun6i_drc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index b95696d748c7..5368961cd727 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -64,6 +64,8 @@ adaptive backlight control.
Required properties:
- compatible: value must be one of:
+ * allwinner,sun6i-a31-drc
+ * allwinner,sun6i-a31s-drc
* allwinner,sun8i-a33-drc
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
diff --git a/drivers/gpu/drm/sun4i/sun6i_drc.c b/drivers/gpu/drm/sun4i/sun6i_drc.c
index bf6d846d8132..6ef707c5a719 100644
--- a/drivers/gpu/drm/sun4i/sun6i_drc.c
+++ b/drivers/gpu/drm/sun4i/sun6i_drc.c
@@ -98,6 +98,8 @@ static int sun6i_drc_remove(struct platform_device *pdev)
}
static const struct of_device_id sun6i_drc_of_table[] = {
+ { .compatible = "allwinner,sun6i-a31-drc" },
+ { .compatible = "allwinner,sun6i-a31s-drc" },
{ .compatible = "allwinner,sun8i-a33-drc" },
{ }
};
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-1-wens@csie.org>
Some rgb-to-vga bridges have an enable GPIO, either directly tied to
an enable pin on the bridge IC, or indirectly controlling a power
switch.
Add support for it.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
.../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++++++++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
index 003bc246a270..d3484822bf77 100644
--- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
@@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for RGB input
- Video port 1 for VGA output
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the bridge
Example
-------
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index afec232185a7..b487e5e9b56d 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -10,6 +10,7 @@
* the License, or (at your option) any later version.
*/
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/of_graph.h>
@@ -23,6 +24,7 @@ struct dumb_vga {
struct drm_connector connector;
struct i2c_adapter *ddc;
+ struct gpio_desc *enable_gpio;
};
static inline struct dumb_vga *
@@ -124,8 +126,26 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
return 0;
}
+static void dumb_vga_enable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (vga->enable_gpio)
+ gpiod_set_value_cansleep(vga->enable_gpio, 1);
+}
+
+static void dumb_vga_disable(struct drm_bridge *bridge)
+{
+ struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
+
+ if (vga->enable_gpio)
+ gpiod_set_value_cansleep(vga->enable_gpio, 0);
+}
+
static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
.attach = dumb_vga_attach,
+ .enable = dumb_vga_enable,
+ .disable = dumb_vga_disable,
};
static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
@@ -169,6 +189,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
return -ENOMEM;
platform_set_drvdata(pdev, vga);
+ vga->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(vga->enable_gpio)) {
+ ret = PTR_ERR(vga->enable_gpio);
+ dev_err(&pdev->dev, "failed to request GPIO: %d\n", ret);
+ return ret;
+ }
+
vga->ddc = dumb_vga_retrieve_ddc(&pdev->dev);
if (IS_ERR(vga->ddc)) {
if (PTR_ERR(vga->ddc) == -ENODEV) {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/8] drm/sun4i: Support first display pipeline on sun6i
From: Chen-Yu Tsai @ 2016-10-20 3:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi everyone,
This series adds support for the first display pipeline found on the
A31 and A31s SoCs, with output through the RGB LCD interface.
This has been tested on the Sinlinx SinA31s development board, with
its included 7" LCD panel, and the Merrii Hummingbird A31 development
board, with its dumb VGA DAC bridge.
Changes since v1:
- Made quirk structures static
- Dropped unused/unsupported quirks
- Dropped dotclock max frequency quirk patch.
The check for maximum PLL clock will be moved to the clk driver.
- Changed is_sun5i quirk to has_unknown_mux
- Dropped SinA31s LCD patch
- Added patch to support enable pin GPIO for dumb VGA DACs
- Added patch to enable VGA output via dumb VGA DAC on Hummingbird
A31 board
Regards
ChenYu
Chen-Yu Tsai (8):
drm/bridge: rgb-to-vga: Support an enable GPIO
drm/sun4i: sun6i-drc: Support DRC on A31 and A31s
drm/sun4i: tcon: Move SoC specific quirks to a DT matched data
structure
drm/sun4i: Add compatible string for A31/A31s TCON (timing controller)
drm/sun4i: Add compatible strings for A31/A31s display pipelines
ARM: dts: sun6i: Add device nodes for first display pipeline
ARM: dts: sun6i: Add A31 LCD0 RGB888 pins
ARM: dts: sun6i: hummingbird-a31: Enable display output through VGA
bridge
.../bindings/display/bridge/dumb-vga-dac.txt | 2 +
.../bindings/display/sunxi/sun4i-drm.txt | 10 +-
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 56 +++++++
arch/arm/boot/dts/sun6i-a31.dtsi | 165 +++++++++++++++++++++
arch/arm/boot/dts/sun6i-a31s.dtsi | 8 +
drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++++
drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +
drivers/gpu/drm/sun4i/sun4i_tcon.c | 43 ++++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 11 +-
drivers/gpu/drm/sun4i/sun6i_drc.c | 2 +
11 files changed, 311 insertions(+), 20 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v2 1/4] cpufreq: pxa: use generic platdev driver for device-tree
From: Viresh Kumar @ 2016-10-20 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmyg3xzh.fsf@belgarion.home>
On 19-10-16, 22:06, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> >> >> + { .compatible = "marvell,pxa250", },
> >> >> + { .compatible = "marvell,pxa270", },
> >> >>
> >> >> { .compatible = "samsung,exynos3250", },
> >> >> { .compatible = "samsung,exynos4210", },
> >> >
> >> > Isn't there a race between cpufreq-dt and the platform driver to
> >> > register first ?
> >> Ah, could you be more specific about the race you're talking of ?
> >>
> >> My understanding was that cpufreq-dt-platdev does create the device, and
> >> cpufreq-dt is a driver for it, so there is no race but a direct relationship
> >> AFAIU.
> >
> > I mean that both the driver may try to register to the cpufreq core if
> > they are both compiled in a single image.
> Euh I still don't follow you. The only driver that can register to the cpufreq
> core is cpufreq-dt.
I was wondering on what will happen if both cpufreq-dt and your pxa2xx-cpufreq
driver are present in the same kernel image. In that case the init routines of
both of them will try to call cpufreq_register_driver().
--
viresh
^ permalink raw reply
* FW: RE: [PATCH 0/4] PM / devfreq: Fix module autoload for platform drivers
From: MyungJoo Ham @ 2016-10-20 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161019210645epcas1p449463edf9c3cb3681b0a4e8116ccf7f2@epcas1p4.samsung.com>
> > Hello,
> >
> > I noticed that module autoload won't be working in some of the defreq
> > platform drivers. This patch series contains the fixes for these.
> >
> > Best regards,
> > Javier
> >
> >
> > Javier Martinez Canillas (4):
> > PM / devfreq: rk3399_dmc: Fix module autoload
> > PM / devfreq: exynos-nocp: Fix module autoload
> > PM / devfreq: rockchip-dfi: Fix module autoload
> > PM / devfreq: exynos-ppmu: Fix module autoload
>
> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
>
> All the four are not at for-4.9-rc branch.
not --> now
> https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-4.9-rc
>
>
> Cheers,
> MyungJoo
>
> >
> > drivers/devfreq/event/exynos-nocp.c | 1 +
> > drivers/devfreq/event/exynos-ppmu.c | 1 +
> > drivers/devfreq/event/rockchip-dfi.c | 1 +
> > drivers/devfreq/rk3399_dmc.c | 1 +
> > 4 files changed, 4 insertions(+)
> >
> > --
> > 2.7.4
^ permalink raw reply
* [PATCH 0/4] PM / devfreq: Fix module autoload for platform drivers
From: Chanwoo Choi @ 2016-10-20 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476911187-11040-1-git-send-email-javier@osg.samsung.com>
Hi Javier,
On 2016? 10? 20? 06:06, Javier Martinez Canillas wrote:
> Hello,
>
> I noticed that module autoload won't be working in some of the defreq
> platform drivers. This patch series contains the fixes for these.
>
> Best regards,
> Javier
>
>
> Javier Martinez Canillas (4):
> PM / devfreq: rk3399_dmc: Fix module autoload
> PM / devfreq: exynos-nocp: Fix module autoload
> PM / devfreq: rockchip-dfi: Fix module autoload
> PM / devfreq: exynos-ppmu: Fix module autoload
>
> drivers/devfreq/event/exynos-nocp.c | 1 +
> drivers/devfreq/event/exynos-ppmu.c | 1 +
> drivers/devfreq/event/rockchip-dfi.c | 1 +
> drivers/devfreq/rk3399_dmc.c | 1 +
> 4 files changed, 4 insertions(+)
>
Looks good to me of all patches.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* RE: [PATCH 0/4] PM / devfreq: Fix module autoload for platform drivers
From: MyungJoo Ham @ 2016-10-20 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161019210645epcas1p449463edf9c3cb3681b0a4e8116ccf7f2@epcas1p4.samsung.com>
> Hello,
>
> I noticed that module autoload won't be working in some of the defreq
> platform drivers. This patch series contains the fixes for these.
>
> Best regards,
> Javier
>
>
> Javier Martinez Canillas (4):
> PM / devfreq: rk3399_dmc: Fix module autoload
> PM / devfreq: exynos-nocp: Fix module autoload
> PM / devfreq: rockchip-dfi: Fix module autoload
> PM / devfreq: exynos-ppmu: Fix module autoload
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
All the four are not at for-4.9-rc branch.
https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-4.9-rc
Cheers,
MyungJoo
>
> drivers/devfreq/event/exynos-nocp.c | 1 +
> drivers/devfreq/event/exynos-ppmu.c | 1 +
> drivers/devfreq/event/rockchip-dfi.c | 1 +
> drivers/devfreq/rk3399_dmc.c | 1 +
> 4 files changed, 4 insertions(+)
>
> --
> 2.7.4
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: uniphier: add CPU clocks and OPP tables for LD20 SoC
From: Masahiro Yamada @ 2016-10-20 1:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476926126-6079-1-git-send-email-yamada.masahiro@socionext.com>
Add a CPU clock to every CPU node and CPU OPP tables to use the
generic cpufreq driver. All the CPUs in each cluster share the
same OPP table.
Note:
clock-latency-ns (300ns) was calculated based on the CPU-gear switch
sequencer spec; it takes 12 clock cycles on the sequencer running
at 50 MHz, plus a bit additional latency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Match the node name to the opp-hz property.
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 84 ++++++++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index 6f48e82..7404678 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -79,28 +79,36 @@
device_type = "cpu";
compatible = "arm,cortex-a72", "arm,armv8";
reg = <0 0x000>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a72", "arm,armv8";
reg = <0 0x001>;
+ clocks = <&sys_clk 32>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 100 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x100>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster1_opp>;
};
cpu3: cpu at 101 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x101>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster1_opp>;
};
};
@@ -109,6 +117,82 @@
method = "smc";
};
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 250000000 {
+ opp-hz = /bits/ 64 <250000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 275000000 {
+ opp-hz = /bits/ 64 <275000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 666667000 {
+ opp-hz = /bits/ 64 <666667000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 733334000 {
+ opp-hz = /bits/ 64 <733334000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1100000000 {
+ opp-hz = /bits/ 64 <1100000000>;
+ clock-latency-ns = <300>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 250000000 {
+ opp-hz = /bits/ 64 <250000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 275000000 {
+ opp-hz = /bits/ 64 <275000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 550000000 {
+ opp-hz = /bits/ 64 <550000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 666666666 {
+ opp-hz = /bits/ 64 <666667000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 733333333 {
+ opp-hz = /bits/ 64 <733334000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 1100000000 {
+ opp-hz = /bits/ 64 <1100000000>;
+ clock-latency-ns = <300>;
+ };
+ };
+
clocks {
refclk: ref {
compatible = "fixed-clock";
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: uniphier: add CPU clock and OPP table for LD11 SoC
From: Masahiro Yamada @ 2016-10-20 1:15 UTC (permalink / raw)
To: linux-arm-kernel
Add a CPU clock to every CPU node and a CPU OPP table to use the
generic cpufreq driver.
Note:
clock-latency-ns (300ns) was calculated based on the CPU-gear switch
sequencer spec; it takes 12 clock cycles on the sequencer running
at 50 MHz, plus a bit additional latency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Match the node name to the opp-hz property.
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 38 ++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 73e0acf..bb05f0a 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -70,14 +70,18 @@
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x000>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0 0x001>;
+ clocks = <&sys_clk 33>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
};
@@ -86,6 +90,40 @@
method = "smc";
};
+ cluster0_opp: opp_table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 245000000 {
+ opp-hz = /bits/ 64 <245000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 250000000 {
+ opp-hz = /bits/ 64 <250000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 490000000 {
+ opp-hz = /bits/ 64 <490000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 653334000 {
+ opp-hz = /bits/ 64 <653334000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 666667000 {
+ opp-hz = /bits/ 64 <666667000>;
+ clock-latency-ns = <300>;
+ };
+ opp at 980000000 {
+ opp-hz = /bits/ 64 <980000000>;
+ clock-latency-ns = <300>;
+ };
+ };
+
clocks {
refclk: ref {
compatible = "fixed-clock";
--
1.9.1
^ permalink raw reply related
* [PATCH] ARM: dts: berlin2q-marvell-dmp: fix typo in chosen node
From: Masahiro Yamada @ 2016-10-20 0:52 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index f485308..d57d675 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -48,7 +48,7 @@
reg = <0x00000000 0x80000000>;
};
- choosen {
+ chosen {
bootargs = "earlyprintk";
stdout-path = "serial0:115200n8";
};
--
1.9.1
^ permalink raw reply related
* [arm:clearfog 10/32] drivers/net/ethernet/marvell/mvneta.c:2605:21: warning: unused variable 'ndev'
From: kbuild test robot @ 2016-10-19 23:55 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git clearfog
head: 6c46cbe69a0e915b481458bef1e1e0ab16a7ac0e
commit: e7c1c68827d53e418cad15f86042b5661819152f [10/32] net: mvneta: convert to phylink
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout e7c1c68827d53e418cad15f86042b5661819152f
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_poll':
>> drivers/net/ethernet/marvell/mvneta.c:2605:21: warning: unused variable 'ndev' [-Wunused-variable]
struct net_device *ndev = pp->dev;
^~~~
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_start_dev':
drivers/net/ethernet/marvell/mvneta.c:2917:21: warning: unused variable 'ndev' [-Wunused-variable]
struct net_device *ndev = pp->dev;
^~~~
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_stop_dev':
drivers/net/ethernet/marvell/mvneta.c:2947:21: warning: unused variable 'ndev' [-Wunused-variable]
struct net_device *ndev = pp->dev;
^~~~
drivers/net/ethernet/marvell/mvneta.c: At top level:
drivers/net/ethernet/marvell/mvneta.c:3311:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mac_link_up = mvneta_mac_link_up,
^~~~~~~~~~~~~~~~~~
drivers/net/ethernet/marvell/mvneta.c:3311:17: note: (near initialization for 'mvneta_phylink_ops.mac_link_up')
drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_mdio_remove':
drivers/net/ethernet/marvell/mvneta.c:3325:21: warning: unused variable 'ndev' [-Wunused-variable]
struct net_device *ndev = pp->dev;
^~~~
cc1: some warnings being treated as errors
vim +/ndev +2605 drivers/net/ethernet/marvell/mvneta.c
e7c1c688 Russell King 2015-09-16 2589 phylink_mac_change(pp->phylink, !!(gmac_stat & MVNETA_GMAC_LINK_UP));
898b2970 Stas Sergeev 2015-04-01 2590 }
898b2970 Stas Sergeev 2015-04-01 2591
c5aff182 Thomas Petazzoni 2012-08-17 2592 /* NAPI handler
c5aff182 Thomas Petazzoni 2012-08-17 2593 * Bits 0 - 7 of the causeRxTx register indicate that are transmitted
c5aff182 Thomas Petazzoni 2012-08-17 2594 * packets on the corresponding TXQ (Bit 0 is for TX queue 1).
c5aff182 Thomas Petazzoni 2012-08-17 2595 * Bits 8 -15 of the cause Rx Tx register indicate that are received
c5aff182 Thomas Petazzoni 2012-08-17 2596 * packets on the corresponding RXQ (Bit 8 is for RX queue 0).
c5aff182 Thomas Petazzoni 2012-08-17 2597 * Each CPU has its own causeRxTx register
c5aff182 Thomas Petazzoni 2012-08-17 2598 */
c5aff182 Thomas Petazzoni 2012-08-17 2599 static int mvneta_poll(struct napi_struct *napi, int budget)
c5aff182 Thomas Petazzoni 2012-08-17 2600 {
c5aff182 Thomas Petazzoni 2012-08-17 2601 int rx_done = 0;
c5aff182 Thomas Petazzoni 2012-08-17 2602 u32 cause_rx_tx;
2dcf75e2 Gregory CLEMENT 2015-12-09 2603 int rx_queue;
c5aff182 Thomas Petazzoni 2012-08-17 2604 struct mvneta_port *pp = netdev_priv(napi->dev);
c6c022e3 Philippe Reynes 2016-07-30 @2605 struct net_device *ndev = pp->dev;
12bb03b4 Maxime Ripard 2015-09-25 2606 struct mvneta_pcpu_port *port = this_cpu_ptr(pp->ports);
c5aff182 Thomas Petazzoni 2012-08-17 2607
c5aff182 Thomas Petazzoni 2012-08-17 2608 if (!netif_running(pp->dev)) {
12bb03b4 Maxime Ripard 2015-09-25 2609 napi_complete(&port->napi);
c5aff182 Thomas Petazzoni 2012-08-17 2610 return rx_done;
c5aff182 Thomas Petazzoni 2012-08-17 2611 }
c5aff182 Thomas Petazzoni 2012-08-17 2612
c5aff182 Thomas Petazzoni 2012-08-17 2613 /* Read cause register */
:::::: The code at line 2605 was first introduced by commit
:::::: c6c022e3602a8165ead71d60ac7ac22e07c81d37 net: ethernet: marvell: mvneta: use phydev from struct net_device
:::::: TO: Philippe Reynes <tremyfr@gmail.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 58866 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/71ffe868/attachment-0001.gz>
^ permalink raw reply
* [PATCH 3/3] clk: imx6: Fix procedure to switch the parent of LDB_DI_CLK
From: Fabio Estevam @ 2016-10-19 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019000526.GR8871@codeaurora.org>
Hi Stephen,
On Tue, Oct 18, 2016 at 10:05 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> Ok that makes it easy. Thanks.
I resent the series yesterday.
https://patchwork.kernel.org/patch/9380917/
https://patchwork.kernel.org/patch/9380919/
https://patchwork.kernel.org/patch/9380921/
Please consider applying them.
Thanks
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Rafael J. Wysocki @ 2016-10-19 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019224405.GA14915@localhost>
On Thu, Oct 20, 2016 at 12:44 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Oct 18, 2016 at 08:32:44AM -0700, Sinan Kaya wrote:
>> Sorry, I think I didn't have enough morning coffee.
>>
>> Looking at these again and trying to be specific.
>>
>> On 10/18/2016 8:20 AM, Sinan Kaya wrote:
>> > It seems wrong to me that we call acpi_irq_get_penalty() from
>> >> acpi_irq_penalty_update() and acpi_penalize_isa_irq(). It seems like they
>> >> should just manipulate acpi_isa_irq_penalty[irq] directly.
>> >>
>> >> acpi_irq_penalty_update() is for command-line parameters, so it certainly
>> >> doesn't need the acpi_irq_pci_sharing_penalty() information (the
>> >> acpi_link_list should be empty at the time we process the command-line
>> >> parameters).
>>
>> Calling acpi_irq_get_penalty for ISA IRQ is OK as long as it doesn't have
>> any dynamic IRQ calculation such that acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty.
>>
>> If this is broken, then we need special care so that we don't assign
>> dynamically calcualted sci_penalty back to acpi_isa_irq_penalty[irq]. This
>> results in returning incorrect penalty as
>>
>> acpi_irq_get_penalty = acpi_isa_irq_original_penalty[irq] + 2 * sci_penalty.
>>
>> Now that we added sci_penalty into the acpi_irq_get_penalty function,
>> calling acpi_irq_get_penalty is not correct anymore. This line here needs to
>> be replaced with acpi_isa_irq_penalty[irq] as you suggested.
>>
>> if (used)
>> new_penalty = acpi_irq_get_penalty(irq) +
>> PIRQ_PENALTY_ISA_USED;
>> else
>> new_penalty = 0;
>>
>> acpi_isa_irq_penalty[irq] = new_penalty;
>>
>>
>> >>
>> >> acpi_penalize_isa_irq() is telling us that a PNP or ACPI device is using
>> >> the IRQ -- this should modify the IRQ's penalty, but it shouldn't depend on
>> >> the acpi_irq_pci_sharing_penalty() value at all.
>> >>
>>
>> Same problem here. This line will be broken after the sci_penalty change.
>>
>> acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
>> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>
> I think the fragility of this code is an indication that we have a
> design problem, so I want to step back from the nitty gritty details
> for a bit and look at the overall design.
>
> Let me restate the overall problem: We have a PCI device connected to
> an interrupt link. The interrupt link can be connected to one of
> several IRQs, and we want to choose one of those IRQs to minimize IRQ
> sharing.
>
> That means we need information about which IRQs are used.
> Historically we've started with a compiled-in table of common ISA IRQ
> usage, and we also collect information about which IRQs are used and
> which *might* be used. So we have the following inputs:
>
> - Compiled-in ISA IRQ usage: the static acpi_isa_irq_penalty[]
> values. ACPI is *supposed* to tell us about all these usages, so
> I don't know why we have the table. But it's been there as long
> as I can remember. The table is probably x86-specific, but we
> keep it in the supposedly generic pci_link.c.
>
> - The "acpi_irq_isa=" and "acpi_irq_pci=" command-line overrides via
> acpi_irq_pci(). I suppose these are for cases where we can't
> figure things out automatically. I would resist adding parameters
> like this today (I would treat the need for them as a bug and look
> for a fix or a quirk), but we might be stuck with these.
>
> - SCI information from the ACPI FADT (acpi_penalize_sci_irq()).
>
> - PNPBIOS and PNPACPI device IRQ usage from _CRS and _PRS via
> acpi_penalize_isa_irq(). This is only for IRQs 0-15, and it does
> NOT include interrupt link (PNP0C0F) devices because we don't
> handle them as PNPACPI devices. I think this is related to the
> fact that PNP0C0F doesn't appear in acpi_pnp_device_ids[].
>
> - For non-PNP0C0F, non-PNPACPI devices, we completely ignore IRQ
> information from _CRS and _PRS. This seems sub-optimal and
> possibly buggy.
>
> - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS via
> acpi_irq_penalty_init(). This is only for IRQs 0-15, and we only
> call this on x86. If _PRS exists, we penalize each possible IRQ.
> If there's no _PRS but _CRS contains an active IRQ, we penalize
> it.
>
> - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS when
> enabling a new link. In acpi_irq_pci_sharing_penalty(), we
> penalize an IRQ if it appears in _CRS or _PRS of any link device
> in the system.
>
> For IRQs 0-15, this overlaps with the penalization done at
> boot-time by acpi_irq_penalty_init(): if a device has _PRS, we'll
> add the "possible" penalty twice (once in acpi_irq_penalty_init()
> and again in acpi_irq_pci_sharing_penalty()), and the "using"
> penalty once (in acpi_irq_pci_sharing_penalty()).
>
> If a device has no _PRS but has _CRS, the "using" penalty is
> applied twice (once in once in acpi_irq_penalty_init() and again
> in acpi_irq_pci_sharing_penalty())
>
> I think this whole thing is baroque and grotesque.
While I agree, I also would like the regression introduced here to be
fixed ASAP.
So do you want me to revert all of the changes made here so far and start over?
Thanks,
Rafael
^ permalink raw reply
* exynos-drm: display manager fails to start without IOMMU problem
From: Shuah Khan @ 2016-10-19 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58079E16.50302@math.uni-bielefeld.de>
On 10/19/2016 10:23 AM, Tobias Jakobi wrote:
> Hello Shuah,
>
> just a short note that more misleading comments about default allocation
> flags can be found in libdrm.
>
> https://cgit.freedesktop.org/mesa/drm/tree/exynos/exynos_drm.c
>
> See e.g. the comment for exynos_bo_create().
>
> In my opinion, the whole approach to _set_ a bit to get non-contigious
> memory is messed up. It would make more sense to me to set a bit to
> request an additional property (here "being contiguous") of the memory.
>
> Anyway, clearing up this situation is highly appreciated!
>
> More comments below.
>
> With best wishes,
> Tobias
>
Hi Tobias,
Thanks for the note. Yes the comments are confusing. It seems like
some old assumptions are persisting. I will fix these as well.
-- Shuah
^ permalink raw reply
* [PATCH] arm64: Add support for additional relocations in the kexec purgatory code
From: Geoff Levand @ 2016-10-19 22:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476892714-27304-1-git-send-email-catalin.marinas@arm.com>
Hi Catalin,
On 10/19/2016 08:58 AM, Catalin Marinas wrote:
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 2e8839a..e067a23 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -585,6 +598,19 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + (((value - address) << 3) & 0xffffe0));
> break;
> + case R_AARCH64_ADR_PREL_PG_HI21:
> + type = "ADR_PREL_PG_HI21";
> + imm = ((value & ~0xfff) - (address & ~0xfff)) >> 12;
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((imm & 3) << 29) + ((imm & 0x1ffffc) << (5 - 2)));
> + break;
> + case R_AARCH64_ADD_ABS_LO12_NC:
> + type = "R_AARCH64_ADD_ABS_LO12_NC";
Following with the others, this should be 'type = "ADD_ABS_LO12_NC"'.
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((value & 0xfff) << 10));
> + break;
> case R_AARCH64_JUMP26:
> type = "JUMP26";
> loc32 = ptr;
> @@ -597,6 +623,15 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, struct mem_sym *UNUSED(sym),
> *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + (((value - address) >> 2) & 0x3ffffff));
> break;
> + case R_AARCH64_LDST64_ABS_LO12_NC:
> + if (value & 7)
> + die("%s: ERROR Unaligned value: %lx\n", __func__,
> + value);
> + type = "R_AARCH64_LDST64_ABS_LO12_NC";
And type = "LDST64_ABS_LO12_NC" here.
> + loc32 = ptr;
> + *loc32 = cpu_to_le32(le32_to_cpu(*loc32)
> + + ((value & 0xff8) << (10 - 3)));
> + break;
> default:
> die("%s: ERROR Unknown type: %lu\n", __func__, r_type);
> break;
Otherwise, looks good. Thanks for taking time to make the fix.
-Geoff
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Bjorn Helgaas @ 2016-10-19 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a82f2ef-b072-d847-104a-320cf804ebd5@codeaurora.org>
On Tue, Oct 18, 2016 at 08:32:44AM -0700, Sinan Kaya wrote:
> Sorry, I think I didn't have enough morning coffee.
>
> Looking at these again and trying to be specific.
>
> On 10/18/2016 8:20 AM, Sinan Kaya wrote:
> > It seems wrong to me that we call acpi_irq_get_penalty() from
> >> acpi_irq_penalty_update() and acpi_penalize_isa_irq(). It seems like they
> >> should just manipulate acpi_isa_irq_penalty[irq] directly.
> >>
> >> acpi_irq_penalty_update() is for command-line parameters, so it certainly
> >> doesn't need the acpi_irq_pci_sharing_penalty() information (the
> >> acpi_link_list should be empty at the time we process the command-line
> >> parameters).
>
> Calling acpi_irq_get_penalty for ISA IRQ is OK as long as it doesn't have
> any dynamic IRQ calculation such that acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty.
>
> If this is broken, then we need special care so that we don't assign
> dynamically calcualted sci_penalty back to acpi_isa_irq_penalty[irq]. This
> results in returning incorrect penalty as
>
> acpi_irq_get_penalty = acpi_isa_irq_original_penalty[irq] + 2 * sci_penalty.
>
> Now that we added sci_penalty into the acpi_irq_get_penalty function,
> calling acpi_irq_get_penalty is not correct anymore. This line here needs to
> be replaced with acpi_isa_irq_penalty[irq] as you suggested.
>
> if (used)
> new_penalty = acpi_irq_get_penalty(irq) +
> PIRQ_PENALTY_ISA_USED;
> else
> new_penalty = 0;
>
> acpi_isa_irq_penalty[irq] = new_penalty;
>
>
> >>
> >> acpi_penalize_isa_irq() is telling us that a PNP or ACPI device is using
> >> the IRQ -- this should modify the IRQ's penalty, but it shouldn't depend on
> >> the acpi_irq_pci_sharing_penalty() value at all.
> >>
>
> Same problem here. This line will be broken after the sci_penalty change.
>
> acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
I think the fragility of this code is an indication that we have a
design problem, so I want to step back from the nitty gritty details
for a bit and look at the overall design.
Let me restate the overall problem: We have a PCI device connected to
an interrupt link. The interrupt link can be connected to one of
several IRQs, and we want to choose one of those IRQs to minimize IRQ
sharing.
That means we need information about which IRQs are used.
Historically we've started with a compiled-in table of common ISA IRQ
usage, and we also collect information about which IRQs are used and
which *might* be used. So we have the following inputs:
- Compiled-in ISA IRQ usage: the static acpi_isa_irq_penalty[]
values. ACPI is *supposed* to tell us about all these usages, so
I don't know why we have the table. But it's been there as long
as I can remember. The table is probably x86-specific, but we
keep it in the supposedly generic pci_link.c.
- The "acpi_irq_isa=" and "acpi_irq_pci=" command-line overrides via
acpi_irq_pci(). I suppose these are for cases where we can't
figure things out automatically. I would resist adding parameters
like this today (I would treat the need for them as a bug and look
for a fix or a quirk), but we might be stuck with these.
- SCI information from the ACPI FADT (acpi_penalize_sci_irq()).
- PNPBIOS and PNPACPI device IRQ usage from _CRS and _PRS via
acpi_penalize_isa_irq(). This is only for IRQs 0-15, and it does
NOT include interrupt link (PNP0C0F) devices because we don't
handle them as PNPACPI devices. I think this is related to the
fact that PNP0C0F doesn't appear in acpi_pnp_device_ids[].
- For non-PNP0C0F, non-PNPACPI devices, we completely ignore IRQ
information from _CRS and _PRS. This seems sub-optimal and
possibly buggy.
- Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS via
acpi_irq_penalty_init(). This is only for IRQs 0-15, and we only
call this on x86. If _PRS exists, we penalize each possible IRQ.
If there's no _PRS but _CRS contains an active IRQ, we penalize
it.
- Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS when
enabling a new link. In acpi_irq_pci_sharing_penalty(), we
penalize an IRQ if it appears in _CRS or _PRS of any link device
in the system.
For IRQs 0-15, this overlaps with the penalization done at
boot-time by acpi_irq_penalty_init(): if a device has _PRS, we'll
add the "possible" penalty twice (once in acpi_irq_penalty_init()
and again in acpi_irq_pci_sharing_penalty()), and the "using"
penalty once (in acpi_irq_pci_sharing_penalty()).
If a device has no _PRS but has _CRS, the "using" penalty is
applied twice (once in once in acpi_irq_penalty_init() and again
in acpi_irq_pci_sharing_penalty())
I think this whole thing is baroque and grotesque.
Here's a strawman idea:
- Maintain a mapping of (IRQ, penalty). Initially all penalties are
zero. This is for *all* IRQs, not just ISA ones. This could be a
linked list, but the structure is not important as long as we can
add things dynamically.
- Add a "acpi_penalize_irq()" function similar to
acpi_penalize_isa_irq(), but not restricted to ISA, so we can
increase the penalty for any IRQ, and maybe we can specify how
much penalty to add.
- Make acpi_irq_get_penalty() a simple lookup in the mapping. No
iterating through all link devices.
- If we think the compiled-in penalties are really necessary, move
the table to x86 code and add a boot-time loop to use
acpi_penalize_irq() to penalize these IRQs. Same for the
command-line options.
- Change acpi_penalize_sci_irq() to use acpi_penalize_irq().
Probably the mapping needs to pay attention to trigger/polarity
somehow, too.
- Figure out how to make the ACPI core use acpi_penalize_irq() to
based on the _CRS and _PRS of every ACPI device, including
PNPACPI, PNP0C0F, etc. Then we can remove acpi_irq_penalty_init().
- Change acpi_pci_link_set() to use acpi_penalize_irq() for the IRQ
it is enabling. Conceptually maybe this should be done in the
acpi_set_current_resources() path so it happens whenever we use
_CRS to enable an IRQ on *any* ACPI device.
I think the biggest issue is figuring out how to get the ACPI core to
look at the _CRS for *all* devices. If we could do that, I think it
could substantially simplify this code.
Bjorn
^ permalink raw reply
* [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem
From: Shuah Khan @ 2016-10-19 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAQKjZMFOe7Aa5Hq5gbMj7=h2VfgXq5jgqbB1wqcZcYZ0ZKZxA@mail.gmail.com>
On 10/19/2016 08:16 AM, Inki Dae wrote:
> Hi Shuah,
>
> 2016-10-13 8:11 GMT+09:00 Shuah Khan <shuahkh@osg.samsung.com>:
>> Hi Inki,
>>
>> On 08/15/2016 10:40 PM, Inki Dae wrote:
>>
>>>>
>>>> okay the very first commit that added IOMMU support
>>>> introduced the code that rejects non-contig gem memory
>>>> type without IOMMU.
>>>>
>>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>>> Author: Inki Dae <inki.dae@samsung.com>
>>>> Date: Sat Oct 20 07:53:42 2012 -0700
>>>>
>>>> drm/exynos: add iommu support for exynos drm framework
>>>>
>>
>> I haven't given up on this yet. I am still seeing the following failure:
>>
>> Additional debug messages I added:
>> [ 15.287403] exynos_drm_gem_create_ioctl() 1
>> [ 15.287419] exynos_drm_gem_create() flags 1
>>
>> [ 15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM memory is not supported.
>>
>> Additional debug message I added:
>> [ 15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize framebuffer
>>
>> This is what happens:
>>
>> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
>> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
>> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>> check_fb_gem_memory_type()
>>
>> At this point, there is no recovery and lightdm fails
>>
>> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
>> allocations are not supported in some exynos drm versions: The following
>> commit introduced this change:
>>
>> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>>
>> excerpts from the diff:- if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
>> - create_exynos.flags = EXYNOS_BO_CONTIG;
>> - else
>> - create_exynos.flags = EXYNOS_BO_NONCONTIG;
>> +
>> + /* Contiguous allocations are not supported in some exynos drm versions.
>> + * When they are supported all allocations are effectively contiguous
>> + * anyway, so for simplicity we always request non contiguous buffers.
>> + */
>> + create_exynos.flags = EXYNOS_BO_NONCONTIG;
>>
>
> Above comment, "Contiguous allocations are not supported in some
> exynos drm versions.", seems wrong assumption.
> The root cause, contiguous allocation is not supported, would be that
> they used Linux kernel which didn't have CMA region enough - as
> default 16MB, or didn't declare CMA region enough for the DMA device.
> So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
> should manage the error case if the allocation failed.
This assumption doesn't sound correct and forcing NONCONTIG isn't right
either.
>
>> There might have been logic on exynos_drm that forced Contig when it coudn't
>> support NONCONTIG. At least, that is what this comment suggests. This assumption
>> doesn't appear to be a good one and not sure if this change was made to fix a bug.
>>
>> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
>> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>>
>> This is what I am running into. This leads to the following question:
>>
>> 1. How do we ensure exynos_drm kernel changes don't break user-space
>> specifically xf86-video-armsoc
>> 2. This seems to have gone undetected for a while. I see a change in
>> exynos_drm_gem_dumb_create() that is probably addressing this type
>> of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>> handling for IOMMU NONCONTIG case.
>
> Seems this patch has a problem. This patch forces to flag NONCONTIG if
> iommu is enabled. The flag should be depend on the argument from
> user-space.
> I.e., if user-space requested a gem allocation with CONTIG flag, then
> Exynos drm driver should allocate contiguous memory even though iommu
> is enabled.
>
>>
>> Anyway, I am interested in getting the exynos_drm kernel side code
>> and xf86-video-armsoc in sync to resolve the issue.
>>
>> Could you recommend a going forward plan?
>
> My opinion are,
>
> 1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
> 2. Do not force to flag NONCONTIG at Exynos drm driver even though
> iommu is enabled and flag allocation type with the argument from
> user-space.
>
> I think you could try to post above patches.
>
Sounds good. I will work on the above two patches.
thanks,
-- Shuah
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-19 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018135912.GD18903@localhost>
Bjorn,
On 10/18/2016 6:59 AM, Bjorn Helgaas wrote:
> It seems wrong to me that we call acpi_irq_get_penalty() from
> acpi_irq_penalty_update() and acpi_penalize_isa_irq(). It seems like they
> should just manipulate acpi_isa_irq_penalty[irq] directly.
>
> acpi_irq_penalty_update() is for command-line parameters, so it certainly
> doesn't need the acpi_irq_pci_sharing_penalty() information (the
> acpi_link_list should be empty at the time we process the command-line
> parameters).
>
> acpi_penalize_isa_irq() is telling us that a PNP or ACPI device is using
> the IRQ -- this should modify the IRQ's penalty, but it shouldn't depend on
> the acpi_irq_pci_sharing_penalty() value at all.
I posted v4 with this change and also went back to the original implementation
for sharing penalty calculation whether the IRQ is ISA or PCI.
Let us know what you think.
I also realized that calculating sharing penalty while the link object is not
initialized is not right.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"
From: Sinan Kaya @ 2016-10-19 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476915664-27231-1-git-send-email-okaya@codeaurora.org>
This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
redundant code in acpi_irq_penalty_init()"").
Now that we understand the real issue (SCI and ISA penalty getting
calculated before ACPI start), there is no need for special handling
for ISA interrupts.
Let's try to simplify the code one more time to share code.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
arch/x86/pci/acpi.c | 1 -
drivers/acpi/pci_link.c | 44 +++++---------------------------------------
include/acpi/acpi_drivers.h | 1 -
3 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 3cd6983..b2a4e2a 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
return -ENODEV;
printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
- acpi_irq_penalty_init();
pcibios_enable_irq = acpi_pci_irq_enable;
pcibios_disable_irq = acpi_pci_irq_disable;
x86_init.pci.init_irq = x86_init_noop;
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 294b190..dd14d78 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
* If a link is active, penalize its IRQ heavily
* so we try to choose a different IRQ.
*/
- if (link->irq.active && link->irq.active == irq)
+ if ((link->irq.active && link->irq.active == irq) &&
+ (link->irq.initialized == 1))
penalty += PIRQ_PENALTY_PCI_USING;
/*
@@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
penalty += sci_penalty;
if (irq < ACPI_MAX_ISA_IRQS)
- return penalty + acpi_isa_irq_penalty[irq];
+ penalty += acpi_isa_irq_penalty[irq];
- return penalty + acpi_irq_pci_sharing_penalty(irq);
-}
-
-int __init acpi_irq_penalty_init(void)
-{
- struct acpi_pci_link *link;
- int i;
-
- /*
- * Update penalties to facilitate IRQ balancing.
- */
- list_for_each_entry(link, &acpi_link_list, list) {
-
- /*
- * reflect the possible and active irqs in the penalty table --
- * useful for breaking ties.
- */
- if (link->irq.possible_count) {
- int penalty =
- PIRQ_PENALTY_PCI_POSSIBLE /
- link->irq.possible_count;
-
- for (i = 0; i < link->irq.possible_count; i++) {
- if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
- acpi_isa_irq_penalty[link->irq.
- possible[i]] +=
- penalty;
- }
-
- } else if (link->irq.active &&
- (link->irq.active < ACPI_MAX_ISA_IRQS)) {
- acpi_isa_irq_penalty[link->irq.active] +=
- PIRQ_PENALTY_PCI_POSSIBLE;
- }
- }
-
- return 0;
+ penalty += acpi_irq_pci_sharing_penalty(irq);
+ return penalty;
}
static int acpi_irq_balance = -1; /* 0: static, 1: balance */
diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
index 29c6912..797ae2e 100644
--- a/include/acpi/acpi_drivers.h
+++ b/include/acpi/acpi_drivers.h
@@ -78,7 +78,6 @@
/* ACPI PCI Interrupt Link (pci_link.c) */
-int acpi_irq_penalty_init(void);
int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
int *polarity, char **name);
int acpi_pci_link_free_irq(acpi_handle handle);
--
1.9.1
^ permalink raw reply related
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