Re: [PATCH] gpu/drm/bridge/sii9234: Use common error handling code in sii9234_writebm()
On Sun, Oct 22, 2017 at 09:32:46PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 22 Oct 2017 21:21:44 +0200
>
> * Add a jump target so that a bit of exception handling can be better
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> * Adjust condition checks.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/gpu/drm/bridge/sii9234.c | 28 ++--
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii9234.c
> b/drivers/gpu/drm/bridge/sii9234.c
> index c77000626c22..fbdacdaf485c 100644
> --- a/drivers/gpu/drm/bridge/sii9234.c
> +++ b/drivers/gpu/drm/bridge/sii9234.c
> @@ -231,30 +231,22 @@ static int sii9234_writebm(struct sii9234 *ctx, int id,
> int offset,
> return ctx->i2c_error;
>
> ret = i2c_smbus_write_byte(client, offset);
> - if (ret < 0) {
> - dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
> - sii9234_client_name[id], offset, value);
> - ctx->i2c_error = ret;
> - return ret;
> - }
> + if (ret)
> + goto report_failure;
>
> ret = i2c_smbus_read_byte(client);
> - if (ret < 0) {
> - dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
> - sii9234_client_name[id], offset, value);
> - ctx->i2c_error = ret;
> - return ret;
> - }
> + if (ret)
> + goto report_failure;
>
> value = (value & mask) | (ret & ~mask);
> -
> ret = i2c_smbus_write_byte_data(client, offset, value);
> - if (ret < 0) {
> - dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
> - sii9234_client_name[id], offset, value);
> - ctx->i2c_error = ret;
> - }
> + if (!ret)
> + return 0;
Ugh. No. Don't do success handling on the last if statement. Also
while I personally prefer testing for non-zero, the ALSA people got
annoyed at you for changing tests for < 0 but you're doing it again.
And it introduces a bug, although I see now that you fixed it in v2.
I can't get excited about these sort of risky low value patches.
>
> +report_failure:
> + dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
> + sii9234_client_name[id], offset, value);
> + ctx->i2c_error = ret;
> return ret;
> }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane
Apply the "panel orientation" drm connector prop to the primary plane so
that fbcon and fbdev using userspace programs display the right way up.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
Signed-off-by: Hans de Goede
---
Changes in v2:
-New patch in v2 of this patch-set
Changes in v3:
-Use a rotation member in struct drm_fb_helper_crtc and set that from
drm_setup_crtcs instead of looping over all crtc's to find the right one
later
-Since we now no longer look at rotation quirks directly in the fbcon code,
set fb_info.fbcon_rotate_hint when the panel is not mounted upright and
we cannot use hardware rotation
---
drivers/gpu/drm/drm_fb_helper.c | 76 +++--
include/drm/drm_fb_helper.h | 8 +
2 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1337c7..e0f95f2cc52f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -41,6 +41,7 @@
#include
#include
+#include "drm_crtc_internal.h"
#include "drm_crtc_helper_internal.h"
static bool drm_fbdev_emulation = true;
@@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool
active)
{
struct drm_device *dev = fb_helper->dev;
+ struct drm_plane_state *plane_state;
struct drm_plane *plane;
struct drm_atomic_state *state;
int i, ret;
@@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
retry:
plane_mask = 0;
drm_for_each_plane(plane, dev) {
- struct drm_plane_state *plane_state;
-
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper
*fb_helper, bool activ
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set =
&fb_helper->crtc_info[i].mode_set;
+ struct drm_plane *primary = mode_set->crtc->primary;
+
+ /* Cannot fail as we've already gotten the plane state above */
+ plane_state = drm_atomic_get_new_plane_state(state, primary);
+ plane_state->rotation = fb_helper->crtc_info[i].rotation;
ret = __drm_atomic_helper_set_config(mode_set, state);
if (ret != 0)
@@ -2334,6 +2339,57 @@ static int drm_pick_crtcs(struct drm_fb_helper
*fb_helper,
return best_score;
}
+/*
+ * This function checks if rotation is necessary because of panel orientation
+ * and if it is, if it is supported.
+ * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
+ * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
+ * or-ed into fb_helper->rotations. In drm_setup_crtcs_fb() we check if only
+ * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
+ * the unsupported rotation.
+ */
+static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
+ struct drm_fb_helper_crtc *fb_crtc,
+ struct drm_connector *connector)
+{
+ struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
+ uint64_t valid_mask = 0;
+ int i, rotation;
+
+ fb_crtc->rotation = DRM_MODE_ROTATE_0;
+
+ switch (connector->display_info.panel_orientation) {
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ rotation = DRM_MODE_ROTATE_180;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ rotation = DRM_MODE_ROTATE_90;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ rotation = DRM_MODE_ROTATE_270;
+ break;
+ default:
+ rotation = DRM_MODE_ROTATE_0;
+ }
+
+ if (rotation == DRM_MODE_ROTATE_0 || !plane->rotation_property) {
+ fb_helper->rotations |= rotation;
+ return;
+ }
+
+ for (i = 0; i < plane->rotation_property->num_values; i++)
+ valid_mask |= (1ULL << plane->rotation_property->values[i]);
+
+ if (!(rotation & valid_mask)) {
+ fb_helper->rotations |= rotation;
+ return;
+ }
+
+ fb_crtc->rotation = rotation;
+ /* Rotating in hardware, fbcon should not rotate */
+ fb_helper->rotations |= DRM_MODE_ROTATE_0;
+}
+
static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
u32 width, u32 height)
{
@@ -2393,6 +2449,7 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
drm_fb_helper_modeset_release(fb_helper,
&fb_helper->crtc_info[i].mode_set);
+ fb_helper->rotations = 0;
drm_fb_
[PATCH v3 3/7] drm: Add support for a panel-orientation connector property
On some devices the LCD panel is mounted in the casing in such a way that
the up/top side of the panel does not match with the top side of the
device (e.g. it is mounted upside-down).
This commit adds the necessary infra for lcd-panel drm_connector-s to
have a "panel orientation" property to communicate how the panel is
orientated vs the casing.
Userspace can use this property to check for non-normal orientation and
then adjust the displayed image accordingly by rotating it to compensate.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Rebased on 4.14-rc1
-Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
access it easily
-Have a single drm_connector_init_panel_orientation_property rather then
create and attach functions. The caller is expected to set
drm_display_info.panel_orientation before calling this, then this will
check for platform specific quirks overriding the panel_orientation and if
the panel_orientation is set after this then it will attach the property.
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_connector.c | 73 +
include/drm/drm_connector.h | 11 +++
include/drm/drm_mode_config.h | 7
include/uapi/drm/drm_mode.h | 7
5 files changed, 99 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9d005ac98c2b..0b166e626eb6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -7,6 +7,7 @@
menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI
support)"
depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
+ select DRM_PANEL_ORIENTATION_QUIRKS
select HDMI
select FB_CMDLINE
select I2C
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..129c83a84320 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -212,6 +213,8 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
connector->status = connector_status_unknown;
+ connector->display_info.panel_orientation =
+ DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
drm_connector_get_cmdline_mode(connector);
@@ -664,6 +667,13 @@ static const struct drm_prop_enum_list
drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
};
+static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
+ { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
+ { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down" },
+ { DRM_MODE_PANEL_ORIENTATION_LEFT_UP, "Left Side Up" },
+ { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, "Right Side Up" },
+};
+
static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -768,6 +778,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
*
* CRTC_ID:
* Mode object ID of the &drm_crtc this connector should be connected to.
+ *
+ * Connectors for LCD panels may also have one standardized property:
+ *
+ * panel orientation:
+ * On some devices the LCD panel is mounted in the casing in such a way
+ * that the up/top side of the panel does not match with the top side of
+ * the device. Userspace can use this property to check for this.
+ * Note that input coordinates from touchscreens (input devices with
+ * INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
+ * coordinates, so if userspace rotates the picture to adjust for
+ * the orientation it must also apply the same transformation to the
+ * touchscreen input coordinates.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1234,6 +1256,57 @@ void drm_mode_connector_set_link_status_property(struct
drm_connector *connector
}
EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+/**
+ * drm_connector_init_panel_orientation_property -
+ * initialize the connecters panel_orientation property
+ * @connector: connector for which to init the panel-orientation property.
+ * @width: width in pixels of the panel, used for panel quirk detection
+ * @height: height in pixels of the panel, used for panel quirk detection
+ *
+ * This function should only be called for built-in panels, after setting
+ * connector->display_info.panel_orientation first (if known).
+ *
+ * This function will check for platform specific (e.g. DMI based) quirks
+ * overriding display_info.panel_orientation first, then if panel_orientation
+ * is not DRM_MODE_PANEL_ORIENTATION_UNKNOWN it will attach the
+ * "panel orientation" property to the connector.
+ *
+
[PATCH v3 0/7] drm/fbdev: Panel orientation connector property support
Hi All, Here is v3 of my series to add a "panel orientation" property to the drm-connector for the LCD panel to let userspace know about LCD panels which are not mounted upright, as well as detecting upside-down panels without needing quirks (like we do for 90 degree rotated screens). As requested by Daniel this version moves the quirks over from the fbdev subsys to the drm subsys. I've done this by simpy starting with a copy of the quirk table and eventually removing the fbdev version. The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5 are all drm patches since patches 2-5 depend on patch 1 I believe it would be best to merge patches 1-5 through the drm tree. For merging patches 6-7 I see 3 options: 1) Wait a kernel cycle, things will work fine without them, they are really just there to remove the fbdev copy of the quirks 2) Merge all 7 patches through the drm tree 3) Use a stable tag in the drm tree which the fbdev tree can merge and then merge patches 6-7 through the drm tree. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [15/23] drm/sun4i: Add LVDS support
Hi Maxime,
On 17 October 2017 at 20:06, Maxime Ripard
wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/Makefile | 1 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
> drivers/gpu/drm/sun4i/sun4i_lvds.h | 18 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 25 -
> 5 files changed, 419 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index cfba2c07519c..6fee15d016ef 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -10,6 +10,7 @@ sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
> +sun4i-tcon-y += sun4i_lvds.o
> sun4i-tcon-y += sun4i_dotclock.o
> sun4i-tcon-y += sun4i_crtc.o
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> new file mode 100644
> index ..635a3f505ecb
> --- /dev/null
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2015 NextThing Co
> + * Copyright (C) 2015-2017 Free Electrons
> + *
> + * Maxime Ripard
> + *
> + * 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 "sun4i_crtc.h"
> +#include "sun4i_tcon.h"
> +#include "sun4i_lvds.h"
> +
> +struct sun4i_lvds {
> + struct drm_connectorconnector;
> + struct drm_encoder encoder;
> +
> + struct sun4i_tcon *tcon;
> +};
> +
> +static inline struct sun4i_lvds *
> +drm_connector_to_sun4i_lvds(struct drm_connector *connector)
> +{
> + return container_of(connector, struct sun4i_lvds,
> + connector);
> +}
> +
> +static inline struct sun4i_lvds *
> +drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
> +{
> + return container_of(encoder, struct sun4i_lvds,
> + encoder);
> +}
> +
> +static int sun4i_lvds_get_modes(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds =
> + drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + return drm_panel_get_modes(tcon->panel);
> +}
> +
> +static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
> + .get_modes = sun4i_lvds_get_modes,
> +};
> +
> +static void
> +sun4i_lvds_connector_destroy(struct drm_connector *connector)
> +{
> + struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + drm_panel_detach(tcon->panel);
> + drm_connector_cleanup(connector);
> +}
> +
> +static const struct drm_connector_funcs sun4i_lvds_con_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy= sun4i_lvds_connector_destroy,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Enabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_prepare(tcon->panel);
> + drm_panel_enable(tcon->panel);
> + }
> +}
> +
> +static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
> + struct sun4i_tcon *tcon = lvds->tcon;
> +
> + DRM_DEBUG_DRIVER("Disabling LVDS output\n");
> +
> + if (!IS_ERR(tcon->panel)) {
> + drm_panel_disable(tcon->panel);
> + drm_panel_unprepare(tcon->panel);
> + }
> +}
> +
> +static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
> + .disable= sun4i_lvds_encoder_disable,
> + .enable = sun4i_lvds_encoder_enable,
> +};
> +
> +static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
> + .destroy= drm_encoder_cleanup,
> +};
> +
> +int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
> +{
> +
[PATCH v3 7/7] fbcon: Remove dmi quirk table
This is now all handled in the drivers and communicated through
fb_info.fbcon_rotate_hint.
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/core/Makefile | 3 -
drivers/video/fbdev/core/fbcon.c| 4 +-
drivers/video/fbdev/core/fbcon.h| 6 --
drivers/video/fbdev/core/fbcon_dmi_quirks.c | 145
4 files changed, 2 insertions(+), 156 deletions(-)
delete mode 100644 drivers/video/fbdev/core/fbcon_dmi_quirks.c
diff --git a/drivers/video/fbdev/core/Makefile
b/drivers/video/fbdev/core/Makefile
index 73493bbd7a15..0214b863ac3f 100644
--- a/drivers/video/fbdev/core/Makefile
+++ b/drivers/video/fbdev/core/Makefile
@@ -14,9 +14,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
fb-y += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
fbcon_ccw.o
endif
-ifeq ($(CONFIG_DMI),y)
-fb-y += fbcon_dmi_quirks.o
-endif
endif
fb-objs := $(fb-y)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fb317ed76b45..157a40670a47 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -968,7 +968,7 @@ static const char *fbcon_startup(void)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
- p->con_rotate = fbcon_platform_get_rotate(info);
+ p->con_rotate = FB_ROTATE_UR;
set_blitting_type(vc, info);
@@ -,7 +,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (p->con_rotate == -1)
p->con_rotate = info->fbcon_rotate_hint;
if (p->con_rotate == -1)
- p->con_rotate = fbcon_platform_get_rotate(info);
+ p->con_rotate = FB_ROTATE_UR;
set_blitting_type(vc, info);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 18f3ac144237..3746828356ed 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -261,10 +261,4 @@ extern void fbcon_set_rotate(struct fbcon_ops *ops);
#define fbcon_set_rotate(x) do {} while(0)
#endif /* CONFIG_FRAMEBUFFER_CONSOLE_ROTATION */
-#ifdef CONFIG_DMI
-int fbcon_platform_get_rotate(struct fb_info *info);
-#else
-#define fbcon_platform_get_rotate(i) FB_ROTATE_UR
-#endif /* CONFIG_DMI */
-
#endif /* _VIDEO_FBCON_H */
diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
b/drivers/video/fbdev/core/fbcon_dmi_quirks.c
deleted file mode 100644
index 6904e47d1e51..
--- a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
+++ /dev/null
@@ -1,145 +0,0 @@
-/*
- * fbcon_dmi_quirks.c -- DMI based quirk detection for fbcon
- *
- * Copyright (C) 2017 Hans de Goede
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive for
- * more details.
- */
-
-#include
-#include
-#include
-#include "fbcon.h"
-
-/*
- * Some x86 clamshell design devices use portrait tablet screens and a display
- * engine which cannot rotate in hardware, so we need to rotate the fbcon to
- * compensate. Unfortunately these (cheap) devices also typically have quite
- * generic DMI data, so we match on a combination of DMI data, screen
resolution
- * and a list of known BIOS dates to avoid false positives.
- */
-
-struct fbcon_dmi_rotate_data {
- int width;
- int height;
- const char * const *bios_dates;
- int rotate;
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_asus_t100ha = {
- .width = 800,
- .height = 1280,
- .rotate = FB_ROTATE_CCW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_pocket = {
- .width = 1200,
- .height = 1920,
- .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
- "07/05/2017", "08/07/2017", NULL },
- .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_gpd_win = {
- .width = 720,
- .height = 1280,
- .bios_dates = (const char * const []){
- "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
- "02/21/2017", "03/20/2017", "05/25/2017", NULL },
- .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_itworks_tw891 = {
- .width = 800,
- .height = 1280,
- .bios_dates = (const char * const []){ "10/16/2015", NULL },
- .rotate = FB_ROTATE_CW,
-};
-
-static const struct fbcon_dmi_rotate_data rotate_data_vios_lth17 = {
- .width = 800,
- .height = 1280,
- .rotate = FB_ROTATE_CW,
-};
-
-static const struct dmi_system_id rotate_data[] = {
- { /* Asus T100HA */
- .matches = {
- DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100H
[PATCH v3 2/7] drm: Add panel orientation quirks
Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.
So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.
This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the device's case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig| 3 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel_orientation_quirks.c | 157 +
include/drm/drm_utils.h| 18 +++
4 files changed, 179 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panel_orientation_quirks.c
create mode 100644 include/drm/drm_utils.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4d9f21831741..9d005ac98c2b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -26,6 +26,9 @@ config DRM_MIPI_DSI
bool
depends on DRM
+config DRM_PANEL_ORIENTATION_QUIRKS
+ tristate
+
config DRM_DP_AUX_CHARDEV
bool "DRM DP AUX Interface"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a3fdc5a68dff..ffb621819bbf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
obj-$(CONFIG_DRM_ARM) += arm/
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
new file mode 100644
index ..cea4d71f4978
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -0,0 +1,157 @@
+/*
+ * drm_panel_orientation_quirks.c -- Quirks for non-normal panel orientation
+ *
+ * Copyright (C) 2017 Hans de Goede
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include
+#include
+
+#ifdef CONFIG_DMI
+
+/*
+ * Some x86 clamshell design devices use portrait tablet screens and a display
+ * engine which cannot rotate in hardware, so we need to rotate the fbcon to
+ * compensate. Unfortunately these (cheap) devices also typically have quite
+ * generic DMI data, so we match on a combination of DMI data, screen
resolution
+ * and a list of known BIOS dates to avoid false positives.
+ */
+
+struct drm_dmi_panel_orientation_data {
+ int width;
+ int height;
+ const char * const *bios_dates;
+ int orientation;
+};
+
+static const struct drm_dmi_panel_orientation_data asus_t100ha = {
+ .width = 800,
+ .height = 1280,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_pocket = {
+ .width = 1200,
+ .height = 1920,
+ .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
+ "07/05/2017", "08/07/2017", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data gpd_win = {
+ .width = 720,
+ .height = 1280,
+ .bios_dates = (const char * const []){
+ "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
+ "02/21/2017", "03/20/2017", "05/25/2017", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data itworks_tw891 = {
+ .width = 800,
+ .height = 1280,
+ .bios_dates = (const char * const []){ "10/16/2015", NULL },
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct drm_dmi_panel_orientation_data vios_lth17 = {
+ .width = 800,
+ .height = 1280,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
+};
+
+static const struct dmi_system_id orientation_data[] = {
+ { /* Asus T100HA */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100HAN"),
+ },
+ .driver_data = (void *)&asus_t100ha,
+ }, {/*
+* GPD Pocket, note that the the DMI data is less generic then
+* it seems, devices with a board-vendor of "AMI Corporation"
+* are quit
[PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info
On some hardware the LCD panel is not mounted upright in the casing,
but upside-down or rotated 90 degrees. In this case we want the console
to automatically be rotated to compensate.
The fbdev-driver may know about the need to rotate. Add a new
fbcon_rotate_hint field to struct fb_info, which gets initialized to -1.
If the fbdev-driver knows that some sort of rotation is necessary then
it can set this field to a FB_ROTATE_* value to tell the fbcon console
driver to rotate the console.
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/core/fbcon.c | 18 --
drivers/video/fbdev/core/fbsysfs.c | 1 +
include/linux/fb.h | 5 +
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 04612f938bab..fb317ed76b45 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -963,10 +963,13 @@ static const char *fbcon_startup(void)
ops->cur_rotate = -1;
ops->cur_blink_jiffies = HZ / 5;
info->fbcon_par = ops;
- if (initial_rotation != -1)
- p->con_rotate = initial_rotation;
- else
+
+ p->con_rotate = initial_rotation;
+ if (p->con_rotate == -1)
+ p->con_rotate = info->fbcon_rotate_hint;
+ if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
if (info->fix.type != FB_TYPE_TEXT) {
@@ -1103,10 +1106,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops = info->fbcon_par;
ops->cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);
- if (initial_rotation != -1)
- p->con_rotate = initial_rotation;
- else
+
+ p->con_rotate = initial_rotation;
+ if (p->con_rotate == -1)
+ p->con_rotate = info->fbcon_rotate_hint;
+ if (p->con_rotate == -1)
p->con_rotate = fbcon_platform_get_rotate(info);
+
set_blitting_type(vc, info);
cols = vc->vc_cols;
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index 15755ce1d26c..e31a182b42bf 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -58,6 +58,7 @@ struct fb_info *framebuffer_alloc(size_t size, struct device
*dev)
info->par = p + fb_info_size;
info->device = dev;
+ info->fbcon_rotate_hint = -1;
#ifdef CONFIG_FB_BACKLIGHT
mutex_init(&info->bl_curve_mutex);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index f4386b0ccf40..10cf71cc5d13 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -464,6 +464,11 @@ struct fb_info {
atomic_t count;
int node;
int flags;
+ /*
+* -1 by default, set to a FB_ROTATE_* value by the driver, if it knows
+* a lcd is not mounted upright and fbcon should rotate to compensate.
+*/
+ int fbcon_rotate_hint;
struct mutex lock; /* Lock for open/release/ioctl funcs */
struct mutex mm_lock; /* Lock for fb_mmap and smem_* fields */
struct fb_var_screeninfo var; /* Current var */
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/23] drm/sun4i: Add LVDS support
On Tue, Oct 17, 2017 at 11:06:22AM +0200, Maxime Ripard wrote:
> The TCON supports the LVDS interface to output to a panel or a bridge.
> Let's add support for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/Makefile | 1 +-
> drivers/gpu/drm/sun4i/sun4i_lvds.c | 183 -
> drivers/gpu/drm/sun4i/sun4i_lvds.h | 18 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 193 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 25 -
> 5 files changed, 419 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h
>
[...]
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 3efa1ab045cd..6a20a467ee6d 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
[...]
> @@ -698,6 +858,26 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> return ret;
> }
>
> + /*
> + * This can only be made optional since we've had DT nodes
> + * without the LVDS reset properties.
> + *
> + * If the property is missing, just disable LVDS, and print a
> + * warning.
> + */
> + tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
> + if (IS_ERR(tcon->lvds_rst)) {
> + dev_err(dev, "Couldn't get our reset line\n");
> + return PTR_ERR(tcon->lvds_rst);
> + } else if (tcon->lvds_rst) {
> + has_lvds = true;
> + reset_control_reset(tcon->lvds_rst);
> + } else {
> + has_lvds = false;
> + dev_warn(dev,
> + "Missing LVDS reset property, you should consider
> upgrading your DT\n");
This will generate annoying warning for tcon1 on A10/A20.
> + }
> +
> ret = sun4i_tcon_init_clocks(dev, tcon);
> if (ret) {
> dev_err(dev, "Couldn't init our TCON clocks\n");
> @@ -729,7 +909,18 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> goto err_free_clocks;
> }
>
> - ret = sun4i_rgb_init(drm, tcon);
> + /*
> + * If we have an LVDS panel connected to the TCON, we should
> + * just probe the LVDS connector. Otherwise, just probe RGB as
> + * we used to.
> + */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] drm/i915: Add "panel orientation" property to the panel connector
Ideally we could use the VBT for this, that would be simple, in
intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
connector->display_info.panel_orientation accordingly and call
drm_connector_init_panel_orientation_property(), done.
Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
with an upside down LCD and where the GOP is properly rotating the
EFI fb in hardware.
So instead we end up reading the rotation from the primary plane.
To read the info from the primary plane, we need to know which crtc
the panel is hooked up to, so we do this the first time the panel
encoder's get_config function get called, as by then the encoder
crtc routing has been set up.
This commit only implements the panel orientation property for DSI
panels on BYT / CHT / BXT hardware, as all known non normal oriented
panels are only found on this hardware.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Read back the rotation applied by the GOP from the primary plane
instead of relying on dev_priv->vbt.dsi.config->rotation, because it
seems that the VBT rotation filed is always 0 even on devices where the
GOP does apply a rotation
Changes in v3:
-Rewrite the code to read back the orientation from the primary
plane to contain all of this in intel_dsi.c instead of poking a bunch
of holes between all the different layers
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_dsi.c | 48 ++
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915/intel_panel.c | 16 +
4 files changed, 67 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a05ab3a1ab27..29fb7a414bbe 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1728,6 +1728,7 @@ void intel_panel_enable_backlight(const struct
intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state);
void intel_panel_disable_backlight(const struct drm_connector_state
*old_conn_state);
void intel_panel_destroy_backlight(struct drm_connector *connector);
+void intel_panel_set_orientation(struct intel_panel *panel, int orientation);
enum drm_connector_status intel_panel_detect(struct drm_i915_private
*dev_priv);
extern struct drm_display_mode *intel_find_panel_downclock(
struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 66bbedc5fa01..86914d2f9f6a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1084,13 +1084,16 @@ static void bxt_dsi_get_pipe_config(struct
intel_encoder *encoder,
struct drm_display_mode *adjusted_mode_sw;
struct intel_crtc *intel_crtc;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct intel_panel *panel = &intel_dsi->attached_connector->panel;
unsigned int lane_count = intel_dsi->lane_count;
unsigned int bpp, fmt;
+ int orientation;
enum port port;
u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
u16 hfp_sw, hsync_sw, hbp_sw;
u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
crtc_hblank_start_sw, crtc_hblank_end_sw;
+ u32 val;
/* FIXME: hw readout should not depend on SW state */
intel_crtc = to_intel_crtc(encoder->base.crtc);
@@ -1234,6 +1237,49 @@ static void bxt_dsi_get_pipe_config(struct intel_encoder
*encoder,
if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
adjusted_mode->crtc_hblank_end =
adjusted_mode_sw->crtc_hblank_end;
+
+ if (!intel_dsi->got_panel_orientation) {
+ val = I915_READ(PLANE_CTL(intel_crtc->pipe, 0));
+ /* The rotation is used to correct for the panel orientation */
+ switch (val & PLANE_CTL_ROTATE_MASK) {
+ case PLANE_CTL_ROTATE_0:
+ orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
+ break;
+ case PLANE_CTL_ROTATE_90:
+ orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
+ break;
+ case PLANE_CTL_ROTATE_180:
+ orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
+ break;
+ case PLANE_CTL_ROTATE_270:
+ orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
+ break;
+ }
+ intel_panel_set_orientation(panel, orientation);
+ intel_dsi->got_panel_orientation = true;
+ }
+}
+
+static void vlv_dsi_get_pipe_config(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_ds
[PATCH v3 6/7] efifb: Set info->fbcon_rotate_hint based on drm_get_panel_orientation_quirk
On some hardware the LCD panel is not mounted upright in the casing,
but rotated by 90 degrees. In this case we want the console to
automatically be rotated to compensate.
The drm subsys has a quirk table for this, use the
drm_get_panel_orientation_quirk function to get the panel orientation
and set info->fbcon_rotate_hint based on this, so that the fbcon console
on top of efifb gets automatically rotated to compensate for the panel
orientation.
Signed-off-by: Hans de Goede
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/efifb.c | 21 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5e58f5ec0a28..c4a90c497839 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -772,6 +772,7 @@ config FB_VESA
config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && !IA64 && EFI
+ select DRM_PANEL_ORIENTATION_QUIRKS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 3a010641f630..8c7f6aeee205 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include /* For drm_get_panel_orientation_quirk */
+#include /* For DRM_MODE_PANEL_ORIENTATION_* */
static bool request_mem_succeeded = false;
static bool nowc = false;
@@ -156,7 +158,7 @@ static u64 bar_offset;
static int efifb_probe(struct platform_device *dev)
{
struct fb_info *info;
- int err;
+ int err, orientation;
unsigned int size_vmode;
unsigned int size_remap;
unsigned int size_total;
@@ -328,6 +330,23 @@ static int efifb_probe(struct platform_device *dev)
info->fix = efifb_fix;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
+ orientation = drm_get_panel_orientation_quirk(efifb_defined.xres,
+ efifb_defined.yres);
+ switch (orientation) {
+ default:
+ info->fbcon_rotate_hint = FB_ROTATE_UR;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP:
+ info->fbcon_rotate_hint = FB_ROTATE_UD;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_LEFT_UP:
+ info->fbcon_rotate_hint = FB_ROTATE_CCW;
+ break;
+ case DRM_MODE_PANEL_ORIENTATION_RIGHT_UP:
+ info->fbcon_rotate_hint = FB_ROTATE_CW;
+ break;
+ }
+
err = sysfs_create_groups(&dev->dev.kobj, efifb_groups);
if (err) {
pr_err("efifb: cannot add sysfs attrs\n");
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: No /dev/fb0 created for omapdrm in current Linux next
On 20/10/17 20:09, Tony Lindgren wrote: > # lsmod > Module Size Used by > omapdrm69632 0 > drm_kms_helper163840 1 omapdrm > cfbfillrect16384 1 drm_kms_helper > syscopyarea16384 1 drm_kms_helper > cfbimgblt 16384 1 drm_kms_helper > sysfillrect16384 1 drm_kms_helper > sysimgblt 16384 1 drm_kms_helper > fb_sys_fops16384 1 drm_kms_helper > cfbcopyarea16384 1 drm_kms_helper > drm 364544 2 omapdrm,drm_kms_helper > panel_sony_acx565akm16384 0 > omapdss 192512 1 > omapdss_base 24576 3 panel_sony_acx565akm,omapdrm,omapdss > tsc200516384 0 > tsc200x_core 16384 1 tsc2005 > twl4030_keypad 16384 0 > matrix_keymap 16384 1 twl4030_keypad > rtc_twl16384 1 > twl4030_wdt16384 0 > > Am I missing some module now? omapdrm takes a ref to the panel module when it's in use, and panel_sony_acx565akm has refcount of 0. So for some reason the display setup has not been done, or it's been deferred. I think you're missing connector_analog_tv (CONFIG_DRM_OMAP_CONNECTOR_ANALOG_TV). I just tried beagleboard, it seems to work ok on next. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103403] something going on across the gpu DAC and monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=103403 --- Comment #1 from korbenpl --- Created attachment 134999 --> https://bugs.freedesktop.org/attachment.cgi?id=134999&action=edit a vid of the glitch -- 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 103403] something going on across the gpu DAC and monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=103403 --- Comment #2 from korbenpl --- Comment on attachment 134989 --> https://bugs.freedesktop.org/attachment.cgi?id=134989 specs included [rafal@rafal-pc ~]$ inxi -Fxzc0 System: Host: rafal-pc Kernel: 4.9.53-1-MANJARO x86_64 bits: 64 gcc: 7.2.0 Desktop: KDE Plasma 5.10.5 (Qt 5.9.1) Distro: Manjaro Linux Machine: Device: laptop System: Sony product: VGN-NW21MF_S v: C602NWLK serial: N/A Mobo: Sony model: VAIO serial: N/A BIOS: American Megatrends v: R1120Y4 date: 08/20/2009 Battery BAT0: charge: 5.8 Wh 99.5% condition: 5.8/48.8 Wh (12%) model: Sony status: Full CPU: Dual core Intel Core2 Duo T6600 (-MCP-) arch: Penryn rev.10 cache: 2048 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3) bmips: 8779 clock speeds: max: 2200 MHz 1: 1200 MHz 2: 1200 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] bus-ID: 01:00.0 Display Server: x11 (X.Org 1.19.4 ) drivers: ati,radeon (unloaded: modesetting) Resolution: 1366x768@59.94hz OpenGL: renderer: AMD RV710 (DRM 2.49.0 / 4.9.53-1-MANJARO, LLVM 5.0.0) version: 3.3 Mesa 17.2.2 Direct Render: Yes Audio: Card-1 Advanced Micro Devices [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] driver: snd_hda_intel bus-ID: 01:00.1 Card-2 Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Sound: Advanced Linux Sound Architecture v: k4.9.53-1-MANJARO Network: Card-1: Marvell 88E8057 PCI-E Gigabit Ethernet Controller driver: sky2 v: 1.30 port: c000 bus-ID: 02:00.0 IF: enp2s0 state: down mac: Card-2: Intel WiFi Link 5100 driver: iwlwifi bus-ID: 03:00.0 IF: wlp3s0 state: up mac: Drives: HDD Total Size: 500.1GB (2.0% used) ID-1: /dev/sda model: SAMSUNG_HM500JI size: 500.1GB Partition: ID-1: / size: 49G used: 9.4G (21%) fs: ext4 dev: /dev/sda2 Sensors: System Temperatures: cpu: 52.0C mobo: 52.0C Fan Speeds (in rpm): cpu: N/A Info: Processes: 143 Uptime: 3:08 Memory: 1096.1/3923.7MB Init: systemd Gcc sys: 7.2.0 Client: Shell (bash 4.4.121) inxi: 2.3.40 [rafal@rafal-pc ~]$ -- 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 103403] something going on across the gpu DAC and monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=103403 --- Comment #3 from korbenpl --- Comment on attachment 134989 --> https://bugs.freedesktop.org/attachment.cgi?id=134989 specs included [rafal@rafal-pc ~]$ inxi -Fxzc0 System: Host: rafal-pc Kernel: 4.9.53-1-MANJARO x86_64 bits: 64 gcc: 7.2.0 Desktop: KDE Plasma 5.10.5 (Qt 5.9.1) Distro: Manjaro Linux Machine: Device: laptop System: Sony product: VGN-NW21MF_S v: C602NWLK serial: N/A Mobo: Sony model: VAIO serial: N/A BIOS: American Megatrends v: R1120Y4 date: 08/20/2009 Battery BAT0: charge: 5.8 Wh 99.5% condition: 5.8/48.8 Wh (12%) model: Sony status: Full CPU: Dual core Intel Core2 Duo T6600 (-MCP-) arch: Penryn rev.10 cache: 2048 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3) bmips: 8779 clock speeds: max: 2200 MHz 1: 1200 MHz 2: 1200 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] bus-ID: 01:00.0 Display Server: x11 (X.Org 1.19.4 ) drivers: ati,radeon (unloaded: modesetting) Resolution: 1366x768@59.94hz OpenGL: renderer: AMD RV710 (DRM 2.49.0 / 4.9.53-1-MANJARO, LLVM 5.0.0) version: 3.3 Mesa 17.2.2 Direct Render: Yes Audio: Card-1 Advanced Micro Devices [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] driver: snd_hda_intel bus-ID: 01:00.1 Card-2 Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Sound: Advanced Linux Sound Architecture v: k4.9.53-1-MANJARO Network: Card-1: Marvell 88E8057 PCI-E Gigabit Ethernet Controller driver: sky2 v: 1.30 port: c000 bus-ID: 02:00.0 IF: enp2s0 state: down mac: Card-2: Intel WiFi Link 5100 driver: iwlwifi bus-ID: 03:00.0 IF: wlp3s0 state: up mac: Drives: HDD Total Size: 500.1GB (2.0% used) ID-1: /dev/sda model: SAMSUNG_HM500JI size: 500.1GB Partition: ID-1: / size: 49G used: 9.4G (21%) fs: ext4 dev: /dev/sda2 Sensors: System Temperatures: cpu: 52.0C mobo: 52.0C Fan Speeds (in rpm): cpu: N/A Info: Processes: 143 Uptime: 3:08 Memory: 1096.1/3923.7MB Init: systemd Gcc sys: 7.2.0 Client: Shell (bash 4.4.121) inxi: 2.3.40 [rafal@rafal-pc ~]$ -- 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 103403] something going on across the gpu DAC and monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=103403 --- Comment #4 from korbenpl --- Comment on attachment 134989 --> https://bugs.freedesktop.org/attachment.cgi?id=134989 specs included [rafal@rafal-pc ~]$ inxi -Fxzc0 System: Host: rafal-pc Kernel: 4.9.53-1-MANJARO x86_64 bits: 64 gcc: 7.2.0 Desktop: KDE Plasma 5.10.5 (Qt 5.9.1) Distro: Manjaro Linux Machine: Device: laptop System: Sony product: VGN-NW21MF_S v: C602NWLK serial: N/A Mobo: Sony model: VAIO serial: N/A BIOS: American Megatrends v: R1120Y4 date: 08/20/2009 Battery BAT0: charge: 5.8 Wh 99.5% condition: 5.8/48.8 Wh (12%) model: Sony status: Full CPU: Dual core Intel Core2 Duo T6600 (-MCP-) arch: Penryn rev.10 cache: 2048 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3) bmips: 8779 clock speeds: max: 2200 MHz 1: 1200 MHz 2: 1200 MHz Graphics: Card: Advanced Micro Devices [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] bus-ID: 01:00.0 Display Server: x11 (X.Org 1.19.4 ) drivers: ati,radeon (unloaded: modesetting) Resolution: 1366x768@59.94hz OpenGL: renderer: AMD RV710 (DRM 2.49.0 / 4.9.53-1-MANJARO, LLVM 5.0.0) version: 3.3 Mesa 17.2.2 Direct Render: Yes Audio: Card-1 Advanced Micro Devices [AMD/ATI] RV710/730 HDMI Audio [Radeon HD 4000 series] driver: snd_hda_intel bus-ID: 01:00.1 Card-2 Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 Sound: Advanced Linux Sound Architecture v: k4.9.53-1-MANJARO Network: Card-1: Marvell 88E8057 PCI-E Gigabit Ethernet Controller driver: sky2 v: 1.30 port: c000 bus-ID: 02:00.0 IF: enp2s0 state: down mac: Card-2: Intel WiFi Link 5100 driver: iwlwifi bus-ID: 03:00.0 IF: wlp3s0 state: up mac: Drives: HDD Total Size: 500.1GB (2.0% used) ID-1: /dev/sda model: SAMSUNG_HM500JI size: 500.1GB Partition: ID-1: / size: 49G used: 9.4G (21%) fs: ext4 dev: /dev/sda2 Sensors: System Temperatures: cpu: 52.0C mobo: 52.0C Fan Speeds (in rpm): cpu: N/A Info: Processes: 143 Uptime: 3:08 Memory: 1096.1/3923.7MB Init: systemd Gcc sys: 7.2.0 Client: Shell (bash 4.4.121) inxi: 2.3.40 [rafal@rafal-pc ~]$ -- 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 v4 1/9] drm/exynos: ipp: Remove Exynos DRM IPP subsystem
Exynos IPP will be rewritten, so remove current IPP core code and mark
existing drivers as BROKEN.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 11 +-
drivers/gpu/drm/exynos/Makefile |1 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 -
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 -
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1806 ---
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 252 -
include/uapi/drm/exynos_drm.h | 192 +---
7 files changed, 4 insertions(+), 2272 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d4ff77..88cff0e039b6 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,26 +94,21 @@ config DRM_EXYNOS_G2D
help
Choose this option if you want to use Exynos G2D for DRM.
-config DRM_EXYNOS_IPP
- bool "Image Post Processor"
- help
- Choose this option if you want to use IPP feature for DRM.
-
config DRM_EXYNOS_FIMC
bool "FIMC"
- depends on DRM_EXYNOS_IPP && MFD_SYSCON
+ depends on BROKEN && MFD_SYSCON
help
Choose this option if you want to use Exynos FIMC for DRM.
config DRM_EXYNOS_ROTATOR
bool "Rotator"
- depends on DRM_EXYNOS_IPP
+ depends on BROKEN
help
Choose this option if you want to use Exynos Rotator for DRM.
config DRM_EXYNOS_GSC
bool "GScaler"
- depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+ depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
help
Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index f663490e949d..09bb002c9555 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,7 +17,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER) += exynos_mixer.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
-exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index e651a58c18cf..2fc5d3c01390 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -28,7 +28,6 @@
#include "exynos_drm_plane.h"
#include "exynos_drm_vidi.h"
#include "exynos_drm_g2d.h"
-#include "exynos_drm_ipp.h"
#include "exynos_drm_iommu.h"
#define DRIVER_NAME"exynos"
@@ -115,14 +114,6 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_PROPERTY, exynos_drm_ipp_get_property,
- DRM_AUTH | DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_SET_PROPERTY, exynos_drm_ipp_set_property,
- DRM_AUTH | DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_QUEUE_BUF, exynos_drm_ipp_queue_buf,
- DRM_AUTH | DRM_RENDER_ALLOW),
- DRM_IOCTL_DEF_DRV(EXYNOS_IPP_CMD_CTRL, exynos_drm_ipp_cmd_ctrl,
- DRM_AUTH | DRM_RENDER_ALLOW),
};
static const struct file_operations exynos_drm_driver_fops = {
@@ -259,9 +250,6 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] =
{
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
- }, {
- DRV_PTR(ipp_driver, CONFIG_DRM_EXYNOS_IPP),
- DRM_VIRTUAL_DEVICE
}, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index f8bae4cb4823..b47f810d64d2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,7 +185,6 @@ struct exynos_drm_g2d_private {
struct drm_exynos_file_private {
struct exynos_drm_g2d_private *g2d_priv;
- struct device *ipp_dev;
};
/*
@@ -293,6 +292,5 @@ extern struct platform_driver g2d_driver;
extern struct platform_driver fimc_driver;
extern struct platform_driver rotator_driver;
extern struct platform_driver gsc_driver;
-extern struct platform_driver ipp_driver;
extern struct platform_driver mic_driver;
#endif
diff --git a/drivers/gpu/drm/exynos/exyn
[PATCH v4 3/9] drm/exynos: rotator: Convert driver to IPP v2 core API
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 740 +++-
drivers/gpu/drm/exynos/exynos_drm_rotator.h | 19 -
4 files changed, 178 insertions(+), 584 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 2e097a81df12..c10c9ca0d8b4 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -105,7 +105,7 @@ config DRM_EXYNOS_FIMC
config DRM_EXYNOS_ROTATOR
bool "Rotator"
- depends on BROKEN
+ select DRM_EXYNOS_IPP
help
Choose this option if you want to use Exynos Rotator for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index de4cce258a5b..3ade2b0ad15d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -257,6 +257,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] =
{
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 79282a820ecc..ffbc49b84562 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -10,6 +10,7 @@
*/
#include
+#include
#include
#include
#include
@@ -22,29 +23,18 @@
#include
#include "regs-rotator.h"
#include "exynos_drm_drv.h"
+#include "exynos_drm_iommu.h"
#include "exynos_drm_ipp.h"
/*
* Rotator supports image crop/rotator and input/output DMA operations.
* input DMA reads image data from the memory.
* output DMA writes image data to memory.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > Rotator H/W > Memory.
*/
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. need to add supported list in prop_list.
- */
+#define ROTATOR_AUTOSUSPEND_DELAY 2000
-#define get_rot_context(dev) platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
- struct rot_context, ippdrv);
-#define rot_read(offset) readl(rot->regs + (offset))
+#define rot_read(offset) readl(rot->regs + (offset))
#define rot_write(cfg, offset) writel(cfg, rot->regs + (offset))
enum rot_irq_status {
@@ -52,54 +42,22 @@ enum rot_irq_status {
ROT_IRQ_STATUS_ILLEGAL = 9,
};
-/*
- * A structure of limitation.
- *
- * @min_w: minimum width.
- * @min_h: minimum height.
- * @max_w: maximum width.
- * @max_h: maximum height.
- * @align: align size.
- */
-struct rot_limit {
- u32 min_w;
- u32 min_h;
- u32 max_w;
- u32 max_h;
- u32 align;
-};
-
-/*
- * A structure of limitation table.
- *
- * @ycbcr420_2p: case of YUV.
- * @rgb888: case of RGB.
- */
-struct rot_limit_table {
- struct rot_limitycbcr420_2p;
- struct rot_limitrgb888;
-};
-
/*
* A structure of rotator context.
* @ippdrv: prepare initialization using ippdrv.
- * @regs_res: register resources.
* @regs: memory mapped io registers.
* @clock: rotator gate clock.
* @limit_tbl: limitation of rotator.
* @irq: irq number.
- * @cur_buf_id: current operation buffer id.
- * @suspended: suspended state.
*/
struct rot_context {
- struct exynos_drm_ippdrvippdrv;
- struct resource *regs_res;
+ struct exynos_drm_ipp ipp;
+ struct drm_device *drm_dev;
+ struct device *dev;
void __iomem*regs;
struct clk *clock;
- struct rot_limit_table *limit_tbl;
- int irq;
- int cur_buf_id[EXYNOS_DRM_OPS_MAX];
- boolsuspended;
+ const struct exynos_drm_ipp_formats *formats;
+ struct exynos_drm_ipp_task *task;
};
static void rotator_reg_set_irq(struct rot_context *rot, bool enable)
@@ -114,15 +72,6 @@ static void rotator_reg_set_irq(struct rot_context *rot,
bool enable)
rot_write(val, ROT_CONFIG);
}
-static u32 rotator_reg_get_fmt(struct rot_context *rot)
-{
- u32 val = rot_read(ROT_CONTROL);
-
- val &= ROT_CONTROL_FMT_MASK;
-
- return val;
-}
-
static enum rot_irq_status rotator_reg_get_irq_status(struct rot_context *rot)
{
u32 val = rot_read(ROT_STATUS);
@@ -
[PATCH v4 2/9] drm/exynos: ipp: Add IPP v2 framework
This patch adds Exynos IPP v2 subsystem and userspace API.
New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.
V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.
V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.
The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
provided structures (source and destination buffers, operation rectangle,
transformation, etc).
The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.
Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.
Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.
Signed-off-by: Marek Szyprowski
Tested-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/Kconfig | 3 +
drivers/gpu/drm/exynos/Makefile | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 9 +
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 911
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 195 +++
include/uapi/drm/exynos_drm.h | 238 +
6 files changed, 1357 insertions(+)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
Choose this option if you want to use Exynos G2D for DRM.
+config DRM_EXYNOS_IPP
+ bool
+
config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER) += exynos_mixer.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o
exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2fc5d3c01390..de4cce258a5b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
#include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
#include "exynos_drm_vidi.h"
#include "exynos_drm_g2d.h"
#include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES,
exynos_drm_ipp_get_res_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_LIMITS,
exynos_drm_ipp_get_limits_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_IPP_COMMIT, exynos_drm_ipp_commit_ioctl,
+ DRM_AUTH | DRM_RENDER_ALLOW),
};
static const struct fil
[PATCH v4 7/9] drm/exynos: Add driver for Exynos Scaler module
From: Andrzej Pietrasiewicz
Exynos Scaler is a hardware module, which processes graphic data fetched
from memory and transfers the resultant dato another memory buffer.
Graphics data can be up/down-scaled, rotated, flipped and converted color
space. Scaler hardware modules are a part of Exynos5420 and newer Exynos
SoCs.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
.../devicetree/bindings/gpu/samsung-scaler.txt | 27 +
drivers/gpu/drm/exynos/Kconfig | 6 +
drivers/gpu/drm/exynos/Makefile| 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c| 3 +
drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 +
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 716 +
drivers/gpu/drm/exynos/regs-scaler.h | 426
7 files changed, 1180 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/samsung-scaler.txt
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_scaler.c
create mode 100644 drivers/gpu/drm/exynos/regs-scaler.h
diff --git a/Documentation/devicetree/bindings/gpu/samsung-scaler.txt
b/Documentation/devicetree/bindings/gpu/samsung-scaler.txt
new file mode 100644
index ..9c3d98105dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/samsung-scaler.txt
@@ -0,0 +1,27 @@
+* Samsung Exynos Image Scaler
+
+Required properties:
+ - compatible : value should be one of the following:
+ (a) "samsung,exynos5420-scaler" for Scaler IP in Exynos5420
+ (b) "samsung,exynos5433-scaler" for Scaler IP in Exynos5433
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : Interrupt specifier for scaler interrupt, according to format
+specific to interrupt parent.
+
+ - clocks : Clock specifier for scaler clock, according to generic clock
+bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
+
+ - clock-names : Names of clocks. For exynos scaler, it should be "mscl"
+ on 5420 and "pclk", "aclk" and "aclk_xiu" on 5433.
+
+Example:
+ scaler@1280 {
+ compatible = "samsung,exynos5420-scaler";
+ reg = <0x1280 0x1294>;
+ interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_MSCL0>;
+ clock-names = "mscl";
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 73f06a3a8bec..bb6fad57e18a 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -109,6 +109,12 @@ config DRM_EXYNOS_ROTATOR
help
Choose this option if you want to use Exynos Rotator for DRM.
+config DRM_EXYNOS_SCALER
+ bool "Scaler"
+ select DRM_EXYNOS_IPP
+ help
+ Choose this option if you want to use Exynos Scaler for DRM.
+
config DRM_EXYNOS_GSC
bool "GScaler"
depends on VIDEO_SAMSUNG_EXYNOS_GSC=n
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index f663490e949d..aa84472ac093 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -20,6 +20,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_SCALER) += exynos_drm_scaler.o
exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4afeffa024f3..b2582ae993ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -260,6 +260,9 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] =
{
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
DRM_COMPONENT_DRIVER
+ }, {
+ DRV_PTR(scaler_driver, CONFIG_DRM_EXYNOS_SCALER),
+ DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
DRM_COMPONENT_DRIVER
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8b3b31d35168..8dc8537f4fd1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -293,6 +293,7 @@ extern struct platform_driver vidi_driver;
extern struct platform_driver g2d_driver;
extern struct platform_driver fimc_driver;
extern struct platform_driver rotator_driver;
+extern struct platform_driver scaler_driver;
extern struct platform_driver gsc_driver;
extern struct platform_driver mic_driver;
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
new file mode 10064
[PATCH v4 5/9] drm/exynos: Add generic support for devices shared with V4L2 subsystem
Some hardware modules, like FIMC in Exynos4 series are shared between
V4L2 (camera support) and DRM (memory-to-memory processing) subsystems.
This patch provides a simple check to let such drivers to be used in the
driver components framework.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 -
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cac0d84385d3..60ae6ae06eb2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -216,6 +216,7 @@ struct exynos_drm_driver_info {
#define DRM_COMPONENT_DRIVER BIT(0) /* supports component framework */
#define DRM_VIRTUAL_DEVICE BIT(1) /* create virtual platform device */
#define DRM_DMA_DEVICE BIT(2) /* can be used for dma allocations */
+#define DRM_SHARED_DEVICE BIT(3) /* devices shared with V4L2 subsystem */
#define DRV_PTR(drv, cond) (IS_ENABLED(cond) ? &drv : NULL)
@@ -267,6 +268,17 @@ static struct exynos_drm_driver_info exynos_drm_drivers[]
= {
}
};
+int exynos_drm_check_shared_device(struct device *dev)
+{
+ /*
+* Exynos DRM drivers handle only devices that support
+* the LCD Writeback data path, rest is handled by V4L2 driver
+*/
+ if (!of_property_read_bool(dev->of_node, "samsung,lcd-wb"))
+ return -ENODEV;
+ return 0;
+}
+
static int compare_dev(struct device *dev, void *data)
{
return dev == (struct device *)data;
@@ -288,7 +300,10 @@ static struct component_match *exynos_drm_match_add(struct
device *dev)
&info->driver->driver,
(void *)platform_bus_type.match))) {
put_device(p);
- component_match_add(dev, &match, compare_dev, d);
+
+ if (!(info->flags & DRM_SHARED_DEVICE) ||
+ exynos_drm_check_shared_device(d) == 0)
+ component_match_add(dev, &match, compare_dev,
d);
p = d;
}
put_device(p);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b47f810d64d2..8b3b31d35168 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,6 +275,8 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
}
#endif
+int exynos_drm_check_shared_device(struct device *dev);
+
int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state
*state,
bool nonblock);
int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state
*state);
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/9] drm/exynos: fimc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM FIMC driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 930 ++-
drivers/gpu/drm/exynos/exynos_drm_fimc.h | 23 -
4 files changed, 282 insertions(+), 674 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimc.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 9b66a9838dca..73f06a3a8bec 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -99,7 +99,7 @@ config DRM_EXYNOS_IPP
config DRM_EXYNOS_FIMC
bool "FIMC"
- depends on BROKEN && MFD_SYSCON
+ select DRM_EXYNOS_IPP
help
Choose this option if you want to use Exynos FIMC for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 60ae6ae06eb2..4afeffa024f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -256,6 +256,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] =
{
DRV_PTR(g2d_driver, CONFIG_DRM_EXYNOS_G2D),
}, {
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
+ DRM_COMPONENT_DRIVER | DRM_SHARED_DEVICE,
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
DRM_COMPONENT_DRIVER
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 5b18b5c5fdf2..870f14b775b5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -12,6 +12,7 @@
*
*/
#include
+#include
#include
#include
#include
@@ -24,8 +25,9 @@
#include
#include "regs-fimc.h"
#include "exynos_drm_drv.h"
+#include "exynos_drm_iommu.h"
#include "exynos_drm_ipp.h"
-#include "exynos_drm_fimc.h"
+
/*
* FIMC stands for Fully Interactive Mobile Camera and
@@ -33,23 +35,6 @@
* input DMA reads image data from the memory.
* output DMA writes image data to memory.
* FIMC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > FIMC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > FIMC H/W > Memory.
- * Output operation : supports direct display using local path.
- * Memory > FIMC H/W > FIMD.
- */
-
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. added check_prepare api for right register.
- * 5. need to add supported list in prop_list.
- * 6. check prescaler/scaler optimization.
*/
#define FIMC_MAX_DEVS 4
@@ -59,29 +44,15 @@
#define FIMC_BUF_STOP 1
#define FIMC_BUF_START 2
#define FIMC_WIDTH_ITU_709 1280
-#define FIMC_REFRESH_MAX 60
-#define FIMC_REFRESH_MIN 12
-#define FIMC_CROP_MAX 8192
-#define FIMC_CROP_MIN 32
-#define FIMC_SCALE_MAX 4224
-#define FIMC_SCALE_MIN 32
+#define FIMC_AUTOSUSPEND_DELAY 2000
#define get_fimc_context(dev) platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
- struct fimc_context, ippdrv);
-enum fimc_wb {
- FIMC_WB_NONE,
- FIMC_WB_A,
- FIMC_WB_B,
-};
enum {
FIMC_CLK_LCLK,
FIMC_CLK_GATE,
FIMC_CLK_WB_A,
FIMC_CLK_WB_B,
- FIMC_CLK_MUX,
- FIMC_CLK_PARENT,
FIMC_CLKS_MAX
};
@@ -90,8 +61,6 @@ static const char * const fimc_clock_names[] = {
[FIMC_CLK_GATE] = "fimc",
[FIMC_CLK_WB_A] = "pxl_async0",
[FIMC_CLK_WB_B] = "pxl_async1",
- [FIMC_CLK_MUX]= "mux",
- [FIMC_CLK_PARENT] = "parent",
};
#define FIMC_DEFAULT_LCLK_FREQUENCY 13300UL
@@ -141,31 +110,29 @@ struct fimc_capability {
/*
* A structure of fimc context.
*
- * @ippdrv: prepare initialization using ippdrv.
* @regs_res: register resources.
* @regs: memory mapped io registers.
* @lock: locking of operations.
* @clocks: fimc clocks.
- * @clk_frequency: LCLK clock frequency.
- * @sysreg: handle to SYSREG block regmap.
* @sc: scaler infomations.
* @pol: porarity of writeback.
* @id: fimc id.
* @irq: irq number.
- * @suspended: qos operations.
*/
struct fimc_context {
- struct exynos_drm_ippdrvippdrv;
+ struct exynos_drm_ipp ipp;
+ struct drm_device *drm_dev;
+ struct device *dev;
+ struct exynos_drm_ipp_task *task;
+ struct exynos_drm_ipp_formats *formats;
+
struct resource *regs_res;
void __iomem*regs;
spinlock_t lock;
struct clk *clocks[FIMC_CLKS_MAX];
[PATCH v4 8/9] ARM: dts: exynos: Add mem-2-mem Scaler devices
From: Andrzej Pietrasiewicz
There are 3 scaler devices in Exynos5420 SoCs, all are a part of MSCL
power domain. MSCL power domain and SYSMMU controllers (two per each
scaler device) have been already added to exynos5420.dtsi earlier,
so bind them to newly added devices.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos5420.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 88e5d6d3f901..7894045bd91b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -678,6 +678,35 @@
iommus = <&sysmmu_gscl1>;
};
+ scaler_0: scaler@1280 {
+ compatible = "samsung,exynos5420-scaler";
+ reg = <0x1280 0x1294>;
+ interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_MSCL0>;
+ clock-names = "mscl";
+ power-domains = <&msc_pd>;
+ iommus = <&sysmmu_scaler0r>, <&sysmmu_scaler0w>;
+ };
+
+ scaler_1: scaler@1281 {
+ compatible = "samsung,exynos5420-scaler";
+ reg = <0x1281 0x1294>;
+ interrupts = <0 221 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_MSCL1>;
+ clock-names = "mscl";
+ power-domains = <&msc_pd>;
+ iommus = <&sysmmu_scaler1r>, <&sysmmu_scaler1w>;
+ };
+ scaler_2: scaler@1282 {
+ compatible = "samsung,exynos5420-scaler";
+ reg = <0x1282 0x1294>;
+ interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clock CLK_MSCL2>;
+ clock-names = "mscl";
+ power-domains = <&msc_pd>;
+ iommus = <&sysmmu_scaler2r>, <&sysmmu_scaler2w>;
+ };
+
jpeg_0: jpeg@11F5 {
compatible = "samsung,exynos5420-jpeg";
reg = <0x11F5 0x1000>;
@@ -812,6 +841,7 @@
interrupts = <22 4>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL0>, <&clock CLK_MSCL0>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
@@ -821,6 +851,7 @@
interrupts = ;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL1>, <&clock CLK_MSCL1>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
@@ -830,6 +861,7 @@
interrupts = ;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL2>, <&clock CLK_MSCL2>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
@@ -840,6 +872,7 @@
interrupts = <27 2>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL0>, <&clock CLK_MSCL0>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
@@ -850,6 +883,7 @@
interrupts = <22 6>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL1>, <&clock CLK_MSCL1>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
@@ -860,6 +894,7 @@
interrupts = <19 6>;
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_MSCL2>, <&clock CLK_MSCL2>;
+ power-domains = <&msc_pd>;
#iommu-cells = <0>;
};
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/9] Exynos DRM: rewrite IPP subsystem and userspace API
Dear all, This patchset performs complete rewrite of Exynos DRM IPP subsystem and its userspace API. Why such rewrite is needed? Exynos DRM IPP API is over-engineered in general, but not really extensible on the other side. It is also buggy, with significant design flaws: - Userspace API covers memory-2-memory picture operations together with CRTC writeback and duplicating features, which belongs to video plane. - Lack of support of the all required image formats (for example NV12 Samsung-tiled cannot be used due to lack of pixel format modifier support). - Userspace API designed only to mimic hardware behaviour, not easy to understand. - Lack of proper input validation in the core, drivers also didn't do that correctly, so it was possible to set incorrect parameters and easil trigger IOMMU fault or memory trash. - Drivers were partially disfunctional or supported only a subset of modes. Due to the above limitations and issues the Exynos DRM IPP API was not used by any of the open-source projects. I assume that it is safe to remove this broken API without any damage to open-source community. All remaining users (mainly Tizen project related) will be updated to the new version. This patchset changes Exynos DRM IPP subsystem to something useful. The userspace API is much simpler, state-less and easy to understand. Also the code of the core and driver is significantly smaller and easier to understand. Patches were tested on Exynos4412 based Odroid U3, Exynos5422 Odroid XU3 and Exynos5433 TM2 boards, on top of Linux next-20171016 kernel. A simple userspace test tool has been sent together with v1 of this patchset: https://www.spinics.net/lists/linux-samsung-soc/msg60498.html Tobias Jakobi has added support for this new API to his fork of libdrm and mpv video player: https://github.com/tobiasjakobi/libdrm/tree/ippv2 https://github.com/tobiasjakobi/mpv Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v4: - fixed Exynos GSC limits (alignment) and operation in 90 degree rotation mode - fixed some style issues in Scaler driver (thanks to Andrzej) - fixed copy/paste typos in commit messages - improved debug messages, especially if provided parameters exceeds hardwave limits v3: https://www.spinics.net/lists/linux-samsung-soc/msg60981.html - fixed minor issues and added features pointed by other developers: * fixed missing ipp_unregister (Hoegeun) * added missing limits to FIMC and GSC driver (Hoegeun) * added more specific compatible strings to GSC driver (Hoegeun) * added Exynos5433 support to GSC driver (Hoegeun) * added autosuspend runtime PM to all IPP drivers (Tobias) - added Exynos5433 support to Scaler driver (thanks to Andrzej) - dropped Exynos5420 clk patch, which has been alredy merged v2: https://www.spinics.net/lists/dri-devel/msg153418.html - fixed minor issues pointed by other developers: * fixed possible null pointer dereferrence (Tobias) * changed limits_size to limits_count (Tobias) * renamed struct exynos_drm_ipp_format to drm_exynos_ipp_format (Andrzej) * added proper return value from exynos_drm_ipp_get_res_ioctl when no IPP driver is present (Andrzej) * properly aligned all uapi structures to be 32/64 bit safe (Emil) * properly initialize all strucutres - added new Exynos Scaler driver from Andrzej Pietrasiewicz v1: https://www.spinics.net/lists/linux-samsung-soc/msg60492.html - initial version of IPP v2 My previous works in this area: "[RFC v2 0/2] Exynos DRM: add Picture Processor extension" https://www.spinics.net/lists/dri-devel/msg140669.html - removed usage of DRM objects and properties - replaced them with simple list of parameters with predefined IDs "[RFC 0/4] Exynos DRM: add Picture Processor extension" https://www.spinics.net/lists/linux-samsung-soc/msg59323.html - moved this feature from DRM core to Exynos DRM driver - changed name from framebuffer processor to picture processor - simplified code to cover only things needed by Exynos drivers - implemented simple fifo task scheduler - cleaned up rotator driver conversion (removed IPP remainings) "[RFC 0/2] New feature: Framebuffer processors" https://www.spinics.net/lists/linux-samsung-soc/msg54810.html - generic approach implemented in DRM core, rejected Patch summary: Andrzej Pietrasiewicz (3): drm/exynos: Add driver for Exynos Scaler module ARM: dts: exynos: Add mem-2-mem Scaler devices ARM64: dts: exynos: Add mem-2-mem Scaler devices Marek Szyprowski (6): drm/exynos: ipp: Remove Exynos DRM IPP subsystem drm/exynos: ipp: Add IPP v2 framework drm/exynos: rotator: Convert driver to IPP v2 core API drm/exynos: gsc: Convert driver to IPP v2 core API drm/exynos: Add generic support for devices shared with V4L2 subsystem drm/exynos: fimc: Convert driver to IPP v2 core API .../devicetree/bindings/gpu/samsung-scaler.txt | 27 + arch/arm/boot/dts/exynos5420.dtsi | 35 + arch/arm64/boot/dts/exynos/exynos5433.dts
[PATCH v4 4/9] drm/exynos: gsc: Convert driver to IPP v2 core API
This patch adapts Exynos DRM GScaler driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core. During the conversion
driver has been adapted to support more specific compatible strings
to distinguish between Exynos5250 and Exynos5420 (different hardware
limits). Support for Exynos5433 variant has been added too
(different limits table, removed dependency on ARCH_EXYNOS5).
Signed-off-by: Marek Szyprowski
Tested-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/Kconfig |3 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c |1 +
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1001 ++-
drivers/gpu/drm/exynos/exynos_drm_gsc.h | 24 -
4 files changed, 321 insertions(+), 708 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_gsc.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index c10c9ca0d8b4..9b66a9838dca 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -111,7 +111,8 @@ config DRM_EXYNOS_ROTATOR
config DRM_EXYNOS_GSC
bool "GScaler"
- depends on BROKEN && ARCH_EXYNOS5 && VIDEO_SAMSUNG_EXYNOS_GSC=n
+ depends on VIDEO_SAMSUNG_EXYNOS_GSC=n
+ select DRM_EXYNOS_IPP
help
Choose this option if you want to use Exynos GSC for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3ade2b0ad15d..cac0d84385d3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -260,6 +260,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] =
{
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
+ DRM_COMPONENT_DRIVER
}, {
&exynos_drm_platform_driver,
DRM_VIRTUAL_DEVICE
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b17ac1..4671ac41469d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -12,18 +12,20 @@
*
*/
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include "regs-gsc.h"
#include "exynos_drm_drv.h"
+#include "exynos_drm_iommu.h"
#include "exynos_drm_ipp.h"
-#include "exynos_drm_gsc.h"
/*
* GSC stands for General SCaler and
@@ -31,26 +33,10 @@
* input DMA reads image data from the memory.
* output DMA writes image data to memory.
* GSC supports image rotation and image effect functions.
- *
- * M2M operation : supports crop/scale/rotation/csc so on.
- * Memory > GSC H/W > Memory.
- * Writeback operation : supports cloned screen with FIMD.
- * FIMD > GSC H/W > Memory.
- * Output operation : supports direct display using local path.
- * Memory > GSC H/W > FIMD, Mixer.
*/
-/*
- * TODO
- * 1. check suspend/resume api if needed.
- * 2. need to check use case platform_device_id.
- * 3. check src/dst size with, height.
- * 4. added check_prepare api for right register.
- * 5. need to add supported list in prop_list.
- * 6. check prescaler/scaler optimization.
- */
-#define GSC_MAX_DEVS 4
+#define GSC_MAX_CLOCKS 8
#define GSC_MAX_SRC4
#define GSC_MAX_DST16
#define GSC_RESET_TIMEOUT 50
@@ -65,8 +51,6 @@
#define GSC_SC_DOWN_RATIO_4_8 131072
#define GSC_SC_DOWN_RATIO_3_8 174762
#define GSC_SC_DOWN_RATIO_2_8 262144
-#define GSC_REFRESH_MIN12
-#define GSC_REFRESH_MAX60
#define GSC_CROP_MAX 8192
#define GSC_CROP_MIN 32
#define GSC_SCALE_MAX 4224
@@ -77,10 +61,9 @@
#define GSC_COEF_H_8T 8
#define GSC_COEF_V_4T 4
#define GSC_COEF_DEPTH 3
+#define GSC_AUTOSUSPEND_DELAY 2000
#define get_gsc_context(dev) platform_get_drvdata(to_platform_device(dev))
-#define get_ctx_from_ippdrv(ippdrv)container_of(ippdrv,\
- struct gsc_context, ippdrv);
#define gsc_read(offset) readl(ctx->regs + (offset))
#define gsc_write(cfg, offset) writel(cfg, ctx->regs + (offset))
@@ -124,7 +107,6 @@ struct gsc_capability {
/*
* A structure of gsc context.
*
- * @ippdrv: prepare initialization using ippdrv.
* @regs_res: register resources.
* @regs: memory mapped io registers.
* @sysreg: handle to SYSREG block regmap.
@@ -137,12 +119,18 @@ struct gsc_capability {
* @suspended: qos operations.
*/
struct gsc_context {
- struct exynos_drm_ippdrvippdrv;
+ struct exynos_drm_ipp ipp;
+ struct drm_device *drm_dev;
+ struct device *dev;
+ struct exynos_drm_ipp_task *task;
+ struct exynos_drm_ipp_formats *formats;
+
struct resource *regs_res;
void __iomem*regs;
struct regmap *sysreg;
- struct mutexlock;
- struct clk *gsc
[PATCH v4 9/9] ARM64: dts: exynos: Add mem-2-mem Scaler devices
From: Andrzej Pietrasiewicz
There are two Scaler devices in Exynos5433 SoCs. Add nodes for them and
their SYSMMU controllers.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 7fe994b750da..97866114767f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -920,6 +920,28 @@
iommus = <&sysmmu_gscl2>;
};
+ scaler_0: scaler@1500 {
+ compatible = "samsung,exynos5433-scaler";
+ reg = <0x1500 0x1294>;
+ interrupts = <0 402 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk", "aclk_xiu";
+ clocks = <&cmu_mscl CLK_PCLK_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_XIU_MSCLX>;
+ iommus = <&sysmmu_scaler_0>;
+ };
+
+ scaler_1: scaler@1501 {
+ compatible = "samsung,exynos5433-scaler";
+ reg = <0x1501 0x1294>;
+ interrupts = <0 403 IRQ_TYPE_LEVEL_HIGH>;
+ clock-names = "pclk", "aclk", "aclk_xiu";
+ clocks = <&cmu_mscl CLK_PCLK_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_XIU_MSCLX>;
+ iommus = <&sysmmu_scaler_1>;
+ };
+
jpeg: codec@1502 {
compatible = "samsung,exynos5433-jpeg";
reg = <0x1502 0x1>;
@@ -1014,6 +1036,26 @@
#iommu-cells = <0>;
};
+ sysmmu_scaler_0: sysmmu@0x1504 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x1504 0x1000>;
+ interrupts = ;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_mscl CLK_PCLK_SMMU_M2MSCALER0>,
+<&cmu_mscl CLK_ACLK_SMMU_M2MSCALER0>;
+ #iommu-cells = <0>;
+ };
+
+ sysmmu_scaler_1: sysmmu@0x1505 {
+ compatible = "samsung,exynos-sysmmu";
+ reg = <0x1505 0x1000>;
+ interrupts = ;
+ clock-names = "pclk", "aclk";
+ clocks = <&cmu_mscl CLK_PCLK_SMMU_M2MSCALER1>,
+<&cmu_mscl CLK_ACLK_SMMU_M2MSCALER1>;
+ #iommu-cells = <0>;
+ };
+
sysmmu_jpeg: sysmmu@1506 {
compatible = "samsung,exynos-sysmmu";
reg = <0x1506 0x1000>;
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/bridge/sii9234: Use common error handling code in sii9234_writebm()
>> ret = i2c_smbus_write_byte_data(client, offset, value);
>> -if (ret < 0) {
>> -dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
>> -sii9234_client_name[id], offset, value);
>> -ctx->i2c_error = ret;
>> -}
>> +if (!ret)
>> +return 0;
>
> Ugh. No. Don't do success handling on the last if statement.
I find my approach useful in this case.
> Also while I personally prefer testing for non-zero,
I got used to this checking style to some degree.
> the ALSA people got annoyed at you for changing tests for < 0
It seems that involved software developers have got special preferences there.
> but you're doing it again.
I dared to propose such an adjustment once more.
Would you like discuss corresponding reasons any further?
> And it introduces a bug,
Unfortunately, a hiccup in my software development attention …
> although I see now that you fixed it in v2.
Thanks that you noticed also this small update.
https://patchwork.kernel.org/patch/10021767/
https://lkml.kernel.org/r/<2ecf0bb7-7129-40e4-cefc-0bc2d0f7e...@users.sourceforge.net>
> I can't get excited about these sort of risky low value patches.
I try again to point special software improvement opportunities out.
>> +report_failure:
>> +dev_err(ctx->dev, "writebm: %4s[0x%02x] <- 0x%02x\n",
>> +sii9234_client_name[id], offset, value);
>> +ctx->i2c_error = ret;
>> return ret;
>> }
How do you think about to move this source code to the end of
this function implementation?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102655] [CI][HSW] igt@gem_flink_race@flink_close - Failed assertion: obj_count == 0
https://bugs.freedesktop.org/show_bug.cgi?id=102655 Marta Löfstedt changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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
[GIT PULL] etnaviv-next-fixes for 4.15
Hi Dave, unfortunately we found some issues with the new perfmon implementation post-merge, so here are 2 patches to disable the feature again. It keeps most of the code in place, so we can fix it up in-tree, but rejects any requests from userspace using the feature. Regards, Lucas The following changes since commit 19f470b2e47ddde4ad51744c2e140b86524b1f5a: Merge tag 'drm-amdkfd-next-2017-10-18' of git://people.freedesktop.org/~gabbayo/linux into drm-next (2017-10-20 15:54:44 +1000) are available in the git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 330b52bd9bba1d66028772dfe08c053a34c5069a: drm/etnaviv: short-circuit perfmon ioctls (2017-10-22 18:41:56 +0200) Lucas Stach (2): Revert "drm/etnaviv: submit supports performance monitor requests" drm/etnaviv: short-circuit perfmon ioctls drivers/gpu/drm/etnaviv/etnaviv_drv.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103317] Tearing in WQHD, but not in FHD
https://bugs.freedesktop.org/show_bug.cgi?id=103317 Michel Dänzer changed: What|Removed |Added Attachment #134943|text/x-log |text/plain mime type|| -- 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 103317] Tearing in WQHD, but not in FHD
https://bugs.freedesktop.org/show_bug.cgi?id=103317 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com, ||jordan.laz...@amd.com --- Comment #7 from Michel Dänzer --- (In reply to Torsten Kessler from comment #6) > The new display engine (amdgpu.dc=1) definitely helps. It nearly eliminates > the flickering during videos or browsing. It has no effect on 3D > applications, for example 0ad. Adding DC developers to Cc. I'm afraid at this point it's unlikely that this issue will be fixed in the non-DC code. -- 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 103413] R9285 Xonotic gpu lock since radeonsi: split si_emit_shader_pointer
https://bugs.freedesktop.org/show_bug.cgi?id=103413 Bug ID: 103413 Summary: R9285 Xonotic gpu lock since radeonsi: split si_emit_shader_pointer Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com QA Contact: dri-devel@lists.freedesktop.org R9285 Tonga, probably since 36626ff radeonsi: split si_emit_shader_pointer Xonotic big-key-bench timedemo may provoke a display/gpu lockup. On head it seemed easy to provoke: one,two or three runs. Bisecting was harder as it took more hence the possibility that I am on a false good. Currently on commit before above and haven't locked so far, don't know if that's luck yet. Lock seems to be same(ish) place in demo = frame 6512, though once it was 6514. Waiting before doing SysRq I will get a timeout trace as below. I tried on older kernels with same result, the dirty here is just a CPU fix I need that's in rc-5. INFO: task gallium_drv:0:985 blocked for more than 120 seconds. Not tainted 4.14.0-rc3-g96687ec-dirty #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. gallium_drv:0 D0 985962 0x Call Trace: __schedule+0x2ce/0x890 ? _raw_write_unlock+0x11/0x30 schedule+0x3b/0x90 amd_sched_entity_push_job+0x9f/0xf0 [amdgpu] ? remove_wait_queue+0x80/0x80 amdgpu_job_submit+0x9a/0xc0 [amdgpu] amdgpu_vm_bo_update_mapping+0x2de/0x3a0 [amdgpu] ? amdgpu_vm_free_mapping.isra.20+0x30/0x30 [amdgpu] amdgpu_vm_bo_update+0x2e8/0x6a0 [amdgpu] amdgpu_gem_va_ioctl+0x476/0x480 [amdgpu] ? amdgpu_gem_metadata_ioctl+0x1d0/0x1d0 [amdgpu] drm_ioctl_kernel+0x6f/0xc0 [drm] drm_ioctl+0x2f9/0x3c0 [drm] ? futex_wake+0x7c/0x140 ? amdgpu_gem_metadata_ioctl+0x1d0/0x1d0 [amdgpu] ? do_futex+0x289/0xb20 ? put_prev_entity+0xf8/0x5a0 ? preempt_count_add+0x99/0xb0 ? _raw_write_unlock_irqrestore+0x13/0x30 ? _raw_spin_unlock_irqrestore+0x9/0x10 amdgpu_drm_ioctl+0x54/0x90 [amdgpu] do_vfs_ioctl+0x98/0x5b0 ? __fget+0x6e/0xa0 SyS_ioctl+0x47/0x80 entry_SYSCALL_64_fastpath+0x17/0x98 RIP: 0033:0x7fee63cb8717 RSP: 002b:7fee567415a8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 7fee2c00bbe0 RCX: 7fee63cb8717 RDX: 7fee567415f0 RSI: c0286448 RDI: 000e RBP: R08: 00015040 R09: 000e R10: 0001 R11: 0246 R12: R13: R14: 0370e4a0 R15: 08881590 -- 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: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem
Hi Philipp, On Thursday, 19 October 2017 17:54:16 EEST Philipp Zabel wrote: > On Thu, 2017-10-19 at 16:39 +0300, Laurent Pinchart wrote: > > On Thursday, 19 October 2017 16:01:54 EEST Philipp Zabel wrote: > >> On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote: > >>> In theory the MMSYS device tree identifier is matches twice, by the > >>> clk driver and the DRM subsystem. But the kernel only matches the > >>> first driver for a device (clk) and discards the second one. This > >>> breaks graphics on mt8173 and most probably on mt2701 as well. > >>> > >>> MMSYS in Mediatek SoCs has some registers to control clock gates > >>> (which is used in the clk driver) and some registers to enable the > >>> differnet blocks of the display subsystem. The kernel uses the binding > >>> to load the central comoponent of the distplay subsystem, which in > >>> place probes all the other components and enables the present ones in > >>> the MMSYS. > >>> > >>> We found us with the problem, that we need to change and therefor > >>> break one of the two bindings, or the DRM one or the clock driver one. > >>> > >>> Apart from that the DRM subysystem does access the MMSYS registers via > >>> relaxed reads/writes. But the it should to so via regmap, as the > >>> registers are shared. > >>> > >>> Possible solutions: > >>> 1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a > >>> simple-mfd under the actual mmsys node. We change the clock driver to > >>> probe on this binding. This would make sense as the clock gate > >>> register live completly in the MMSYS configuration registers. > >> > >> The reason why the drm driver matches against the mmsys node in the > >> first place is that we wanted to avoid 2). > > > > Why did you want to avoid 2) ? > > Because the "display-subsystem" node does not represent a real device, > it's just there to probe the driver that stitches all the DISP components > together. I'm not a big supported of such DT nodes for "logical" devices either. When possible I prefer describing the relationship between display IP cores using OF graph DT bindings. In some cases (and I don't know if the Mediatek display is one of them) there is no single IP core that can be considered as a master from a display point of view. This is inconvenient for device drivers as there's no clear place for an entry point. I could thus be convinced to accept DT bindings for a logical display DT node when there's really no other good choice. > >> Also, mmsys is not a pure clock controller, as it also contains the > >> display path configuration in its register space. > > > > Which makes the mmsys related to display, but more in a syscon (combining > > clocks and routing, and I assume other miscellaneous features that > > wouldn't fit nicely in the other display-related IP cores) way than > > actually being part of the display subsystem. Or does mmsys only provide > > display-related features ? > > All devices in the 0x1400 - 0x14ff memory range are part of the > MMSYS system. That includes the MMSYS control or system configuration > block at 0x1400 - 0x14000fff as well as all the related MDP (media > data path) and DISP (display data path) blocks that follow. The DISP > blocks are purely display related, while the MDP blocks implement > implement mem2mem functions like scaling and conversion. Without more information about the hardware it's hard to tell whether the DT nodes for the DISP and MDP IP cores should be children of the MMSYS DT node or not. In any case, it looks like the MMSYS is a syscon that provides miscellaneous functions not fitting anywhere else. On simple solution, which shouldn't require DT changes, would be to merge the MMSYS clock driver into the mediatek DRM driver, and register the MMSYS clocks at probe time instead of using CLK_OF_DECLARE. Another option would be to handle MMSYS as an MFD. That shouldn't require DT changes either. > >>> 2) As the nodes of the DRM subsystem just need some of the registers > >>> of MMSYS we add a new binding mediatek,mt8173-dispsys which probes the > >>> central component of the DRM system. It has only a handle to mt8173- > >>> mmsys to access the registerspace via regmap functions. > >>> > >>> In this patchset I implemented 2). Please take into account, that this > >>> is a RFC. I had no time to actually test the verison on real HW. Some > >>> of the register accesses should be done using regmap_update instead of > >>> regmap_read + regmap_write. > >>> > >>> This RFC shall only show how solution 2) would look like. We can use > >>> it as discussion to see how we circumvent the actual situation. > >> > >> Or we could leave the bindings untouched and create one platform device > >> from the other or even set up the clocks from the drm driver? > > > > Does mmsys provide features (such as clocks) to non-display IP cores ? > > The MMSYS control block provides clocks for the DISP (display data path) > and MDP (multimedia d
[Bug 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx
https://bugs.freedesktop.org/show_bug.cgi?id=103401 Michel Dänzer changed: What|Removed |Added Product|xorg|Mesa Component|Driver/AMDgpu |Drivers/Gallium/radeonsi Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org |dri-devel@lists.freedesktop ||.org --- Comment #3 from Michel Dänzer --- Please attach the full corresponding Xorg log file and output of glxinfo. Looks like the crash happens in Mesa. Would be helpful if you could get more information about the crash, either with gdb (see https://www.x.org/wiki/Development/Documentation/ServerDebugging/) or addr2line. -- 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 v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight
On 21/10/17 12:55, Meghana Madhyastha wrote: Changes in v14: - s/backlight_get/of_find_backlight/ in patch 2/3 - Change commit message in patch 3/3 from requiring to acquiring Can you take a look at https://www.spinics.net/lists/dri-devel/msg154459.html ? This doesn't seem to have been acted on... and nor was it challenged ;-) . Daniel. Meghana Madhyastha (3): drm/tinydrm: Move helper functions from tinydrm-helpers to backlight.h drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c drm/tinydrm: Add devres versions of of_find_backlight drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 95 -- drivers/gpu/drm/tinydrm/mi0283qt.c | 3 +- drivers/gpu/drm/tinydrm/mipi-dbi.c | 5 +- drivers/video/backlight/backlight.c| 68 ++ include/drm/tinydrm/tinydrm-helpers.h | 4 -- include/linux/backlight.h | 56 +++ 6 files changed, 129 insertions(+), 102 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH v13 2/3] drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
On 20/10/17 18:20, Sean Paul wrote: On Wed, Oct 18, 2017 at 1:11 PM, Meghana Madhyastha wrote: On Mon, Oct 16, 2017 at 02:26:00PM -0400, Sean Paul wrote: On Fri, Oct 13, 2017 at 6:42 PM, Noralf Trønnes wrote: Den 13.10.2017 22.25, skrev Sean Paul: On Fri, Oct 13, 2017 at 04:11:43PM +0530, Meghana Madhyastha wrote: Rename tinydrm_of_find_backlight to backlight_get and move it to linux/backlight.c so that it can be used by other drivers. [apologies if this has been brought up in previous versions, I haven't been following closely] I don't think "backlight_get" is a good name for this function. How about of_find_backlight_by_name (since there's already of_find_backlight_by_node)? I came up with that name modelled after gpiod_get() and gpiod_put() and I deliberately kept the of_ part out of the name like the gpio functions. gpiod_get() checks OF, ACPI and platform for gpios and calling it backlight_get() would keep the door open for other ways of connecting backlight devices in the future, other than Device Tree. Thanks for the background, Noralf! Apologies for stepping on top of your previous reviews. I think of_find_backlight() would be better than *_by_name(), since 'backlight' is the common DT property name, so it wouldn't make much sense to require every caller to pass in the same name. of_find_backlight() sounds like a good compromise. Sean Are there any changes that need to be made to this patchset now ? I still prefer s/backlight_get/of_find_backlight/ and it seems Noralf is Ok with that too. I think there were also review comments surrounding the _put function? How did this conversation result in a new patchset with the name changed? Did I miss something. Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103384] [UBUNTU 16.04] Poor performance after update video-driver (HD7790, radeonsi)
https://bugs.freedesktop.org/show_bug.cgi?id=103384 --- Comment #1 from Michel Dänzer --- Which components did you update exactly, from which version to which? -- 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 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #90 from Jean Delvare (jdelv...@suse.de) --- yousifjkadom, your problem has nothing to do with this bug, please create a new bug for it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 Nicolai Hähnle changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #9 from Nicolai Hähnle --- I assume it's safe to close this bug report then? Please re-open if you still run into issue. -- 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 libdrm 1/2] headers: Sync amdgpu_drm.h with drm-next
Both patches:
Reviewed-by: Nicolai Hähnle
On 20.10.2017 16:57, Andres Rodriguez wrote:
Generated using make headers_install from:
airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ...
Signed-off-by: Andres Rodriguez
---
include/drm/amdgpu_drm.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 4c6e8c4..ff01818 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -53,6 +53,7 @@ extern "C" {
#define DRM_AMDGPU_WAIT_FENCES0x12
#define DRM_AMDGPU_VM 0x13
#define DRM_AMDGPU_FENCE_TO_HANDLE0x14
+#define DRM_AMDGPU_SCHED 0x15
#define DRM_IOCTL_AMDGPU_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
#define DRM_IOCTL_AMDGPU_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -69,6 +70,7 @@ extern "C" {
#define DRM_IOCTL_AMDGPU_WAIT_FENCES DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
#define DRM_IOCTL_AMDGPU_VM DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_VM, union drm_amdgpu_vm)
#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
+#define DRM_IOCTL_AMDGPU_SCHED DRM_IOW(DRM_COMMAND_BASE +
DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
@@ -91,6 +93,8 @@ extern "C" {
#define AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS (1 << 5)
/* Flag that BO is always valid in this VM */
#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID (1 << 6)
+/* Flag that BO sharing will be explicitly synchronized */
+#define AMDGPU_GEM_CREATE_EXPLICIT_SYNC(1 << 7)
struct drm_amdgpu_gem_create_in {
/** the requested memory size */
@@ -166,13 +170,22 @@ union drm_amdgpu_bo_list {
/* unknown cause */
#define AMDGPU_CTX_UNKNOWN_RESET 3
+/* Context priority level */
+#define AMDGPU_CTX_PRIORITY_UNSET -2048
+#define AMDGPU_CTX_PRIORITY_VERY_LOW-1023
+#define AMDGPU_CTX_PRIORITY_LOW -512
+#define AMDGPU_CTX_PRIORITY_NORMAL 0
+/* Selecting a priority above NORMAL requires CAP_SYS_NICE or DRM_MASTER */
+#define AMDGPU_CTX_PRIORITY_HIGH512
+#define AMDGPU_CTX_PRIORITY_VERY_HIGH 1023
+
struct drm_amdgpu_ctx_in {
/** AMDGPU_CTX_OP_* */
__u32 op;
/** For future use, no flags defined so far */
__u32 flags;
__u32 ctx_id;
- __u32 _pad;
+ __s32 priority;
};
union drm_amdgpu_ctx_out {
@@ -216,6 +229,21 @@ union drm_amdgpu_vm {
struct drm_amdgpu_vm_out out;
};
+/* sched ioctl */
+#define AMDGPU_SCHED_OP_PROCESS_PRIORITY_OVERRIDE 1
+
+struct drm_amdgpu_sched_in {
+ /* AMDGPU_SCHED_OP_* */
+ __u32 op;
+ __u32 fd;
+ __s32 priority;
+ __u32 flags;
+};
+
+union drm_amdgpu_sched {
+ struct drm_amdgpu_sched_in in;
+};
+
/*
* This is not a reliable API and you should expect it to fail for any
* number of reasons and have fallback path that do not use userptr to
@@ -629,6 +657,7 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_SENSOR_VDDGFX 0x7
/* Number of VRAM page faults on CPU access. */
#define AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS 0x1E
+#define AMDGPU_INFO_VRAM_LOST_COUNTER 0x1F
#define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
#define AMDGPU_INFO_MMR_SE_INDEX_MASK 0xff
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103415] System is accepting the invalid Username
https://bugs.freedesktop.org/show_bug.cgi?id=103415 Bug ID: 103415 Summary: System is accepting the invalid Username Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Windows (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: arthurnee...@gmail.com Created attachment 135002 --> https://bugs.freedesktop.org/attachment.cgi?id=135002&action=edit UserName Field is Step 1 Enter Valid URL Click on GO step 2 Enter invalid username and Password Click on Login -- 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 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx
https://bugs.freedesktop.org/show_bug.cgi?id=103401 --- Comment #4 from Sergey Kondakov --- Created attachment 135003 --> https://bugs.freedesktop.org/attachment.cgi?id=135003&action=edit X log from lightdm It's not much bigger than a snippet above. -- 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 v3] drm: exynos: Add driver for HDMI audio interface
On 10/23/2017 03:27 AM, Inki Dae wrote:
>> +static int hdmi_audio_digital_mute(struct device *dev, void *data, bool
>> mute)
>> +{
>> +struct hdmi_context *hdata = dev_get_drvdata(dev);
>> +
>> +mutex_lock(&hdata->mutex);
>> +
>> +hdata->audio.enable = !mute;
>
> Wouldn't it be better to keep 'mute' instead of 'enable'?
> 'hdata->audio.enable'
is used by only hdmi_adio_control function and whether hdmi is power on or nis
already checked by 'hdata->powered'
Yes, makes sense, I'll change it.
>> +
>> +if (hdata->powered)
>> +hdmi_audio_control(hdata);
>> +
>> +mutex_unlock(&hdata->mutex);
>> +
>> +return 0;
>> +}
>> +static void hdmi_unregister_audio_device(struct hdmi_context *hdata)
>> +{
>> +platform_device_unregister(hdata->audio.pdev);
>> +}
>
> This function is unnecessary wrapper. You can use
> platform_device_unregister(hdata->audio.pdev) at probe callback.
> And you would need to unregister audio device at remove callback.
Fixed in v4.
>> static int hdmi_bridge_init(struct hdmi_context *hdata)
>> @@ -1697,6 +1812,7 @@ static int hdmi_bind(struct device *dev, struct device
>> *master, void *data)
>> struct drm_device *drm_dev = data;
>> struct hdmi_context *hdata = dev_get_drvdata(dev);
>> struct drm_encoder *encoder = &hdata->encoder;
>> +struct hdmi_audio_infoframe *audio_infoframe = &hdata->audio.infoframe;
>> struct exynos_drm_crtc *crtc;
>> int ret;
>>
>> @@ -1704,6 +1820,12 @@ static int hdmi_bind(struct device *dev, struct
>> device *master, void *data)
>>
>> hdata->phy_clk.enable = hdmiphy_clk_enable;
>>
>> +hdmi_audio_infoframe_init(audio_infoframe);
>> +audio_infoframe->coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
>> +audio_infoframe->sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
>> +audio_infoframe->sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
>> +audio_infoframe->channels = 2;
>
> Audio device is registered at probe callback so it would be better to move
> above code into probe callback.
> I coudln't see initializing audio infoframe should be done here.
Yes, it makes more sense indeed to have this initialization in probe().
Thanks for your review.
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx
https://bugs.freedesktop.org/show_bug.cgi?id=103401 --- Comment #5 from Sergey Kondakov --- Created attachment 135004 --> https://bugs.freedesktop.org/attachment.cgi?id=135004&action=edit X log from startx Not a hint for trouble. -- 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 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx
https://bugs.freedesktop.org/show_bug.cgi?id=103401 --- Comment #6 from Sergey Kondakov --- Created attachment 135005 --> https://bugs.freedesktop.org/attachment.cgi?id=135005&action=edit glxinfo_20171023 -- 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 103401] X with radeon/amdgpu crashes under lightdm and sddm but not xdm and startx
https://bugs.freedesktop.org/show_bug.cgi?id=103401 --- Comment #7 from Sergey Kondakov --- (In reply to Michel Dänzer from comment #3) > Please attach the full corresponding Xorg log file and output of glxinfo. > > Looks like the crash happens in Mesa. > > Would be helpful if you could get more information about the crash, either > with gdb (see > https://www.x.org/wiki/Development/Documentation/ServerDebugging/) or > addr2line. That's would be hard since it crashes only when launched by a system service. At best I can try to install debug symbols to convert those numbers to something readable. -- 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 103393] glDispatchComputeGroupSizeARB : gl_GlobalInvocationID.x != gl_WorkGroupID.x * gl_LocalGroupSizeARB.x + gl_LocalInvocationID.x
https://bugs.freedesktop.org/show_bug.cgi?id=103393 --- Comment #7 from Ilia Mirkin --- An updated patch fixes the issue in a more complete way (with multiple shaders being linked together, even non-variable local sizes were broken). This is now upstream in commit 4d24a7cb97641cacecd371d1968f6964785822e4 Author: Ilia Mirkin Date: Sat Oct 21 15:15:41 2017 -0400 glsl: fix derived cs variables Thanks for reporting and providing a repro! As the original issue was filed against radeonsi, I'm going to leave this open until someone can confirm that this does indeed fix the problem there. -- 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 v4] drm: exynos: Add driver for HDMI audio interface
The hdmi-codec interface added in this patch is required to properly
support HDMI audio. Currently the audio part of the SoC internal
HDMI transmitter is configured with fixed values, which makes HDMI
audio working by chance, only on boards having an external audio
codec connected in parallel with the HDMI audio transmitter's input
I2S interface.
Signed-off-by: Sylwester Nawrocki
Reviewed-by: Andrzej Hajda
---
Changes since v3:
- removed unregister_audio_device() function, added missing
audio platform device unregistration in probe(),
- 'enable' field in struct hdmi_audio replace with 'mute',
- audio infoframe initialization moved from the bind()
callback to probe().
Changes since v2:
- u8 replaced with bool type,
- the HDMI codec iec.status data used directly for setting up
the HDMI controller registers rather than using hard coded
constants,
- constants used for configuring the HDMI_AUI_CON register
instead of plain numbers,
- if/IS_ERR/return replaced with PTR_ERR_OR_ZERO().
Changes since v1:
- rebased onto v4.14-rc1 and adapted locking
Changes since RFC version:
- fixed hdmi-codec locking issue
- added a comment documenting struct hdmi_contex::mutex
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 250 ++-
drivers/gpu/drm/exynos/regs-hdmi.h | 8 +-
3 files changed, 194 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 305dc3d4ff77..5a7c9d8abd6b 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -3,6 +3,7 @@ config DRM_EXYNOS
depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS ||
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+ select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option if you have a Samsung SoC EXYNOS chipset.
If M is selected the module will be called exynosdrm.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 1309b1c9e074..82d1b7e2febe 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -40,7 +40,7 @@
#include
#include
#include
-
+#include
#include
#include
@@ -111,12 +111,18 @@ struct hdmi_driver_data {
struct string_array_spec clk_muxes;
};
+struct hdmi_audio {
+ struct platform_device *pdev;
+ struct hdmi_audio_infoframe infoframe;
+ struct hdmi_codec_paramsparams;
+ boolmute;
+};
+
struct hdmi_context {
struct drm_encoder encoder;
struct device *dev;
struct drm_device *drm_dev;
struct drm_connectorconnector;
- boolpowered;
booldvi_mode;
struct delayed_work hotplug_work;
struct cec_notifier *notifier;
@@ -136,6 +142,11 @@ struct hdmi_context {
struct regulator*reg_hdmi_en;
struct exynos_drm_clk phy_clk;
struct drm_bridge *bridge;
+
+ /* mutex protecting subsequent fields below */
+ struct mutexmutex;
+ struct hdmi_audio audio;
+ boolpowered;
};
static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
@@ -776,6 +787,22 @@ static int hdmi_clk_set_parents(struct hdmi_context
*hdata, bool to_phy)
return ret;
}
+static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
+{
+ struct hdmi_audio_infoframe *infoframe = &hdata->audio.infoframe;
+ u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
+ int len;
+
+ len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
+ if (len < 0)
+ return len;
+
+ hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
+ hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
+
+ return 0;
+}
+
static void hdmi_reg_infoframes(struct hdmi_context *hdata)
{
struct drm_display_mode *m = &hdata->encoder.crtc->state->mode;
@@ -812,15 +839,7 @@ static void hdmi_reg_infoframes(struct hdmi_context *hdata)
hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
}
- ret = hdmi_audio_infoframe_init(&frm.audio);
- if (!ret) {
- frm.audio.channels = 2;
- ret = hdmi_audio_infoframe_pack(&frm.audio, buf, sizeof(buf));
- }
- if (ret > 0) {
- hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
- hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, ret);
- }
+ hdmi_audio_infoframe_apply(hdata);
}
static enum drm_connector_status hdmi_detect(struct drm_connector *connector,
@@ -1010,23 +1029,18 @@ static void hdmi_reg_acr(struc
Re: [PATCH v3 1/7] fbcon: Add fbcon_rotate_hint to struct fb_info
Hi, On 23-10-17 14:43, Sebastian Reichel wrote: Hi Hans, On Mon, Oct 23, 2017 at 09:14:19AM +0200, Hans de Goede wrote: On some hardware the LCD panel is not mounted upright in the casing, but upside-down or rotated 90 degrees. In this case we want the console to automatically be rotated to compensate. The fbdev-driver may know about the need to rotate. Add a new fbcon_rotate_hint field to struct fb_info, which gets initialized to -1. If the fbdev-driver knows that some sort of rotation is necessary then it can set this field to a FB_ROTATE_* value to tell the fbcon console driver to rotate the console. Signed-off-by: Hans de Goede --- Thanks for your work. I will give it a try with Droid 4 and N950 once I find some time :) Ah, I did not even realize that this work would be useful for those too, but yes that makes sense. [...] + p->con_rotate = initial_rotation; + if (p->con_rotate == -1) + p->con_rotate = info->fbcon_rotate_hint; + if (p->con_rotate == -1) p->con_rotate = fbcon_platform_get_rotate(info); [...] + p->con_rotate = initial_rotation; + if (p->con_rotate == -1) + p->con_rotate = info->fbcon_rotate_hint; + if (p->con_rotate == -1) p->con_rotate = fbcon_platform_get_rotate(info); + maybe add a little helper function to reduce code duplication? Maybe, I took a look and there already is a fbcon_set_rotation() helper which does something completely different, so it might be best to just keep this as is to avoid confusion between 2 similar named functions. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
2017-10-18 22:07 GMT+02:00 Laura Abbott :
> On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 93e2c90..092b24c 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -40,6 +40,8 @@
>>
>> #include "ion.h"
>>
>> +#define ION_DEV_MAX 32
>> +
>> static struct ion_device *internal_dev;
>> static int heap_id;
>>
>> @@ -537,15 +539,28 @@ static int debug_shrink_get(void *data, u64 *val)
>> DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
>> debug_shrink_set, "%llu\n");
>>
>> -void ion_device_add_heap(struct ion_heap *heap)
>> +int ion_device_add_heap(struct ion_heap *heap)
>> {
>> struct dentry *debug_file;
>> struct ion_device *dev = internal_dev;
>> + int ret = 0;
>>
>> if (!heap->ops->allocate || !heap->ops->free)
>> pr_err("%s: can not add heap with invalid ops struct.\n",
>> __func__);
>>
>> + if (heap_id >= ION_DEV_MAX)
>> + return -EBUSY;
>> +
>> + heap->ddev.devt = MKDEV(MAJOR(dev->devt), heap_id);
>> + dev_set_name(&heap->ddev, "ion%d", heap_id);
>> + device_initialize(&heap->ddev);
>> + cdev_init(&heap->chrdev, &ion_fops);
>> + heap->chrdev.owner = THIS_MODULE;
>> + ret = cdev_device_add(&heap->chrdev, &heap->ddev);
>> + if (ret < 0)
>> + return ret;
>> +
>> spin_lock_init(&heap->free_lock);
>> heap->free_list_size = 0;
>>
>> @@ -583,6 +598,8 @@ void ion_device_add_heap(struct ion_heap *heap)
>>
>> dev->heap_cnt++;
>> up_write(&dev->lock);
>> +
>> + return ret;
>> }
>> EXPORT_SYMBOL(ion_device_add_heap);
>>
>> @@ -595,6 +612,7 @@ static int ion_device_create(void)
>> if (!idev)
>> return -ENOMEM;
>>
>> +#ifdef CONFIG_ION_LEGACY_DEVICE_API
>> idev->dev.minor = MISC_DYNAMIC_MINOR;
>> idev->dev.name = "ion";
>> idev->dev.fops = &ion_fops;
>> @@ -605,6 +623,17 @@ static int ion_device_create(void)
>> kfree(idev);
>> return ret;
>> }
>> +#endif
>> +
>> + ret = alloc_chrdev_region(&idev->devt, 0, ION_DEV_MAX, "ion");
>> + if (ret) {
>> + pr_err("ion: unable to allocate device\n");
>> +#ifdef CONFIG_ION_LEGACY_DEVICE_API
>> + misc_deregister(&idev->dev);
>> +#endif
>> + kfree(idev);
>> + return ret;
>> + }
>>
>> idev->debug_root = debugfs_create_dir("ion", NULL);
>> if (!idev->debug_root) {
>
> I'm not 100% sure about the device hierarchy here. We're
> ending up with devices at the root of /sys/devices
>
> /sys/devices # ls
> breakpoint ion0 ion1 ion2 platform software system virtual
>
> and the Android init system doesn't pick this up. I'll
> admit to being out of my area here but I don't think
> this looks quite right.
>
You are right it is because ion devices are parentless so they
directly put under /sys/devices directory. I will give them platform_bus
as parent to solve that problem.
Benjamin
> Thanks,
> Laura
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug
From: Ville Syrjälä
Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
even drivers that don't implement accurate vblank timestamps will end
up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
time drm_crtc_arm_vblank_event() gets called. The could be as often
as every frame for each active crtc.
Considering drm_crtc_accurate_vblank_count() is never any worse than
the drm_vblank_count() we used previously, let's just skip the WARN
unless DRM_UT_VBL is enabled. That way people won't be bothered by
this unless they're debugging vblank code. And let's also change it
to WARN_ONCE() so that even when you're debugging vblank code you
won't get drowned by constant WARNs.
Cc: sta...@vger.kernel.org
Cc: Daniel Vetter
Cc: "Szyprowski, Marek"
Cc: Andrzej Hajda
Reported-by: Andrzej Hajda
Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_vblank.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 13722c373a6a..c81c297995c6 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -299,8 +299,8 @@ u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc)
u32 vblank;
unsigned long flags;
- WARN(!dev->driver->get_vblank_timestamp,
-"This function requires support for accurate vblank timestamps.");
+ WARN_ONCE(drm_debug & DRM_UT_VBL && !dev->driver->get_vblank_timestamp,
+ "This function requires support for accurate vblank
timestamps.");
spin_lock_irqsave(&dev->vblank_time_lock, flags);
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196247] AMD FirePro W5130M - Radeon driver - ring 0 stalled
https://bugzilla.kernel.org/show_bug.cgi?id=196247 Mathias (mat...@yahoo.de) changed: What|Removed |Added Kernel Version|4.x |4.14 Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/2] staging: ion: get one device per heap
version 6: - add platform_bus and platform_bus_type when register Ion devices to make them appear in /sys/devices/platform. - re-order include files in aphabetic order. version 5: - create a configuration flag to keep legacy Ion misc device version 4: - add a configuration flag to switch between legacy Ion misc device and one device per heap version. This change has been suggested after Laura talks at XDC 2017. version 3: - change ion_device_add_heap prototype to return a possible error. version 2: - simplify ioctl check like propose by Dan - make sure that we don't register more than ION_DEV_MAX heaps. Until now all ion heaps are addressing using the same device "/dev/ion". This way of working doesn't allow to give access rights (for example with SElinux rules) per heap. This series propose to have one device "/dev/ionX" per heap. Query heaps informations will be possible on each device node but allocation request will only be possible if heap_mask_id match with device minor number. Using legacy Ion misc device is still by setting ION_LEGACY_DEVICE_API configuration flag. Benjamin Gaignard (2): staging: ion: simplify ioctl args checking function staging: ion: create one device entry per heap drivers/staging/android/TODO| 1 - drivers/staging/android/ion/Kconfig | 7 + drivers/staging/android/ion/ion-ioctl.c | 29 +- drivers/staging/android/ion/ion.c | 53 ++--- drivers/staging/android/ion/ion.h | 15 -- 5 files changed, 84 insertions(+), 21 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] staging: ion: simplify ioctl args checking function
Make arguments checking more easy to read.
Signed-off-by: Benjamin Gaignard
Acked-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index d9f8b14..e26b786 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -27,19 +27,18 @@ union ion_ioctl_arg {
static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
{
- int ret = 0;
-
switch (cmd) {
case ION_IOC_HEAP_QUERY:
- ret = arg->query.reserved0 != 0;
- ret |= arg->query.reserved1 != 0;
- ret |= arg->query.reserved2 != 0;
+ if (arg->query.reserved0 ||
+ arg->query.reserved1 ||
+ arg->query.reserved2 )
+ return -EINVAL;
break;
default:
break;
}
- return ret ? -EINVAL : 0;
+ return 0;
}
/* fix up the cases where the ioctl direction bits are incorrect */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] staging: ion: create one device entry per heap
Instead a getting only one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.
Allocation requests will be only allowed if the mask_id
match with device minor.
Query request could be done on any of the devices.
Ion devices are parentless so it is need to add platform_bus as
parent and platform_bus_type as bus to be put in /sys/device/paltform.
Those two parameters need platform_device.h to be included but
include files weren't in alphabetic order so I reorder them correctly.
Signed-off-by: Benjamin Gaignard
---
drivers/staging/android/TODO| 1 -
drivers/staging/android/ion/Kconfig | 7 +
drivers/staging/android/ion/ion-ioctl.c | 18 +--
drivers/staging/android/ion/ion.c | 53 ++---
drivers/staging/android/ion/ion.h | 15 --
5 files changed, 79 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 5f14247..d770ffa 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -9,7 +9,6 @@ TODO:
ion/
- Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
involve putting appropriate bindings in a memory node for Ion to find.
- - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
- Better test framework (integration with VGEM was suggested)
Please send patches to Greg Kroah-Hartman and Cc:
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index a517b2d..cb4666e 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,13 @@ menuconfig ION
If you're not using Android its probably safe to
say N here.
+config ION_LEGACY_DEVICE_API
+ bool "Keep using Ion legacy misc device API"
+ depends on ION
+ help
+ Choose this option to keep using Ion legacy misc device API
+ i.e. /dev/ion
+
config ION_SYSTEM_HEAP
bool "Ion system heap"
depends on ION
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index e26b786..bb5c77b 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -25,7 +25,8 @@ union ion_ioctl_arg {
struct ion_heap_query query;
};
-static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
+static int validate_ioctl_arg(struct file *filp,
+ unsigned int cmd, union ion_ioctl_arg *arg)
{
switch (cmd) {
case ION_IOC_HEAP_QUERY:
@@ -34,6 +35,19 @@ static int validate_ioctl_arg(unsigned int cmd, union
ion_ioctl_arg *arg)
arg->query.reserved2 )
return -EINVAL;
break;
+
+ case ION_IOC_ALLOC:
+ {
+ int mask = 1 << iminor(filp->f_inode);
+
+#ifdef CONFIG_ION_LEGACY_DEVICE_API
+ if (imajor(filp->f_inode) == MISC_MAJOR)
+ return 0;
+#endif
+ if (!(arg->allocation.heap_id_mask & mask))
+ return -EINVAL;
+ break;
+ }
default:
break;
}
@@ -69,7 +83,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
return -EFAULT;
- ret = validate_ioctl_arg(cmd, &data);
+ ret = validate_ioctl_arg(filp, cmd, &data);
if (WARN_ON_ONCE(ret))
return ret;
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 93e2c90..dd66f55 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -15,31 +15,35 @@
*
*/
+#include
+#include
#include
+#include
#include
+#include
#include
#include
#include
-#include
+#include
#include
#include
#include
#include
-#include
#include
#include
+#include
#include
-#include
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
#include "ion.h"
+#define ION_DEV_MAX 32
+#define ION_NAME "ion"
+
static struct ion_device *internal_dev;
static int heap_id;
@@ -537,15 +541,30 @@ static int debug_shrink_get(void *data, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
-void ion_device_add_heap(struct ion_heap *heap)
+int ion_device_add_heap(struct ion_heap *heap)
{
struct dentry *debug_file;
struct ion_device *dev = internal_dev;
+ int ret = 0;
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
__func__);
+ if (heap_id >= ION_DEV_MAX)
+
[Bug 103384] [UBUNTU 16.04] Poor performance after update video-driver (HD7790, radeonsi)
https://bugs.freedesktop.org/show_bug.cgi?id=103384 --- Comment #2 from Max --- (In reply to Michel Dänzer from comment #1) > Which components did you update exactly, from which version to which? Probably: vmlinuz-4.4.0-83-generic -> vmlinuz-4.4.0-87-generic (and all new, include 4.10.x) Precisely: Mesa 17.2 (latest build) -> Mesa 17.3 I do not remember precisely what were updated components together with specified. Really performance is VERY LOW!!! In 3D and some 2D. ... Also i have built-in video core in AMD 790GX chipset: HD3300,but his always disabled. Whether the driver two of these video cards at the same time can involve and work? HD3300 for 2D, and HD7790 for 3D??? -- 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 102809] Rust shadows(?) flash random colours
https://bugs.freedesktop.org/show_bug.cgi?id=102809 Nicolai Hähnle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Nicolai Hähnle --- commit f9ccfda9bc8166f833fdb64adf1eca5b8ee69251 Author: Nicolai Hähnle Date: Thu Oct 12 11:21:26 2017 +0200 amd/common/gfx9: workaround DCC corruption more conservatively Fixes KHR-GL45.texture_swizzle.smoke and others on Vega. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102809 Cc: mesa-sta...@lists.freedesktop.org Reviewed-by: Marek Olšák -- 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 196247] AMD FirePro W5130M - Radeon driver - ring 0 stalled
https://bugzilla.kernel.org/show_bug.cgi?id=196247 --- Comment #5 from Michel Dänzer (mic...@daenzer.net) --- What was the newest kernel version where this didn't happen? Can you bisect between that and the oldest version where it first happened? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103384] [UBUNTU 16.04] Poor performance after update video-driver (HD7790, radeonsi)
https://bugs.freedesktop.org/show_bug.cgi?id=103384 --- Comment #3 from Michel Dänzer --- Please attach the Xorg log file. -- 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/i915/gvt: Clean up dead code in cmd_parser
Thanks, applied! :)
On 10/16/17 06:32, Christos Gkekas wrote:
Delete variables 'gma_bottom' that are set but never used.
Signed-off-by: Christos Gkekas
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 2c0ccbb..d75ce70 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2511,7 +2511,7 @@ static int command_scan(struct parser_exec_state *s,
static int scan_workload(struct intel_vgpu_workload *workload)
{
- unsigned long gma_head, gma_tail, gma_bottom;
+ unsigned long gma_head, gma_tail;
struct parser_exec_state s;
int ret = 0;
@@ -2521,7 +2521,6 @@ static int scan_workload(struct intel_vgpu_workload *workload)
gma_head = workload->rb_start + workload->rb_head;
gma_tail = workload->rb_start + workload->rb_tail;
- gma_bottom = workload->rb_start + _RING_CTL_BUF_SIZE(workload->rb_ctl);
s.buf_type = RING_BUFFER_INSTRUCTION;
s.buf_addr_type = GTT_BUFFER;
@@ -2557,7 +2556,7 @@ static int scan_workload(struct intel_vgpu_workload
*workload)
static int scan_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
{
- unsigned long gma_head, gma_tail, gma_bottom, ring_size, ring_tail;
+ unsigned long gma_head, gma_tail, ring_size, ring_tail;
struct parser_exec_state s;
int ret = 0;
struct intel_vgpu_workload *workload = container_of(wa_ctx,
@@ -2573,7 +2572,6 @@ static int scan_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
PAGE_SIZE);
gma_head = wa_ctx->indirect_ctx.guest_gma;
gma_tail = wa_ctx->indirect_ctx.guest_gma + ring_tail;
- gma_bottom = wa_ctx->indirect_ctx.guest_gma + ring_size;
s.buf_type = RING_BUFFER_INSTRUCTION;
s.buf_addr_type = GTT_BUFFER;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: use ARRAY_SIZE
Thanks, applied!
On 10/16/17 10:32, Jérémy Lefaure wrote:
Using the ARRAY_SIZE macro improves the readability of the code. Also,
it's useless to use a variable to store this constant calculated at
compile time.
Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
(sizeof(E)@p /sizeof(*E))
|
(sizeof(E)@p /sizeof(E[...]))
|
(sizeof(E)@p /sizeof(T))
)
Signed-off-by: Jérémy Lefaure
---
This patch was part of a bigger patch [1].
[1]: https://patchwork.kernel.org/patch/9979843/
drivers/gpu/drm/i915/gvt/vgpu.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 02c61a1ad56a..b32c1c889ea8 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -31,6 +31,7 @@
*
*/
+#include
#include "i915_drv.h"
#include "gvt.h"
#include "i915_pvinfo.h"
@@ -98,7 +99,6 @@ static struct {
*/
int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
{
- unsigned int num_types;
unsigned int i, low_avail, high_avail;
unsigned int min_low;
@@ -116,15 +116,14 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
*/
low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
- num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
- gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),
-GFP_KERNEL);
+ gvt->types = kzalloc(ARRAY_SIZE(vgpu_types) *
+sizeof(struct intel_vgpu_type), GFP_KERNEL);
if (!gvt->types)
return -ENOMEM;
min_low = MB_TO_BYTES(32);
- for (i = 0; i < num_types; ++i) {
+ for (i = 0; i < ARRAY_SIZE(vgpu_types); ++i) {
if (low_avail / vgpu_types[i].low_mm == 0)
break;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/framebuffer: Add framebuffer debugfs file
Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_debugfs.c | 6 +
drivers/gpu/drm/drm_framebuffer.c | 51 +++
drivers/gpu/drm/drm_gem.c | 11 +
drivers/gpu/drm/drm_internal.h| 4 +++
4 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c1807d5754b2..550f29de6c1f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
}
+ ret = drm_framebuffer_debugfs_init(minor);
+ if (ret) {
+ DRM_ERROR("Failed to create framebuffer debugfs file\n");
+ return ret;
+ }
+
if (dev->driver->debugfs_init) {
ret = dev->driver->debugfs_init(minor);
if (ret) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index af279844d7ce..ebdfe2b5689f 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -25,7 +25,9 @@
#include
#include
#include
+#include
+#include "drm_internal.h"
#include "drm_crtc_internal.h"
/**
@@ -955,3 +957,52 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
}
EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+#ifdef CONFIG_DEBUG_FS
+static void drm_framebuffer_print(struct drm_framebuffer *fb,
+ struct drm_printer *p)
+{
+ unsigned int i;
+
+ drm_printf(p, "[FB:%d] %dx%d@%4.4s refcount=%d\n", fb->base.id,
+ fb->width, fb->height, (char *)&fb->format->format,
+ drm_framebuffer_read_refcount(fb));
+
+ for (i = 0; i < fb->format->num_planes; i++) {
+ drm_printf(p, "\t%u: offset=%d pitch=%d",
+ i, fb->offsets[i], fb->pitches[i]);
+ if (fb->obj[i]) {
+ drm_printf(p, " GEM: ");
+ drm_gem_print(fb->obj[i], p);
+ } else {
+ drm_printf(p, "\n");
+ }
+ }
+}
+
+static int drm_framebuffer_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct drm_framebuffer *fb;
+
+ mutex_lock(&dev->mode_config.fb_lock);
+ drm_for_each_fb(fb, dev)
+ drm_framebuffer_print(fb, &p);
+ mutex_unlock(&dev->mode_config.fb_lock);
+
+ return 0;
+}
+
+static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
+ { "framebuffer", drm_framebuffer_info, 0 },
+};
+
+int drm_framebuffer_debugfs_init(struct drm_minor *minor)
+{
+ return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+ ARRAY_SIZE(drm_framebuffer_debugfs_list),
+ minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 55d6182555c7..f42977b28701 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "drm_internal.h"
/** @file drm_gem.c
@@ -1040,3 +1041,13 @@ int drm_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return ret;
}
EXPORT_SYMBOL(drm_gem_mmap);
+
+#ifdef CONFIG_DEBUG_FS
+void drm_gem_print(const struct drm_gem_object *obj, struct drm_printer *p)
+{
+ drm_printf(p, "name=%d refcount=%d start=%08lx size=%zu%s\n",
+ obj->name, kref_read(&obj->refcount),
+ drm_vma_node_start(&obj->vma_node), obj->size,
+ obj->import_attach ? " (imported)" : "");
+}
+#endif
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index fbc3f308fa19..7f4564419bf4 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -106,6 +106,7 @@ int drm_gem_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void drm_gem_open(struct drm_device *dev, struct drm_file *file_private);
void drm_gem_release(struct drm_device *dev, struct drm_file *file_private);
+void drm_gem_print(const struct drm_gem_object *obj, struct drm_printer *p);
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
@@ -173,3 +174,6 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+
+/* drm_framebuffer.c */
+int drm_framebuffer_debugfs_init(struct drm_minor *minor);
--
2.14.2
_
[Bug 100666] amdgpu coolers never stoping linux
https://bugs.freedesktop.org/show_bug.cgi?id=100666 --- Comment #7 from Lucas Riutzel --- Dimitrios, Good to know. Looks like my short term solution became a long term one. I unplugged the builtin fan and ziptied on another fan and connected it to a motherboard fan header. I might come back and extend the original fan header to reach the motherboard. -- 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 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #26 from fin4...@hotmail.com --- Milo, try to set amdgpu.audio=0 to the kernel command line. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: Improve unlocking of a mutex in etnaviv_iommu_map_gem()
From: Markus Elfring
Date: Mon, 23 Oct 2017 21:27:30 +0200
Add a jump target so that a call of the function "mutex_unlock" is stored
only once at the end of this function implementation.
Replace three calls by goto statements.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index f103e787de94..9b0d797349d4 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -221,18 +221,16 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
if (iova < 0x8000 - sg_dma_len(sgt->sgl)) {
mapping->iova = iova;
list_add_tail(&mapping->mmu_node, &mmu->mappings);
- mutex_unlock(&mmu->lock);
- return 0;
+ ret = 0;
+ goto unlock;
}
}
node = &mapping->vram_node;
ret = etnaviv_iommu_find_iova(mmu, node, etnaviv_obj->base.size);
- if (ret < 0) {
- mutex_unlock(&mmu->lock);
- return ret;
- }
+ if (ret < 0)
+ goto unlock;
mmu->last_iova = node->start + etnaviv_obj->base.size;
mapping->iova = node->start;
@@ -242,13 +240,12 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
if (ret < 0) {
drm_mm_remove_node(node);
- mutex_unlock(&mmu->lock);
- return ret;
+ goto unlock;
}
list_add_tail(&mapping->mmu_node, &mmu->mappings);
mmu->need_flush = true;
+unlock:
mutex_unlock(&mmu->lock);
-
return ret;
}
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91221] UVD: GPU lockup with BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=91221 --- Comment #3 from jancoow --- I'm facing the same issue: AMD XFX HD6850 Black Edition Intel I3 3550 If I remove the vdaup packages playblack is smootly. But when i'm trying to use video acceleration it's choppy and eventually crash my desktop. -- 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 91221] UVD: GPU lockup with BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=91221 --- Comment #4 from jancoow --- Dmesg info: [ 52.191082] [drm:btc_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed [ 112.173163] radeon :01:00.0: ring 0 stalled for more than 10283msec [ 112.173171] radeon :01:00.0: GPU lockup (current fence id 0x4009 last fence id 0x401e on ring 0) [ 112.468609] radeon :01:00.0: couldn't schedule ib [ 112.468627] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD (-22)! [ 112.469664] radeon :01:00.0: Saved 695 dwords of commands on ring 0. [ 112.469674] radeon :01:00.0: GPU softreset: 0x0088 [ 112.469675] radeon :01:00.0: GRBM_STATUS = 0xA0003828 [ 112.469676] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 112.469677] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 112.469678] radeon :01:00.0: SRBM_STATUS = 0x200840C0 [ 112.469679] radeon :01:00.0: SRBM_STATUS2 = 0x [ 112.469680] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 112.469681] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 [ 112.469682] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 [ 112.469683] radeon :01:00.0: R_008680_CP_STAT = 0x80010243 [ 112.469684] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 112.501078] radeon :01:00.0: GRBM_SOFT_RESET=0x4001 [ 112.501130] radeon :01:00.0: SRBM_SOFT_RESET=0x8100 [ 112.502283] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 112.502284] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 112.502285] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 112.502286] radeon :01:00.0: SRBM_STATUS = 0x200800C0 [ 112.502287] radeon :01:00.0: SRBM_STATUS2 = 0x [ 112.502288] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 112.502289] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 112.502290] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 112.502291] radeon :01:00.0: R_008680_CP_STAT = 0x [ 112.502292] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 112.502302] radeon :01:00.0: GPU reset succeeded, trying to resume [ 112.526119] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 112.528665] [drm] PCIE GART of 1024M enabled (table at 0x00162000). [ 112.528756] radeon :01:00.0: WB enabled [ 112.528757] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x97f5155a1c00 [ 112.528758] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x97f5155a1c0c [ 112.529503] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xbb7702c32118 [ 112.545920] [drm] ring test on 0 succeeded in 3 usecs [ 112.545930] [drm] ring test on 3 succeeded in 7 usecs [ 112.723049] [drm] ring test on 5 succeeded in 2 usecs [ 112.723057] [drm] UVD initialized successfully. [ 113.879790] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out. [ 113.879818] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110). [ 114.346545] radeon :01:00.0: couldn't schedule ib [ 114.346562] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD (-22)! [ 114.347615] radeon :01:00.0: GPU softreset: 0x0088 [ 114.347616] radeon :01:00.0: GRBM_STATUS = 0xA0003828 [ 114.347617] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 114.347618] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 114.347619] radeon :01:00.0: SRBM_STATUS = 0x200040C0 [ 114.347620] radeon :01:00.0: SRBM_STATUS2 = 0x [ 114.347621] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 114.347622] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 [ 114.347623] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 [ 114.347624] radeon :01:00.0: R_008680_CP_STAT = 0x80010243 [ 114.347625] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 114.361570] radeon_dp_aux_transfer_native: 190 callbacks suppressed [ 114.362412] rfkill: input handler enabled [ 114.373793] radeon :01:00.0: GRBM_SOFT_RESET=0x4001 [ 114.373845] radeon :01:00.0: SRBM_SOFT_RESET=0x8100 [ 114.374998] radeon :01:00.0: GRBM_STATUS = 0x3828 [ 114.374999] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0007 [ 114.375000] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0007 [ 114.375001] radeon :01:00.0: SRBM_STATUS = 0x20C0 [ 114.375002] radeon :01:00.0: SRBM_STATU
Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file
On Mon, Oct 23, 2017 at 9:47 AM, Noralf Trønnes wrote:
> Add debugfs file that dumps info about the framebuffers and its planes.
> Also dump info about any connected gem object(s).
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_debugfs.c | 6 +
> drivers/gpu/drm/drm_framebuffer.c | 51
> +++
> drivers/gpu/drm/drm_gem.c | 11 +
> drivers/gpu/drm/drm_internal.h| 4 +++
> 4 files changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index c1807d5754b2..550f29de6c1f 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> }
> }
>
> + ret = drm_framebuffer_debugfs_init(minor);
> + if (ret) {
> + DRM_ERROR("Failed to create framebuffer debugfs file\n");
> + return ret;
> + }
> +
> if (dev->driver->debugfs_init) {
> ret = dev->driver->debugfs_init(minor);
> if (ret) {
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index af279844d7ce..ebdfe2b5689f 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -25,7 +25,9 @@
> #include
> #include
> #include
> +#include
>
> +#include "drm_internal.h"
> #include "drm_crtc_internal.h"
>
> /**
> @@ -955,3 +957,52 @@ int drm_framebuffer_plane_height(int height,
> return fb_plane_height(height, fb->format, plane);
> }
> EXPORT_SYMBOL(drm_framebuffer_plane_height);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static void drm_framebuffer_print(struct drm_framebuffer *fb,
> + struct drm_printer *p)
> +{
> + unsigned int i;
> +
> + drm_printf(p, "[FB:%d] %dx%d@%4.4s refcount=%d\n", fb->base.id,
> + fb->width, fb->height, (char *)&fb->format->format,
> + drm_framebuffer_read_refcount(fb));
Could you print the format modifier as well?
> +
> + for (i = 0; i < fb->format->num_planes; i++) {
> + drm_printf(p, "\t%u: offset=%d pitch=%d",
> + i, fb->offsets[i], fb->pitches[i]);
> + if (fb->obj[i]) {
> + drm_printf(p, " GEM: ");
> + drm_gem_print(fb->obj[i], p);
> + } else {
> + drm_printf(p, "\n");
> + }
> + }
> +}
> +
> +static int drm_framebuffer_info(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct drm_framebuffer *fb;
> +
> + mutex_lock(&dev->mode_config.fb_lock);
> + drm_for_each_fb(fb, dev)
> + drm_framebuffer_print(fb, &p);
> + mutex_unlock(&dev->mode_config.fb_lock);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
> + { "framebuffer", drm_framebuffer_info, 0 },
This is quite useful, thanks. Ultimately, it would be very nice to
have something like i915_display_info, but in a generic way. There's
not much there that's actually i915 specific:
localhost ~ # cat /sys/kernel/debug/dri/0/i915_display_info
CRTC info
-
CRTC 36: pipe: A, active=yes, (size=2400x1600), dither=no, bpp=24
fb: 88, pos: 0x0, size: 2400x1600
encoder 57: type: TMDS-57, connectors:
connector 58: type: eDP-1, status: connected, mode:
id 0:"2400x1600" freq 60 clock 252750 hdisp 2400 hss
2448 hse 2480 htot 2560 vdisp 1600 vss 1603 vse 1613 vtot 1646 type
0x48 flags 0xa
cursor visible? no, position (0, 0), size 0x0, addr
0x, active? no
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]:
use=no, mode=0, scalers[1]: use=no, mode=0
--Plane id 27: type=PRI, crtc_pos= 0x 0,
crtc_size=2400x1600, src_pos=0.x0.,
src_size=2400.x1600., format=XR24 little-endian (0x34325258),
rotation=0 (0x0001)
--Plane id 30: type=OVL, crtc_pos= 0x 0, crtc_size= 0x
0, src_pos=0.x0., src_size=0.x0., format=N/A,
rotation=0 (0x0001)
--Plane id 33: type=CUR, crtc_pos= 0x 0, crtc_size= 0x
0, src_pos=0.x0., src_size=0.x0., format=N/A,
rotation=0 (0x0001)
underrun reporting: cpu=yes pch=yes
CRTC 46: pipe: B, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
Connector info
--
connector 58: type eDP-1, status: connected
name:
physical dimensions: 260x170mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 12
audio support: no
fixed mo
Re: [PATCH v4 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
On Fri, Oct 20, 2017 at 09:49:22AM +0200, Boris Brezillon wrote:
> Document the bindings used for the Cadence DSI bridge.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi Rob,
>
> I dropped your A-b because two important things changed in this
> version:
> * the clk names have changed (they are now prefixed with dsi_)
> * compatible no longer contains the IP version
>
> Feel free to add it back.
>
> Regards,
>
> Boris
>
> Changes in v4:
> - Rename DSI clks (suggested by Tomi)
> - Drop the IP version in the compatible since it can be extracted from
> a register (suggested by Andrzej)
>
> Changes in v3:
> - Fix clock names in the example
> - Document how to represent DSI devices that are controller through
> an external bus like I2C or SPI
>
> Changes in v2:
> - None
> ---
> .../bindings/display/bridge/cdns,dsi.txt | 109
> +
> 1 file changed, 109 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> new file mode 100644
> index ..50bb3189f2ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
> @@ -0,0 +1,109 @@
> +Cadence DSI bridge
> +==
> +
> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
> +
> +Required properties:
> +- compatible: should be set to "cdns,dsi".
> +- reg: physical base address and length of the controller's registers.
> +- interrupts: interrupt line connected to the DSI bridge.
> +- clocks: DSI bridge clocks.
> +- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
> +- phys: phandle link to the MIPI D-PHY controller.
> +- phy-names: must contain "dphy".
> +- #address-cells: must be set to 1.
> +- #size-cells: must be set to 0.
> +
> +Required subnodes:
> +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
> + 2 ports are available:
> + * port 0: this port is only needed if some of your DSI devices are
> + controlled through an external bus like I2C or SPI. Can have at
> + most 4 endpoints. The endpoint number is directly encoding the
> + DSI virtual channel used by this device.
> + * port 1: represents the DPI input.
> + Other ports will be added later to support the new kind of inputs.
> +
> +- one subnode per DSI device connected on the DSI bus. Each DSI device should
> + contain a reg property encoding its virtual channel.
> +
> +Example:
> +
> + dsi0: dsi@fd0c {
> + compatible = "cdns,dsi-1.3.1";
> + reg = <0x0 0xfd0c 0x0 0x1000>;
> + clocks = <&pclk>, <&sysclk>;
> + clock-names = "dsi_p_clk", "dsi_sys_clk";
> + interrupts = <1>;
> + phys = <&dphy1>;
> + phy-names = "dphy";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + dsi0_dpi_input: endpoint {
> + remote-endpoint = <&xxx_dpi_output>;
> + };
> + };
> + };
> +
> + panel: dsi-dev@0 {
> + compatible = "";
> + reg = <0>;
> + };
> + };
> +
> +or
> +
> + dsi0: dsi@fd0c {
> + compatible = "cdns,dsi";
> + reg = <0x0 0xfd0c 0x0 0x1000>;
> + clocks = <&pclk>, <&sysclk>;
> + clock-names = "sys_p_clk", "dsi_sys_clk";
Needs updating?
With that,
Acked-by: Rob Herring
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/framebuffer: Add framebuffer debugfs file
Hi Noralf,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.14-rc6 next-20171018]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Noralf-Tr-nnes/drm-framebuffer-Add-framebuffer-debugfs-file/20171024-054910
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-x001-201743 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_gem.c: In function 'drm_gem_print':
>> drivers/gpu/drm/drm_gem.c:1050:25: warning: passing argument 1 of
>> 'drm_vma_node_start' discards 'const' qualifier from pointer target type
>> [-Wdiscarded-qualifiers]
drm_vma_node_start(&obj->vma_node), obj->size,
^
In file included from drivers/gpu/drm/drm_gem.c:41:0:
include/drm/drm_vma_manager.h:155:29: note: expected 'struct
drm_vma_offset_node *' but argument is of type 'const struct
drm_vma_offset_node *'
static inline unsigned long drm_vma_node_start(struct drm_vma_offset_node
*node)
^~
vim +1050 drivers/gpu/drm/drm_gem.c
1044
1045 #ifdef CONFIG_DEBUG_FS
1046 void drm_gem_print(const struct drm_gem_object *obj, struct drm_printer
*p)
1047 {
1048 drm_printf(p, "name=%d refcount=%d start=%08lx size=%zu%s\n",
1049 obj->name, kref_read(&obj->refcount),
> 1050 drm_vma_node_start(&obj->vma_node), obj->size,
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: display: amlogic, meson-vpu: Add optional power domain property
On Tue, Oct 17, 2017 at 10:07:41AM +0200, Neil Armstrong wrote: > The Video Processing Unit power domain was setup by the Vendor U-Boot, > add support for an optional Power Domain phandle to setup it from the kernel. > > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt | 4 > 1 file changed, 4 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: amlogic, meson-dw-hdmi: Add optional HDMI 5V regulator
On Tue, Oct 17, 2017 at 10:07:42AM +0200, Neil Armstrong wrote: > On reference boards and derivatives, the HDMI Logic is powered by an external > 5V regulator. > This regulator was set by the Vendor U-Boot, add optional support for it. > > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt > b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt > index 7f040ed..bf4a180 100644 > --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt > +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt > @@ -48,6 +48,10 @@ Required properties: >Documentation/devicetree/bindings/reset/reset.txt, >the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy" > > +Optional properties: > +- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI > + logic, as described in the file ../regulator/regulator.txt 5V into a modern SoC sounds strange. Is this really for the chip or for 5V to the connector? The latter should be in the connector node. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103408] [bisected] frames dropped during video replay due to "add hardware_planes_only to list of affected planes"
https://bugs.freedesktop.org/show_bug.cgi?id=103408 --- Comment #1 from dwagner --- Created attachment 135018 --> https://bugs.freedesktop.org/attachment.cgi?id=135018&action=edit 1-minute test video, smooth horizontal pan in 3840x2160 23.976 fps For more convenient reproducability, I created and attached a one-minute sample video file, which just contains a smooth horizontal pan over big letters. When I replay this file with the defect, about 7 frames are dropped, easily spottable as harsh temporary stops in the normally smooth scrolling. -- 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 4/4] dt-bindings: display: msm: update clk names
On Tue, Oct 17, 2017 at 06:49:58AM -0400, Rob Clark wrote: > Now that drm/msm is converted over to use msm_get_clk() everywhere (that > matters), which handles falling back to looking for a clock with the > "_clk" suffix, we can remove "_clk" from the documentation so that new > dts files added do not include "_clk" in the name. > > Previously we were doing this for the more recently upstreamed bindings > but not for (nearly) all. > > Signed-off-by: Rob Clark > --- > .../devicetree/bindings/display/msm/dsi.txt| 36 > +++--- > .../devicetree/bindings/display/msm/edp.txt| 20 ++-- > .../devicetree/bindings/display/msm/hdmi.txt | 8 ++--- > .../devicetree/bindings/display/msm/mdp5.txt | 32 +-- > 4 files changed, 48 insertions(+), 48 deletions(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91221] UVD: GPU lockup with BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=91221 --- Comment #5 from Chí-Thanh Christopher Nguyễn --- As suggested by iive on #radeon, I tried to set R600_DEBUG=nodma and while the problem still happens, the time to trigger the problem increases considerably from a few minutes to 15 minutes or more. -- 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 v3 7/9] drm/exynos: Add driver for Exynos Scaler module
On Tue, Oct 17, 2017 at 01:07:50PM +0200, Marek Szyprowski wrote: > From: Andrzej Pietrasiewicz > > Exynos Scaler is a hardware module, which processes graphic data fetched > from memory and transfers the resultant dato another memory buffer. > Graphics data can be up/down-scaled, rotated, flipped and converted color > space. Scaler hardware modules are a part of Exynos5420 and newer Exynos > SoCs. > > Signed-off-by: Andrzej Pietrasiewicz > Signed-off-by: Marek Szyprowski > --- > .../devicetree/bindings/gpu/samsung-scaler.txt | 26 + In the future, please split bindings to separate patches. Acked-by: Rob Herring > drivers/gpu/drm/exynos/Kconfig | 6 + > drivers/gpu/drm/exynos/Makefile| 1 + > drivers/gpu/drm/exynos/exynos_drm_drv.c| 3 + > drivers/gpu/drm/exynos/exynos_drm_drv.h| 1 + > drivers/gpu/drm/exynos/exynos_drm_ipp.h| 4 + > drivers/gpu/drm/exynos/exynos_drm_scaler.c | 717 > + > drivers/gpu/drm/exynos/regs-scaler.h | 426 > 8 files changed, 1184 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpu/samsung-scaler.txt > create mode 100644 drivers/gpu/drm/exynos/exynos_drm_scaler.c > create mode 100644 drivers/gpu/drm/exynos/regs-scaler.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] drm: exynos: Add driver for HDMI audio interface
Merged.
Thanks,
Inki Dae
2017년 10월 23일 21:49에 Sylwester Nawrocki 이(가) 쓴 글:
> The hdmi-codec interface added in this patch is required to properly
> support HDMI audio. Currently the audio part of the SoC internal
> HDMI transmitter is configured with fixed values, which makes HDMI
> audio working by chance, only on boards having an external audio
> codec connected in parallel with the HDMI audio transmitter's input
> I2S interface.
>
> Signed-off-by: Sylwester Nawrocki
> Reviewed-by: Andrzej Hajda
>
> ---
> Changes since v3:
> - removed unregister_audio_device() function, added missing
>audio platform device unregistration in probe(),
> - 'enable' field in struct hdmi_audio replace with 'mute',
> - audio infoframe initialization moved from the bind()
>callback to probe().
>
> Changes since v2:
> - u8 replaced with bool type,
> - the HDMI codec iec.status data used directly for setting up
>the HDMI controller registers rather than using hard coded
>constants,
> - constants used for configuring the HDMI_AUI_CON register
>instead of plain numbers,
> - if/IS_ERR/return replaced with PTR_ERR_OR_ZERO().
>
> Changes since v1:
> - rebased onto v4.14-rc1 and adapted locking
>
> Changes since RFC version:
> - fixed hdmi-codec locking issue
> - added a comment documenting struct hdmi_contex::mutex
> ---
> drivers/gpu/drm/exynos/Kconfig | 1 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 250
> ++-
> drivers/gpu/drm/exynos/regs-hdmi.h | 8 +-
> 3 files changed, 194 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 305dc3d4ff77..5a7c9d8abd6b 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -3,6 +3,7 @@ config DRM_EXYNOS
> depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS ||
> ARCH_MULTIPLATFORM)
> select DRM_KMS_HELPER
> select VIDEOMODE_HELPERS
> + select SND_SOC_HDMI_CODEC if SND_SOC
> help
> Choose this option if you have a Samsung SoC EXYNOS chipset.
> If M is selected the module will be called exynosdrm.
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 1309b1c9e074..82d1b7e2febe 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -40,7 +40,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
>
> #include
> @@ -111,12 +111,18 @@ struct hdmi_driver_data {
> struct string_array_spec clk_muxes;
> };
>
> +struct hdmi_audio {
> + struct platform_device *pdev;
> + struct hdmi_audio_infoframe infoframe;
> + struct hdmi_codec_paramsparams;
> + boolmute;
> +};
> +
> struct hdmi_context {
> struct drm_encoder encoder;
> struct device *dev;
> struct drm_device *drm_dev;
> struct drm_connectorconnector;
> - boolpowered;
> booldvi_mode;
> struct delayed_work hotplug_work;
> struct cec_notifier *notifier;
> @@ -136,6 +142,11 @@ struct hdmi_context {
> struct regulator*reg_hdmi_en;
> struct exynos_drm_clk phy_clk;
> struct drm_bridge *bridge;
> +
> + /* mutex protecting subsequent fields below */
> + struct mutexmutex;
> + struct hdmi_audio audio;
> + boolpowered;
> };
>
> static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -776,6 +787,22 @@ static int hdmi_clk_set_parents(struct hdmi_context
> *hdata, bool to_phy)
> return ret;
> }
>
> +static int hdmi_audio_infoframe_apply(struct hdmi_context *hdata)
> +{
> + struct hdmi_audio_infoframe *infoframe = &hdata->audio.infoframe;
> + u8 buf[HDMI_INFOFRAME_SIZE(AUDIO)];
> + int len;
> +
> + len = hdmi_audio_infoframe_pack(infoframe, buf, sizeof(buf));
> + if (len < 0)
> + return len;
> +
> + hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
> + hdmi_reg_write_buf(hdata, HDMI_AUI_HEADER0, buf, len);
> +
> + return 0;
> +}
> +
> static void hdmi_reg_infoframes(struct hdmi_context *hdata)
> {
> struct drm_display_mode *m = &hdata->encoder.crtc->state->mode;
> @@ -812,15 +839,7 @@ static void hdmi_reg_infoframes(struct hdmi_context
> *hdata)
> hdmi_reg_write_buf(hdata, HDMI_VSI_DATA(0), buf + 3, ret - 3);
> }
>
> - ret = hdmi_audio_infoframe_init(&frm.audio);
> - if (!ret) {
> - frm.audio.channels = 2;
> - ret = hdmi_audio_infoframe_pack(&frm.audio, buf, sizeof(buf));
> - }
> - if (ret > 0) {
> - hdmi_reg_writeb(hdata, HDMI_AUI_CON, HDMI_AUI_CON_EVERY_VSYNC);
> -
Re: [PATCH v6 1/2] drm_fourcc: Add new P010, P016 video format
On 10/17/2017 02:43 PM, ayaka wrote:
On 10/12/2017 07:56 PM, Tapani Pälli wrote:
Is this one going to land soon? The discussion was a bit hard to read
but it looks like in the end consensus was that everything looks good
in this patch.
I am very sorry, I am too busy with the other dma problem in rockchip.
The main problem is that none of the driver have used those format.
Although the rockchip vop supports 10 bit pixel format but not the p010.
OK no worries, I thought these formats are already used by some driver.
Thanks;
On 03/01/2017 01:21 AM, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info
*__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY, .depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes
= 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_P010, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h
b/include/uapi/drm/drm_fourcc.h
index ef20abb..762646d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /*
2x2 subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /*
2x2 subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /*
2x2 subsampled Cr:Cb plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 --- Comment #10 from Luc --- Well, we have solved it in our software now. The question concerning if this case may be closed or not boils down to following question: Performing a texture upload on a texture ID while it is being rendered (drawn) should this potentially lead to a crash? Under such case I would expect to detect tearing yes, but in my opinion it should not crash I let the mesa3d team decide, as we solved it by adapting our code. -- 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
