[PATCH V3 3/8] drm/bridge: Add a driver which binds drm_bridge with drm_panel
Add a dummy bridge which binds all of the drm_bridge callbacks
to corresponding drm_panel callbacks.
In theory, this is just a glue layer for the last bridge and
the panel attached to it.
This driver also implements the required drm_connector ops
for the encoder(on which the entire bridge chain is hanging off).
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/Kconfig|7 ++
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/panel_binder.c | 196 +
include/drm/bridge/panel_binder.h | 42 +++
4 files changed, 246 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
create mode 100644 include/drm/bridge/panel_binder.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..e3fb487 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -3,3 +3,10 @@ config DRM_PTN3460
depends on DRM
select DRM_KMS_HELPER
---help---
+
+config DRM_PANEL_BINDER
+ tristate "bridge panel binder"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_PANEL
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..ba8b5b8 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
+obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
diff --git a/drivers/gpu/drm/bridge/panel_binder.c
b/drivers/gpu/drm/bridge/panel_binder.c
new file mode 100644
index 000..c97e3a9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/panel_binder.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+
+#include
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+#include "bridge/panel_binder.h"
+
+struct panel_binder {
+ struct drm_connectorconnector;
+ struct i2c_client *client;
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+ struct drm_panel*panel;
+};
+
+static void panel_binder_pre_enable(struct drm_bridge *bridge)
+{
+ struct panel_binder *panel_binder = bridge->driver_private;
+
+ drm_panel_prepare(panel_binder->panel);
+}
+
+static void panel_binder_enable(struct drm_bridge *bridge)
+{
+ struct panel_binder *panel_binder = bridge->driver_private;
+
+ drm_panel_enable(panel_binder->panel);
+}
+
+static void panel_binder_disable(struct drm_bridge *bridge)
+{
+ struct panel_binder *panel_binder = bridge->driver_private;
+
+ drm_panel_disable(panel_binder->panel);
+}
+
+static void panel_binder_post_disable(struct drm_bridge *bridge)
+{
+ struct panel_binder *panel_binder = bridge->driver_private;
+
+ drm_panel_unprepare(panel_binder->panel);
+}
+
+void panel_binder_destroy(struct drm_bridge *bridge)
+{
+ struct panel_binder *panel_binder = bridge->driver_private;
+
+ drm_panel_detach(panel_binder->panel);
+ drm_bridge_cleanup(bridge);
+}
+
+struct drm_bridge_funcs panel_binder_funcs = {
+ .pre_enable = panel_binder_pre_enable,
+ .enable = panel_binder_enable,
+ .disable = panel_binder_disable,
+ .post_disable = panel_binder_post_disable,
+ .destroy = panel_binder_destroy,
+};
+
+static int panel_binder_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
+
+static int panel_binder_get_modes(struct drm_connector *connector)
+{
+ struct panel_binder *panel_binder;
+
+ panel_binder = container_of(connector, struct panel_binder, connector);
+
+ return panel_binder->panel->funcs->get_modes(panel_binder->panel);
+}
+
+static struct drm_encoder *panel_binder_best_encoder(struct drm_connector
+ *connector)
+{
+ struct panel_binder *panel_binder;
+
+ panel_binder = container_of(connector, struct panel_binder, connector);
+
+ return panel_binder->encoder;
+}
+
+static const struct drm_connector_helper_funcs
+ panel_binder_connector_helper_funcs = {
+ .get_modes = panel_binder_get_modes,
+ .mode_valid = panel_binder_mode_valid,
+ .best_encoder = panel_binder_best_encoder,
+};
+
+static enum drm_connector_status panel_binder_detect(struct drm_connector
+
[PATCH V3 0/8] drm: exynos: few patches to enhance bridge chip support
This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. This patchset also consolidates various inputs from the drm community regarding the bridge chaining concept: (1) [RFC V2 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30160.html (2) [RFC V3 0/3] drm/bridge: panel and chaining http://www.spinics.net/lists/linux-samsung-soc/msg30507.html Changes since V2: -- Address comments from Jingoo Han for ps8622 driver -- Address comments from Daniel, Rob and Thierry regarding bridge chaining -- Address comments from Thierry regarding the names for new drm_panel functions Ajay Kumar (6): [PATCH V3 1/8] drm/bridge: add helper functions to support bridge chain [PATCH V3 2/8] drm/panel: add prepare and unprepare routines [PATCH V3 3/8] drm/bridge: Add a driver which binds drm_bridge with drm_panel [PATCH V3 4/8] drm/bridge: ptn3460: Support bridge chaining [PATCH V3 5/8] drm/panel: Add driver for lvds/edp based panels [PATCH V3 6/8] drm/exynos: dp: Modify driver to support bridge chaining Vincent Palatin (1): [PATCH V3 7/8] drm/bridge: Add ps8622/ps8625 bridge driver Rahul Sharma (1): [PATCH V3 8/8] drm/exynos: Add ps8622 lvds bridge discovery to DP driver .../devicetree/bindings/drm/bridge/ps8622.txt | 21 + .../devicetree/bindings/panel/panel-lvds.txt | 50 +++ .../devicetree/bindings/video/exynos_dp.txt|2 + drivers/gpu/drm/bridge/Kconfig | 15 + drivers/gpu/drm/bridge/Makefile|2 + drivers/gpu/drm/bridge/panel_binder.c | 196 drivers/gpu/drm/bridge/ps8622.c| 475 drivers/gpu/drm/bridge/ptn3460.c | 136 +- drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_dp_core.c| 58 ++- drivers/gpu/drm/exynos/exynos_dp_core.h|1 + drivers/gpu/drm/panel/Kconfig | 18 + drivers/gpu/drm/panel/Makefile |2 + drivers/gpu/drm/panel/panel-lvds.c | 262 +++ include/drm/bridge/panel_binder.h | 42 ++ include/drm/bridge/ps8622.h| 41 ++ include/drm/bridge/ptn3460.h | 15 +- include/drm/drm_crtc.h | 72 +++ include/drm/drm_panel.h| 18 + 19 files changed, 1291 insertions(+), 136 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt create mode 100644 drivers/gpu/drm/bridge/panel_binder.c create mode 100644 drivers/gpu/drm/bridge/ps8622.c create mode 100644 drivers/gpu/drm/panel/panel-lvds.c create mode 100644 include/drm/bridge/panel_binder.h create mode 100644 include/drm/bridge/ps8622.h -- 1.7.9.5
[PATCH V3 6/8] drm/exynos: dp: Modify driver to support bridge chaining
exynos_dp supports a simple bridge chain with ptn3460 bridge
and an LVDS panel attached to it.
This patch creates the bridge chain with ptn3460 as the head
of the list and panel_binder being the tail.
Also, DERER_PROBE for exynos_dp is tested with this patch.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/exynos_dp.txt|2 +
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c| 39 +++-
drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
4 files changed, 34 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 53dbccf..0c118ff 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -51,6 +51,8 @@ Required properties for dp-controller:
LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/video/display-timing.txt
+ -edp-panel:
+ phandle for the drm_panel node required by panel_binder.
Optional properties for dp-controller:
-interlaced:
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 178d2a9..fd1c070 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n ||
DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
+ select DRM_PANEL
help
This enables support for DP device.
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 414f5e5..a608f5c 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -28,7 +28,9 @@
#include
#include
#include
+#include
#include
+#include
#include "exynos_drm_drv.h"
#include "exynos_dp_core.h"
@@ -983,7 +985,7 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
struct drm_encoder *encoder)
{
struct bridge_init bridge;
- struct drm_bridge *bridge_chain = NULL;
+ struct drm_bridge *bridge_chain = NULL, *next = NULL;
bool connector_created = false;
if (find_bridge("nxp,ptn3460", &bridge)) {
@@ -991,6 +993,14 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
bridge.node);
}
+ if (dp->edp_panel) {
+ next = panel_binder_init(dp->drm_dev, encoder, bridge.client,
+ bridge.node, dp->edp_panel, DRM_CONNECTOR_POLL_HPD);
+ if (next)
+ connector_created = true;
+ drm_bridge_add_to_chain(bridge_chain, next);
+ }
+
return connector_created;
}
@@ -1215,16 +1225,10 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm_dev = data;
struct resource *res;
- struct exynos_dp_device *dp;
+ struct exynos_dp_device *dp = exynos_dp_display.ctx;
unsigned int irq_flags;
-
int ret = 0;
- dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
- GFP_KERNEL);
- if (!dp)
- return -ENOMEM;
-
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1298,7 +1302,6 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
disable_irq(dp->irq);
dp->drm_dev = drm_dev;
- exynos_dp_display.ctx = dp;
platform_set_drvdata(pdev, &exynos_dp_display);
@@ -1325,6 +1328,9 @@ static const struct component_ops exynos_dp_ops = {
static int exynos_dp_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
+ struct device_node *panel_node;
+ struct exynos_dp_device *dp;
int ret;
ret = exynos_drm_component_add(&pdev->dev, EXYNOS_DEVICE_TYPE_CONNECTOR,
@@ -1332,6 +1338,21 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (ret)
return ret;
+ dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
+ GFP_KERNEL);
+ if (!dp)
+ return -ENOMEM;
+
+ panel_node = of_parse_phandle(dev->of_node, "edp-panel", 0);
+ if (panel_node) {
+ dp->edp_panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (!dp->edp_panel)
+ return -EPROBE_DEFER;
+ }
+
+ exynos_dp_display.ctx = dp;
+
ret = component_add(&p
[PATCH V3 7/8] drm/bridge: Add ps8622/ps8625 bridge driver
From: Vincent Palatin
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin
Signed-off-by: Andrew Bresticker
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/drm/bridge/ps8622.txt | 21 +
drivers/gpu/drm/bridge/Kconfig |8 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/ps8622.c| 475
include/drm/bridge/ps8622.h| 41 ++
5 files changed, 546 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
create mode 100644 include/drm/bridge/ps8622.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
new file mode 100644
index 000..1afbd9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
@@ -0,0 +1,21 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: "parade,ps8622"
+ - reg: first i2c address of the bridge
+ - sleep-gpio: OF device-tree gpio specification
+ - reset-gpio: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
+
+Example:
+ ps8622-bridge at 48 {
+ compatible = "parade,ps8622";
+ reg = <0x48>;
+ sleep-gpio = <&gpc3 6 1 0 0>;
+ reset-gpio = <&gpc3 1 1 0 0>;
+ display-timings = <&lcd_display_timings>;
+ lane-count = <1>
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e3fb487..7b843c8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+ tristate "Parade eDP/LVDS bridge"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index ba8b5b8..b494d4b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..387d332
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,475 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmP.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+struct ps8622_bridge {
+ struct drm_bridge *bridge;
+ struct drm_encoder *encoder;
+ struct i2c_client *client;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
+
+ int gpio_slp_n;
+ int gpio_rst_n;
+
+ u8 max_lane_count;
+ u8 lane_count;
+
+ bool enabled;
+};
+
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) > \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error "T2.min + T1.max must be less than T2.max + T1.min"
+#endif
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client->adapter;
+ struct i2c_msg
[PATCH V3 5/8] drm/panel: Add driver for lvds/edp based panels
+Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BACKLIGHT_EN pin to
> enable/ disable the backlight.
> Sometimes, we can have LCD_EN switches as well.
>
> The routines in this driver can be used to control
> panel power sequence on such boards.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/panel/panel-lvds.txt | 50
> drivers/gpu/drm/panel/Kconfig | 18 ++
> drivers/gpu/drm/panel/Makefile |2 +
> drivers/gpu/drm/panel/panel-lvds.c | 262
>
> 4 files changed, 332 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
> create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>
> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt
> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> new file mode 100644
> index 000..465016d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> @@ -0,0 +1,50 @@
> +panel interface for eDP/lvds panels
> +
> +Required properties:
> + - compatible: "panel-lvds"
> +
> +Optional properties:
> + -lcd-en-gpio:
> + panel LCD poweron GPIO.
> + Indicates which GPIO needs to be powered up as output
> + to powerup/enable the switch to the LCD panel.
> + -led-en-gpio:
> + panel LED enable GPIO.
> + Indicates which GPIO needs to be powered up as output
> + to enable the backlight.
> + -panel-prepare-delay:
> + delay value in ms required for panel_prepare process
> + Delay in ms needed for the panel LCD unit to
> + powerup completely.
> + ex: delay needed till eDP panel throws HPD.
> + delay needed so that we cans tart reading edid.
> + -panel-enable-delay:
> + delay value in ms required for panel_enable process
> + Delay in ms needed for the panel backlight/LED unit
> + to powerup, and delay needed between video_enable and
> + backlight_enable.
> + -panel-disable-delay:
> + delay value in ms required for panel_disable process
> + Delay in ms needed for the panel backlight/LED unit
> + powerdown, and delay needed between backlight_disable
> + and video_disable.
> + -panel-unprepare-delay:
> + delay value in ms required for panel_post_disable process
> + Delay in ms needed for the panel LCD unit to
> + to powerdown completely, and the minimum delay needed
> + before powering it on again.
> + -panel-width-mm: physical panel width [mm]
> + -panel-height-mm: physical panel height [mm]
> +
> +Example:
> +
> + panel-lvds {
> + compatible = "panel-lvds";
> + led-en-gpio = <&gpx3 0 1>;
> + panel-pre-enable-delay = <40>;
> + panel-enable-delay = <20>;
> + panel-disable-delay = <20>;
> + panel-post-disable-delay = <30>;
> + panel-width-mm = <256>;
> + panel-height-mm = <144>;
> + };
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..3743947 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,22 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_LVDS
> + tristate "support for LVDS panels"
> + depends on OF && DRM_PANEL
> + help
> + DRM panel driver for LVDS connected via DP bridges that need at most
> + a regulator for LCD unit, a regulator for LED unit and/or enable
> + GPIOs for LCD or LED units. Delay values can also be
> + specified to support powerup and powerdown process.
> +
> +config DRM_PANEL_EDP
> + tristate "support for eDP panels"
> + depends on OF && DRM_PANEL
> + help
> + DRM panel driver for eDP panels that need at most a
> + regulator for LCD unit, a regulator for LED unit and/or enable
> + GPIOs for LCD or LED units. Delay values can also be
> + specified to support powerup and powerdown process.
> +
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b92921..9c4f120 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,5 @@
> obj-$(CONFIG_DR
[PATCH V3 6/8] drm/exynos: dp: Modify driver to support bridge chaining
+Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> exynos_dp supports a simple bridge chain with ptn3460 bridge
> and an LVDS panel attached to it.
> This patch creates the bridge chain with ptn3460 as the head
> of the list and panel_binder being the tail.
>
> Also, DERER_PROBE for exynos_dp is tested with this patch.
>
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/exynos_dp.txt|2 +
> drivers/gpu/drm/exynos/Kconfig |1 +
> drivers/gpu/drm/exynos/exynos_dp_core.c| 39
> +++-
> drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
> 4 files changed, 34 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index 53dbccf..0c118ff 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -51,6 +51,8 @@ Required properties for dp-controller:
> LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> - display-timings: timings for the connected panel as described by
> Documentation/devicetree/bindings/video/display-timing.txt
> + -edp-panel:
> + phandle for the drm_panel node required by panel_binder.
>
> Optional properties for dp-controller:
> -interlaced:
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 178d2a9..fd1c070 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
> bool "EXYNOS DRM DP driver support"
> depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n ||
> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
> default DRM_EXYNOS
> + select DRM_PANEL
> help
> This enables support for DP device.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 414f5e5..a608f5c 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -28,7 +28,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
>
> #include "exynos_drm_drv.h"
> #include "exynos_dp_core.h"
> @@ -983,7 +985,7 @@ static int exynos_drm_attach_lcd_bridge(struct
> exynos_dp_device *dp,
> struct drm_encoder *encoder)
> {
> struct bridge_init bridge;
> - struct drm_bridge *bridge_chain = NULL;
> + struct drm_bridge *bridge_chain = NULL, *next = NULL;
> bool connector_created = false;
>
> if (find_bridge("nxp,ptn3460", &bridge)) {
> @@ -991,6 +993,14 @@ static int exynos_drm_attach_lcd_bridge(struct
> exynos_dp_device *dp,
> bridge.node);
> }
>
> + if (dp->edp_panel) {
> + next = panel_binder_init(dp->drm_dev, encoder, bridge.client,
> + bridge.node, dp->edp_panel, DRM_CONNECTOR_POLL_HPD);
> + if (next)
> + connector_created = true;
> + drm_bridge_add_to_chain(bridge_chain, next);
> + }
> +
> return connector_created;
> }
>
> @@ -1215,16 +1225,10 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm_dev = data;
> struct resource *res;
> - struct exynos_dp_device *dp;
> + struct exynos_dp_device *dp = exynos_dp_display.ctx;
> unsigned int irq_flags;
> -
> int ret = 0;
>
> - dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
> - GFP_KERNEL);
> - if (!dp)
> - return -ENOMEM;
> -
> dp->dev = &pdev->dev;
> dp->dpms_mode = DRM_MODE_DPMS_OFF;
>
> @@ -1298,7 +1302,6 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> disable_irq(dp->irq);
>
> dp->drm_dev = drm_dev;
> - exynos_dp_display.ctx = dp;
>
> platform_set_drvdata(pdev, &exynos_dp_display);
>
> @@ -1325,6 +1328,9 @@ static const struct component_ops exynos_dp_ops = {
>
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> + struct device_node *panel_node;
> + struct exynos_dp_device *dp;
> int ret;
>
> ret = exynos_drm_component_add(&pdev->dev,
> EXYNOS_DEVICE_TYPE_CONNECTOR,
> @@ -1332,6 +1338,21 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
> if (ret)
> return ret;
>
> + dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
> + GFP_KERNEL);
> + if (!dp)
> + return -ENOMEM;
> +
> + panel_node = of_parse_phandl
[PATCH V3 7/8] drm/bridge: Add ps8622/ps8625 bridge driver
On Fri, Jun 6, 2014 at 12:46 AM, Ajay kumar wrote:
> + Device tree list
>
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> From: Vincent Palatin
>>
>> This patch adds drm_bridge driver for parade DisplayPort
>> to LVDS bridge chip.
>>
>> Signed-off-by: Vincent Palatin
>> Signed-off-by: Andrew Bresticker
>> Signed-off-by: Sean Paul
>> Signed-off-by: Rahul Sharma
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bindings/drm/bridge/ps8622.txt | 21 +
>> drivers/gpu/drm/bridge/Kconfig |8 +
>> drivers/gpu/drm/bridge/Makefile|1 +
>> drivers/gpu/drm/bridge/ps8622.c| 475
>>
>> include/drm/bridge/ps8622.h| 41 ++
>> 5 files changed, 546 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>> create mode 100644 include/drm/bridge/ps8622.h
>>
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> new file mode 100644
>> index 000..1afbd9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>> @@ -0,0 +1,21 @@
>> +ps8622-bridge bindings
>> +
>> +Required properties:
>> + - compatible: "parade,ps8622"
>> + - reg: first i2c address of the bridge
>> + - sleep-gpio: OF device-tree gpio specification
>> + - reset-gpio: OF device-tree gpio specification
>> +
>> +Optional properties:
>> + - lane-count: number of DP lanes to use
>> + - use-external-pwm: backlight will be controlled by an external PWM
>> +
>> +Example:
>> + ps8622-bridge at 48 {
>> + compatible = "parade,ps8622";
>> + reg = <0x48>;
>> + sleep-gpio = <&gpc3 6 1 0 0>;
>> + reset-gpio = <&gpc3 1 1 0 0>;
>> + display-timings = <&lcd_display_timings>;
>> + lane-count = <1>
>> + };
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index e3fb487..7b843c8 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
>> select DRM_KMS_HELPER
>> select DRM_PANEL
>> ---help---
>> +
>> +config DRM_PS8622
>> + tristate "Parade eDP/LVDS bridge"
>> + depends on DRM
>> + select DRM_KMS_HELPER
>> + select BACKLIGHT_LCD_SUPPORT
>> + select BACKLIGHT_CLASS_DEVICE
>> + ---help---
>> diff --git a/drivers/gpu/drm/bridge/Makefile
>> b/drivers/gpu/drm/bridge/Makefile
>> index ba8b5b8..b494d4b 100644
>> --- a/drivers/gpu/drm/bridge/Makefile
>> +++ b/drivers/gpu/drm/bridge/Makefile
>> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>>
>> obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
>> obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
>> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
>> diff --git a/drivers/gpu/drm/bridge/ps8622.c
>> b/drivers/gpu/drm/bridge/ps8622.c
>> new file mode 100644
>> index 000..387d332
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>> @@ -0,0 +1,475 @@
>> +/*
>> + * Parade PS8622 eDP/LVDS bridge driver
>> + *
>> + * Copyright (C) 2014 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "drmP.h"
>> +#include "drm_crtc.h"
>> +#include "drm_crtc_helper.h"
>> +
>> +struct ps8622_bridge {
>> + struct drm_bridge *bridge;
>> + struct drm_encoder *encoder;
>> + struct i2c_client *client;
>> + struct regulator *v12;
>> + struct backlight_device *bl;
>> + struct mutex enable_mutex;
>> +
>> + int gpio_slp_n;
>> + int gpio_rst_n;
>> +
>> + u8 max_lane_count;
>> + u8 lane_count;
>> +
>> + bool enabled;
>> +};
>> +
>> +struct ps8622_device_data {
>> + u8 max_lane_count;
>> +};
>> +
>> +static const struct ps8622_device_data ps8622_data = {
>> + .max_lane_count = 1,
>> +};
>> +
>> +static const struct ps8622_device_data ps8625_data = {
>> + .max_lane_count = 2,
>> +};
>> +
>> +/* Brightness scale on the Parade chip */
>> +#define PS8622_MAX_BRIGHTNESS 0xff
>> +
>> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
>> +#define PS8622_POWER_RISE_T1_MIN_US 10
>> +#define PS8622_POWER_RISE_T1_MAX_US
[PATCH V3 2/8] drm/panel: add prepare and unprepare routines
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff LCD unit/LCD_EN
With existing callbacks for drm panel, we cannot accomodate such panels,
since only two callbacks, i.e "panel_enable" and panel_disable are supported.
This patch adds:
-- "prepare" callback which can be called before
the actual video data is on, and then call the "enable"
callback after the video data is available.
-- "unprepare" callback which can be called after
the video data is off, and use "disable" callback
to do something before switching off the video data.
Now, we can easily map the above scenario as shown below:
poweron LCD unit/LCD_EN = "prepare" callback
poweron LED unit/BACKLIGHT_EN = "enable" callback
poweroff LED unit/BACKLIGHT_EN = "disable" callback
poweroff LCD unit/LCD_EN = "unprepare" callback
Signed-off-by: Ajay Kumar
---
include/drm/drm_panel.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index c2ab77a..9addc69 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -31,7 +31,9 @@ struct drm_device;
struct drm_panel;
struct drm_panel_funcs {
+ int (*unprepare)(struct drm_panel *panel);
int (*disable)(struct drm_panel *panel);
+ int (*prepare)(struct drm_panel *panel);
int (*enable)(struct drm_panel *panel);
int (*get_modes)(struct drm_panel *panel);
};
@@ -46,6 +48,14 @@ struct drm_panel {
struct list_head list;
};
+static inline int drm_panel_unprepare(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->unprepare)
+ return panel->funcs->unprepare(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_disable(struct drm_panel *panel)
{
if (panel && panel->funcs && panel->funcs->disable)
@@ -54,6 +64,14 @@ static inline int drm_panel_disable(struct drm_panel *panel)
return panel ? -ENOSYS : -EINVAL;
}
+static inline int drm_panel_prepare(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->prepare)
+ return panel->funcs->prepare(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+
static inline int drm_panel_enable(struct drm_panel *panel)
{
if (panel && panel->funcs && panel->funcs->enable)
--
1.7.9.5
[PATCH V3 4/8] drm/bridge: ptn3460: Support bridge chaining
Modify the driver to invoke callbacks for the next bridge
in the bridge chain.
Also, remove the drm_connector implementation from ptn3460,
since the same is implemented using panel_binder.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/ptn3460.c| 136 +--
drivers/gpu/drm/exynos/exynos_dp_core.c | 16 ++--
include/drm/bridge/ptn3460.h| 15 ++--
3 files changed, 39 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 98fd17a..21e9db8 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -34,37 +34,15 @@
#define PTN3460_EDID_SRAM_LOAD_ADDR0x85
struct ptn3460_bridge {
- struct drm_connector connector;
struct i2c_client *client;
struct drm_encoder *encoder;
struct drm_bridge *bridge;
- struct edid *edid;
int gpio_pd_n;
int gpio_rst_n;
u32 edid_emulation;
bool enabled;
};
-static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
- u8 *buf, int len)
-{
- int ret;
-
- ret = i2c_master_send(ptn_bridge->client, &addr, 1);
- if (ret <= 0) {
- DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
- return ret;
- }
-
- ret = i2c_master_recv(ptn_bridge->client, buf, len);
- if (ret <= 0) {
- DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
char val)
{
@@ -126,6 +104,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
gpio_set_value(ptn_bridge->gpio_rst_n, 1);
}
+ drm_next_bridge_pre_enable(bridge);
+
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -142,6 +122,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
static void ptn3460_enable(struct drm_bridge *bridge)
{
+ drm_next_bridge_enable(bridge);
}
static void ptn3460_disable(struct drm_bridge *bridge)
@@ -153,6 +134,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge->enabled = false;
+ drm_next_bridge_disable(bridge);
+
if (gpio_is_valid(ptn_bridge->gpio_rst_n))
gpio_set_value(ptn_bridge->gpio_rst_n, 1);
@@ -162,6 +145,7 @@ static void ptn3460_disable(struct drm_bridge *bridge)
static void ptn3460_post_disable(struct drm_bridge *bridge)
{
+ drm_next_bridge_post_disable(bridge);
}
void ptn3460_bridge_destroy(struct drm_bridge *bridge)
@@ -173,6 +157,9 @@ void ptn3460_bridge_destroy(struct drm_bridge *bridge)
gpio_free(ptn_bridge->gpio_pd_n);
if (gpio_is_valid(ptn_bridge->gpio_rst_n))
gpio_free(ptn_bridge->gpio_rst_n);
+
+ drm_next_bridge_destroy(bridge);
+
/* Nothing else to free, we've got devm allocated memory */
}
@@ -184,81 +171,10 @@ struct drm_bridge_funcs ptn3460_bridge_funcs = {
.destroy = ptn3460_bridge_destroy,
};
-int ptn3460_get_modes(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes;
- bool power_off;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- if (ptn_bridge->edid)
- return drm_add_edid_modes(connector, ptn_bridge->edid);
-
- power_off = !ptn_bridge->enabled;
- ptn3460_pre_enable(ptn_bridge->bridge);
-
- edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
- if (!edid) {
- DRM_ERROR("Failed to allocate edid\n");
- return 0;
- }
-
- ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
- if (ret) {
- kfree(edid);
- num_modes = 0;
- goto out;
- }
-
- ptn_bridge->edid = (struct edid *)edid;
- drm_mode_connector_update_edid_property(connector, ptn_bridge->edid);
-
- num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
-
-out:
- if (power_off)
- ptn3460_disable(ptn_bridge->bridge);
-
- return num_modes;
-}
-
-struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
-{
- struct ptn3460_bridge *ptn_bridge;
-
- ptn_bridge = container_of(connector, struct ptn3460_bridge, connector);
-
- return ptn_bridge->encoder;
-}
-
-struct drm_connector_helper_funcs ptn3460_connector_helper_funcs = {
- .get_modes = ptn3460_get_modes,
- .best_encoder = ptn3460_best_encoder,
-};
-
-enum drm_connector_status ptn3460_detect(struct drm_connector *connector,
- bool force)
-{
- return connector_status_connected;
-}
-
-void ptn3460_connector
[PATCH V3 5/8] drm/panel: Add driver for lvds/edp based panels
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/LVDS panels.
The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BACKLIGHT_EN pin to
enable/ disable the backlight.
Sometimes, we can have LCD_EN switches as well.
The routines in this driver can be used to control
panel power sequence on such boards.
Signed-off-by: Ajay Kumar
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/panel/panel-lvds.txt | 50
drivers/gpu/drm/panel/Kconfig | 18 ++
drivers/gpu/drm/panel/Makefile |2 +
drivers/gpu/drm/panel/panel-lvds.c | 262
4 files changed, 332 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt
b/Documentation/devicetree/bindings/panel/panel-lvds.txt
new file mode 100644
index 000..465016d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
@@ -0,0 +1,50 @@
+panel interface for eDP/lvds panels
+
+Required properties:
+ - compatible: "panel-lvds"
+
+Optional properties:
+ -lcd-en-gpio:
+ panel LCD poweron GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to powerup/enable the switch to the LCD panel.
+ -led-en-gpio:
+ panel LED enable GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to enable the backlight.
+ -panel-prepare-delay:
+ delay value in ms required for panel_prepare process
+ Delay in ms needed for the panel LCD unit to
+ powerup completely.
+ ex: delay needed till eDP panel throws HPD.
+ delay needed so that we cans tart reading edid.
+ -panel-enable-delay:
+ delay value in ms required for panel_enable process
+ Delay in ms needed for the panel backlight/LED unit
+ to powerup, and delay needed between video_enable and
+ backlight_enable.
+ -panel-disable-delay:
+ delay value in ms required for panel_disable process
+ Delay in ms needed for the panel backlight/LED unit
+ powerdown, and delay needed between backlight_disable
+ and video_disable.
+ -panel-unprepare-delay:
+ delay value in ms required for panel_post_disable process
+ Delay in ms needed for the panel LCD unit to
+ to powerdown completely, and the minimum delay needed
+ before powering it on again.
+ -panel-width-mm: physical panel width [mm]
+ -panel-height-mm: physical panel height [mm]
+
+Example:
+
+ panel-lvds {
+ compatible = "panel-lvds";
+ led-en-gpio = <&gpx3 0 1>;
+ panel-pre-enable-delay = <40>;
+ panel-enable-delay = <20>;
+ panel-disable-delay = <20>;
+ panel-post-disable-delay = <30>;
+ panel-width-mm = <256>;
+ panel-height-mm = <144>;
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..3743947 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,22 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_LVDS
+ tristate "support for LVDS panels"
+ depends on OF && DRM_PANEL
+ help
+ DRM panel driver for LVDS connected via DP bridges that need at most
+ a regulator for LCD unit, a regulator for LED unit and/or enable
+ GPIOs for LCD or LED units. Delay values can also be
+ specified to support powerup and powerdown process.
+
+config DRM_PANEL_EDP
+ tristate "support for eDP panels"
+ depends on OF && DRM_PANEL
+ help
+ DRM panel driver for eDP panels that need at most a
+ regulator for LCD unit, a regulator for LED unit and/or enable
+ GPIOs for LCD or LED units. Delay values can also be
+ specified to support powerup and powerdown process.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..9c4f120 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
+obj-$(CONFIG_DRM_PANEL_EDP) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm
[PATCH V3 8/8] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
From: Rahul Sharma
This patch adds ps8622 lvds bridge discovery code to the dp driver.
Signed-off-by: Rahul Sharma
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a608f5c..44ebf54 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "exynos_drm_drv.h"
#include "exynos_dp_core.h"
@@ -991,6 +992,10 @@ static int exynos_drm_attach_lcd_bridge(struct
exynos_dp_device *dp,
if (find_bridge("nxp,ptn3460", &bridge)) {
bridge_chain = ptn3460_init(dp->drm_dev, encoder, bridge.client,
bridge.node);
+ } else if (find_bridge("parade,ps8622", &bridge) ||
+ find_bridge("parade,ps8625", &bridge)) {
+ bridge_chain = ps8622_init(dp->drm_dev, encoder, bridge.client,
+ bridge.node);
}
if (dp->edp_panel) {
--
1.7.9.5
[PATCH V3 7/8] drm/bridge: Add ps8622/ps8625 bridge driver
+ Device tree list
On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar wrote:
> From: Vincent Palatin
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin
> Signed-off-by: Andrew Bresticker
> Signed-off-by: Sean Paul
> Signed-off-by: Rahul Sharma
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/drm/bridge/ps8622.txt | 21 +
> drivers/gpu/drm/bridge/Kconfig |8 +
> drivers/gpu/drm/bridge/Makefile|1 +
> drivers/gpu/drm/bridge/ps8622.c| 475
>
> include/drm/bridge/ps8622.h| 41 ++
> 5 files changed, 546 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> create mode 100644 drivers/gpu/drm/bridge/ps8622.c
> create mode 100644 include/drm/bridge/ps8622.h
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> new file mode 100644
> index 000..1afbd9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> @@ -0,0 +1,21 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8622"
> + - reg: first i2c address of the bridge
> + - sleep-gpio: OF device-tree gpio specification
> + - reset-gpio: OF device-tree gpio specification
> +
> +Optional properties:
> + - lane-count: number of DP lanes to use
> + - use-external-pwm: backlight will be controlled by an external PWM
> +
> +Example:
> + ps8622-bridge at 48 {
> + compatible = "parade,ps8622";
> + reg = <0x48>;
> + sleep-gpio = <&gpc3 6 1 0 0>;
> + reset-gpio = <&gpc3 1 1 0 0>;
> + display-timings = <&lcd_display_timings>;
> + lane-count = <1>
> + };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e3fb487..7b843c8 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
> select DRM_KMS_HELPER
> select DRM_PANEL
> ---help---
> +
> +config DRM_PS8622
> + tristate "Parade eDP/LVDS bridge"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select BACKLIGHT_LCD_SUPPORT
> + select BACKLIGHT_CLASS_DEVICE
> + ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index ba8b5b8..b494d4b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>
> obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..387d332
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,475 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +
> +struct ps8622_bridge {
> + struct drm_bridge *bridge;
> + struct drm_encoder *encoder;
> + struct i2c_client *client;
> + struct regulator *v12;
> + struct backlight_device *bl;
> + struct mutex enable_mutex;
> +
> + int gpio_slp_n;
> + int gpio_rst_n;
> +
> + u8 max_lane_count;
> + u8 lane_count;
> +
> + bool enabled;
> +};
> +
> +struct ps8622_device_data {
> + u8 max_lane_count;
> +};
> +
> +static const struct ps8622_device_data ps8622_data = {
> + .max_lane_count = 1,
> +};
> +
> +static const struct ps8622_device_data ps8625_data = {
> + .max_lane_count = 2,
> +};
> +
> +/* Brightness scale on the Parade chip */
> +#define PS8622_MAX_BRIGHTNESS 0xff
> +
> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> +#define PS8622_POWER_RISE_T1_MIN_US 10
> +#define PS8622_POWER_RISE_T1_MAX_US 1
> +#define PS8622_RST_HIGH_T2_MIN_US 3000
> +#define PS8622_RST_HIGH_T2_MAX_US 3
> +#define PS8622_PWMO_END_T12_MS 200
> +#define PS8622_POWER_FALL_T16_MAX_US 1
> +#define PS8622_POWER_OFF_T17_MS 500
>
[PATCH V3 6/8] drm/exynos: dp: Modify driver to support bridge chaining
On Fri, Jun 6, 2014 at 12:48 AM, Ajay kumar wrote:
> +Device tree list
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> exynos_dp supports a simple bridge chain with ptn3460 bridge
>> and an LVDS panel attached to it.
>> This patch creates the bridge chain with ptn3460 as the head
>> of the list and panel_binder being the tail.
>>
>> Also, DERER_PROBE for exynos_dp is tested with this patch.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bindings/video/exynos_dp.txt|2 +
>> drivers/gpu/drm/exynos/Kconfig |1 +
>> drivers/gpu/drm/exynos/exynos_dp_core.c| 39
>> +++-
>> drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>> 4 files changed, 34 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt
>> b/Documentation/devicetree/bindings/video/exynos_dp.txt
>> index 53dbccf..0c118ff 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
>> @@ -51,6 +51,8 @@ Required properties for dp-controller:
>> LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
>> - display-timings: timings for the connected panel as described by
>> Documentation/devicetree/bindings/video/display-timing.txt
>> + -edp-panel:
>> + phandle for the drm_panel node required by panel_binder.
>>
>> Optional properties for dp-controller:
>> -interlaced:
>> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
>> index 178d2a9..fd1c070 100644
>> --- a/drivers/gpu/drm/exynos/Kconfig
>> +++ b/drivers/gpu/drm/exynos/Kconfig
>> @@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
>> bool "EXYNOS DRM DP driver support"
>> depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n ||
>> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
>> default DRM_EXYNOS
>> + select DRM_PANEL
>> help
>> This enables support for DP device.
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 414f5e5..a608f5c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -28,7 +28,9 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> +#include
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_dp_core.h"
>> @@ -983,7 +985,7 @@ static int exynos_drm_attach_lcd_bridge(struct
>> exynos_dp_device *dp,
>> struct drm_encoder *encoder)
>> {
>> struct bridge_init bridge;
>> - struct drm_bridge *bridge_chain = NULL;
>> + struct drm_bridge *bridge_chain = NULL, *next = NULL;
>> bool connector_created = false;
>>
>> if (find_bridge("nxp,ptn3460", &bridge)) {
>> @@ -991,6 +993,14 @@ static int exynos_drm_attach_lcd_bridge(struct
>> exynos_dp_device *dp,
>> bridge.node);
>> }
>>
>> + if (dp->edp_panel) {
>> + next = panel_binder_init(dp->drm_dev, encoder, bridge.client,
>> + bridge.node, dp->edp_panel, DRM_CONNECTOR_POLL_HPD);
>> + if (next)
>> + connector_created = true;
>> + drm_bridge_add_to_chain(bridge_chain, next);
>> + }
>> +
>> return connector_created;
>> }
>>
>> @@ -1215,16 +1225,10 @@ static int exynos_dp_bind(struct device *dev, struct
>> device *master, void *data)
>> struct platform_device *pdev = to_platform_device(dev);
>> struct drm_device *drm_dev = data;
>> struct resource *res;
>> - struct exynos_dp_device *dp;
>> + struct exynos_dp_device *dp = exynos_dp_display.ctx;
>> unsigned int irq_flags;
>> -
>> int ret = 0;
>>
>> - dp = devm_kzalloc(&pdev->dev, sizeof(struct exynos_dp_device),
>> - GFP_KERNEL);
>> - if (!dp)
>> - return -ENOMEM;
>> -
>> dp->dev = &pdev->dev;
>> dp->dpms_mode = DRM_MODE_DPMS_OFF;
>>
>> @@ -1298,7 +1302,6 @@ static int exynos_dp_bind(struct device *dev, struct
>> device *master, void *data)
>> disable_irq(dp->irq);
>>
>> dp->drm_dev = drm_dev;
>> - exynos_dp_display.ctx = dp;
>>
>> platform_set_drvdata(pdev, &exynos_dp_display);
>>
>> @@ -1325,6 +1328,9 @@ static const struct component_ops exynos_dp_ops = {
>>
>> static int exynos_dp_probe(struct platform_device *pdev)
>> {
>> + struct device *dev = &pdev->dev;
>> + struct device_node *panel_node;
>> + struct exynos_dp_device *dp;
>> int ret;
>>
>> ret = exynos_drm_component_add(&pdev->dev,
>> EXYNOS_DEVICE_TYPE_CONNECTOR,
>> @@ -1332,6 +1338,21 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>> if (ret)
>> return ret;
>>
>> + dp = devm_kzallo
[PATCH V3 1/8] drm/bridge: add helper functions to support bridge chain
Add helper functions to create bridge chain and to call the
corresponding next_bridge functions.
Signed-off-by: Ajay Kumar
Suggested-by: Rob Clark
---
include/drm/drm_crtc.h | 72
1 file changed, 72 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31c..4665d42 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -623,6 +623,7 @@ struct drm_bridge_funcs {
struct drm_bridge {
struct drm_device *dev;
struct list_head head;
+ struct drm_bridge *next_bridge;
struct drm_mode_object base;
@@ -1079,6 +1080,77 @@ static inline struct drm_encoder
*drm_encoder_find(struct drm_device *dev,
return mo ? obj_to_encoder(mo) : NULL;
}
+static inline int drm_bridge_add_to_chain(struct drm_bridge *head,
+ struct drm_bridge *last)
+{
+ struct drm_bridge *temp = head;
+
+ if (head && last) {
+ while (temp->next_bridge)
+ temp = temp->next_bridge;
+
+ temp->next_bridge = last;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static inline void drm_next_bridge_mode_fixup(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->mode_fixup)
+ bridge->next_bridge->funcs->mode_fixup(bridge->next_bridge,
+ mode, adjusted_mode);
+}
+
+static inline void drm_next_bridge_disable(struct drm_bridge *bridge)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->disable)
+ bridge->next_bridge->funcs->disable(bridge->next_bridge);
+}
+
+static inline void drm_next_bridge_post_disable(struct drm_bridge *bridge)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->post_disable)
+ bridge->next_bridge->funcs->post_disable(bridge->next_bridge);
+}
+
+static inline void drm_next_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->mode_set)
+ bridge->next_bridge->funcs->mode_set(bridge->next_bridge,
+ mode, adjusted_mode);
+}
+
+static inline void drm_next_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->pre_enable)
+ bridge->next_bridge->funcs->pre_enable(bridge->next_bridge);
+}
+
+static inline void drm_next_bridge_enable(struct drm_bridge *bridge)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->enable)
+ bridge->next_bridge->funcs->enable(bridge->next_bridge);
+}
+
+static inline void drm_next_bridge_destroy(struct drm_bridge *bridge)
+{
+ if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
+ bridge->next_bridge->funcs->destroy)
+ bridge->next_bridge->funcs->destroy(bridge->next_bridge);
+}
+
/* Plane list iterator for legacy (overlay only) planes. */
#define drm_for_each_legacy_plane(plane, planelist) \
list_for_each_entry(plane, planelist, head) \
--
1.7.9.5
[PATCH V3 5/8] drm/panel: Add driver for lvds/edp based panels
On Fri, Jun 6, 2014 at 12:47 AM, Ajay kumar wrote:
> +Device tree list
>
> On Fri, Jun 6, 2014 at 12:40 AM, Ajay Kumar
> wrote:
>> This patch adds a simple driver to handle all the LCD and LED
>> powerup/down routines needed to support eDP/LVDS panels.
>>
>> The LCD and LED units are usually powered up via regulators,
>> and almost on all boards, we will have a BACKLIGHT_EN pin to
>> enable/ disable the backlight.
>> Sometimes, we can have LCD_EN switches as well.
>>
>> The routines in this driver can be used to control
>> panel power sequence on such boards.
>>
>> Signed-off-by: Ajay Kumar
>> Signed-off-by: Rahul Sharma
>> ---
>> .../devicetree/bindings/panel/panel-lvds.txt | 50
>> drivers/gpu/drm/panel/Kconfig | 18 ++
>> drivers/gpu/drm/panel/Makefile |2 +
>> drivers/gpu/drm/panel/panel-lvds.c | 262
>>
>> 4 files changed, 332 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>> create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>>
>> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> new file mode 100644
>> index 000..465016d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
>> @@ -0,0 +1,50 @@
>> +panel interface for eDP/lvds panels
>> +
>> +Required properties:
>> + - compatible: "panel-lvds"
>> +
>> +Optional properties:
>> + -lcd-en-gpio:
>> + panel LCD poweron GPIO.
>> + Indicates which GPIO needs to be powered up as output
>> + to powerup/enable the switch to the LCD panel.
>> + -led-en-gpio:
>> + panel LED enable GPIO.
>> + Indicates which GPIO needs to be powered up as output
>> + to enable the backlight.
>> + -panel-prepare-delay:
>> + delay value in ms required for panel_prepare process
>> + Delay in ms needed for the panel LCD unit to
>> + powerup completely.
>> + ex: delay needed till eDP panel throws HPD.
>> + delay needed so that we cans tart reading edid.
>> + -panel-enable-delay:
>> + delay value in ms required for panel_enable process
>> + Delay in ms needed for the panel backlight/LED unit
>> + to powerup, and delay needed between video_enable and
>> + backlight_enable.
>> + -panel-disable-delay:
>> + delay value in ms required for panel_disable process
>> + Delay in ms needed for the panel backlight/LED unit
>> + powerdown, and delay needed between backlight_disable
>> + and video_disable.
>> + -panel-unprepare-delay:
>> + delay value in ms required for panel_post_disable process
>> + Delay in ms needed for the panel LCD unit to
>> + to powerdown completely, and the minimum delay needed
>> + before powering it on again.
>> + -panel-width-mm: physical panel width [mm]
>> + -panel-height-mm: physical panel height [mm]
>> +
>> +Example:
>> +
>> + panel-lvds {
>> + compatible = "panel-lvds";
>> + led-en-gpio = <&gpx3 0 1>;
>> + panel-pre-enable-delay = <40>;
>> + panel-enable-delay = <20>;
>> + panel-disable-delay = <20>;
>> + panel-post-disable-delay = <30>;
>> + panel-width-mm = <256>;
>> + panel-height-mm = <144>;
>> + };
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index 4ec874d..3743947 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -30,4 +30,22 @@ config DRM_PANEL_S6E8AA0
>> select DRM_MIPI_DSI
>> select VIDEOMODE_HELPERS
>>
>> +config DRM_PANEL_LVDS
>> + tristate "support for LVDS panels"
>> + depends on OF && DRM_PANEL
>> + help
>> + DRM panel driver for LVDS connected via DP bridges that need at
>> most
>> + a regulator for LCD unit, a regulator for LED unit and/or enable
>> + GPIOs for LCD or LED units. Delay values can also be
>> + specified to support powerup and powerdown process.
>> +
>> +config DRM_PANEL_EDP
>> + tristate "support for eDP panels"
>> + depends on OF && DRM_PANEL
>> + help
>> + DRM panel driver for eDP panels that need at most a
>> + regulator for LCD unit, a regulator for LED unit and/or enable
>> + GPIOs for LCD or LED units. Delay values can also be
>> + specified to support powerup and powerdown process.
>> +
>> endmenu
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drive
linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build
(x86_64 allmodconfig) failed like this:
drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
drivers/gpu/drm/i915/intel_fbdev.c:392:4: error: implicit declaration of
function 'drm_get_connector_name' [-Werror=implicit-function-declaration]
DRM_DEBUG_KMS("using first mode listed on connector %s\n",
^
This is just the error I reported yesterday against the drm and
drm-intel trees, but migrated to the drm-intel-fixes tree. Your -fixes
tree shoudl really only contain stuff that depend on Linus' trees ...
but here it include all of yesterday's drm tree as well.
I have used the drm-intel-fixes tree from next-20140605 for today.
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/0e3f08e4/attachment.sig>
[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading
https://bugs.freedesktop.org/show_bug.cgi?id=79659 --- Comment #4 from Michel D?nzer --- (In reply to comment #3) > force_glsl_extensions_warn=true That's enabled by default for Heaven in /etc/drirc, but I just tried setting it explicitly just in case. Doesn't help. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/3c4d3b62/attachment.html>
[PATCH] [RFC] drm/i915/dp: add support for load detect Apple DP->VGA dongles
From: Dave Airlie
The DP1.2 spec has some bits for forced load sensing on VGA dongles,
however the apple dongle I have doesn't do DP 1.2 yet, so I dug into
its vendor specific area and found a register that seems to correspond
to load detected on the outputs.
The main reason I need this was at LCA this year the slide capture system
failed to provide EDID, but I realised OSX worked. Really need to add support
to nouveau, but hey i915 is a start.
The dongle also appears to use short IRQs to denote a plug/unplug event,
though something seems to be failing in reading back the dpcd values from it.
(also this is based on my MST work just because.)
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_dp.c | 29 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
include/drm/drm_dp_helper.h | 19 +++
3 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c500f63..49afd7d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3173,6 +3173,16 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
buf[0], buf[1], buf[2]);
+ intel_dp->is_apple_vga = false;
+ if (drm_dp_branch_is_apple(buf)) {
+ u8 mybuf[8];
+ if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_BRANCH_OUI + 3,
mybuf, 8)) {
+ if (drm_dp_apple_has_load_detect(mybuf)) {
+ DRM_DEBUG_KMS("detected Apple DP VGA dongle\n");
+ intel_dp->is_apple_vga = true;
+ }
+ }
+ }
edp_panel_vdd_off(intel_dp, false);
}
@@ -3404,6 +3414,21 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (drm_probe_ddc(&intel_dp->aux.ddc))
return connector_status_connected;
+ if (intel_dp->is_apple_vga) {
+ u8 detect_buf;
+ int ret;
+ ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_APPLE_LOAD_DETECT,
+ &detect_buf);
+
+ if (ret == 1) {
+ DRM_DEBUG_KMS("Apple VGA detect is 0x%x\n", detect_buf);
+ /* I suspect 4 == load, 8 == edid */
+ if (detect_buf)
+ return connector_status_connected;
+ else
+ return connector_status_disconnected;
+ }
+ }
/* Well we tried, say unknown for unreliable port types */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
@@ -3854,6 +3879,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
* but for short hpds we should check it now
*/
intel_dp_check_link_status(intel_dp);
+
+ /* if we get a short hpd on apple vga - its a hotplug */
+ if (intel_dp->is_apple_vga)
+ return true;
}
}
return false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1edb38a..23f767c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -549,6 +549,7 @@ struct intel_dp {
bool use_tps3;
bool can_mst; /* this port supports mst */
bool is_mst;
+ bool is_apple_vga;
int active_mst_links;
/* connector directly attached - won't be use for modeset in mst world
*/
struct intel_connector *attached_connector;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 517d6c1..c8ebd27 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -612,4 +612,23 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
drm_dp_link *link);
int drm_dp_aux_register(struct drm_dp_aux *aux);
void drm_dp_aux_unregister(struct drm_dp_aux *aux);
+#define DP_APPLE_OUI 0x10fa
+
+#define DP_APPLE_LOAD_DETECT (DP_BRANCH_OUI + 12)
+
+static inline bool drm_dp_branch_is_apple(const u8 buf[3])
+{
+ if (buf[0] == ((DP_APPLE_OUI >> 16) & 0xff) &&
+ buf[1] == ((DP_APPLE_OUI >> 8) & 0xff) &&
+ buf[2] == ((DP_APPLE_OUI & 0xff)))
+ return true;
+ return false;
+}
+
+static inline bool drm_dp_apple_has_load_detect(const u8 buf[8])
+{
+ if (!memcmp((const char *)buf, "mVGAa", 5))
+ return true;
+ return false;
+}
#endif /* _DRM_DP_HELPER_H_ */
--
1.9.3
[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #2 from Michel D?nzer --- It might be worth getting the PITCAIRN_mc2.bin microcode and trying a 3.15 kernel. Does this happen with particular pictures or randomly? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/5acf1f44/attachment.html>
[PULL] drm-intel-fixes
Hi Dave, Bunch of stuff for 3.16 still: - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've squeezed this in since it's a regression compared to vbios and we've been ridiculed about it a bit too often ... - connection_mutex deadlock fix in get_connector (only affects i915). - Core patches from Matt's primary plane from Matt Roper, I've pushed the i915 stuff to 3.17. - vlv power well sequencing fixes from Jesse. - Fix for cursor size changes from Chris. - agpbusy fixes from Ville. - A few smaller things. >From here on Jani will take over shepherding 3.16. Cheers, Daniel The following changes since commit 5ea1f752ae04be403a3dc8ec876a60d7f5f6990a: drm: add drm_fb_helper_restore_fbdev_mode_unlocked() (2014-06-05 10:02:40 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel danvet/drm-intel-fixes for you to fetch changes up to 15d24aa5602fb87c7b1358cfabcfeb9b26db290f: drm/i915: BDW: Adding missing cursor offsets. (2014-06-05 16:10:29 +0200) Akash Goel (1): drm/i915/vlv: Modifying WA 'WaDisableL3Bank2xClockGate for vlv Ben Widawsky (1): drm/i915/bdw: Only use 2g GGTT for 32b platforms Chris Wilson (2): drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent object drm/i915: Always apply cursor width changes Daniel Vetter (8): drm/i915: Add fifo underrun reporting state to debugfs drm/i915: Fix up fifo underrun tracking, take N drm/i915: Disable gpu reset on i965g/gm drm/i915: Inline ilk/gen8_irq_reset drm/i915: Improve irq handling after gpu resets drm/i915: Extract gen8_gt_irq_reset drm/i915: Nuke pipe A quirk on i830M drm: Fix getconnector connection_mutex locking Imre Deak (2): drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering drm/i915: fix display power sw state reporting Jani Nikula (1): drm/i915: tell the user if both KMS and UMS are disabled Jesse Barnes (7): drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3 drm/i915/vlv: drop power well enable in uncore_sanitize drm/i915/vlv: move CRI refclk enable into __vlv_set_power_well drm/i915/vlv: re-order power wells so DPIO common comes after TX drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_well drm/i915/vlv: add pll assertion when disabling DPIO common well drm/i915: use VBT to determine whether to enumerate the VGA port Matt Roper (2): drm: Check CRTC compatibility in setplane drm/plane-helper: Add drm_plane_helper_check_update() (v3) Rodrigo Vivi (1): drm/i915: BDW: Adding missing cursor offsets. Shobhit Kumar (2): drm/i915: Add support for Generic MIPI panel driver drm/i915: Detect if MIPI panel based on VBT and initialize only if present Ville Syrj?l? (5): drm/i915: Set AGPBUSY# bit in init_clock_gating drm/i915: Flip the sense of AGPBUSY_DIS bit drm/i915: Enable interrupt-based AGPBUSY# enable on 85x drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() for KMS drm/i915: Don't WARN about ring idle bit on gen2 drivers/gpu/drm/drm_crtc.c | 11 +- drivers/gpu/drm/drm_plane_helper.c | 131 +-- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_debugfs.c| 6 +- drivers/gpu/drm/i915/i915_drv.c| 19 +- drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/i915_gem.c| 4 +- drivers/gpu/drm/i915/i915_gem_gtt.c| 7 + drivers/gpu/drm/i915/i915_irq.c| 83 ++-- drivers/gpu/drm/i915/i915_reg.h| 6 +- drivers/gpu/drm/i915/intel_bios.c | 13 + drivers/gpu/drm/i915/intel_bios.h | 4 + drivers/gpu/drm/i915/intel_display.c | 145 --- drivers/gpu/drm/i915/intel_drv.h | 6 +- drivers/gpu/drm/i915/intel_dsi.c | 30 +- drivers/gpu/drm/i915/intel_dsi.h | 2 + drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 589 + drivers/gpu/drm/i915/intel_pm.c| 95 - drivers/gpu/drm/i915/intel_ringbuffer.c| 2 +- drivers/gpu/drm/i915/intel_uncore.c| 21 +- include/drm/drm_plane_helper.h | 22 ++ 21 files changed, 981 insertions(+), 218 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
linux-next: build failure after merge of the drm-intel-fixes tree
On Fri, Jun 6, 2014 at 4:03 AM, Stephen Rothwell
wrote:
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build
> (x86_64 allmodconfig) failed like this:
>
>
> drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config':
> drivers/gpu/drm/i915/intel_fbdev.c:392:4: error: implicit declaration of
> function 'drm_get_connector_name' [-Werror=implicit-function-declaration]
> DRM_DEBUG_KMS("using first mode listed on connector %s\n",
> ^
>
> This is just the error I reported yesterday against the drm and
> drm-intel trees, but migrated to the drm-intel-fixes tree. Your -fixes
> tree shoudl really only contain stuff that depend on Linus' trees ...
> but here it include all of yesterday's drm tree as well.
Should be fixed now since Dave pushed out the backmerge to drm-next
with the resolution.
I'm sorry about the mess this caused but Linus' interleaved merge
window has caused quite a havoc with my branch model here. But since I
have everything ready already and no outstanding fixes I've moved
drm-intel-fixes already over to track 3.17 and gather patches on top
of the all the work readied before the merge window.
> I have used the drm-intel-fixes tree from next-20140605 for today.
I think you should drop drm-intel-fixes until 3.16 is out and the
merge window properly public, otherwise this mess will repeat.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PULL] drm-intel-fixes
On Fri, Jun 06, 2014 at 08:38:36AM +0200, Daniel Vetter wrote: > Hi Dave, > > Bunch of stuff for 3.16 still: > - Mipi dsi panel support for byt. Finally! From Shobhit&others. I've > squeezed this in since it's a regression compared to vbios and we've > been ridiculed about it a bit too often ... > - connection_mutex deadlock fix in get_connector (only affects i915). > - Core patches from Matt's primary plane from Matt Roper, I've pushed the > i915 stuff to 3.17. > - vlv power well sequencing fixes from Jesse. > - Fix for cursor size changes from Chris. > - agpbusy fixes from Ville. > - A few smaller things. > > From here on Jani will take over shepherding 3.16. > > Cheers, Daniel > > > The following changes since commit 5ea1f752ae04be403a3dc8ec876a60d7f5f6990a: > > drm: add drm_fb_helper_restore_fbdev_mode_unlocked() (2014-06-05 10:02:40 > +1000) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel danvet/drm-intel-fixes > > for you to fetch changes up to 15d24aa5602fb87c7b1358cfabcfeb9b26db290f: git2 broke my script and didn't replace the internal branch any more with the public tag. Here's the right thing to pull (otherwise unchanged): The following changes since commit 5ea1f752ae04be403a3dc8ec876a60d7f5f6990a: drm: add drm_fb_helper_restore_fbdev_mode_unlocked() (2014-06-05 10:02:40 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-06-06 for you to fetch changes up to 15d24aa5602fb87c7b1358cfabcfeb9b26db290f: drm/i915: BDW: Adding missing cursor offsets. (2014-06-05 16:10:29 +0200) Cheers, Daniel > > drm/i915: BDW: Adding missing cursor offsets. (2014-06-05 16:10:29 +0200) > > > Akash Goel (1): > drm/i915/vlv: Modifying WA 'WaDisableL3Bank2xClockGate for vlv > > Ben Widawsky (1): > drm/i915/bdw: Only use 2g GGTT for 32b platforms > > Chris Wilson (2): > drm/i915: Silence the WARN if the user tries to GTT mmap an incoherent > object > drm/i915: Always apply cursor width changes > > Daniel Vetter (8): > drm/i915: Add fifo underrun reporting state to debugfs > drm/i915: Fix up fifo underrun tracking, take N > drm/i915: Disable gpu reset on i965g/gm > drm/i915: Inline ilk/gen8_irq_reset > drm/i915: Improve irq handling after gpu resets > drm/i915: Extract gen8_gt_irq_reset > drm/i915: Nuke pipe A quirk on i830M > drm: Fix getconnector connection_mutex locking > > Imre Deak (2): > drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable > ordering > drm/i915: fix display power sw state reporting > > Jani Nikula (1): > drm/i915: tell the user if both KMS and UMS are disabled > > Jesse Barnes (7): > drm/i915/vlv: assert and de-assert sideband reset at boot and resume v3 > drm/i915/vlv: drop power well enable in uncore_sanitize > drm/i915/vlv: move CRI refclk enable into __vlv_set_power_well > drm/i915/vlv: re-order power wells so DPIO common comes after TX > drm/i915/vlv: move DPIO common reset de-assert into __vlv_set_power_well > drm/i915/vlv: add pll assertion when disabling DPIO common well > drm/i915: use VBT to determine whether to enumerate the VGA port > > Matt Roper (2): > drm: Check CRTC compatibility in setplane > drm/plane-helper: Add drm_plane_helper_check_update() (v3) > > Rodrigo Vivi (1): > drm/i915: BDW: Adding missing cursor offsets. > > Shobhit Kumar (2): > drm/i915: Add support for Generic MIPI panel driver > drm/i915: Detect if MIPI panel based on VBT and initialize only if > present > > Ville Syrj?l? (5): > drm/i915: Set AGPBUSY# bit in init_clock_gating > drm/i915: Flip the sense of AGPBUSY_DIS bit > drm/i915: Enable interrupt-based AGPBUSY# enable on 85x > drm/i915: Move the C3 LP write bit setup to gen3_init_clock_gating() > for KMS > drm/i915: Don't WARN about ring idle bit on gen2 > > drivers/gpu/drm/drm_crtc.c | 11 +- > drivers/gpu/drm/drm_plane_helper.c | 131 +-- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/i915_debugfs.c| 6 +- > drivers/gpu/drm/i915/i915_drv.c| 19 +- > drivers/gpu/drm/i915/i915_drv.h| 2 + > drivers/gpu/drm/i915/i915_gem.c| 4 +- > drivers/gpu/drm/i915/i915_gem_gtt.c| 7 + > drivers/gpu/drm/i915/i915_irq.c| 83 ++-- > drivers/gpu/drm/i915/i915_reg.h| 6 +- > drivers/gpu/drm/i915/intel_bios.c | 13 + > drivers/gpu/drm/i915/intel_bios.h | 4 + > drivers/gpu/drm/i915/intel_display.c | 145 --- > drivers/gpu/drm/i915/intel_drv.h | 6 +- > drivers/gpu/drm/i915/intel_dsi.c | 30 +- > drivers/gpu/drm/i915/intel_dsi.h | 2 + > drivers/gpu/drm/i91
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #21 from Teofilis Martisius --- Created attachment 138351 --> https://bugzilla.kernel.org/attachment.cgi?id=138351&action=edit Dmesg output from 3.15rc8 without radeon.dpm=1 switch Dmesg output from 3.15rc8 without radeon.dpm=1 switch and without radeon.runpm=0 switch. Command line: BOOT_IMAGE=/boot/vmlinuz-3.15.0-rc8 root=UUID=6b66e960-0da6-4a99-abfe-f23614b50db9 ro quiet radeon.audio=0 modeset=1 radeon.no_wb=1 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/5] vt: Don't ignore unbind errors in vt_unbind
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Otherwise the loop will never stop since we don't make any
> forward progress. Noticed while breaking this accidentally
> in a painful attempt to make vga_con unregistering work.
>
> With this patch we'll bail out on the first attempt, which
> at least leaves a useful enough system behind for debugging.
> Livelocks on console_lock just aren't fun.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Signed-off-by: Daniel Vetter
We used to return 0 on errors here, which is very backwards to me.. so
your change to use "retval" looks fine to me. This is:
Reviewed-by: David Herrmann
Thanks
David
> ---
> drivers/tty/vt/vt.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 5077fe87324d..3c00dcb3b145 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3260,6 +3260,7 @@ static int vt_unbind(struct con_driver *con)
> {
> const struct consw *csw = NULL;
> int i, more = 1, first = -1, last = -1, deflt = 0;
> + int ret;
>
> if (!con->con || !(con->flag & CON_DRIVER_FLAG_MODULE) ||
> con_is_graphics(con->con, con->first, con->last))
> @@ -3285,8 +3286,10 @@ static int vt_unbind(struct con_driver *con)
>
> if (first != -1) {
> console_lock();
> - do_unbind_con_driver(csw, first, last, deflt);
> + ret = do_unbind_con_driver(csw, first, last, deflt);
> console_unlock();
> + if (ret != 0)
> + return ret;
> }
>
> first = -1;
> --
> 1.8.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] vt: Fix replacement console check when unbinding
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> I don't fully understand the magic of the vt register/unregister
> logic, but apparently everything but the inital console (as set
> in the conswitchp pointer) is marked with FLAG_MODULE. Which means
> if something unregistered the boot vt driver (e.g. i915.ko kicking
> out vga_con) there's nothing left when trying to unbind e.g. fbcon
> through sysfs.
>
> But we always have the dummy console hanging around, so this test
> is fairly dubious. What we actually want is simply a different console
> than the one we want to unbind.
For unknown reasons, you can disable the dummy console via Kconfig, so
it's not guaranteed to be around. But your comment is still valid.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Signed-off-by: Daniel Vetter
> ---
> drivers/tty/vt/vt.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 3ad0b61e35b4..ea600f482eeb 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3155,8 +3155,7 @@ int do_unbind_con_driver(const struct consw *csw, int
> first, int last, int deflt
> for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> con_back = ®istered_con_driver[i];
>
> - if (con_back->con &&
> - !(con_back->flag & CON_DRIVER_FLAG_MODULE)) {
> + if (con_back->con && con_back->con != csw) {
Funny thing is, if you run do_bind_con_driver() on the range first,
you kick out the existing driver and can then unload it regardless
whether the fallback was FLAG_MODULE or not. Therefore, I think that
change is safe. This is:
Reviewed-by: David Herrmann
Thanks
David
> defcsw = con_back->con;
> retval = 0;
> break;
> --
> 1.8.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] vt: Fix up unregistration of vt drivers
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> A bunch of issues:
> - We should not kick out the default console (which is tracked in
> conswitchp), so check for that.
> - Add better error codes so callers can differentiate between "something
> went wrong" and "your driver isn't registered already". i915 needs
> that so it doesn't fall over when reloading the driver and hence
> vga_con is already unregistered.
> - There's a mess with the driver flags: What we need to check for is
> that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
> And not whether it's the boot console or not (which is the only one
> which doesn't have FLAG_MODULE). Otherwise there's no way to kick
> out the boot console, which i915 wants to do to prevent havoc with
> vga_con interferring (which tends to hang machines).
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Signed-off-by: Daniel Vetter
> ---
> drivers/tty/vt/vt.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index ea600f482eeb..5077fe87324d 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3573,17 +3573,20 @@ err:
> */
> int do_unregister_con_driver(const struct consw *csw)
> {
> - int i, retval = -ENODEV;
> + int i;
>
> /* cannot unregister a bound driver */
> if (con_is_bound(csw))
> - goto err;
> + return -EBUSY;
> +
> + if (csw == conswitchp)
> + return -EINVAL;
Ugh, that fix is correct, but I'd rather like to see
do_unbind_con_driver() do the right thing. It currently resets
conswitchp _only_ if the new fallback is unbound. Why not _always_ set
conswitchp to defcsw _iff_ conswitchp == csw there?
This way, you _know_ here that if !con_is_bound(csw), then csw != conswitchp.
>
> for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> struct con_driver *con_driver = ®istered_con_driver[i];
>
> if (con_driver->con == csw &&
> - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
> + con_driver->flag & CON_DRIVER_FLAG_INIT) {
That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
why FLAG_MODULE exists, anyway.
Otherwise looks good.
Thanks
David
> vtconsole_deinit_device(con_driver);
> device_destroy(vtconsole_class,
>MKDEV(0, con_driver->node));
> @@ -3594,12 +3597,11 @@ int do_unregister_con_driver(const struct consw *csw)
> con_driver->flag = 0;
> con_driver->first = 0;
> con_driver->last = 0;
> - retval = 0;
> - break;
> + return 0;
> }
> }
> -err:
> - return retval;
> +
> + return -ENODEV;
> }
> EXPORT_SYMBOL_GPL(do_unregister_con_driver);
>
> --
> 1.8.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: Kick out vga console
Hi
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbcon.
>
> Also, we want this to make I915_FBDEV=n safe.
>
> v2: Rebase and pimp commit message.
>
> v3: We also need to unregister the vga console, otherwise the unbind
> of the fb console before module unload might resurrect it again.
>
> v4: Ignore errors when the vga console is already unregistered - this
> can happen when e.g. reloading i915.ko.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jani Nikula
> Signed-off-by: Chris Wilson (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 43
> +++-
> drivers/video/console/dummycon.c | 1 +
> drivers/video/console/vgacon.c | 1 +
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 27fe65ac5940..bcb66ddd649e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -36,6 +36,8 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct
> drm_i915_private *dev_priv)
> }
> #endif
>
> +#if !defined(CONFIG_VGA_CONSOLE)
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return 0;
> +}
> +#elif !defined(CONFIG_DUMMY_CONSOLE)
Why not "select DUMMY_CONSOLE if VT"? It's really stupid to disable
DUMMY_CONSOLE.. Furthermore, we already rely on HW_CONSOLE_BINDING so
this should be safe.
Patch looks good to me:
Reviewed-by: David Herrmann
Thanks
David
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return -ENODEV;
> +}
> +#else
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + int ret;
> +
> + DRM_INFO("Replacing VGA console driver\n");
> +
> + console_lock();
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (ret == 0) {
> + ret = do_unregister_con_driver(&vga_con);
> +
> + /* Ignore "already unregistered". */
> + if (ret == -ENODEV)
> + ret = 0;
> + }
> + console_unlock();
> +
> + return ret;
> +}
> +#endif
> +
> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
> {
> const struct intel_device_info *info = &dev_priv->info;
> @@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> if (ret)
> goto out_regs;
>
> - if (drm_core_check_feature(dev, DRIVER_MODESET))
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + ret = i915_kick_out_vgacon(dev_priv);
> + if (ret) {
> + DRM_ERROR("failed to remove conflicting VGA
> console\n");
> + goto out_gtt;
> + }
> +
> i915_kick_out_firmware_fb(dev_priv);
> + }
>
> pci_set_master(dev->pdev);
>
> diff --git a/drivers/video/console/dummycon.c
> b/drivers/video/console/dummycon.c
> index b63860f7beab..40bec8d64b0a 100644
> --- a/drivers/video/console/dummycon.c
> +++ b/drivers/video/console/dummycon.c
> @@ -77,3 +77,4 @@ const struct consw dummy_con = {
> .con_set_palette = DUMMY,
> .con_scrolldelta = DUMMY,
> };
> +EXPORT_SYMBOL_GPL(dummy_con);
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index 9d8feac67637..84acd6223dc5 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
> .con_build_attr = vgacon_build_attr,
> .con_invert_region = vgacon_invert_region,
> };
> +EXPORT_SYMBOL(vga_con);
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.4
>
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #22 from Teofilis Martisius --- Ok, I tried playing around with Linux 3.12, that's the last stable version before that commit. Booted with parameters: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=... ro quiet radeon.audio=0 modeset=1 radeon.dpm=1 radeon.no_wb=1 radeon.runpm=0 Executed: echo OFF >/sys/kernel/debug/vgaswitcheroo/switch dGPU got switched off, everything works fine. Got a message in dmesg: [ 1454.396648] radeon: switched off I don't want to spam attachments on this bug report, full dmesg output if needed at: http://menulis.org/kernel/dmesg_3.12_off1.log I tried it with radeon.runpm=1 as well, same results, everything works fine. Dmesg: http://menulis.org/kernel/dmesg_3.12_off2.log Let me know if you want these two dmesg logs attached here in bugzilla. Let me know if you need me to try something else next. Sincerely, Teofilis Martisius -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 5/5] drm/i915: Kick out vga console
On Fri, Jun 06, 2014 at 09:28:03AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > Touching the VGA resources on an IVB EFI machine causes hard hangs when
> > we then kick out the efifb. Ouch.
> >
> > Apparently this also prevents unclaimed register errors on hsw and
> > hard machine hangs on my i855gm when trying to unbind fbcon.
> >
> > Also, we want this to make I915_FBDEV=n safe.
> >
> > v2: Rebase and pimp commit message.
> >
> > v3: We also need to unregister the vga console, otherwise the unbind
> > of the fb console before module unload might resurrect it again.
> >
> > v4: Ignore errors when the vga console is already unregistered - this
> > can happen when e.g. reloading i915.ko.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> > Cc: David Herrmann
> > Cc: Jean-Christophe Plagniol-Villard
> > Cc: Tomi Valkeinen
> > Cc: linux-fbdev at vger.kernel.org
> > Cc: Jani Nikula
> > Signed-off-by: Chris Wilson (v1)
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 43
> > +++-
> > drivers/video/console/dummycon.c | 1 +
> > drivers/video/console/vgacon.c | 1 +
> > 3 files changed, 44 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 27fe65ac5940..bcb66ddd649e 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -36,6 +36,8 @@
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct
> > drm_i915_private *dev_priv)
> > }
> > #endif
> >
> > +#if !defined(CONFIG_VGA_CONSOLE)
> > +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > +{
> > + return 0;
> > +}
> > +#elif !defined(CONFIG_DUMMY_CONSOLE)
>
> Why not "select DUMMY_CONSOLE if VT"? It's really stupid to disable
> DUMMY_CONSOLE.. Furthermore, we already rely on HW_CONSOLE_BINDING so
> this should be safe.
Iirc this lead kconfig to complain about dep loops ... And I've tried to
figure it out, but I think it's actually impossible. So I let it be with
the -ENODEV to make sure if it's not impossible any more we'll catch it.
-Daniel
>
> Patch looks good to me:
>
> Reviewed-by: David Herrmann
>
> Thanks
> David
>
> > +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > +{
> > + return -ENODEV;
> > +}
> > +#else
> > +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > +{
> > + int ret;
> > +
> > + DRM_INFO("Replacing VGA console driver\n");
> > +
> > + console_lock();
> > + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> > + if (ret == 0) {
> > + ret = do_unregister_con_driver(&vga_con);
> > +
> > + /* Ignore "already unregistered". */
> > + if (ret == -ENODEV)
> > + ret = 0;
> > + }
> > + console_unlock();
> > +
> > + return ret;
> > +}
> > +#endif
> > +
> > static void i915_dump_device_info(struct drm_i915_private *dev_priv)
> > {
> > const struct intel_device_info *info = &dev_priv->info;
> > @@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > if (ret)
> > goto out_regs;
> >
> > - if (drm_core_check_feature(dev, DRIVER_MODESET))
> > + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > + ret = i915_kick_out_vgacon(dev_priv);
> > + if (ret) {
> > + DRM_ERROR("failed to remove conflicting VGA
> > console\n");
> > + goto out_gtt;
> > + }
> > +
> > i915_kick_out_firmware_fb(dev_priv);
> > + }
> >
> > pci_set_master(dev->pdev);
> >
> > diff --git a/drivers/video/console/dummycon.c
> > b/drivers/video/console/dummycon.c
> > index b63860f7beab..40bec8d64b0a 100644
> > --- a/drivers/video/console/dummycon.c
> > +++ b/drivers/video/console/dummycon.c
> > @@ -77,3 +77,4 @@ const struct consw dummy_con = {
> > .con_set_palette = DUMMY,
> > .con_scrolldelta = DUMMY,
> > };
> > +EXPORT_SYMBOL_GPL(dummy_con);
> > diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> > index 9d8feac67637..84acd6223dc5 100644
> > --- a/drivers/video/console/vgacon.c
> > +++ b/drivers/video/console/vgacon.c
> > @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
> > .con_build_attr = vgacon_build_attr,
> > .con_invert_region = vgacon_invert_region,
> > };
> > +EXPORT_SYMBOL(vga_con);
> >
> > MODULE_LICENSE("GPL");
> > --
> > 1.8.1.4
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/5] vt: Fix replacement console check when unbinding
On Fri, Jun 06, 2014 at 09:16:13AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > I don't fully understand the magic of the vt register/unregister
> > logic, but apparently everything but the inital console (as set
> > in the conswitchp pointer) is marked with FLAG_MODULE. Which means
> > if something unregistered the boot vt driver (e.g. i915.ko kicking
> > out vga_con) there's nothing left when trying to unbind e.g. fbcon
> > through sysfs.
> >
> > But we always have the dummy console hanging around, so this test
> > is fairly dubious. What we actually want is simply a different console
> > than the one we want to unbind.
>
> For unknown reasons, you can disable the dummy console via Kconfig, so
> it's not guaranteed to be around. But your comment is still valid.
Right, I'll reword this a bit to clarify.
>
> >
> > Cc: Greg Kroah-Hartman
> > Cc: Jiri Slaby
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/tty/vt/vt.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 3ad0b61e35b4..ea600f482eeb 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -3155,8 +3155,7 @@ int do_unbind_con_driver(const struct consw *csw, int
> > first, int last, int deflt
> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> > con_back = ®istered_con_driver[i];
> >
> > - if (con_back->con &&
> > - !(con_back->flag & CON_DRIVER_FLAG_MODULE)) {
> > + if (con_back->con && con_back->con != csw) {
>
> Funny thing is, if you run do_bind_con_driver() on the range first,
> you kick out the existing driver and can then unload it regardless
> whether the fallback was FLAG_MODULE or not. Therefore, I think that
> change is safe. This is:
>
> Reviewed-by: David Herrmann
>
> Thanks
> David
>
> > defcsw = con_back->con;
> > retval = 0;
> > break;
> > --
> > 1.8.1.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/5] vt: Fix up unregistration of vt drivers
On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> wrote:
> > A bunch of issues:
> > - We should not kick out the default console (which is tracked in
> > conswitchp), so check for that.
> > - Add better error codes so callers can differentiate between "something
> > went wrong" and "your driver isn't registered already". i915 needs
> > that so it doesn't fall over when reloading the driver and hence
> > vga_con is already unregistered.
> > - There's a mess with the driver flags: What we need to check for is
> > that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
> > And not whether it's the boot console or not (which is the only one
> > which doesn't have FLAG_MODULE). Otherwise there's no way to kick
> > out the boot console, which i915 wants to do to prevent havoc with
> > vga_con interferring (which tends to hang machines).
> >
> > Cc: Greg Kroah-Hartman
> > Cc: Jiri Slaby
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/tty/vt/vt.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index ea600f482eeb..5077fe87324d 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -3573,17 +3573,20 @@ err:
> > */
> > int do_unregister_con_driver(const struct consw *csw)
> > {
> > - int i, retval = -ENODEV;
> > + int i;
> >
> > /* cannot unregister a bound driver */
> > if (con_is_bound(csw))
> > - goto err;
> > + return -EBUSY;
> > +
> > + if (csw == conswitchp)
> > + return -EINVAL;
>
> Ugh, that fix is correct, but I'd rather like to see
> do_unbind_con_driver() do the right thing. It currently resets
> conswitchp _only_ if the new fallback is unbound. Why not _always_ set
> conswitchp to defcsw _iff_ conswitchp == csw there?
Ha, that's what I've thought, too. But do_unbind doesn't actually change
conswitchp, it only restores it because apparently the
vga_con->con_startup function is a real con and changes it behind
everyones back for no good reason. Or at least that's what the comment
claims. Note how defconsw != defcsw ...
I've tried to follow around how conswitchp is actually used, but besides
that it's used to select the boot console I'm not sure at all what's going
hence.
> This way, you _know_ here that if !con_is_bound(csw), then csw != conswitchp.
Hence why I dropped this approach again (I've done it originally) and
opted for the straightforward but albeit crude direct check.
> >
> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> > struct con_driver *con_driver = ®istered_con_driver[i];
> >
> > if (con_driver->con == csw &&
> > - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
> > + con_driver->flag & CON_DRIVER_FLAG_INIT) {
>
> That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
> why FLAG_MODULE exists, anyway.
I've dug around in git history and it's less than useful. It was renamed
from FLAG_BIND (which makes somewhat sense, since it roughly tracks
whether a console is bound). But there's never been a justification for
it, neither in the original patch nor in the one that renamed it.
So I decided to not tempt fate and went with the small change here that
I've understood somewhat (I've tried other, more invasive changes and
failed).
> Otherwise looks good.
I'm really reluctant to do the right thing here since the code overall has
very unclear semantics with conswitchp and FLAG_MODULE. Can I convince
yout that the more direct approach here is the right one?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 79504] LLVM error on fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=79504 --- Comment #10 from Kyle Blake --- Created attachment 100512 --> https://bugs.freedesktop.org/attachment.cgi?id=100512&action=edit full testcase Sorry for the delay. Attached is a new test case that actually uses the shaders. When it calls glDrawElements(), everything goes to hell, triggering random segfault, graphics memory corruption, and kernel panics. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/b1cb38cd/attachment.html>
[PATCH 2/5] vt: Fix up unregistration of vt drivers
Hi
On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
>> wrote:
>> > A bunch of issues:
>> > - We should not kick out the default console (which is tracked in
>> > conswitchp), so check for that.
>> > - Add better error codes so callers can differentiate between "something
>> > went wrong" and "your driver isn't registered already". i915 needs
>> > that so it doesn't fall over when reloading the driver and hence
>> > vga_con is already unregistered.
>> > - There's a mess with the driver flags: What we need to check for is
>> > that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
>> > And not whether it's the boot console or not (which is the only one
>> > which doesn't have FLAG_MODULE). Otherwise there's no way to kick
>> > out the boot console, which i915 wants to do to prevent havoc with
>> > vga_con interferring (which tends to hang machines).
>> >
>> > Cc: Greg Kroah-Hartman
>> > Cc: Jiri Slaby
>> > Signed-off-by: Daniel Vetter
>> > ---
>> > drivers/tty/vt/vt.c | 16 +---
>> > 1 file changed, 9 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>> > index ea600f482eeb..5077fe87324d 100644
>> > --- a/drivers/tty/vt/vt.c
>> > +++ b/drivers/tty/vt/vt.c
>> > @@ -3573,17 +3573,20 @@ err:
>> > */
>> > int do_unregister_con_driver(const struct consw *csw)
>> > {
>> > - int i, retval = -ENODEV;
>> > + int i;
>> >
>> > /* cannot unregister a bound driver */
>> > if (con_is_bound(csw))
>> > - goto err;
>> > + return -EBUSY;
>> > +
>> > + if (csw == conswitchp)
>> > + return -EINVAL;
>>
>> Ugh, that fix is correct, but I'd rather like to see
>> do_unbind_con_driver() do the right thing. It currently resets
>> conswitchp _only_ if the new fallback is unbound. Why not _always_ set
>> conswitchp to defcsw _iff_ conswitchp == csw there?
>
> Ha, that's what I've thought, too. But do_unbind doesn't actually change
> conswitchp, it only restores it because apparently the
> vga_con->con_startup function is a real con and changes it behind
> everyones back for no good reason. Or at least that's what the comment
> claims. Note how defconsw != defcsw ...
>
> I've tried to follow around how conswitchp is actually used, but besides
> that it's used to select the boot console I'm not sure at all what's going
> hence.
I missed that line:
const struct consw *defconsw = conswitchp;
Now that I looked at it again, this looks _really_ wrong. If
conswitchp is vgacon and startup fails, we keep it set to vgacon..
ugh, weird. But ok, that's up to the people who wrote that.
Btw., conswitchp is used for visual_init(), that is, every new VT
allocation gets assigned to conswitchp. Therefore, it must be a valid
driver. (VTs are allocated and deallocated by agetty/systemd after a
session is started/ended).
>> This way, you _know_ here that if !con_is_bound(csw), then csw != conswitchp.
>
> Hence why I dropped this approach again (I've done it originally) and
> opted for the straightforward but albeit crude direct check.
>
>> >
>> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
>> > struct con_driver *con_driver = ®istered_con_driver[i];
>> >
>> > if (con_driver->con == csw &&
>> > - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
>> > + con_driver->flag & CON_DRIVER_FLAG_INIT) {
>>
>> That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
>> why FLAG_MODULE exists, anyway.
>
> I've dug around in git history and it's less than useful. It was renamed
> from FLAG_BIND (which makes somewhat sense, since it roughly tracks
> whether a console is bound). But there's never been a justification for
> it, neither in the original patch nor in the one that renamed it.
>
> So I decided to not tempt fate and went with the small change here that
> I've understood somewhat (I've tried other, more invasive changes and
> failed).
>
>> Otherwise looks good.
>
> I'm really reluctant to do the right thing here since the code overall has
> very unclear semantics with conswitchp and FLAG_MODULE. Can I convince
> yout that the more direct approach here is the right one?
Yeah, patch looks good.
Reviewed-by: David Herrmann
Thanks
David
[PATCH 2/5] vt: Fix up unregistration of vt drivers
On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> Hi
>
> On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> >> Hi
> >>
> >> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter
> >> wrote:
> >> > A bunch of issues:
> >> > - We should not kick out the default console (which is tracked in
> >> > conswitchp), so check for that.
> >> > - Add better error codes so callers can differentiate between "something
> >> > went wrong" and "your driver isn't registered already". i915 needs
> >> > that so it doesn't fall over when reloading the driver and hence
> >> > vga_con is already unregistered.
> >> > - There's a mess with the driver flags: What we need to check for is
> >> > that the driver isn't used any more, i.e. unbound completely
> >> > (FLAG_INIT).
> >> > And not whether it's the boot console or not (which is the only one
> >> > which doesn't have FLAG_MODULE). Otherwise there's no way to kick
> >> > out the boot console, which i915 wants to do to prevent havoc with
> >> > vga_con interferring (which tends to hang machines).
> >> >
> >> > Cc: Greg Kroah-Hartman
> >> > Cc: Jiri Slaby
> >> > Signed-off-by: Daniel Vetter
> >> > ---
> >> > drivers/tty/vt/vt.c | 16 +---
> >> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >> >
> >> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> >> > index ea600f482eeb..5077fe87324d 100644
> >> > --- a/drivers/tty/vt/vt.c
> >> > +++ b/drivers/tty/vt/vt.c
> >> > @@ -3573,17 +3573,20 @@ err:
> >> > */
> >> > int do_unregister_con_driver(const struct consw *csw)
> >> > {
> >> > - int i, retval = -ENODEV;
> >> > + int i;
> >> >
> >> > /* cannot unregister a bound driver */
> >> > if (con_is_bound(csw))
> >> > - goto err;
> >> > + return -EBUSY;
> >> > +
> >> > + if (csw == conswitchp)
> >> > + return -EINVAL;
> >>
> >> Ugh, that fix is correct, but I'd rather like to see
> >> do_unbind_con_driver() do the right thing. It currently resets
> >> conswitchp _only_ if the new fallback is unbound. Why not _always_ set
> >> conswitchp to defcsw _iff_ conswitchp == csw there?
> >
> > Ha, that's what I've thought, too. But do_unbind doesn't actually change
> > conswitchp, it only restores it because apparently the
> > vga_con->con_startup function is a real con and changes it behind
> > everyones back for no good reason. Or at least that's what the comment
> > claims. Note how defconsw != defcsw ...
> >
> > I've tried to follow around how conswitchp is actually used, but besides
> > that it's used to select the boot console I'm not sure at all what's going
> > hence.
>
> I missed that line:
> const struct consw *defconsw = conswitchp;
>
> Now that I looked at it again, this looks _really_ wrong. If
> conswitchp is vgacon and startup fails, we keep it set to vgacon..
> ugh, weird. But ok, that's up to the people who wrote that.
>
> Btw., conswitchp is used for visual_init(), that is, every new VT
> allocation gets assigned to conswitchp. Therefore, it must be a valid
> driver. (VTs are allocated and deallocated by agetty/systemd after a
> session is started/ended).
Ah, I missed where conswitchp was used in the maze, was getting a bit hazy
;-)
Rules for changing/updateing conswitchp are indeed a bit strange, which is
why I really don't want to touch this too much.
> >> This way, you _know_ here that if !con_is_bound(csw), then csw !=
> >> conswitchp.
> >
> > Hence why I dropped this approach again (I've done it originally) and
> > opted for the straightforward but albeit crude direct check.
> >
> >> >
> >> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> >> > struct con_driver *con_driver =
> >> > ®istered_con_driver[i];
> >> >
> >> > if (con_driver->con == csw &&
> >> > - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
> >> > + con_driver->flag & CON_DRIVER_FLAG_INIT) {
> >>
> >> That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
> >> why FLAG_MODULE exists, anyway.
> >
> > I've dug around in git history and it's less than useful. It was renamed
> > from FLAG_BIND (which makes somewhat sense, since it roughly tracks
> > whether a console is bound). But there's never been a justification for
> > it, neither in the original patch nor in the one that renamed it.
> >
> > So I decided to not tempt fate and went with the small change here that
> > I've understood somewhat (I've tried other, more invasive changes and
> > failed).
> >
> >> Otherwise looks good.
> >
> > I'm really reluctant to do the right thing here since the code overall has
> > very unclear semantics with conswitchp and FLAG_MODULE. Can I convince
> > yout that the more direct approach here is the right one?
>
> Yeah, patch looks good.
>
> Reviewed-by: David Herrmann
Thanks for the review.
Greg, are you ok with these 3
[PATCH] vt: Fix replacement console check when unbinding
I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left when trying to unbind e.g. fbcon
through sysfs.
But in most cases have the dummy console hanging around besides the
boot console, so this test is fairly dubious. What we actually want is
simply a different console than the one we want to unbind.
v2: Correct the commit message to clarify that the dummy console isn't
always around, but only in most cases (David).
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Herrmann
Reviewed-by: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/tty/vt/vt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 3ad0b61e35b4..ea600f482eeb 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3155,8 +3155,7 @@ int do_unbind_con_driver(const struct consw *csw, int
first, int last, int deflt
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_back = ®istered_con_driver[i];
- if (con_back->con &&
- !(con_back->flag & CON_DRIVER_FLAG_MODULE)) {
+ if (con_back->con && con_back->con != csw) {
defcsw = con_back->con;
retval = 0;
break;
--
1.8.1.4
[Bug 79504] LLVM error on fragment shader
https://bugs.freedesktop.org/show_bug.cgi?id=79504
Michel D?nzer changed:
What|Removed |Added
Assignee|dri-devel at lists.freedesktop |idr at freedesktop.org
|.org|
QA Contact||intel-3d-bugs at lists.freedes
||ktop.org
Component|Drivers/Gallium/radeonsi|glsl-compiler
--- Comment #11 from Michel D?nzer ---
I run into the assertion failure below in the GLSL compiler. That should be
addressed first.
test2: ../../../src/glsl/ir_validate.cpp:436: virtual ir_visitor_status
{anonymous}::ir_validate::visit_leave(ir_expression*): Assertion
`ir->operands[0]->type == ir->operands[1]->type' failed.
Program received signal SIGABRT, Aborted.
0x775973a9 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x775973a9 in __GI_raise (sig=sig at entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x7759a4c8 in __GI_abort () at abort.c:89
#2 0x775904c6 in __assert_fail_base (fmt=0x776c7668 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n",
assertion=assertion at entry=0x744c6b40 "ir->operands[0]->type ==
ir->operands[1]->type", file=file at entry=0x744ee9d8
"../../../src/glsl/ir_validate.cpp", line=line at entry=436,
function=function at entry=0x744efd80 <(anonymous
namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__>
"virtual ir_visitor_status
{anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:92
#3 0x77590572 in __GI___assert_fail (assertion=0x744c6b40
"ir->operands[0]->type == ir->operands[1]->type", file=0x744ee9d8
"../../../src/glsl/ir_validate.cpp", line=436,
function=0x744efd80 <(anonymous
namespace)::ir_validate::visit_leave(ir_expression*)::__PRETTY_FUNCTION__>
"virtual ir_visitor_status
{anonymous}::ir_validate::visit_leave(ir_expression*)") at assert.c:101
#4 0x742e57b1 in (anonymous namespace)::ir_validate::visit_leave
(this=, ir=) at
../../../src/glsl/ir_validate.cpp:436
#5 0x742e2fdf in ir_assignment::accept (this=0xaaa360,
v=0x7fffe420) at ../../../src/glsl/ir_hv_accept.cpp:308
#6 0x742e2a16 in visit_list_elements (v=v at entry=0x7fffe420,
l=l at entry=0xaa95e8, statement_list=statement_list at entry=true) at
../../../src/glsl/ir_hv_accept.cpp:56
#7 0x742e3204 in ir_if::accept (this=0xaa95c0, v=0x7fffe420) at
../../../src/glsl/ir_hv_accept.cpp:391
#8 0x742e2a16 in visit_list_elements (v=v at entry=0x7fffe420,
l=l at entry=0x732698, statement_list=statement_list at entry=true) at
../../../src/glsl/ir_hv_accept.cpp:56
#9 0x742e2b79 in ir_function_signature::accept (this=0x732650,
v=0x7fffe420) at ../../../src/glsl/ir_hv_accept.cpp:116
#10 0x742e2a16 in visit_list_elements (v=v at entry=0x7fffe420,
l=l at entry=0x7324f8, statement_list=statement_list at entry=false) at
../../../src/glsl/ir_hv_accept.cpp:56
#11 0x742e2be7 in ir_function::accept (this=0x7324d0, v=0x7fffe420)
at ../../../src/glsl/ir_hv_accept.cpp:128
#12 0x742e2a16 in visit_list_elements (v=v at entry=0x7fffe420,
l=l at entry=0x6cc4a0, statement_list=statement_list at entry=true) at
../../../src/glsl/ir_hv_accept.cpp:56
#13 0x742e293f in ir_hierarchical_visitor::run
(this=this at entry=0x7fffe420, instructions=instructions at
entry=0x6cc4a0) at
../../../src/glsl/ir_hierarchical_visitor.cpp:309
#14 0x742e7ae0 in validate_ir_tree (instructions=0x6cc4a0) at
../../../src/glsl/ir_validate.cpp:817
#15 0x742d3d2b in _mesa_glsl_compile_shader
(ctx=ctx at entry=0x77fd4010, shader=shader at entry=0x6c1ea0,
dump_ast=dump_ast at entry=false, dump_hir=dump_hir at entry=false)
at ../../../src/glsl/glsl_parser_extras.cpp:1470
#16 0x741aa481 in compile_shader (ctx=0x77fd4010,
shaderObj=) at ../../../src/mesa/main/shaderapi.c:850
#17 0x00401c4f in create_shader ()
#18 0x00402073 in init_resources ()
#19 0x004027ec in main ()
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/babeb0aa/attachment.html>
[PATCH] [RFC] drm/i915/dp: add support for load detect Apple DP->VGA dongles
On Fri, 06 Jun 2014, Dave Airlie wrote:
> From: Dave Airlie
>
> The DP1.2 spec has some bits for forced load sensing on VGA dongles,
> however the apple dongle I have doesn't do DP 1.2 yet, so I dug into
> its vendor specific area and found a register that seems to correspond
> to load detected on the outputs.
>
> The main reason I need this was at LCA this year the slide capture system
> failed to provide EDID, but I realised OSX worked. Really need to add support
> to nouveau, but hey i915 is a start.
>
> The dongle also appears to use short IRQs to denote a plug/unplug event,
> though something seems to be failing in reading back the dpcd values from it.
> (also this is based on my MST work just because.)
Good timing for making use of the OUI! See
http://mid.gmane.org/1401920981-3137-1-git-send-email-clinton.a.taylor at
intel.com
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/intel_dp.c | 29 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> include/drm/drm_dp_helper.h | 19 +++
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index c500f63..49afd7d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3173,6 +3173,16 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
> DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
> buf[0], buf[1], buf[2]);
>
> + intel_dp->is_apple_vga = false;
> + if (drm_dp_branch_is_apple(buf)) {
> + u8 mybuf[8];
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_BRANCH_OUI + 3,
> mybuf, 8)) {
That may return negative values for errors.
FWIW I've thought about reading the sink/branch device identification
strings unconditionally along with the OUI just for debug purposes. I
wouldn't be opposed to such a change here.
> + if (drm_dp_apple_has_load_detect(mybuf)) {
> + DRM_DEBUG_KMS("detected Apple DP VGA dongle\n");
> + intel_dp->is_apple_vga = true;
> + }
> + }
> + }
I think I'd like this abstracted to a dedicated function and doing:
intel_dp->is_apple_vga = is_apple_vga(intel_dp, buf);
or something.
> edp_panel_vdd_off(intel_dp, false);
> }
>
> @@ -3404,6 +3414,21 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
> if (drm_probe_ddc(&intel_dp->aux.ddc))
> return connector_status_connected;
>
> + if (intel_dp->is_apple_vga) {
> + u8 detect_buf;
> + int ret;
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_APPLE_LOAD_DETECT,
> + &detect_buf);
> +
> + if (ret == 1) {
> + DRM_DEBUG_KMS("Apple VGA detect is 0x%x\n", detect_buf);
> + /* I suspect 4 == load, 8 == edid */
> + if (detect_buf)
> + return connector_status_connected;
> + else
> + return connector_status_disconnected;
> + }
> + }
> /* Well we tried, say unknown for unreliable port types */
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
> type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> @@ -3854,6 +3879,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
>* but for short hpds we should check it now
>*/
> intel_dp_check_link_status(intel_dp);
> +
> + /* if we get a short hpd on apple vga - its a hotplug */
> + if (intel_dp->is_apple_vga)
> + return true;
> }
> }
> return false;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1edb38a..23f767c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -549,6 +549,7 @@ struct intel_dp {
> bool use_tps3;
> bool can_mst; /* this port supports mst */
> bool is_mst;
> + bool is_apple_vga;
> int active_mst_links;
> /* connector directly attached - won't be use for modeset in mst world
> */
> struct intel_connector *attached_connector;
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 517d6c1..c8ebd27 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -612,4 +612,23 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
> drm_dp_link *link);
> int drm_dp_aux_register(struct drm_dp_aux *aux);
> void drm_dp_aux_unregister(struct drm_dp_aux *aux);
>
> +#define DP_APPLE_OUI 0x10fa
> +
> +#define DP_APPLE_LOAD_DETECT (DP_BRANCH_OUI + 12)
> +
> +static inline bool drm_dp_branch_is_apple(const u8 buf[3])
Naming buf and its size simila
[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #3 from Marti Raudsepp --- > Does this happen with particular pictures or randomly? I haven't tried to reproduce it yet, I will try to find the time for it. > It might be worth getting the PITCAIRN_mc2.bin microcode and trying a 3.15 > kernel. I guess once I've managed to reproduce it, otherwise we don't know if it fixes anything. PITCAIRN_mc2.bin will be included with the kernel 3.15 firmware package right? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/2bcd10ce/attachment.html>
[PATCH 1/5] drm/i915: preserve SSC if previously set v2
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there. So check for it and keep it enabled if we see it
> already on. Based on an earlier fix from Kristian.
>
> v2: honor modparam if set too (Daniel)
> read out at init time and store for panel_use_ssc() use (Jesse)
>
> Reported-by: Kristian H?gsberg
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 11 ++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8631fb3..f57b752 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1404,6 +1404,8 @@ struct drm_i915_private {
> struct intel_opregion opregion;
> struct intel_vbt_data vbt;
>
> + bool bios_ssc; /* BIOS had SSC enabled at boot? */
> +
> /* overlay */
> struct intel_overlay *overlay;
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b5cbb28..0e8c9bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5355,7 +5355,7 @@ static inline bool intel_panel_use_ssc(struct
> drm_i915_private *dev_priv)
> {
> if (i915.panel_use_ssc >= 0)
> return i915.panel_use_ssc != 0;
> - return dev_priv->vbt.lvds_use_ssc
> + return (dev_priv->vbt.lvds_use_ssc || dev_priv->bios_ssc)
> && !(dev_priv->quirks & QUIRK_LVDS_SSC_DISABLE);
> }
>
> @@ -12478,6 +12478,7 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
>
> void intel_modeset_gem_init(struct drm_device *dev)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *c;
> struct intel_framebuffer *fb;
>
> @@ -12485,6 +12486,14 @@ void intel_modeset_gem_init(struct drm_device *dev)
> intel_init_gt_powersave(dev);
> mutex_unlock(&dev->struct_mutex);
>
> + /*
> + * There may be no VBT; and if the BIOS enabled SSC we can
> + * just keep using it to avoid unnecessary flicker.
> + */
> + if ((HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) &&
> + (I915_READ(PCH_DREF_CONTROL) & DREF_SSC1_ENABLE))
> + dev_priv->bios_ssc = true;
Do we have any need to differentiate between this and what VBT has? We
could just treat dev_priv->vbt as "VBT or what BIOS did", and do
dev_priv->vbt.lvds_use_ssc = true; here, possibly with a
DRM_DEBUG_KMS. It would simplify code elsewhere and be less error prone.
We already do a similar thing for the eDP bpp (see intel_dp.c, look for
"This is a big fat ugly hack").
BR,
Jani.
> +
> intel_modeset_init_hw(dev);
>
> intel_setup_overlay(dev);
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 1/5] drm/i915: preserve SSC if previously set v2
On Fri, Jun 06, 2014 at 02:04:21PM +0300, Jani Nikula wrote: > Do we have any need to differentiate between this and what VBT has? We > could just treat dev_priv->vbt as "VBT or what BIOS did", and do > dev_priv->vbt.lvds_use_ssc = true; here, possibly with a > DRM_DEBUG_KMS. It would simplify code elsewhere and be less error prone. > We already do a similar thing for the eDP bpp (see intel_dp.c, look for > "This is a big fat ugly hack"). Indeed, that is a nice simplification. Conceptually, at least. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 5/5] drm/i915: enable fastboot by default
On Thu, 05 Jun 2014, Jesse Barnes wrote:
> Let them eat mincemeat pie.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_params.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index d05a2af..081ab2f 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
> .preliminary_hw_support =
> IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
> .disable_power_well = 1,
> .enable_ips = 1,
> - .fastboot = 0,
> + .fastboot = 42,
The answer to the ultimate question of life, the universe, and
everything should simply be "true" here. Personally, I don't think it's
a bad answer.
> .prefault_disable = 0,
> .reset = true,
> .invert_brightness = 0,
> @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, "Enable IPS (default:
> true)");
>
> module_param_named(fastboot, i915.fastboot, bool, 0600);
Side note, why do we allow the param to be changed after boot?
BR,
Jani.
> MODULE_PARM_DESC(fastboot,
> - "Try to skip unnecessary mode sets at boot time (default: false)");
> + "Try to skip unnecessary mode sets at boot time (default: true)");
>
> module_param_named(prefault_disable, i915.prefault_disable, bool, 0600);
> MODULE_PARM_DESC(prefault_disable,
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
ast2400 woes
Hi Dave ! So your AST driver in -next is blowing up on my power8 box :-) There are several issues that I want to discuss here (YC Chen on CC might also have some valuable input here). * First, accessors. The first obvious cause for blowing up for me is that you are using the "old style" PIO offsets for these guys: #define AST_IO_AR_PORT_WRITE(0x40) #define AST_IO_MISC_PORT_WRITE (0x42) #define AST_IO_SEQ_PORT (0x44) #define AST_DAC_INDEX_READ (0x3c7) #define AST_IO_DAC_INDEX_WRITE (0x48) #define AST_IO_DAC_DATA (0x49) #define AST_IO_GR_PORT (0x4E) #define AST_IO_CRTC_PORT(0x54) #define AST_IO_INPUT_STATUS1_READ (0x5A) #define AST_IO_MISC_PORT_READ (0x4C) (And accessing them via PIO) And I don't have PIO on that platform at all :-) I tried using MMIO, but the above offsets don't work. Those things are accessible via the MMIO BAR which is much better via these offsets: #define AR_PORT_WRITE (pAST->MMIOVirtualAddr + 0x3c0) #define MISC_PORT_WRITE (pAST->MMIOVirtualAddr + 0x3c2) #define VGA_ENABLE_PORT (pAST->MMIOVirtualAddr + 0x3c3) #define SEQ_PORT(pAST->MMIOVirtualAddr + 0x3c4) #define DAC_INDEX_READ (pAST->MMIOVirtualAddr + 0x3c7) #define DAC_INDEX_WRITE (pAST->MMIOVirtualAddr + 0x3c8) #define DAC_DATA(pAST->MMIOVirtualAddr + 0x3c9) #define GR_PORT (pAST->MMIOVirtualAddr + 0x3cE) #define CRTC_PORT (pAST->MMIOVirtualAddr + 0x3d4) #define INPUT_STATUS1_READ (pAST->MMIOVirtualAddr + 0x3dA) #define MISC_PORT_READ (pAST->MMIOVirtualAddr + 0x3cc) (From the X driver). The spec is pretty tricky to read but seems to indicate that the above offset should also work for PIO if needed, however, it seems like the X driver is pretty happy to use MMIO unconditionally for them. Any objection on me sending you a patch to send (almost) everybody to use the MMIO path ? The only remaining "issues" with PIO is the EnableVGA / IsVGAEnabled path which still uses PIO in X. Now, at least on the AST2400, the register in question is also on MMIO (3c3, aka VGA_ENABLE_PORT in the above list), but I don't know whether that works on all the older chipsets. (YC Chen on CC might have an opinion). * Then, I notice that you only POST the chip in the "thaw" path which as far as I can tell is only called on resume from sleep, am I correct ? We don't have a BIOS so we rely on the kernel driver doing the full init. For example we come up with VGA disabled, so the driver must enable it (via 3c3 MMIO !) first thing first. The current probe code will just blow up even if adjusted to use the MMIO offsets due to trying to access the CRTC registers when VGA is disabled. This leads to the question, mostly for YC Chen I suppose: Is there a way to detect that the chip has been POSTed already by the BIOS or not ? Should we key that off VGA Enabled being 0 ? Cheers, Ben.
ast2400 woes
Hi Dave ! So your AST KMS driver in -next is blowing up on my power8 box :-) There are several issues that I want to discuss here (YC Chen on CC might also have some valuable input here) before I send you patches to fix it :-) * First, accessors. The first obvious cause for blowing up for me is that you are using the "old style" PIO offsets for these guys: #define AST_IO_AR_PORT_WRITE(0x40) #define AST_IO_MISC_PORT_WRITE (0x42) #define AST_IO_SEQ_PORT (0x44) #define AST_DAC_INDEX_READ (0x3c7) #define AST_IO_DAC_INDEX_WRITE (0x48) #define AST_IO_DAC_DATA (0x49) #define AST_IO_GR_PORT (0x4E) #define AST_IO_CRTC_PORT(0x54) #define AST_IO_INPUT_STATUS1_READ (0x5A) #define AST_IO_MISC_PORT_READ (0x4C) (And accessing them via PIO) And I don't have PIO on that platform at all :-) I tried using MMIO, but the above offsets don't work. Those things are accessible via the MMIO BAR which is much better via these offsets: #define AR_PORT_WRITE (pAST->MMIOVirtualAddr + 0x3c0) #define MISC_PORT_WRITE (pAST->MMIOVirtualAddr + 0x3c2) #define VGA_ENABLE_PORT (pAST->MMIOVirtualAddr + 0x3c3) #define SEQ_PORT(pAST->MMIOVirtualAddr + 0x3c4) #define DAC_INDEX_READ (pAST->MMIOVirtualAddr + 0x3c7) #define DAC_INDEX_WRITE (pAST->MMIOVirtualAddr + 0x3c8) #define DAC_DATA(pAST->MMIOVirtualAddr + 0x3c9) #define GR_PORT (pAST->MMIOVirtualAddr + 0x3cE) #define CRTC_PORT (pAST->MMIOVirtualAddr + 0x3d4) #define INPUT_STATUS1_READ (pAST->MMIOVirtualAddr + 0x3dA) #define MISC_PORT_READ (pAST->MMIOVirtualAddr + 0x3cc) (From the X driver). The spec is pretty tricky to read but seems to indicate that the above offset should also work for PIO if needed, however, it seems like the X driver is pretty happy to use MMIO unconditionally for them. Any objection on me sending you a patch to send (almost) everybody to use the MMIO path ? The only remaining "issues" with PIO is the EnableVGA / IsVGAEnabled path which still uses PIO in X. Now, at least on the AST2400, the register in question is also on MMIO (3c3, aka VGA_ENABLE_PORT in the above list), but I don't know whether that works on all the older chipsets. (YC Chen on CC might have an opinion). * Then, I notice that you only POST the chip in the "thaw" path which as far as I can tell is only called on resume from sleep, am I correct ? We don't have a BIOS so we rely on the kernel driver doing the full init. For example we come up with VGA disabled, so the driver must enable it (via 3c3 MMIO !) first thing first. The current probe code will just blow up even if adjusted to use the MMIO offsets due to trying to access the CRTC registers when VGA is disabled. This leads to the question, mostly for YC Chen I suppose: Is there a way to detect that the chip has been POSTed already by the BIOS or not ? Should we key that off VGA Enabled being 0 ? Cheers, Ben.
[PATCH 4/5] drm/i915: Fixup global gtt cleanup
On Thu, 2014-06-05 at 16:58 +0200, Daniel Vetter wrote:
> The global gtt is setup up in 2 parts, so we need to be careful
> with the cleanup. For consistency shovel it all into the ->cleanup
> callback, like with ppgtt.
>
> Noticed because it blew up in the out_gtt: cleanup code while
> fiddling with the vgacon code.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_dma.c | 4
> drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b9159ade5e85..27fe65ac5940 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1386,7 +1386,6 @@ cleanup_gem:
> i915_gem_context_fini(dev);
> mutex_unlock(&dev->struct_mutex);
> WARN_ON(dev_priv->mm.aliasing_ppgtt);
> - drm_mm_takedown(&dev_priv->gtt.base.mm);
> cleanup_irq:
> drm_irq_uninstall(dev);
> cleanup_gem_stolen:
> @@ -1756,8 +1755,6 @@ out_mtrrfree:
> arch_phys_wc_del(dev_priv->gtt.mtrr);
> io_mapping_free(dev_priv->gtt.mappable);
> out_gtt:
> - list_del(&dev_priv->gtt.base.global_link);
> - drm_mm_takedown(&dev_priv->gtt.base.mm);
> dev_priv->gtt.base.cleanup(&dev_priv->gtt.base);
> out_regs:
> intel_uncore_fini(dev);
> @@ -1846,7 +1843,6 @@ int i915_driver_unload(struct drm_device *dev)
> i915_free_hws(dev);
> }
>
> - list_del(&dev_priv->gtt.base.global_link);
> WARN_ON(!list_empty(&dev_priv->vm_list));
>
> drm_vblank_cleanup(dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 931b906f292a..41e864ec5632 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1985,7 +1985,10 @@ static void gen6_gmch_remove(struct i915_address_space
> *vm)
>
> struct i915_gtt *gtt = container_of(vm, struct i915_gtt, base);
>
> - drm_mm_takedown(&vm->mm);
> + if (drm_mm_initialized(&vm->mm)) {
> + drm_mm_takedown(&vm->mm);
> + list_del(&vm->global_link);
> + }
> iounmap(gtt->gsm);
> teardown_scratch_page(vm->dev);
> }
> @@ -2018,6 +2021,10 @@ static int i915_gmch_probe(struct drm_device *dev,
>
> static void i915_gmch_remove(struct i915_address_space *vm)
> {
> + if (drm_mm_initialized(&vm->mm)) {
> + drm_mm_takedown(&vm->mm);
> + list_del(&vm->global_link);
> + }
> intel_gmch_remove();
> }
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/774c4762/attachment.sig>
[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state
On Fri, Jun 06, 2014 at 02:56:43PM +0100, Russell King wrote: > The initial state at boot is assumed to be disconnected, and we hope > to receive an interrupt to update the status. Let's be more explicit > about the current state - reading the PHY status register tells us > the current level of the hotplug signal, which we can report back in > the _detect() method. > > Signed-off-by: Russell King > --- > This fix should go in for -rc - though it's probably too late to get it > in for 3.15, it may be considered as a potential stable candidate. If > not, can we get this in for 3.16-rc1 please? Yes, it's too late for 3.15, but I can mark it for -stable and get it in for 3.16-rc1. thanks, greg k-h
[PATCH] drm/msm/hdmi: set hdp clock rate before prepare_enable call
The clock driver usually complains when a clock is being prepared
before setting its rate. It is the case here for "core_clk" which
needs to be set at 19.2 MHz before we attempt a prepare_enable().
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 ++
drivers/gpu/drm/msm/hdmi/hdmi.h | 1 +
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8
3 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index ae750f6..7f7aade 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -277,6 +277,7 @@ static int hdmi_bind(struct device *dev, struct device
*master, void *data)
static const char *hpd_reg_names[] = {"hpd-gdsc", "hpd-5v"};
static const char *pwr_reg_names[] = {"core-vdda", "core-vcc"};
static const char *hpd_clk_names[] = {"iface_clk", "core_clk",
"mdp_core_clk"};
+ static unsigned long hpd_clk_freq[] = {0, 1920, 0};
static const char *pwr_clk_names[] = {"extp_clk", "alt_iface_clk"};
config.phy_init = hdmi_phy_8x74_init;
@@ -286,6 +287,7 @@ static int hdmi_bind(struct device *dev, struct device
*master, void *data)
config.pwr_reg_names = pwr_reg_names;
config.pwr_reg_cnt = ARRAY_SIZE(pwr_reg_names);
config.hpd_clk_names = hpd_clk_names;
+ config.hpd_freq = hpd_clk_freq;
config.hpd_clk_cnt = ARRAY_SIZE(hpd_clk_names);
config.pwr_clk_names = pwr_clk_names;
config.pwr_clk_cnt = ARRAY_SIZE(pwr_clk_names);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 9fafee6..9d7723c 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -87,6 +87,7 @@ struct hdmi_platform_config {
/* clks that need to be on for hpd: */
const char **hpd_clk_names;
+ const long unsigned *hpd_freq;
int hpd_clk_cnt;
/* clks that need to be on for screen pwr (ie pixel clk): */
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 7dedfdd..93d1551 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -127,6 +127,14 @@ static int hpd_enable(struct hdmi_connector
*hdmi_connector)
}
for (i = 0; i < config->hpd_clk_cnt; i++) {
+ if (config->hpd_freq[i]) {
+ ret = clk_set_rate(hdmi->hpd_clks[i],
+ config->hpd_freq[i]);
+ if (ret)
+ dev_warn(dev->dev, "failed to set clk %s
(%d)\n",
+ config->hpd_clk_names[i], ret);
+ }
+
ret = clk_prepare_enable(hdmi->hpd_clks[i]);
if (ret) {
dev_err(dev->dev, "failed to enable hpd clk: %s (%d)\n",
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #23 from Alex Deucher --- Sorry, I should have been more clear, on kernel 3.12, does the dGPU switch on again properly after via debugfs after you've disabled it via debugfs? The problem you are sseing is that the GPU turns off ok, but seems to have problems turning back on: [ 52.340438] radeon :01:00.0: Refused to change power state, currently in D3 [ 52.416464] radeon :01:00.0: Refused to change power state, currently in D3 [ 52.432469] radeon :01:00.0: Refused to change power state, currently in D3 and the registers are all reading back 0x which usually means the device is still powered off. Also why are you using radeon.no_wb=1? That may cause problems. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #4 from Alex Deucher --- (In reply to comment #3) > > Does this happen with particular pictures or randomly? > > I haven't tried to reproduce it yet, I will try to find the time for it. > > > It might be worth getting the PITCAIRN_mc2.bin microcode and trying a 3.15 > > kernel. > > I guess once I've managed to reproduce it, otherwise we don't know if it > fixes anything. > > PITCAIRN_mc2.bin will be included with the kernel 3.15 firmware package > right? It's available in the linuxfirmware tree: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=4848a1e059de5aa723ff6627b90de8a5d9632626 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/b737ffd5/attachment-0001.html>
[PATCH 5/5] drm/i915: Kick out vga console
Tomi/Jean can you please ack merging this through drm-intel trees? It
just exports the vga and dummy consoles so that i915 can do what it
needs to do.
Thanks, Daniel
On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter wrote:
> Touching the VGA resources on an IVB EFI machine causes hard hangs when
> we then kick out the efifb. Ouch.
>
> Apparently this also prevents unclaimed register errors on hsw and
> hard machine hangs on my i855gm when trying to unbind fbcon.
>
> Also, we want this to make I915_FBDEV=n safe.
>
> v2: Rebase and pimp commit message.
>
> v3: We also need to unregister the vga console, otherwise the unbind
> of the fb console before module unload might resurrect it again.
>
> v4: Ignore errors when the vga console is already unregistered - this
> can happen when e.g. reloading i915.ko.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
> Cc: David Herrmann
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fbdev at vger.kernel.org
> Cc: Jani Nikula
> Signed-off-by: Chris Wilson (v1)
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_dma.c | 43
> +++-
> drivers/video/console/dummycon.c | 1 +
> drivers/video/console/vgacon.c | 1 +
> 3 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 27fe65ac5940..bcb66ddd649e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -36,6 +36,8 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct
> drm_i915_private *dev_priv)
> }
> #endif
>
> +#if !defined(CONFIG_VGA_CONSOLE)
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return 0;
> +}
> +#elif !defined(CONFIG_DUMMY_CONSOLE)
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + return -ENODEV;
> +}
> +#else
> +static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> +{
> + int ret;
> +
> + DRM_INFO("Replacing VGA console driver\n");
> +
> + console_lock();
> + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> + if (ret == 0) {
> + ret = do_unregister_con_driver(&vga_con);
> +
> + /* Ignore "already unregistered". */
> + if (ret == -ENODEV)
> + ret = 0;
> + }
> + console_unlock();
> +
> + return ret;
> +}
> +#endif
> +
> static void i915_dump_device_info(struct drm_i915_private *dev_priv)
> {
> const struct intel_device_info *info = &dev_priv->info;
> @@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> if (ret)
> goto out_regs;
>
> - if (drm_core_check_feature(dev, DRIVER_MODESET))
> + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> + ret = i915_kick_out_vgacon(dev_priv);
> + if (ret) {
> + DRM_ERROR("failed to remove conflicting VGA
> console\n");
> + goto out_gtt;
> + }
> +
> i915_kick_out_firmware_fb(dev_priv);
> + }
>
> pci_set_master(dev->pdev);
>
> diff --git a/drivers/video/console/dummycon.c
> b/drivers/video/console/dummycon.c
> index b63860f7beab..40bec8d64b0a 100644
> --- a/drivers/video/console/dummycon.c
> +++ b/drivers/video/console/dummycon.c
> @@ -77,3 +77,4 @@ const struct consw dummy_con = {
> .con_set_palette = DUMMY,
> .con_scrolldelta = DUMMY,
> };
> +EXPORT_SYMBOL_GPL(dummy_con);
> diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
> index 9d8feac67637..84acd6223dc5 100644
> --- a/drivers/video/console/vgacon.c
> +++ b/drivers/video/console/vgacon.c
> @@ -1440,5 +1440,6 @@ const struct consw vga_con = {
> .con_build_attr = vgacon_build_attr,
> .con_invert_region = vgacon_invert_region,
> };
> +EXPORT_SYMBOL(vga_con);
>
> MODULE_LICENSE("GPL");
> --
> 1.8.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)
On Fri, Jun 06, 2014 at 11:42:23AM +0200, Ken Helias wrote: > All other add functions for lists have the new item as first argument and the > position where it is added as second argument. This was changed for no good > reason in this function and makes using it unnecessary confusing. > > Also the naming of the arguments in hlist_add_after was confusing. It was > changed to use the same names as hlist_add_after_rcu. > > Signed-off-by: Ken Helias > Cc: David Airlie > Cc: Jeff Kirsher > Cc: Jesse Brandeburg > Cc: Bruce Allan > Cc: Carolyn Wyborny > Cc: Don Skidmore > Cc: Greg Rose > Cc: Alex Duyck > Cc: John Ronciak > Cc: Mitch Williams > Cc: Linux NICS > Cc: Alexander Viro > Cc: Dipankar Sarma > Cc: "Paul E. McKenney" > Cc: Marek Lindner > Cc: Simon Wunderlich > Cc: Antonio Quartulli > Cc: "David S. Miller" > Cc: Stephen Hemminger > Cc: Alexey Kuznetsov > Cc: James Morris > Cc: Hideaki YOSHIFUJI > Cc: Patrick McHardy > Cc: Steffen Klassert > Cc: Herbert Xu > Cc: dri-devel at lists.freedesktop.org > Cc: e1000-devel at lists.sourceforge.net > Cc: netdev at vger.kernel.org > Cc: devel at driverdev.osuosl.org > Cc: linux-fsdevel at vger.kernel.org > Cc: b.a.t.m.a.n at lists.open-mesh.org > Cc: bridge at lists.linux-foundation.org > --- > Patch based on "Add linux-next specific files for 20140606" > > drivers/gpu/drm/drm_hashtab.c| 2 +- > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +- > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +- > drivers/staging/lustre/lustre/libcfs/hash.c | 4 ++-- > fs/namespace.c | 2 +- > fs/notify/inode_mark.c | 2 +- > fs/notify/vfsmount_mark.c| 2 +- > include/linux/list.h | 12 ++-- > include/linux/rculist.h | 6 +++--- > net/batman-adv/fragmentation.c | 2 +- > net/bridge/br_multicast.c| 2 +- > net/ipv4/fib_trie.c | 2 +- > net/ipv6/addrlabel.c | 2 +- > net/xfrm/xfrm_policy.c | 4 ++-- > 14 files changed, 23 insertions(+), 23 deletions(-) drivers/staging/ portion: Acked-by: Greg Kroah-Hartman
[PATCH 2/5] vt: Fix up unregistration of vt drivers
On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > Hi
> >
> > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> > >> Hi
> > >>
> > >> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter > >> ffwll.ch> wrote:
> > >> > A bunch of issues:
> > >> > - We should not kick out the default console (which is tracked in
> > >> > conswitchp), so check for that.
> > >> > - Add better error codes so callers can differentiate between
> > >> > "something
> > >> > went wrong" and "your driver isn't registered already". i915 needs
> > >> > that so it doesn't fall over when reloading the driver and hence
> > >> > vga_con is already unregistered.
> > >> > - There's a mess with the driver flags: What we need to check for is
> > >> > that the driver isn't used any more, i.e. unbound completely
> > >> > (FLAG_INIT).
> > >> > And not whether it's the boot console or not (which is the only one
> > >> > which doesn't have FLAG_MODULE). Otherwise there's no way to kick
> > >> > out the boot console, which i915 wants to do to prevent havoc with
> > >> > vga_con interferring (which tends to hang machines).
> > >> >
> > >> > Cc: Greg Kroah-Hartman
> > >> > Cc: Jiri Slaby
> > >> > Signed-off-by: Daniel Vetter
> > >> > ---
> > >> > drivers/tty/vt/vt.c | 16 +---
> > >> > 1 file changed, 9 insertions(+), 7 deletions(-)
> > >> >
> > >> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > >> > index ea600f482eeb..5077fe87324d 100644
> > >> > --- a/drivers/tty/vt/vt.c
> > >> > +++ b/drivers/tty/vt/vt.c
> > >> > @@ -3573,17 +3573,20 @@ err:
> > >> > */
> > >> > int do_unregister_con_driver(const struct consw *csw)
> > >> > {
> > >> > - int i, retval = -ENODEV;
> > >> > + int i;
> > >> >
> > >> > /* cannot unregister a bound driver */
> > >> > if (con_is_bound(csw))
> > >> > - goto err;
> > >> > + return -EBUSY;
> > >> > +
> > >> > + if (csw == conswitchp)
> > >> > + return -EINVAL;
> > >>
> > >> Ugh, that fix is correct, but I'd rather like to see
> > >> do_unbind_con_driver() do the right thing. It currently resets
> > >> conswitchp _only_ if the new fallback is unbound. Why not _always_ set
> > >> conswitchp to defcsw _iff_ conswitchp == csw there?
> > >
> > > Ha, that's what I've thought, too. But do_unbind doesn't actually change
> > > conswitchp, it only restores it because apparently the
> > > vga_con->con_startup function is a real con and changes it behind
> > > everyones back for no good reason. Or at least that's what the comment
> > > claims. Note how defconsw != defcsw ...
> > >
> > > I've tried to follow around how conswitchp is actually used, but besides
> > > that it's used to select the boot console I'm not sure at all what's going
> > > hence.
> >
> > I missed that line:
> > const struct consw *defconsw = conswitchp;
> >
> > Now that I looked at it again, this looks _really_ wrong. If
> > conswitchp is vgacon and startup fails, we keep it set to vgacon..
> > ugh, weird. But ok, that's up to the people who wrote that.
> >
> > Btw., conswitchp is used for visual_init(), that is, every new VT
> > allocation gets assigned to conswitchp. Therefore, it must be a valid
> > driver. (VTs are allocated and deallocated by agetty/systemd after a
> > session is started/ended).
>
> Ah, I missed where conswitchp was used in the maze, was getting a bit hazy
> ;-)
>
> Rules for changing/updateing conswitchp are indeed a bit strange, which is
> why I really don't want to touch this too much.
>
> > >> This way, you _know_ here that if !con_is_bound(csw), then csw !=
> > >> conswitchp.
> > >
> > > Hence why I dropped this approach again (I've done it originally) and
> > > opted for the straightforward but albeit crude direct check.
> > >
> > >> >
> > >> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> > >> > struct con_driver *con_driver =
> > >> > ®istered_con_driver[i];
> > >> >
> > >> > if (con_driver->con == csw &&
> > >> > - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
> > >> > + con_driver->flag & CON_DRIVER_FLAG_INIT) {
> > >>
> > >> That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
> > >> why FLAG_MODULE exists, anyway.
> > >
> > > I've dug around in git history and it's less than useful. It was renamed
> > > from FLAG_BIND (which makes somewhat sense, since it roughly tracks
> > > whether a console is bound). But there's never been a justification for
> > > it, neither in the original patch nor in the one that renamed it.
> > >
> > > So I decided to not tempt fate and went with the small change here that
> > > I've understood somewhat (I've tried other, more invasive changes and
> > > failed).
> > >
> > >> Otherwise looks good.
> > >
> > > I'm really reluctant to
[PATCH] drm/radeon: add query for number of active CUs
Query to find out how many compute units on a GPU.
Useful for OpenCL usermode drivers.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c| 12 +++-
drivers/gpu/drm/radeon/evergreen.c | 12
drivers/gpu/drm/radeon/ni.c | 12
drivers/gpu/drm/radeon/r600.c | 3 +++
drivers/gpu/drm/radeon/radeon.h | 6 ++
drivers/gpu/drm/radeon/radeon_drv.c | 3 ++-
drivers/gpu/drm/radeon/radeon_kms.c | 16
drivers/gpu/drm/radeon/rv770.c | 3 +++
drivers/gpu/drm/radeon/si.c | 11 ++-
include/uapi/drm/radeon_drm.h | 2 +-
10 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e4b2f2b..dcd4518 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -80,6 +80,7 @@ extern int sumo_rlc_init(struct radeon_device *rdev);
extern void si_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc
*mc);
extern void si_rlc_reset(struct radeon_device *rdev);
extern void si_init_uvd_internal_cg(struct radeon_device *rdev);
+static u32 cik_get_cu_active_bitmap(struct radeon_device *rdev, u32 se, u32
sh);
extern int cik_sdma_resume(struct radeon_device *rdev);
extern void cik_sdma_enable(struct radeon_device *rdev, bool enable);
extern void cik_sdma_fini(struct radeon_device *rdev);
@@ -3257,7 +3258,7 @@ static void cik_gpu_init(struct radeon_device *rdev)
u32 mc_shared_chmap, mc_arb_ramcfg;
u32 hdp_host_path_cntl;
u32 tmp;
- int i, j;
+ int i, j, k;
switch (rdev->family) {
case CHIP_BONAIRE:
@@ -3446,6 +3447,15 @@ static void cik_gpu_init(struct radeon_device *rdev)
rdev->config.cik.max_sh_per_se,
rdev->config.cik.max_backends_per_se);
+ for (i = 0; i < rdev->config.cik.max_shader_engines; i++) {
+ for (j = 0; j < rdev->config.cik.max_sh_per_se; j++) {
+ for (k = 0; k < rdev->config.cik.max_cu_per_sh; k++) {
+ rdev->config.cik.active_cus +=
+
hweight32(cik_get_cu_active_bitmap(rdev, i, j));
+ }
+ }
+ }
+
/* set HW defaults for 3D engine */
WREG32(CP_MEQ_THRESHOLDS, MEQ1_START(0x30) | MEQ2_START(0x60));
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 653eff8..e2f6052 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3337,6 +3337,18 @@ static void evergreen_gpu_init(struct radeon_device
*rdev)
disabled_rb_mask &= ~(1 << i);
}
+ for (i = 0; i < rdev->config.evergreen.num_ses; i++) {
+ u32 simd_disable_bitmap;
+
+ WREG32(GRBM_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_INDEX(i));
+ WREG32(RLC_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_INDEX(i));
+ simd_disable_bitmap = (RREG32(CC_GC_SHADER_PIPE_CONFIG) &
0x) >> 16;
+ simd_disable_bitmap |= 0x <<
rdev->config.evergreen.max_simds;
+ tmp <<= 16;
+ tmp |= simd_disable_bitmap;
+ }
+ rdev->config.evergreen.active_simds = hweight32(~tmp);
+
WREG32(GRBM_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_BROADCAST_WRITES);
WREG32(RLC_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_BROADCAST_WRITES);
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index c0fd8f6..5a33ca6 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1057,6 +1057,18 @@ static void cayman_gpu_init(struct radeon_device *rdev)
disabled_rb_mask &= ~(1 << i);
}
+ for (i = 0; i < rdev->config.cayman.max_shader_engines; i++) {
+ u32 simd_disable_bitmap;
+
+ WREG32(GRBM_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_INDEX(i));
+ WREG32(RLC_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_INDEX(i));
+ simd_disable_bitmap = (RREG32(CC_GC_SHADER_PIPE_CONFIG) &
0x) >> 16;
+ simd_disable_bitmap |= 0x <<
rdev->config.cayman.max_simds_per_se;
+ tmp <<= 16;
+ tmp |= simd_disable_bitmap;
+ }
+ rdev->config.cayman.active_simds = hweight32(~tmp);
+
WREG32(GRBM_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_BROADCAST_WRITES);
WREG32(RLC_GFX_INDEX, INSTANCE_BROADCAST_WRITES | SE_BROADCAST_WRITES);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index c2ff17c..c66952d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1958,6 +1958,9 @@ static void r600_gpu_init(struct radeon_device *rdev)
if (tmp < rdev->config.r600.max_simds) {
rdev->config.r600.max_simds = tmp;
}
+ tmp = rdev->config.r600.max_simds -
+
[Bug 76659] Display does not return from DPMS off using ATI drivers
https://bugs.freedesktop.org/show_bug.cgi?id=76659 --- Comment #11 from Tyler Brock --- I'm seeing new messages now when I look in dmesg: [drm:radeon_dp_link_train_cr] *ERROR* clock recovery tried 5 times [drm:radeon_dp_link_train_cr] *ERROR* clock recovery failed -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/bfe7bf42/attachment.html>
[Intel-gfx] [PATCH 2/5] vt: Fix up unregistration of vt drivers
On Fri, Jun 06, 2014 at 08:51:31AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 06, 2014 at 11:40:50AM +0200, Daniel Vetter wrote:
> > On Fri, Jun 06, 2014 at 10:47:25AM +0200, David Herrmann wrote:
> > > Hi
> > >
> > > On Fri, Jun 6, 2014 at 9:56 AM, Daniel Vetter wrote:
> > > > On Fri, Jun 06, 2014 at 09:24:35AM +0200, David Herrmann wrote:
> > > >> Hi
> > > >>
> > > >> On Thu, Jun 5, 2014 at 4:58 PM, Daniel Vetter > > >> ffwll.ch> wrote:
> > > >> > A bunch of issues:
> > > >> > - We should not kick out the default console (which is tracked in
> > > >> > conswitchp), so check for that.
> > > >> > - Add better error codes so callers can differentiate between
> > > >> > "something
> > > >> > went wrong" and "your driver isn't registered already". i915 needs
> > > >> > that so it doesn't fall over when reloading the driver and hence
> > > >> > vga_con is already unregistered.
> > > >> > - There's a mess with the driver flags: What we need to check for is
> > > >> > that the driver isn't used any more, i.e. unbound completely
> > > >> > (FLAG_INIT).
> > > >> > And not whether it's the boot console or not (which is the only one
> > > >> > which doesn't have FLAG_MODULE). Otherwise there's no way to kick
> > > >> > out the boot console, which i915 wants to do to prevent havoc with
> > > >> > vga_con interferring (which tends to hang machines).
> > > >> >
> > > >> > Cc: Greg Kroah-Hartman
> > > >> > Cc: Jiri Slaby
> > > >> > Signed-off-by: Daniel Vetter
> > > >> > ---
> > > >> > drivers/tty/vt/vt.c | 16 +---
> > > >> > 1 file changed, 9 insertions(+), 7 deletions(-)
> > > >> >
> > > >> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > > >> > index ea600f482eeb..5077fe87324d 100644
> > > >> > --- a/drivers/tty/vt/vt.c
> > > >> > +++ b/drivers/tty/vt/vt.c
> > > >> > @@ -3573,17 +3573,20 @@ err:
> > > >> > */
> > > >> > int do_unregister_con_driver(const struct consw *csw)
> > > >> > {
> > > >> > - int i, retval = -ENODEV;
> > > >> > + int i;
> > > >> >
> > > >> > /* cannot unregister a bound driver */
> > > >> > if (con_is_bound(csw))
> > > >> > - goto err;
> > > >> > + return -EBUSY;
> > > >> > +
> > > >> > + if (csw == conswitchp)
> > > >> > + return -EINVAL;
> > > >>
> > > >> Ugh, that fix is correct, but I'd rather like to see
> > > >> do_unbind_con_driver() do the right thing. It currently resets
> > > >> conswitchp _only_ if the new fallback is unbound. Why not _always_ set
> > > >> conswitchp to defcsw _iff_ conswitchp == csw there?
> > > >
> > > > Ha, that's what I've thought, too. But do_unbind doesn't actually change
> > > > conswitchp, it only restores it because apparently the
> > > > vga_con->con_startup function is a real con and changes it behind
> > > > everyones back for no good reason. Or at least that's what the comment
> > > > claims. Note how defconsw != defcsw ...
> > > >
> > > > I've tried to follow around how conswitchp is actually used, but besides
> > > > that it's used to select the boot console I'm not sure at all what's
> > > > going
> > > > hence.
> > >
> > > I missed that line:
> > > const struct consw *defconsw = conswitchp;
> > >
> > > Now that I looked at it again, this looks _really_ wrong. If
> > > conswitchp is vgacon and startup fails, we keep it set to vgacon..
> > > ugh, weird. But ok, that's up to the people who wrote that.
> > >
> > > Btw., conswitchp is used for visual_init(), that is, every new VT
> > > allocation gets assigned to conswitchp. Therefore, it must be a valid
> > > driver. (VTs are allocated and deallocated by agetty/systemd after a
> > > session is started/ended).
> >
> > Ah, I missed where conswitchp was used in the maze, was getting a bit hazy
> > ;-)
> >
> > Rules for changing/updateing conswitchp are indeed a bit strange, which is
> > why I really don't want to touch this too much.
> >
> > > >> This way, you _know_ here that if !con_is_bound(csw), then csw !=
> > > >> conswitchp.
> > > >
> > > > Hence why I dropped this approach again (I've done it originally) and
> > > > opted for the straightforward but albeit crude direct check.
> > > >
> > > >> >
> > > >> > for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
> > > >> > struct con_driver *con_driver =
> > > >> > ®istered_con_driver[i];
> > > >> >
> > > >> > if (con_driver->con == csw &&
> > > >> > - con_driver->flag & CON_DRIVER_FLAG_MODULE) {
> > > >> > + con_driver->flag & CON_DRIVER_FLAG_INIT) {
> > > >>
> > > >> That makes FLAG_MODULE almost a no-op except for ->unbind(). I wonder
> > > >> why FLAG_MODULE exists, anyway.
> > > >
> > > > I've dug around in git history and it's less than useful. It was renamed
> > > > from FLAG_BIND (which makes somewhat sense, since it roughly tracks
> > > > whether a console is bound). But there's never been a justification for
> > > > it, neither in the o
[PATCH 1/2] drm/plane-helper: storage class should be before const qualifier
On Thu, Jun 05, 2014 at 06:30:57PM +0100, Peter Griffin wrote:
> The C99 specification states in section 6.11.5:
>
> The placement of a storage-class specifier other than at the beginning
> of the declaration specifiers in a declaration is an obsolescent
> feature.
This is definitely the right change to make, but I believe Thierry
already included a fix for this in patch
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=233fd4ec92b90a2d3bb5104d17835072ba2fde4b
which also cleans up some whitespace problems.
Matt
>
> Signed-off-by: Peter Griffin
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index d2b1c03..88a6c49 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -36,7 +36,7 @@
> * creating the primary plane. However drivers that still call
> * drm_plane_init() will use this minimal format list as the default.
> */
> -const static uint32_t safe_modeset_formats[] = {
> +static const uint32_t safe_modeset_formats[] = {
> DRM_FORMAT_XRGB,
> DRM_FORMAT_ARGB,
> };
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #24 from Teofilis Martisius --- Hi, Thank you once again for quick response. Ok, a while ago I added radeon.no_wb=1 as without it I was getting display corruption. That problem seems to be gone now, so there's no reason to keep that option any more- I've taken it off. I think you nailed the problem. On 3.12, it fails to turn ON the dGPU after it has been turned OFF. I have tried this by booting 3.12 with following boot parameters: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.12-1-amd64 root=UUID=6b66e960-0da6-4a99-abfe-f23614b50db9 ro quiet radeon.audio=0 modeset= Then I did: echo OFF >/sys/kernel/debug/vgaswitcheroo/switch echo ON >/sys/kernel/debug/vgaswitcheroo/switch After "echo ON" I got similar "atombios stuck in loop" errors in dmesg, and errors that dGPU failed to come back on. "DRI_PRIME=1 glxgears" of course fails to work after that as well. I've attached the dmesg from 3.12. Ok, what next? P.S. Sorry for slow responses. I only have time to do this in the evenings, and I'm in London- I guess you are in a different timezone. Sincerely, Teofilis Martisius -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #25 from Teofilis Martisius --- Created attachment 138411 --> https://bugzilla.kernel.org/attachment.cgi?id=138411&action=edit Dmesg output from 3.12, fails to turn on dGPU -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #26 from Alex Deucher --- Ok, so it appears your dGPU never powered up properly. You just see the problem now because prior to the runpm patch (which dynamically turns the dGPU on/off) it was always left on. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 --- Comment #27 from Alex Deucher --- Created attachment 138421 --> https://bugzilla.kernel.org/attachment.cgi?id=138421&action=edit possible fix Does this patch help? If not, can you try increasing the size of the delay and see if that helps? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #5 from Marti Raudsepp --- (In reply to comment #2) > Does this happen with particular pictures or randomly? Randomly. I can reproduce this pretty reliably now by enabling slideshow in Geeqie, setting delay to 0.2s, letting it run for 15 mins or so. If you need some more information about the crash, I can provide. > It might be worth getting the PITCAIRN_mc2.bin microcode and trying a 3.15 > kernel. Indeed, after upgrading to kernel 3.15rc8 and git firmware, I can no longer reproduce the issue. It's been running without problems for 45 minutes now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/f1168dc0/attachment-0001.html>
[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie
https://bugs.freedesktop.org/show_bug.cgi?id=79696 --- Comment #6 from Marti Raudsepp --- Just to be clear, there's still a bug in Xorg segfaulting, right? Should it be able to survive GPU hangs? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/48597e21/attachment.html>
[Bug 79756] New: [Radeon] Resizing Steam windows freezes Xorg
https://bugs.freedesktop.org/show_bug.cgi?id=79756 Priority: medium Bug ID: 79756 Assignee: dri-devel at lists.freedesktop.org Summary: [Radeon] Resizing Steam windows freezes Xorg Severity: normal Classification: Unclassified OS: Linux (All) Reporter: marti at juffo.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 100572 --> https://bugs.freedesktop.org/attachment.cgi?id=100572&action=edit kernel.log The gauntlet continues... After solving bug 79325, Steam now starts, but when I try to resize any Steam windows, Xorg freezes: it does not react to keyboard input (VT switching or num lock) and killing Steam doesn't unlock it. But the mouse cursor still responds to mouse movements. There is nothing in Xorg logs after the freeze. xorg-server 1.15.1 linux 3.15-rc8 linux-firmware a4f3bc03f1e7b1f25cc52328981c2a35871e55a1 (with PITCAIRN_mc2.bin) xf86-video-ati 7.3.0 Tried ati-dri/mesa versions 10.2.0rc5 as well as 10.1.3 Tried glamor-egl git a4fbc7732a1e56de385f50b778aafbdd186e015c as well as 0.6.0 (patched with cccfea4454949e3e376be42bb230603848997195 per bug 79325) gdb dump at the time of freeze: (gdb) thread apply all bt Thread 2 (Thread 0x7f34a3efd700 (LWP 630)): #0 0x7f34ae00cb2f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x7f34a65679cb in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #2 0x7f34a6567117 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #3 0x7f34ae008124 in start_thread () from /usr/lib/libpthread.so.0 #4 0x7f34acd374bd in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7f34aeac5880 (LWP 553)): #0 0x7f34ae00f38c in __lll_lock_wait () from /usr/lib/libpthread.so.0 #1 0x7f34ae00ab3c in _L_lock_553 () from /usr/lib/libpthread.so.0 #2 0x7f34ae00a91a in pthread_mutex_lock () from /usr/lib/libpthread.so.0 #3 0x7f34aad16fae in eglCreateImageKHR () from /usr/lib/libEGL.so.1 #4 0x7f34aaf35e21 in glamor_egl_create_textured_pixmap () from /usr/lib/xorg/modules/libglamoregl.so #5 0x7f34a77e1ac0 in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so #6 0x7f34a77e1e26 in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so #7 0x7f34a77d8819 in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so #8 0x005554c3 in ?? () #9 0x0055628f in ?? () #10 0x00556690 in DRI2GetBuffersWithFormat () #11 0x7f34a7c2e661 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #12 0x7f34a656383a in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #13 0x7f34a656190a in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #14 0x7f34a66baa2e in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #15 0x7f34a66bbb98 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #16 0x7f34a668d9c0 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #17 0x7f34a66a19d5 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #18 0x7f34a6676577 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #19 0x7f34a665d74c in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #20 0x7f34a66735d4 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #21 0x7f34a659d403 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so #22 0x7f34aad20fee in ?? () from /usr/lib/libEGL.so.1 #23 0x7f34aad193c5 in eglMakeCurrent () from /usr/lib/libEGL.so.1 #24 0x7f34aaf35c08 in glamor_egl_make_current () from /usr/lib/xorg/modules/libglamoregl.so #25 0x7f34aa8cdc69 in glamor_block_handler () from /usr/lib/libglamor.so.0 #26 0x0043ad64 in _CallCallbacks () #27 0x00588096 in WriteToClient () #28 0x7f34a7c13761 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #29 0x7f34a7c271d0 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so #30 0x00435c8e in ?? () #31 0x00439aaa in ?? () #32 0x7f34acc6e000 in __libc_start_main () from /usr/lib/libc.so.6 #33 0x0042507e in _start () -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140606/2f3c845c/attachment.html>
[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)
On Fri, 6 Jun 2014 10:22:51 -0700 "Paul E. McKenney" wrote: > On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote: > > From: Behalf Of Ken Helias > > > All other add functions for lists have the new item as first argument and > > > the > > > position where it is added as second argument. This was changed for no > > > good > > > reason in this function and makes using it unnecessary confusing. > > > > > > Also the naming of the arguments in hlist_add_after was confusing. It was > > > changed to use the same names as hlist_add_after_rcu. > > ... > > > -static inline void hlist_add_after_rcu(struct hlist_node *prev, > > > -struct hlist_node *n) > > > +static inline void hlist_add_after_rcu(struct hlist_node *n, > > > +struct hlist_node *prev) > > > > It is rather a shame that the change doesn't generate a compilation > > error for old source files. > > I am also a bit concerned by this. > yup. hlist_add_behind()?
[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)
From: Behalf Of Ken Helias > All other add functions for lists have the new item as first argument and the > position where it is added as second argument. This was changed for no good > reason in this function and makes using it unnecessary confusing. > > Also the naming of the arguments in hlist_add_after was confusing. It was > changed to use the same names as hlist_add_after_rcu. ... > -static inline void hlist_add_after_rcu(struct hlist_node *prev, > -struct hlist_node *n) > +static inline void hlist_add_after_rcu(struct hlist_node *n, > +struct hlist_node *prev) It is rather a shame that the change doesn't generate a compilation error for old source files. David
[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)
On Fri, Jun 06, 2014 at 03:56:52PM +, David Laight wrote: > From: Behalf Of Ken Helias > > All other add functions for lists have the new item as first argument and > > the > > position where it is added as second argument. This was changed for no good > > reason in this function and makes using it unnecessary confusing. > > > > Also the naming of the arguments in hlist_add_after was confusing. It was > > changed to use the same names as hlist_add_after_rcu. > ... > > -static inline void hlist_add_after_rcu(struct hlist_node *prev, > > - struct hlist_node *n) > > +static inline void hlist_add_after_rcu(struct hlist_node *n, > > + struct hlist_node *prev) > > It is rather a shame that the change doesn't generate a compilation > error for old source files. I am also a bit concerned by this. Thanx, Paul
[PATCHv2 02/13] list: Fix order of arguments for hlist_add_after(_rcu)
From: Ken Helias
All other add functions for lists have the new item as first argument and the
position where it is added as second argument. This was changed for no good
reason in this function and makes using it unnecessary confusing.
Signed-off-by: Ken Helias
Cc: Linux NICS
Cc: "Paul E. McKenney"
Cc: dri-devel at lists.freedesktop.org
Cc: e1000-devel at lists.sourceforge.net
Cc: netdev at vger.kernel.org
Cc: devel at driverdev.osuosl.org
Cc: linux-fsdevel at vger.kernel.org
Cc: b.a.t.m.a.n at lists.open-mesh.org
Cc: bridge at lists.linux-foundation.org
---
Patch based on "Add linux-next specific files for 20140606"
v2:
Splitted into two patches
reduced number of Cc
drivers/gpu/drm/drm_hashtab.c| 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
drivers/staging/lustre/lustre/libcfs/hash.c | 4 ++--
fs/namespace.c | 2 +-
fs/notify/inode_mark.c | 2 +-
fs/notify/vfsmount_mark.c| 2 +-
include/linux/list.h | 4 ++--
include/linux/rculist.h | 6 +++---
net/batman-adv/fragmentation.c | 2 +-
net/bridge/br_multicast.c| 2 +-
net/ipv4/fib_trie.c | 2 +-
net/ipv6/addrlabel.c | 2 +-
net/xfrm/xfrm_policy.c | 4 ++--
14 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 7e4bae7..4077a35 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -125,7 +125,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = &entry->head;
}
if (parent) {
- hlist_add_after_rcu(parent, &item->head);
+ hlist_add_after_rcu(&item->head, parent);
} else {
hlist_add_head_rcu(&item->head, h_list);
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1bb470b..db0a7e1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1437,7 +1437,7 @@ static int i40e_update_ethtool_fdir_entry(struct i40e_vsi
*vsi,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_after(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&pf->fdir_filter_list);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 23e4e6a..23f4ff3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -2518,7 +2518,7 @@ static int ixgbe_update_ethtool_fdir_entry(struct
ixgbe_adapter *adapter,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_after(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&adapter->fdir_filter_list);
diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c
b/drivers/staging/lustre/lustre/libcfs/hash.c
index 6d2b455..35835e5 100644
--- a/drivers/staging/lustre/lustre/libcfs/hash.c
+++ b/drivers/staging/lustre/lustre/libcfs/hash.c
@@ -351,7 +351,7 @@ cfs_hash_dh_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_t, dh_head);
if (dh->dh_tail != NULL) /* not empty */
- hlist_add_after(dh->dh_tail, hnode);
+ hlist_add_after(hnode, dh->dh_tail);
else /* empty list */
hlist_add_head(hnode, &dh->dh_head);
dh->dh_tail = hnode;
@@ -406,7 +406,7 @@ cfs_hash_dd_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_dep_t, dd_head);
if (dh->dd_tail != NULL) /* not empty */
- hlist_add_after(dh->dd_tail, hnode);
+ hlist_add_after(hnode, dh->dd_tail);
else /* empty list */
hlist_add_head(hnode, &dh->dd_head);
dh->dd_tail = hnode;
diff --git a/fs/namespace.c b/fs/namespace.c
index b10db3d..14b751f 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -845,7 +845,7 @@ static void commit_tree(struct mount *mnt, struct mount
*shadows)
list_splice(&head, n->list.prev);
if (shadows)
- hlist_add_after
[PATCH] list: Fix order of arguments for hlist_add_after(_rcu)
All other add functions for lists have the new item as first argument and the
position where it is added as second argument. This was changed for no good
reason in this function and makes using it unnecessary confusing.
Also the naming of the arguments in hlist_add_after was confusing. It was
changed to use the same names as hlist_add_after_rcu.
Signed-off-by: Ken Helias
Cc: David Airlie
Cc: Jeff Kirsher
Cc: Jesse Brandeburg
Cc: Bruce Allan
Cc: Carolyn Wyborny
Cc: Don Skidmore
Cc: Greg Rose
Cc: Alex Duyck
Cc: John Ronciak
Cc: Mitch Williams
Cc: Linux NICS
Cc: Alexander Viro
Cc: Dipankar Sarma
Cc: "Paul E. McKenney"
Cc: Marek Lindner
Cc: Simon Wunderlich
Cc: Antonio Quartulli
Cc: "David S. Miller"
Cc: Stephen Hemminger
Cc: Alexey Kuznetsov
Cc: James Morris
Cc: Hideaki YOSHIFUJI
Cc: Patrick McHardy
Cc: Steffen Klassert
Cc: Herbert Xu
Cc: dri-devel at lists.freedesktop.org
Cc: e1000-devel at lists.sourceforge.net
Cc: netdev at vger.kernel.org
Cc: devel at driverdev.osuosl.org
Cc: linux-fsdevel at vger.kernel.org
Cc: b.a.t.m.a.n at lists.open-mesh.org
Cc: bridge at lists.linux-foundation.org
---
Patch based on "Add linux-next specific files for 20140606"
drivers/gpu/drm/drm_hashtab.c| 2 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +-
drivers/staging/lustre/lustre/libcfs/hash.c | 4 ++--
fs/namespace.c | 2 +-
fs/notify/inode_mark.c | 2 +-
fs/notify/vfsmount_mark.c| 2 +-
include/linux/list.h | 12 ++--
include/linux/rculist.h | 6 +++---
net/batman-adv/fragmentation.c | 2 +-
net/bridge/br_multicast.c| 2 +-
net/ipv4/fib_trie.c | 2 +-
net/ipv6/addrlabel.c | 2 +-
net/xfrm/xfrm_policy.c | 4 ++--
14 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index 7e4bae7..4077a35 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -125,7 +125,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = &entry->head;
}
if (parent) {
- hlist_add_after_rcu(parent, &item->head);
+ hlist_add_after_rcu(&item->head, parent);
} else {
hlist_add_head_rcu(&item->head, h_list);
}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1bb470b..db0a7e1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1437,7 +1437,7 @@ static int i40e_update_ethtool_fdir_entry(struct i40e_vsi
*vsi,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_after(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&pf->fdir_filter_list);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 23e4e6a..23f4ff3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -2518,7 +2518,7 @@ static int ixgbe_update_ethtool_fdir_entry(struct
ixgbe_adapter *adapter,
/* add filter to the list */
if (parent)
- hlist_add_after(&parent->fdir_node, &input->fdir_node);
+ hlist_add_after(&input->fdir_node, &parent->fdir_node);
else
hlist_add_head(&input->fdir_node,
&adapter->fdir_filter_list);
diff --git a/drivers/staging/lustre/lustre/libcfs/hash.c
b/drivers/staging/lustre/lustre/libcfs/hash.c
index 6d2b455..35835e5 100644
--- a/drivers/staging/lustre/lustre/libcfs/hash.c
+++ b/drivers/staging/lustre/lustre/libcfs/hash.c
@@ -351,7 +351,7 @@ cfs_hash_dh_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_t, dh_head);
if (dh->dh_tail != NULL) /* not empty */
- hlist_add_after(dh->dh_tail, hnode);
+ hlist_add_after(hnode, dh->dh_tail);
else /* empty list */
hlist_add_head(hnode, &dh->dh_head);
dh->dh_tail = hnode;
@@ -406,7 +406,7 @@ cfs_hash_dd_hnode_add(struct cfs_hash *hs, struct
cfs_hash_bd *bd,
cfs_hash_dhead_dep_t, dd_head);
if (dh->d
[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state
The initial state at boot is assumed to be disconnected, and we hope
to receive an interrupt to update the status. Let's be more explicit
about the current state - reading the PHY status register tells us
the current level of the hotplug signal, which we can report back in
the _detect() method.
Signed-off-by: Russell King
---
This fix should go in for -rc - though it's probably too late to get it
in for 3.15, it may be considered as a potential stable candidate. If
not, can we get this in for 3.16-rc1 please?
Thanks.
drivers/staging/imx-drm/imx-hdmi.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-hdmi.c
b/drivers/staging/imx-drm/imx-hdmi.c
index d47dedd2cdb4..6f5efcc89880 100644
--- a/drivers/staging/imx-drm/imx-hdmi.c
+++ b/drivers/staging/imx-drm/imx-hdmi.c
@@ -120,8 +120,6 @@ struct imx_hdmi {
struct clk *isfr_clk;
struct clk *iahb_clk;
- enum drm_connector_status connector_status;
-
struct hdmi_data_info hdmi_data;
int vic;
@@ -1382,7 +1380,9 @@ static enum drm_connector_status
imx_hdmi_connector_detect(struct drm_connector
{
struct imx_hdmi *hdmi = container_of(connector, struct imx_hdmi,
connector);
- return hdmi->connector_status;
+
+ return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
+ connector_status_connected : connector_status_disconnected;
}
static int imx_hdmi_connector_get_modes(struct drm_connector *connector)
@@ -1524,7 +1524,6 @@ static irqreturn_t imx_hdmi_irq(int irq, void *dev_id)
hdmi_modb(hdmi, 0, HDMI_PHY_HPD, HDMI_PHY_POL0);
- hdmi->connector_status = connector_status_connected;
imx_hdmi_poweron(hdmi);
} else {
dev_dbg(hdmi->dev, "EVENT=plugout\n");
@@ -1532,7 +1531,6 @@ static irqreturn_t imx_hdmi_irq(int irq, void *dev_id)
hdmi_modb(hdmi, HDMI_PHY_HPD, HDMI_PHY_HPD,
HDMI_PHY_POL0);
- hdmi->connector_status = connector_status_disconnected;
imx_hdmi_poweroff(hdmi);
}
drm_helper_hpd_irq_event(hdmi->connector.dev);
@@ -1606,7 +1604,6 @@ static int imx_hdmi_bind(struct device *dev, struct
device *master, void *data)
return -ENOMEM;
hdmi->dev = dev;
- hdmi->connector_status = connector_status_disconnected;
hdmi->sample_rate = 48000;
hdmi->ratio = 100;
--
1.8.3.1
