[Bug 99967] RX 480 sclk clock speed lowers when under load
https://bugs.freedesktop.org/show_bug.cgi?id=99967 --- Comment #3 from Christoph Haag --- Some more experimentation: The SaschaWillems Vulkan examples that cause a lot of gpu load (like computecullandlod) make the GPU run at the highest performance level. McNoppers OpenGL Example30 (raytracing with compute shaders) does the same. But Furmark still only makes the GPU run at 600-900 MHz. So most likely the cause is NOT in X or the general handling of one of the graphics APIs and most likely it is not a general power supply issue. It could be that it only happens when certain hardware parts of the GPU are under high load, or are not under high load. On IRC some people tried furmark and could not reproduce this behavior. (The user Remco with a factory overclocked XFX RX 480 too, though a different model than mine). This is good news for the driver developers. This is not so good news for me because now I have to find out whether it's bad hardware (mainboard, GPU?) on my part or something in my software configuration. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/tinydrm: Add tinydrm_panel abstraction
Add support for displays that can be operated using a simple vtable.
Geared towards controllers that can represent it's registers using
regmap.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/tinydrm.rst| 12 +
drivers/gpu/drm/tinydrm/Kconfig | 1 +
drivers/gpu/drm/tinydrm/core/Makefile| 2 +-
drivers/gpu/drm/tinydrm/core/tinydrm-panel.c | 532 +++
include/drm/tinydrm/tinydrm-panel.h | 153
5 files changed, 699 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
create mode 100644 include/drm/tinydrm/tinydrm-panel.h
diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst
index a913644..bb78433 100644
--- a/Documentation/gpu/tinydrm.rst
+++ b/Documentation/gpu/tinydrm.rst
@@ -20,6 +20,18 @@ Core functionality
.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c
:export:
+Panel
+=
+
+.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/tinydrm/tinydrm-panel.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
+ :export:
+
Additional helpers
==
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 3504c53..4ea0fbc 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -1,6 +1,7 @@
menuconfig DRM_TINYDRM
tristate "Support for simple displays"
depends on DRM
+ select REGMAP
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/gpu/drm/tinydrm/core/Makefile
b/drivers/gpu/drm/tinydrm/core/Makefile
index fb221e6..213b479 100644
--- a/drivers/gpu/drm/tinydrm/core/Makefile
+++ b/drivers/gpu/drm/tinydrm/core/Makefile
@@ -1,3 +1,3 @@
-tinydrm-y := tinydrm-core.o tinydrm-pipe.o tinydrm-helpers.o
+tinydrm-y := tinydrm-core.o tinydrm-pipe.o tinydrm-panel.o tinydrm-helpers.o
obj-$(CONFIG_DRM_TINYDRM) += tinydrm.o
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
new file mode 100644
index 000..f3e5fb1
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-panel.c
@@ -0,0 +1,532 @@
+/*
+ * Copyright 2017 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers for displays/panels that can be operated
+ * using a simple vtable.
+ *
+ * Many controllers are operated through a register making ®map a useful
+ * abstraction for the register interface code. This helper is geared towards
+ * such controllers. Often controllers also support more than one bus, and
+ * should for instance a controller be connected in a non-standard way
+ * (e.g. memory mapped), then only the regmap needs to be changed.
+ */
+
+static int tinydrm_panel_prepare(struct tinydrm_panel *panel)
+{
+ if (panel->funcs && panel->funcs->prepare)
+ return panel->funcs->prepare(panel);
+
+ if (panel->regulator)
+ return regulator_enable(panel->regulator);
+
+ return 0;
+}
+
+static int tinydrm_panel_enable(struct tinydrm_panel *panel)
+{
+ if (panel->funcs && panel->funcs->enable)
+ return panel->funcs->enable(panel);
+
+ return tinydrm_enable_backlight(panel->backlight);
+}
+
+static int tinydrm_panel_disable(struct tinydrm_panel *panel)
+{
+ if (panel->funcs && panel->funcs->disable)
+ return panel->funcs->disable(panel);
+
+ return tinydrm_disable_backlight(panel->backlight);
+}
+
+static int tinydrm_panel_unprepare(struct tinydrm_panel *panel)
+{
+ if (panel->funcs && panel->funcs->unprepare)
+ return panel->funcs->unprepare(panel);
+
+ if (panel->regulator)
+ return regulator_disable(panel->regulator);
+
+ return 0;
+}
+
+static void tinydrm_panel_pipe_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
+{
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct tinydrm_panel *panel = tinydrm_to_panel(tdev);
+ struct drm_framebuffer *fb = pipe->plane.fb;
+
+ panel->enabled = true;
+ fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+ tinydrm_panel_enable(panel);
+}
+
+static void tinydrm_panel_pipe_disable(struct drm_simple_display_pipe *pipe)
+{
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct tinydrm_panel *panel = tinydrm_to_panel(tdev);
+
+ panel->enabled = false;
+ tiny
[PATCH 0/5] drm/tinydrm: Add tinydrm_panel abstraction
Add support for displays that have a register interface and can be operated using a simple vtable. I have looked through the staging/fbtft drivers and it seems that, except the MIPI controllers, most if not all controllers are operated through a register. And since most controllers have more than one bus interface option, regmap seems like a good choice to describe the interface (tested[1,2]). MIPI DCS can't be represented using regmap since some commands doesn't have a parameter. That would be like a register without a value, which doesn't make sense. In my second RFC of tinydrm I used drm_panel to decribe the panels since it was a good match to the fbtft displays. I was then told that drm_panel wasn't supposed to used like that, so I dropped it and have tried to use the drm_simple_display_pipe_funcs vtable directly. This hasn't been all successful, since I ended up using devm_add_action() to power down the controller at the right time. Thierry Reding wasn't happy with this and suggested "to add an explicit callback somewhere". My solution has been to copy the drm_panel_funcs vtable. Since I now have a vtable, I also added a callback to flush the framebuffer. So presumably all the fbtft drivers can now be operated through the tinydrm_panel_funcs vtable. After having done this the question arises: Why not extend tinydrm_device instead of subclassing it? The benefit of subclassing is that it keeps the door open for drivers that can use tinydrm_device, but not tinydrm_panel. But I don't know of such a driver now, then again who knows what the future brings. Something that might or might not happen isn't a good reason, so it seems that I want it this way because I just like it. And it's easy to merge the two should it be that no one uses tinydrm_device directly three years down the line. But I'm actually not sure what's best. To recap: tinydrm_device - Combines drm_simple_display_pipe with CMA backed framebuffer and fbdev. - Optional pipe setup with a connector with one mode, but the driver can do it's own. tinydrm_panel - All drm operations are distilled down to tinydrm_panel_funcs. - Some common driver properties Noralf. [1] https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c [2] https://github.com/notro/tinydrm/blob/master/fb_ili9325.c Noralf Trønnes (5): drm/tinydrm: Add tinydrm_rgb565_buf_copy() drm/tinydrm: Add tinydrm_panel abstraction drm/tinydrm/mipi-dbi: Start conversion to tinydrm_panel drm/tinydrm/mi0283qt: Use tinydrm_panel drm/tinydrm/mipi-dbi: Clean up after tinydrm_panel conversion Documentation/gpu/tinydrm.rst | 12 + drivers/gpu/drm/tinydrm/Kconfig| 1 + drivers/gpu/drm/tinydrm/core/Makefile | 2 +- drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 ++- drivers/gpu/drm/tinydrm/core/tinydrm-panel.c | 532 + drivers/gpu/drm/tinydrm/mi0283qt.c | 113 ++ drivers/gpu/drm/tinydrm/mipi-dbi.c | 246 include/drm/tinydrm/mipi-dbi.h | 35 +- include/drm/tinydrm/tinydrm-helpers.h | 2 + include/drm/tinydrm/tinydrm-panel.h| 153 +++ 10 files changed, 867 insertions(+), 285 deletions(-) create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-panel.c create mode 100644 include/drm/tinydrm/tinydrm-panel.h -- 2.10.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/tinydrm/mipi-dbi: Start conversion to tinydrm_panel
This starts the conversion of basing mipi_dbi on tinydrm_panel.
- Add mipi_dbi_flush() and mipi_dbi_panel_disable()
- Switch to tinydrm_panel properties
MIPI DCS can't be represented using regmap since some commands doesn't
have a parameter. That would be like a register without a value, which
doesn't make sense. So the tinydrm_panel->reg property isn't used.
Additionally change to the common header include order.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mipi-dbi.c | 95 ++
include/drm/tinydrm/mipi-dbi.h | 14 +-
2 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 29c0939..2cdd558 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -9,14 +9,16 @@
* (at your option) any later version.
*/
-#include
-#include
#include
#include
#include
#include
#include
#include
+
+#include
+#include
+
#include
#define MIPI_DBI_MAX_SPI_READ_SPEED 200 /* 2MHz */
@@ -283,22 +285,84 @@ void mipi_dbi_pipe_enable(struct drm_simple_display_pipe
*pipe,
}
EXPORT_SYMBOL(mipi_dbi_pipe_enable);
+/**
+ * mipi_dbi_panel_flush - MIPI DBI panel flush helper
+ * @panel: tinydrm panel
+ * @fb: DRM framebuffer
+ * @rect: Clip rectangle to flush
+ *
+ * This function flushes the framebuffer changes to the display/controller.
+ * Drivers can use this as their &tinydrm_panel_funcs->flush callback.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_panel_flush(struct tinydrm_panel *panel,
+struct drm_framebuffer *fb,
+struct drm_clip_rect *rect)
+{
+ struct mipi_dbi *mipi = mipi_dbi_from_panel(panel);
+ void *tr;
+
+ DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u, swap=%u\n",
+ fb->base.id, rect->x1, rect->x2, rect->y1, rect->y2,
+ panel->swap_bytes);
+
+ tr = tinydrm_panel_rgb565_buf(panel, fb, rect);
+ if (IS_ERR(tr))
+ return PTR_ERR(tr);
+
+ mipi_dbi_command(mipi, MIPI_DCS_SET_COLUMN_ADDRESS,
+(rect->x1 >> 8) & 0xFF, rect->x1 & 0xFF,
+(rect->x2 >> 8) & 0xFF, (rect->x2 - 1) & 0xFF);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PAGE_ADDRESS,
+(rect->y1 >> 8) & 0xFF, rect->y1 & 0xFF,
+(rect->y2 >> 8) & 0xFF, (rect->y2 - 1) & 0xFF);
+
+ return mipi_dbi_command_buf(mipi, MIPI_DCS_WRITE_MEMORY_START, tr,
+ (rect->x2 - rect->x1) *
+ (rect->y2 - rect->y1) * 2);
+}
+EXPORT_SYMBOL(mipi_dbi_panel_flush);
+
static void mipi_dbi_blank(struct mipi_dbi *mipi)
{
- struct drm_device *drm = mipi->tinydrm.drm;
+ struct tinydrm_panel *panel = &mipi->panel;
+ struct drm_device *drm = panel->tinydrm.drm;
u16 height = drm->mode_config.min_height;
u16 width = drm->mode_config.min_width;
size_t len = width * height * 2;
- memset(mipi->tx_buf, 0, len);
+ memset(panel->tx_buf, 0, len);
mipi_dbi_command(mipi, MIPI_DCS_SET_COLUMN_ADDRESS, 0, 0,
(width >> 8) & 0xFF, (width - 1) & 0xFF);
mipi_dbi_command(mipi, MIPI_DCS_SET_PAGE_ADDRESS, 0, 0,
(height >> 8) & 0xFF, (height - 1) & 0xFF);
mipi_dbi_command_buf(mipi, MIPI_DCS_WRITE_MEMORY_START,
-(u8 *)mipi->tx_buf, len);
+panel->tx_buf, len);
+}
+
+/**
+ * mipi_dbi_panel_disable - MIPI DBI panel disable helper
+ * @panel: tinydrm panel
+ *
+ * This function disables backlight if present or if not the
+ * display memory is blanked. Drivers can use this as their
+ * &tinydrm_panel_funcs->disable callback.
+ */
+int mipi_dbi_panel_disable(struct tinydrm_panel *panel)
+{
+ struct mipi_dbi *mipi = mipi_dbi_from_panel(panel);
+
+ if (panel->backlight)
+ return tinydrm_disable_backlight(panel->backlight);
+
+ mipi_dbi_blank(mipi);
+
+ return 0;
}
+EXPORT_SYMBOL(mipi_dbi_panel_disable);
/**
* mipi_dbi_pipe_disable - MIPI DBI pipe disable helper
@@ -356,6 +420,7 @@ int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
{
size_t bufsize = mode->vdisplay * mode->hdisplay * sizeof(u16);
struct tinydrm_device *tdev = &mipi->tinydrm;
+ struct tinydrm_panel *panel = &mipi->panel;
int ret;
if (!mipi->command)
@@ -388,6 +453,12 @@ int mipi_dbi_init(struct device *dev, struct mipi_dbi
*mipi,
DRM_DEBUG_KMS("preferred_depth=%u, rotation = %u\n",
tdev->drm->mode_config.preferred_depth, rotation);
+ /* transitional assignements */
+ panel->tinydrm.drm = mipi->tinydrm.drm;
+ mipi->swap_bytes = panel->swap_bytes;
+ panel->tx_buf = mipi->tx_buf;
+
[PATCH 4/5] drm/tinydrm/mi0283qt: Use tinydrm_panel
Convert mi0283qt to use tinydrm_panel.
Let mipi-dbi use tinydrm_panel_init().
Additionally change to the common header include order.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 113 +++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 51 -
include/drm/tinydrm/mipi-dbi.h | 4 +-
3 files changed, 45 insertions(+), 123 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index b29fe86..6e8142a 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -9,27 +9,30 @@
* (at your option) any later version.
*/
-#include
-#include
-#include
#include
#include
#include
#include
#include
#include
+
+#include
+#include
+#include
+
#include
-static int mi0283qt_init(struct mipi_dbi *mipi)
+static int mi0283qt_prepare(struct tinydrm_panel *panel)
{
- struct tinydrm_device *tdev = &mipi->tinydrm;
+ struct mipi_dbi *mipi = mipi_dbi_from_panel(panel);
+ struct tinydrm_device *tdev = &panel->tinydrm;
struct device *dev = tdev->drm->dev;
u8 addr_mode;
int ret;
DRM_DEBUG_KMS("\n");
- ret = regulator_enable(mipi->regulator);
+ ret = regulator_enable(panel->regulator);
if (ret) {
dev_err(dev, "Failed to enable regulator %d\n", ret);
return ret;
@@ -43,7 +46,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
if (ret) {
dev_err(dev, "Error sending command %d\n", ret);
- regulator_disable(mipi->regulator);
+ regulator_disable(panel->regulator);
return ret;
}
@@ -68,7 +71,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
/* Memory Access Control */
mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
- switch (mipi->rotation) {
+ switch (panel->rotation) {
default:
addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
ILI9341_MADCTL_MX;
@@ -113,19 +116,10 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
return 0;
}
-static void mi0283qt_fini(void *data)
-{
- struct mipi_dbi *mipi = data;
-
- DRM_DEBUG_KMS("\n");
- regulator_disable(mipi->regulator);
-}
-
-static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
- .enable = mipi_dbi_pipe_enable,
- .disable = mipi_dbi_pipe_disable,
- .update = tinydrm_display_pipe_update,
- .prepare_fb = tinydrm_display_pipe_prepare_fb,
+static const struct tinydrm_panel_funcs mi0283qt_funcs = {
+ .prepare = mi0283qt_prepare,
+ .disable = mipi_dbi_panel_disable,
+ .flush = mipi_dbi_panel_flush,
};
static const struct drm_display_mode mi0283qt_mode = {
@@ -161,6 +155,7 @@ static int mi0283qt_probe(struct spi_device *spi)
{
struct device *dev = &spi->dev;
struct tinydrm_device *tdev;
+ struct tinydrm_panel *panel;
struct mipi_dbi *mipi;
struct gpio_desc *dc;
u32 rotation = 0;
@@ -170,10 +165,13 @@ static int mi0283qt_probe(struct spi_device *spi)
if (!mipi)
return -ENOMEM;
- mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
- if (IS_ERR(mipi->reset)) {
+ panel = &mipi->panel;
+ tdev = &panel->tinydrm;
+
+ panel->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(panel->reset)) {
dev_err(dev, "Failed to get gpio 'reset'\n");
- return PTR_ERR(mipi->reset);
+ return PTR_ERR(panel->reset);
}
dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
@@ -182,39 +180,26 @@ static int mi0283qt_probe(struct spi_device *spi)
return PTR_ERR(dc);
}
- mipi->regulator = devm_regulator_get(dev, "power");
- if (IS_ERR(mipi->regulator))
- return PTR_ERR(mipi->regulator);
+ panel->regulator = devm_regulator_get(dev, "power");
+ if (IS_ERR(panel->regulator))
+ return PTR_ERR(panel->regulator);
- mipi->backlight = tinydrm_of_find_backlight(dev);
- if (IS_ERR(mipi->backlight))
- return PTR_ERR(mipi->backlight);
+ panel->backlight = tinydrm_of_find_backlight(dev);
+ if (IS_ERR(panel->backlight))
+ return PTR_ERR(panel->backlight);
device_property_read_u32(dev, "rotation", &rotation);
- ret = mipi_dbi_spi_init(spi, mipi, dc, &mi0283qt_pipe_funcs,
+ ret = mipi_dbi_spi_init(spi, mipi, dc, &mi0283qt_funcs,
&mi0283qt_driver, &mi0283qt_mode, rotation);
if (ret)
return ret;
- ret = mi0283qt_init(mipi);
- if (ret)
- return ret;
-
- /* use devres to fini after drm unregister (drv->
[PATCH 5/5] drm/tinydrm/mipi-dbi: Clean up after tinydrm_panel conversion
Finish conversion to tinydrm_panel by removing unneeded functions and
properties.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mipi-dbi.c | 154 -
include/drm/tinydrm/mipi-dbi.h | 25 --
2 files changed, 179 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 2f12a9a..0c29b74 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -155,136 +155,6 @@ int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd,
u8 *data, size_t len)
}
EXPORT_SYMBOL(mipi_dbi_command_buf);
-static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
- struct drm_clip_rect *clip, bool swap)
-{
- struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
- struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
- struct drm_format_name_buf format_name;
- void *src = cma_obj->vaddr;
- int ret = 0;
-
- if (import_attach) {
- ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
- DMA_FROM_DEVICE);
- if (ret)
- return ret;
- }
-
- switch (fb->format->format) {
- case DRM_FORMAT_RGB565:
- if (swap)
- tinydrm_swab16(dst, src, fb, clip);
- else
- tinydrm_memcpy(dst, src, fb, clip);
- break;
- case DRM_FORMAT_XRGB:
- tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
- break;
- default:
- dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
-drm_get_format_name(fb->format->format,
-&format_name));
- return -EINVAL;
- }
-
- if (import_attach)
- ret = dma_buf_end_cpu_access(import_attach->dmabuf,
-DMA_FROM_DEVICE);
- return ret;
-}
-
-static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
-struct drm_file *file_priv,
-unsigned int flags, unsigned int color,
-struct drm_clip_rect *clips,
-unsigned int num_clips)
-{
- struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
- struct tinydrm_device *tdev = fb->dev->dev_private;
- struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
- bool swap = mipi->swap_bytes;
- struct drm_clip_rect clip;
- int ret = 0;
- bool full;
- void *tr;
-
- mutex_lock(&tdev->dirty_lock);
-
- if (!mipi->enabled)
- goto out_unlock;
-
- /* fbdev can flush even when we're not interested */
- if (tdev->pipe.plane.fb != fb)
- goto out_unlock;
-
- full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
- fb->width, fb->height);
-
- DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u\n", fb->base.id,
- clip.x1, clip.x2, clip.y1, clip.y2);
-
- if (!mipi->dc || !full || swap ||
- fb->format->format == DRM_FORMAT_XRGB) {
- tr = mipi->tx_buf;
- ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, &clip, swap);
- if (ret)
- goto out_unlock;
- } else {
- tr = cma_obj->vaddr;
- }
-
- mipi_dbi_command(mipi, MIPI_DCS_SET_COLUMN_ADDRESS,
-(clip.x1 >> 8) & 0xFF, clip.x1 & 0xFF,
-(clip.x2 >> 8) & 0xFF, (clip.x2 - 1) & 0xFF);
- mipi_dbi_command(mipi, MIPI_DCS_SET_PAGE_ADDRESS,
-(clip.y1 >> 8) & 0xFF, clip.y1 & 0xFF,
-(clip.y2 >> 8) & 0xFF, (clip.y2 - 1) & 0xFF);
-
- ret = mipi_dbi_command_buf(mipi, MIPI_DCS_WRITE_MEMORY_START, tr,
- (clip.x2 - clip.x1) * (clip.y2 - clip.y1) * 2);
-
-out_unlock:
- mutex_unlock(&tdev->dirty_lock);
-
- if (ret)
- dev_err_once(fb->dev->dev, "Failed to update display %d\n",
-ret);
-
- return ret;
-}
-
-static const struct drm_framebuffer_funcs mipi_dbi_fb_funcs = {
- .destroy= drm_fb_cma_destroy,
- .create_handle = drm_fb_cma_create_handle,
- .dirty = mipi_dbi_fb_dirty,
-};
-
-/**
- * mipi_dbi_pipe_enable - MIPI DBI pipe enable helper
- * @pipe: Display pipe
- * @crtc_state: CRTC state
- *
- * This function enables backlight. Drivers can use this as their
- * &drm_simple_display_pipe_funcs->enable callback.
- */
-void mipi_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
-{
- struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
- struct mip
[PATCH 1/5] drm/tinydrm: Add tinydrm_rgb565_buf_copy()
Add tinydrm_rgb565_buf_copy() function that copies buffer rectangle to
destination buffer and also handles XRGB and byte swap conversions.
Useful for displays that only support RGB565 and can do partial updates.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 56 +-
include/drm/tinydrm/tinydrm-helpers.h | 2 +
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d4cda33..e639453 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -7,13 +7,15 @@
* (at your option) any later version.
*/
-#include
-#include
#include
+#include
#include
#include
#include
+#include
+#include
+
static unsigned int spi_max;
module_param(spi_max, uint, 0400);
MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
@@ -181,6 +183,56 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
/**
+ * tinydrm_rgb565_buf_copy - Copy RGB565/XRGB to RGB565 clip buffer
+ * @dst: RGB565 destination buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @swap: Swap bytes
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int tinydrm_rgb565_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap)
+{
+ struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+ struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
+ struct drm_format_name_buf format_name;
+ void *src = cma_obj->vaddr;
+ int ret = 0;
+
+ if (import_attach) {
+ ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
+ DMA_FROM_DEVICE);
+ if (ret)
+ return ret;
+ }
+
+ switch (fb->format->format) {
+ case DRM_FORMAT_RGB565:
+ if (swap)
+ tinydrm_swab16(dst, src, fb, clip);
+ else
+ tinydrm_memcpy(dst, src, fb, clip);
+ break;
+ case DRM_FORMAT_XRGB:
+ tinydrm_xrgb_to_rgb565(dst, src, fb, clip, swap);
+ break;
+ default:
+ dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
+drm_get_format_name(fb->format->format,
+&format_name));
+ return -EINVAL;
+ }
+
+ if (import_attach)
+ ret = dma_buf_end_cpu_access(import_attach->dmabuf,
+DMA_FROM_DEVICE);
+ return ret;
+}
+EXPORT_SYMBOL(tinydrm_rgb565_buf_copy);
+
+/**
* tinydrm_of_find_backlight - Find backlight device in device-tree
* @dev: Device
*
diff --git a/include/drm/tinydrm/tinydrm-helpers.h
b/include/drm/tinydrm/tinydrm-helpers.h
index 9b9b6cf..d1f6722 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -43,6 +43,8 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct
drm_framebuffer *fb,
void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_clip_rect *clip, bool swap);
+int tinydrm_rgb565_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap);
struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
int tinydrm_enable_backlight(struct backlight_device *backlight);
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490
--- Comment #121 from Franc[e]sco ---
I removed the quirks for my r9 270x and I have no stability issues whatsoever,
it's a really nice performance boost.
this is the line I commented out for my card:
{ PCI_VENDOR_ID_ATI, 0x6810, 0x174b, 0xe271, 85000, 9 },
and here's full info on my system on this forum post:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/937952-sapphire-dual-x-r9-270x-not-running-at-full-clock-speeds-amdgpu-and-radeon
let me know if you need any more testing on this, but I'm pretty sure it's
stable
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled
Touching HW while clocks are off is a serious error and for instance
breaks suspend functionality. After this patch tilcdc_crtc_update_fb()
always updates the primary plane's framebuffer pointer, increases fb's
reference count and stores vblank event. tilcdc_crtc_update_fb() only
writes the fb's DMA address to HW if the crtc is enabled, as
tilcdc_crtc_enable() takes care of writing the address on enable.
This patch also refactors the tilcdc_crtc_update_fb() a bit. Number of
subsequent small changes to had made it almost unreadable. There
should be no other functional changes but checking the CRTC's enable
state. However, the locking goes a bit differently and some of the
redundant checks have been removed in this new version.
The enable_lock should be enough to protect the access to
tilcdc_crtc->enabled. The irq_lock protects the access to last_vblank
and next_fb. The check for vrefresh and last_vblank being valid is
redundant, as the vrefresh should be always valid if the CRTC is
enabled and now last_vblank should be too, because it is initialized
to current time when CRTC raster is enabled. If for some reason the
values are not corretly initialized the division by zero waning is
quite appropriate.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 37 +++-
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index f80bf93..bd92c89 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -1,4 +1,4 @@
-/*
+*
* Copyright (C) 2012 Texas Instruments
* Author: Rob Clark
*
@@ -464,6 +464,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+ unsigned long flags;
WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
mutex_lock(&tilcdc_crtc->enable_lock);
@@ -484,7 +485,17 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
tilcdc_write_mask(dev, LCDC_RASTER_CTRL_REG,
LCDC_PALETTE_LOAD_MODE(DATA_ONLY),
LCDC_PALETTE_LOAD_MODE_MASK);
+
+ /* There is no real chance for a race here as the time stamp
+* is taken before the raster DMA is started. The spin-lock is
+* taken to have a memory barrier after taking the time-stamp
+* and to avoid a context switch between taking the stamp and
+* enabling the raster.
+*/
+ spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+ tilcdc_crtc->last_vblank = ktime_get();
tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+ spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
drm_crtc_vblank_on(crtc);
@@ -539,7 +550,6 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool
shutdown)
}
drm_flip_work_commit(&tilcdc_crtc->unref_work, priv->wq);
- tilcdc_crtc->last_vblank = 0;
tilcdc_crtc->enabled = false;
mutex_unlock(&tilcdc_crtc->enable_lock);
@@ -602,7 +612,6 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
{
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
- unsigned long flags;
WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
@@ -614,28 +623,30 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
drm_framebuffer_reference(fb);
crtc->primary->fb = fb;
+ tilcdc_crtc->event = event;
- spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+ mutex_lock(&tilcdc_crtc->enable_lock);
- if (crtc->hwmode.vrefresh && ktime_to_ns(tilcdc_crtc->last_vblank)) {
+ if (tilcdc_crtc->enabled) {
+ unsigned long flags;
ktime_t next_vblank;
s64 tdiff;
+ spin_lock_irqsave(&tilcdc_crtc->irq_lock, flags);
+
next_vblank = ktime_add_us(tilcdc_crtc->last_vblank,
- 100 / crtc->hwmode.vrefresh);
-
+ 100 / crtc->hwmode.vrefresh);
tdiff = ktime_to_us(ktime_sub(next_vblank, ktime_get()));
if (tdiff < TILCDC_VBLANK_SAFETY_THRESHOLD_US)
tilcdc_crtc->next_fb = fb;
+ else
+ set_scanout(crtc, fb);
+
+ spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
}
- if (tilcdc_crtc->next_fb != fb)
- set_scanout(crtc, fb);
-
- tilcdc_crtc->event = event;
-
- spin_unlock_irqrestore(&tilcdc_crtc->irq_lock, flags);
+ mutex_unlock(&tilcdc_crtc->enable_lock);
return 0;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100101] [SNB GT1] GPU HANG: ecode 6:0:0x85deffbc, in gnome-shell [3664], reason: Hang on render ring, action: reset
https://bugs.freedesktop.org/show_bug.cgi?id=100101 Kenneth Graunke changed: What|Removed |Added Summary|[i915] GPU HANG: ecode |[SNB GT1] GPU HANG: ecode |6:0:0x85deffbc, in |6:0:0x85deffbc, in |gnome-shell [3664], reason: |gnome-shell [3664], reason: |Hang on render ring,|Hang on render ring, |action: reset |action: reset -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
Hello,
Le 10/03/2017 à 12:15, Russell King - ARM Linux a écrit :
> On Fri, Mar 10, 2017 at 11:58:19AM +0100, Romain Perier wrote:
>> Hello,
>>
>> Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit :
>>> I also would not think that it's platform specific - remember that
>>> this is Designware IP, and it's likely that other platforms with
>>> exactly the same IP would suffer from the same problem. It's
>>> probably revision specific, but we need Synopsis' input on that.
>>>
>>> However, I do believe that your patch probably doesn't have much
>>> merit in any case: on a mode set, you enable the audio clock, and
>>> it will remain enabled until the audio device is first opened and
>>> then closed. If another mode set comes along, then exactly the
>>> same situation happens again. So, really it isn't achieving all
>>> that much.
>> The fact is we still have sound glitches caused by this workaround on
>> Rockchip, we probably have a revision
>> of the IP without this issue. If CTS+N is not forced to zero we no
>> longer have the glitches :/ (with or without touching the clock)
> Are you sure that removing the workaround just doesn't result in the
> same bug as on iMX6 appearing? The bug concerned is the ordering of
> the channels, so unless you're (eg0 monitoring left/right separately
> or directing audio to just one channel, you may not (with modern TVs)
> realise that the channels are swapped. I'll include the errata
> description and impact below.
>
> There are occasional issues on iMX6 as well despite this work-around,
> but I don't clearly remember what devmem2 tweaks I've done in the past
> to get it to resolve itself, nor could I describe them from memory
> any better than "burbling audio".
Well, I have reverted locally your patch (I did it quickly by hand
because it did not work via git revert... anyway...),
And I no longer have the issue at all. It's working fine all the time
and it's truly deterministic (see attachment)
Also, I have found that the version of the IP is not exactly the same.
On Rockchip it's 0x20:0xa:0xa0:0xc1, on IMX.6 it's 0x13:0xa:0xa0:0xc1.
>
>
> When the AHB Audio DMA is started, by setting to 1'b1 for the first
> time the register field AHB_DMA_START.data_buffer_ready, the AHB
> Audio DMA will request data from the AHB bus to fill its internal
> AHB DMA FIFO. It is possible that a AHB DMA FIFO read action occurs
> during the time window between the first sample stored on the AHB
> DMA FIFO and when the AHB DMA FIFO has stored, at least, the number
> of configured audio channels in samples. If this happens, the AHB
> DMA FIFO will reply with samples that are currently on the AHB
> Audio FIFO and will repeat the last sample after the empty condition
> is reached.
>
> Projected Impact:
> This will miss-align the audio stream, causing a shift in the
> distribution of audio on the channels on the HDMI sink side, with no
> knowledge of the DWC_hdmi_tx enabled system.
Thanks for this, it helps!
It looks specific to AHB audio
>
>
> If you know that this definitely does not apply to your version, then
> we need to split the audio enable/disable functions between the AHB
> and I2S variants.
Mhhh, yeah both seem to work differently.
Romain
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
index aaf287d..ce589402 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi-i2s-audio.c
@@ -67,8 +67,6 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void *data,
hdmi_write(audio, conf0, HDMI_AUD_CONF0);
hdmi_write(audio, conf1, HDMI_AUD_CONF1);
- dw_hdmi_audio_enable(hdmi);
-
return 0;
}
@@ -77,8 +75,6 @@ static void dw_hdmi_i2s_audio_shutdown(struct device *dev, void *data)
struct dw_hdmi_i2s_audio_data *audio = data;
struct dw_hdmi *hdmi = audio->hdmi;
- dw_hdmi_audio_disable(hdmi);
-
hdmi_write(audio, HDMI_AUD_CONF0_SW_RESET, HDMI_AUD_CONF0);
}
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b621fc7..7529cb9 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
@@ -148,12 +147,8 @@ struct dw_hdmi {
bool rxsense; /* rxsense state */
u8 phy_mask; /* desired phy int mask settings */
- spinlock_t audio_lock;
struct mutex audio_mutex;
unsigned int sample_rate;
- unsigned int audio_cts;
- unsigned int audio_n;
- bool audio_enable;
void (*write)(struct dw_hdmi *hdmi, u8 val, int offset);
u8 (*read)(struct dw_hdmi *hdmi, int offset);
@@ -505,11 +500,7 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
__func__, sample_rate, ftdms / 100, (ftdms / 1000) % 1000,
n, cts);
- spin_lock_irq(&hdmi->audio_lock);
- hdmi->audio_n = n;
- hdmi->audio_cts = cts;
- hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
- spin_unlock_irq(&hdmi->audio_lock);
+ hdmi_s
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
Hello, Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit : > On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: >> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at >> step E. and is kept enabled for later use. This clock should be enabled >> and disabled along with the actual audio stream and not always on (that >> is bad for PM). Futhermore, this might cause sound glitches with some >> HDMI devices, as the CTS+N is forced to zero when the stream is disabled >> while the audio clock is still running. >> >> This commit adds a parameter to hdmi_audio_enable_clk() that controls >> when the audio sample clock must be enabled or disabled. Then, it moves >> the call to this function into dw_hdmi_audio_enable() and >> dw_hdmi_audio_disable(). > How does this interact with the workaround given in my commit introducing > these functions? (Commit b90120a96608). > > Setting N=0 is a work-around for iMX6, and we need the audio FIFO to be > loaded with data prior to setting N non-zero. If disabling the audio > clock prevents the audio FIFO being loaded, your patch will break iMX6. > Mhhh, the fact is I have no IMX6 devices here (only Rockchip). So I only tested on Rockchip devices. An approach might be to introduce an option for handling this errata, because that's platform specific and other platforms (like Rockchip) are in conflict with this. Romain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
On Fri, Mar 10, 2017 at 11:21:53AM +0100, Romain Perier wrote: > Hello, > > Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit : > > On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: > >> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at > >> step E. and is kept enabled for later use. This clock should be enabled > >> and disabled along with the actual audio stream and not always on (that > >> is bad for PM). Futhermore, this might cause sound glitches with some > >> HDMI devices, as the CTS+N is forced to zero when the stream is disabled > >> while the audio clock is still running. > >> > >> This commit adds a parameter to hdmi_audio_enable_clk() that controls > >> when the audio sample clock must be enabled or disabled. Then, it moves > >> the call to this function into dw_hdmi_audio_enable() and > >> dw_hdmi_audio_disable(). > > How does this interact with the workaround given in my commit introducing > > these functions? (Commit b90120a96608). > > > > Setting N=0 is a work-around for iMX6, and we need the audio FIFO to be > > loaded with data prior to setting N non-zero. If disabling the audio > > clock prevents the audio FIFO being loaded, your patch will break iMX6. > > > Mhhh, the fact is I have no IMX6 devices here (only Rockchip). So > I only tested on Rockchip devices. An approach might be to introduce an > option for handling this errata, because that's platform specific and > other platforms (like Rockchip) are in conflict with this. I'd say that they _aren't_ in conflict with it - or are you saying that the I2S driver was never functionally tested as working? I also would not think that it's platform specific - remember that this is Designware IP, and it's likely that other platforms with exactly the same IP would suffer from the same problem. It's probably revision specific, but we need Synopsis' input on that. However, I do believe that your patch probably doesn't have much merit in any case: on a mode set, you enable the audio clock, and it will remain enabled until the audio device is first opened and then closed. If another mode set comes along, then exactly the same situation happens again. So, really it isn't achieving all that much. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
step E. and is kept enabled for later use. This clock should be enabled
and disabled along with the actual audio stream and not always on (that
is bad for PM). Futhermore, this might cause sound glitches with some
HDMI devices, as the CTS+N is forced to zero when the stream is disabled
while the audio clock is still running.
This commit adds a parameter to hdmi_audio_enable_clk() that controls
when the audio sample clock must be enabled or disabled. Then, it moves
the call to this function into dw_hdmi_audio_enable() and
dw_hdmi_audio_disable().
Signed-off-by: Romain Perier
---
drivers/gpu/drm/bridge/dw-hdmi.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index b621fc7..5b6090c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -537,6 +537,12 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi,
unsigned int rate)
}
EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
+static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
+{
+ hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
+ HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+}
+
void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
{
unsigned long flags;
@@ -544,6 +550,7 @@ void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
spin_lock_irqsave(&hdmi->audio_lock, flags);
hdmi->audio_enable = true;
hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
+ hdmi_enable_audio_clk(hdmi, true);
spin_unlock_irqrestore(&hdmi->audio_lock, flags);
}
EXPORT_SYMBOL_GPL(dw_hdmi_audio_enable);
@@ -554,6 +561,7 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
spin_lock_irqsave(&hdmi->audio_lock, flags);
hdmi->audio_enable = false;
+ hdmi_enable_audio_clk(hdmi, false);
hdmi_set_cts_n(hdmi, hdmi->audio_cts, 0);
spin_unlock_irqrestore(&hdmi->audio_lock, flags);
}
@@ -1343,11 +1351,6 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi
*hdmi)
}
}
-static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
-{
- hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
-}
-
/* Workaround to clear the overflow condition */
static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
{
@@ -1430,7 +1433,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
/* HDMI Initialization Step E - Configure audio */
hdmi_clk_regenerator_update_pixel_clock(hdmi);
- hdmi_enable_audio_clk(hdmi);
+ hdmi_enable_audio_clk(hdmi, true);
}
/* not for DVI mode */
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
On Fri, Mar 10, 2017 at 11:58:19AM +0100, Romain Perier wrote: > Hello, > > Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit : > > I also would not think that it's platform specific - remember that > > this is Designware IP, and it's likely that other platforms with > > exactly the same IP would suffer from the same problem. It's > > probably revision specific, but we need Synopsis' input on that. > > > > However, I do believe that your patch probably doesn't have much > > merit in any case: on a mode set, you enable the audio clock, and > > it will remain enabled until the audio device is first opened and > > then closed. If another mode set comes along, then exactly the > > same situation happens again. So, really it isn't achieving all > > that much. > > The fact is we still have sound glitches caused by this workaround on > Rockchip, we probably have a revision > of the IP without this issue. If CTS+N is not forced to zero we no > longer have the glitches :/ (with or without touching the clock) Are you sure that removing the workaround just doesn't result in the same bug as on iMX6 appearing? The bug concerned is the ordering of the channels, so unless you're (eg0 monitoring left/right separately or directing audio to just one channel, you may not (with modern TVs) realise that the channels are swapped. I'll include the errata description and impact below. There are occasional issues on iMX6 as well despite this work-around, but I don't clearly remember what devmem2 tweaks I've done in the past to get it to resolve itself, nor could I describe them from memory any better than "burbling audio". When the AHB Audio DMA is started, by setting to 1'b1 for the first time the register field AHB_DMA_START.data_buffer_ready, the AHB Audio DMA will request data from the AHB bus to fill its internal AHB DMA FIFO. It is possible that a AHB DMA FIFO read action occurs during the time window between the first sample stored on the AHB DMA FIFO and when the AHB DMA FIFO has stored, at least, the number of configured audio channels in samples. If this happens, the AHB DMA FIFO will reply with samples that are currently on the AHB Audio FIFO and will repeat the last sample after the empty condition is reached. Projected Impact: This will miss-align the audio stream, causing a shift in the distribution of audio on the channels on the HDMI sink side, with no knowledge of the DWC_hdmi_tx enabled system. If you know that this definitely does not apply to your version, then we need to split the audio enable/disable functions between the AHB and I2S variants. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
Currently, the irq handler that monitores changes for HPD anx RX_SENSE
relies on the status of the bridge for updating the status of the HPD.
The update is done only when the bridge is enabled.
However, on Rockchip platforms we have found use cases where it could be
a problem. When HDMI is being used, turning off/on the screen or
unplugging/re-plugging the cable, the following simplified code path
will happen:
- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
hdmi->disabled is false, then the handler will update the rxsense flag
accordingly.
- dw_hdmi_update_power() will be invoked with the mode
DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
called and the PHY will be desactivated (its pixel clocks and TMDS)
[...]
- dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
disabled.
- dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
currently disabled the HPD status won't be updated, so hdmi->rxsense
won't be changed. Even if the data part of the PHY is disabled, this
information coming from the HDMI Transmitter is correct and should be
saved.
[...]
- dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
enabled.
- dw_hdmi_update_power() will be called. When hdmi->force is equal to
DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this
field has not been updated by the irq handler, it will be false and
DRM_FORCE_ON won't be put to hdmi->force.
Consequently, most of the time dw_hdmi_poweron() won't be called in this
use case, TMDS won't be re-enabled the PHY won't be re-initialized,
resulting in a "Signal not found".
This commit fixes the issue by removing the check for "!hdmi->disabled".
As already explained, even if the PHY is partially disabled, information
coming from HDMI Transmitter about HPD should be saved for a later use.
Signed-off-by: Romain Perier
---
Changes in v2:
- I have re-worded the commit message, as suggested by Russel
drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 3a70016..5b6090c 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1793,7 +1793,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
mutex_lock(&hdmi->mutex);
- if (!hdmi->disabled && !hdmi->force) {
+ if (!hdmi->force) {
/*
* If the RX sense status indicates we're disconnected,
* clear the software rxsense status.
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
Hello, Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit : > On Fri, Mar 10, 2017 at 11:21:53AM +0100, Romain Perier wrote: >> Hello, >> >> Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit : >>> On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: Currently, the audio sampler clock is enabled from dw_hdmi_setup() at step E. and is kept enabled for later use. This clock should be enabled and disabled along with the actual audio stream and not always on (that is bad for PM). Futhermore, this might cause sound glitches with some HDMI devices, as the CTS+N is forced to zero when the stream is disabled while the audio clock is still running. This commit adds a parameter to hdmi_audio_enable_clk() that controls when the audio sample clock must be enabled or disabled. Then, it moves the call to this function into dw_hdmi_audio_enable() and dw_hdmi_audio_disable(). >>> How does this interact with the workaround given in my commit introducing >>> these functions? (Commit b90120a96608). >>> >>> Setting N=0 is a work-around for iMX6, and we need the audio FIFO to be >>> loaded with data prior to setting N non-zero. If disabling the audio >>> clock prevents the audio FIFO being loaded, your patch will break iMX6. >>> >> Mhhh, the fact is I have no IMX6 devices here (only Rockchip). So >> I only tested on Rockchip devices. An approach might be to introduce an >> option for handling this errata, because that's platform specific and >> other platforms (like Rockchip) are in conflict with this. > or are you saying > that the I2S driver was never functionally tested as working? No ^^ > > I also would not think that it's platform specific - remember that > this is Designware IP, and it's likely that other platforms with > exactly the same IP would suffer from the same problem. It's > probably revision specific, but we need Synopsis' input on that. > > However, I do believe that your patch probably doesn't have much > merit in any case: on a mode set, you enable the audio clock, and > it will remain enabled until the audio device is first opened and > then closed. If another mode set comes along, then exactly the > same situation happens again. So, really it isn't achieving all > that much. > The fact is we still have sound glitches caused by this workaround on Rockchip, we probably have a revision of the IP without this issue. If CTS+N is not forced to zero we no longer have the glitches :/ (with or without touching the clock) Romain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane
I think the easiest (if definitely not the fastest) way for me to test these patches the Arch way IF they will apply cleanly against 4.11-rc1 is to patch the linux-armv7-rc PKGBUILD so that it will apply Phillipp's patches before it builds the kernel. The linux-armv7-rc PKGBUILD is available from git clone https://github.com/archlinuxarm/PKGBUILDs.git under core/linux-armv7-rc. I think all I should need to do is add: git fetch https://git.pengutronix.de/git/pza/linux.git tags/v4.10-ipu-dp-plane-fix git checkout FETCH_HEAD To the prepare() section of the PKGBUILD, prob just after the last `git apply ...` line Should your patches work fine under 4.11-rc1 Phillipp or do I need to test againt the very latest git? I realise that would be preferred. If anyone can tell me how I would build linux git specifically for Arch on the SABRE Lite, that'd be even better! I haven't needed to build a kernel in a very long time! Thanks On Thu, Mar 9, 2017 at 10:00 AM, Dan MacDonald wrote: > Thanks for your tips and links Philipp and Russell! > > My distro of choice is Arch and so really I should try to install the > patched git kernel "the Arch way" so my first question is, does anyone > on this list have an Arch PKGBUILD script to create a linux (4.x) git > kernel package for imx6 alikes? > > If the answer to that is no then I think I'm most of the way to having > created one based upon https://aur.archlinux.org/packages/linux-git/ > but I'm missing a suitable kernel .config file. I tried putting > > make imx_v6_v7_defconfig > > Into the PKGBUILD but that didn't work out and the ALARM imx6 kernel > config is for kernel 3.14 so I can't use that either. > > Thanks > > > > On Mon, Mar 6, 2017 at 4:29 PM, Russell King - ARM Linux > wrote: >> On Mon, Mar 06, 2017 at 02:50:58PM +0100, Philipp Zabel wrote: >>> Sorry, I should have mentioned that this must be called from inside an >>> existing kernel git repository. The idea is that you don't have to clone >>> the whole kernel through our pipe, but can use the upstream repository, >>> which has a much better internet connection, for most of the data: >>> >>> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> cd linux >>> git fetch https://git.pengutronix.de/git/pza/linux.git >>> tags/v4.10-ipu-dp-plane-fix >>> git checkout -b "branchname" FETCH_HEAD >> >> If you have an existing tree which is based on Linus' tree, you can save >> the server and download bandwidth by doing: >> >> git clone --dissociate --reference /path/to/local/copy/of/linus/tree >> https://git.pengutronix.de/git/pza/linux.git >> cd linux >> git checkout tags/v4.10-ipu-dp-plane-fix >> >> This will clone your tree, but make use of the objects already present >> in /path/to/local/copy/of/linus/tree, making copies of them (so it >> doesn't matter if you subsequently get rid of that reference tree.) >> >> -- >> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ >> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up >> according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions
On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: > Currently, the audio sampler clock is enabled from dw_hdmi_setup() at > step E. and is kept enabled for later use. This clock should be enabled > and disabled along with the actual audio stream and not always on (that > is bad for PM). Futhermore, this might cause sound glitches with some > HDMI devices, as the CTS+N is forced to zero when the stream is disabled > while the audio clock is still running. > > This commit adds a parameter to hdmi_audio_enable_clk() that controls > when the audio sample clock must be enabled or disabled. Then, it moves > the call to this function into dw_hdmi_audio_enable() and > dw_hdmi_audio_disable(). How does this interact with the workaround given in my commit introducing these functions? (Commit b90120a96608). Setting N=0 is a work-around for iMX6, and we need the audio FIFO to be loaded with data prior to setting N non-zero. If disabling the audio clock prevents the audio FIFO being loaded, your patch will break iMX6. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: connector/edid probing races
On Fri, Mar 10, 2017 at 01:13:12PM -0500, Sean Paul wrote: > On Fri, Mar 10, 2017 at 05:52:34PM +0100, Daniel Vetter wrote: > > On Fri, Mar 10, 2017 at 11:01:54AM -0500, Sean Paul wrote: > > > On Fri, Mar 10, 2017 at 02:12:14PM +1000, Dave Airlie wrote: > > > > Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug > > > > all 3 of them were diving into the connector getting code. Now I think > > > > we can avoid this in userspace by not probing when not owning the VT, > > > > but it's still messy behaviour. > > > > > > > > It looks like one thread does a getconnector, this fills out the EDID > > > > blob with a specific blob id, > > > > then second thread does getconnector, which replaces the EDID blob > > > > with another one > > > > the first thread calls get property blob, but the blob id it is > > > > looking for is destroyed. > > > > > > > > Ideas? > > > > > > I think you could probably fix this by introducing a new > > > drm_property_overwrite_global_blob() function. If the size of the current > > > blob is > > > the same as the new blob, you could just overwrite the data and preserve > > > the id > > > and references. You could then replace the > > > drm_property_replace_global_blob() call in > > > drm_mode_connector_update_edid_property() to call the new function. Of > > > course, > > > you would need to fall back on *replace_global_blob() if size differed, > > > but it > > > would probably solve the issue above. > > > > blobs are imutable (not that userspace can use that much since we can > > reuse ids), > > Pedantic distinction: blobs themselves aren't inherantly immutable. However, > the > EDID property is defined as immutable. I suppose there could conceivably be > some > userspace somewhere that relies on this. Bummer. It's more tricky: The property is labelled as IMMUTABLE, but that's a lie, it essentially only means that userspace isn't allowed to change it. The kernel is. But blobs themselves are immutable, this is the same semantics as with framebuffer objects, and we carried that over when we started to allow userspace to create blobs (for atomic). The only benefit is for drivers, as long as you hold a life reference you can just compare pointers and if they're equal, you know nothing changed. Due to id reuse, userspace unfortunately can't do this (and yes we've had clever userspace who got this wrong). > > I think if we do this we should compare the contents of the > > blob. > > > > > That said, I'm not convinced it should be kernel's responsibility to > > > really > > > solve this problem. How much effort should we put into mitigating the > > > effects of > > > a racey and wasteful userspace? > > > > It's a tradeoff between "why should the kernel care" and "every compositor > > will get this wrong". Maybe something like libweston will fix this > > eventually > > So the question is whether it's worth it to penalize well-behaved compositors > with superfluous memcmp on EDID fetches to make up for the ill-behaved ones. I > don't think it is, but perhaps there are other benefits to preserving the > single > blob for the lifetime of the connection. If you can profile that memcmp in a 25ms edid read, I'll buy this argument :-) I think the better argument against is that there's still cases where userspace must recover from similar issues (getconnector racing with a hpd which can also update the edid), but those are even rarer. It might be good to keep the easier-to-hit races open, to force better error handling in userspace. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v4.12] Bye bye drm_platform midlayer
On Fri, Feb 17, 2017 at 03:40:16PM +0200, Laurent Pinchart wrote: > Hi Dave, > > The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c: > > Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000) > > are available in the git repository at: > > git://linuxtv.org/pinchartl/media.git drm/next/platform Pulled into drm-misc-next since that also allowed me to fix up the drm_platform_init misplacemenet fumble :-) Thanks, Daniel > > for you to fetch changes up to 76adb460fd939756db689f238d5c2ddb45469705: > > drm: Remove the struct drm_device platformdev field (2017-02-17 15:27:24 > +0200) > > > Laurent Pinchart (4): > drm: shmobile: Perform initialization/cleanup at probe/remove time > drm: exynos: Perform initialization/cleanup at probe/remove time > drm: Remove unused drm_platform midlayer > drm: Remove the struct drm_device platformdev field > > Documentation/gpu/drm-internals.rst | 3 - > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/armada/armada_drv.c | 3 +- > drivers/gpu/drm/drm_platform.c| 87 --- > drivers/gpu/drm/exynos/exynos_dp.c| 1 - > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 241 +++-- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 - > drivers/gpu/drm/exynos/exynos_hdmi.c | 1 - > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c | 2 +- > drivers/gpu/drm/msm/msm_drv.c | 1 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +- > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 204 > drivers/gpu/drm/sti/sti_drv.c | 2 - > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - > include/drm/drmP.h| 4 - > 21 files changed, 236 insertions(+), 336 deletions(-) > delete mode 100644 drivers/gpu/drm/drm_platform.c > > -- > Regards, > > Laurent Pinchart > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #22 from cosiek...@o2.pl --- Created attachment 130163 --> https://bugs.freedesktop.org/attachment.cgi?id=130163&action=edit mesa 17.0.1 kernel 4.10.1 hyperz on -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37724] r300g with HyperZ/Z compression: occlusion queries are messed up in ut2004 (regression, bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=37724 --- Comment #21 from cosiek...@o2.pl --- Created attachment 130162 --> https://bugs.freedesktop.org/attachment.cgi?id=130162&action=edit mesa 17.0.1 kernel 4.10.1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] PCI: Recognize Thunderbolt devices
On Fri, Mar 10, 2017 at 02:47:04PM -0600, Bjorn Helgaas wrote:
> On Fri, Mar 10, 2017 at 2:23 PM, Lukas Wunner wrote:
> > +/**
> > + * pci_is_thunderbolt_attached - whether device is on a Thunderbolt daisy
> > chain
> > + * @pdev: PCI device to check
> > + *
> > + * Walk upwards from @pdev and check for each encountered bridge if it's
> > part
> > + * of a Thunderbolt controller. Reaching the host bridge means @pdev is
> > not
> > + * Thunderbolt-attached. (But rather soldered to the mainboard usually.)
>
> The "soldered to the mainboard" comment is misleading. We'll reach
> the host bridge and return "false" for any non-Thunderbolt-attached
> device, including all plug-in PCI and PCIe devices.
It does say "usually". :-) Seriously though, for someone coming from one
of the callers of pci_is_thunderbolt_attached() and trying to understand
its meaning, it may not be helpful if I had left it at "Reaching the host
bridge means @pdev is not Thunderbolt-attached."
What is the *consequence* of that? Most Thunderbolt-equipped products
have no other PCI expansion options, so indeed if the device is not on
a Thunderbolt daisy chain it must be soldered to the mainboard. If one
wants to be pedantic, one could add that it may alternatively be
soldered to a *daughter*board. (Which is the case on the MacPro6,1,
the black trashcan.) I was just trying to strike a balance between
technical correctness, didactic quality and brevity.
Best regards,
Lukas
>
> > + */
> > +static inline bool pci_is_thunderbolt_attached(struct pci_dev *pdev)
> > +{
> > + struct pci_dev *parent = pdev;
> > +
> > + if (pdev->is_thunderbolt)
> > + return true;
> > +
> > + while ((parent = pci_upstream_bridge(parent)))
> > + if (parent->is_thunderbolt)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > /* provide the legacy pci_dma_* API */
> > #include
> >
> > --
> > 2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
