[RFC 4/7] drm/omap: Separate the dssdevs array setup from the connect function
In order to ease up on the logic, break the current code to gather the
dssdevs:
first get all available dssdevs, then call connect on each dssdev. As the
last step remove the dssdevs which failed to connect from the available
dssdev list.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 54 --
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index b089604e871c..32dc0e88220f 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -162,34 +162,60 @@ static void omap_disconnect_dssdevs(struct drm_device
*ddev)
priv->num_dssdevs = 0;
}
-static int omap_connect_dssdevs(struct drm_device *ddev)
+static void omap_collect_dssdevs(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
struct omap_dss_device *dssdev = NULL;
- int r;
+
+ for_each_dss_dev(dssdev) {
+ omap_dss_get_device(dssdev);
+ priv->dssdevs[priv->num_dssdevs++] = dssdev;
+ if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ /* To balance the 'for_each_dss_dev' loop */
+ omap_dss_put_device(dssdev);
+ break;
+ }
+ }
+}
+
+static int omap_connect_dssdevs(struct drm_device *ddev)
+{
+ struct omap_drm_private *priv = ddev->dev_private;
+ u32 working = 0;
+ int r, i, j;
if (!omapdss_stack_is_ready())
return -EPROBE_DEFER;
- for_each_dss_dev(dssdev) {
+ omap_collect_dssdevs(ddev);
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
+
r = dssdev->driver->connect(dssdev);
- if (r == -EPROBE_DEFER) {
- omap_dss_put_device(dssdev);
+ if (r == -EPROBE_DEFER)
goto cleanup;
- } else if (r) {
+ else if (r)
dev_warn(dssdev->dev, "could not connect display: %s\n",
- dssdev->name);
+dssdev->name);
+ else
+ working |= BIT(i);
+ }
+
+ /* Remove the dssdevs if their connect failed */
+ j = 0;
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ if (working & BIT(i)) {
+ if (j != i)
+ priv->dssdevs[j] = priv->dssdevs[i];
+ j++;
} else {
- omap_dss_get_device(dssdev);
- priv->dssdevs[priv->num_dssdevs++] = dssdev;
- if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
- /* To balance the 'for_each_dss_dev' loop */
- omap_dss_put_device(dssdev);
- break;
- }
+ omap_dss_put_device(priv->dssdevs[i]);
}
}
+ priv->num_dssdevs = j;
+
return 0;
cleanup:
--
2.14.1
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
[RFC 3/7] drm/omap: Manage the usable omap_dss_device list within omap_drm_private
Instead of reaching back to DSS to iterate through the dss_devices every
time, use an internal array where we store the available and usable
dss_devices.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 95 +++---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++
2 files changed, 62 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index bd7fe317a365..b089604e871c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -146,18 +146,27 @@ static int get_connector_type(struct omap_dss_device
*dssdev)
}
}
-static void omap_disconnect_dssdevs(void)
+static void omap_disconnect_dssdevs(struct drm_device *ddev)
{
- struct omap_dss_device *dssdev = NULL;
+ struct omap_drm_private *priv = ddev->dev_private;
+ int i;
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
- for_each_dss_dev(dssdev)
dssdev->driver->disconnect(dssdev);
+ priv->dssdevs[i] = NULL;
+ omap_dss_put_device(dssdev);
+ }
+
+ priv->num_dssdevs = 0;
}
-static int omap_connect_dssdevs(void)
+static int omap_connect_dssdevs(struct drm_device *ddev)
{
- int r;
+ struct omap_drm_private *priv = ddev->dev_private;
struct omap_dss_device *dssdev = NULL;
+ int r;
if (!omapdss_stack_is_ready())
return -EPROBE_DEFER;
@@ -170,6 +179,14 @@ static int omap_connect_dssdevs(void)
} else if (r) {
dev_warn(dssdev->dev, "could not connect display: %s\n",
dssdev->name);
+ } else {
+ omap_dss_get_device(dssdev);
+ priv->dssdevs[priv->num_dssdevs++] = dssdev;
+ if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ /* To balance the 'for_each_dss_dev' loop */
+ omap_dss_put_device(dssdev);
+ break;
+ }
}
}
@@ -180,7 +197,7 @@ static int omap_connect_dssdevs(void)
* if we are deferring probe, we disconnect the devices we previously
* connected
*/
- omap_disconnect_dssdevs();
+ omap_disconnect_dssdevs(ddev);
return r;
}
@@ -205,7 +222,7 @@ static int omap_modeset_init(struct drm_device *dev)
int num_ovls = priv->dispc_ops->get_num_ovls();
int num_mgrs = priv->dispc_ops->get_num_mgrs();
int num_crtcs, crtc_idx, plane_idx;
- int ret;
+ int ret, i;
u32 plane_crtc_mask;
drm_mode_config_init(dev);
@@ -222,11 +239,7 @@ static int omap_modeset_init(struct drm_device *dev)
* configuration does not match the expectations or exceeds
* the available resources, the configuration is rejected.
*/
- num_crtcs = 0;
- for_each_dss_dev(dssdev)
- if (omapdss_device_is_connected(dssdev))
- num_crtcs++;
-
+ num_crtcs = priv->num_dssdevs;
if (num_crtcs > num_mgrs || num_crtcs > num_ovls ||
num_crtcs > ARRAY_SIZE(priv->crtcs) ||
num_crtcs > ARRAY_SIZE(priv->planes) ||
@@ -244,15 +257,13 @@ static int omap_modeset_init(struct drm_device *dev)
crtc_idx = 0;
plane_idx = 0;
- for_each_dss_dev(dssdev) {
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_plane *plane;
struct drm_crtc *crtc;
- if (!omapdss_device_is_connected(dssdev))
- continue;
-
encoder = omap_encoder_init(dev, dssdev);
if (!encoder)
return -ENOMEM;
@@ -326,11 +337,14 @@ static int omap_modeset_init(struct drm_device *dev)
/*
* Enable the HPD in external components if supported
*/
-static void omap_modeset_enable_external_hpd(void)
+static void omap_modeset_enable_external_hpd(struct drm_device *ddev)
{
- struct omap_dss_device *dssdev = NULL;
+ struct omap_drm_private *priv = ddev->dev_private;
+ int i;
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
- for_each_dss_dev(dssdev) {
if (dssdev->driver->enable_hpd)
dssdev->driver->enable_hpd(dssdev);
}
@@ -339,11 +353,14 @@ static void omap_modeset_enable_external_hpd(void)
/*
* Disable the HPD in external components if supported
*/
-static void omap_modeset_disable_external_hpd(void)
+static void omap_modeset_disable_external_hpd(struct drm_device *
[RFC 0/7] drm/omap: Module parameter for display order configuration
Hi The series adds support for changing the order of the displays defined by DT display aliases. The motivation to do such a thing is that for example the fb emulation is treating the first display/crtc as the 'main' display and will create the fb emulation based on the first display's properties. There are many custom applications using DRM directly and they assume that the first connector is the 'main' display. Afaik weston provides no means either to change the 'main/preferred' display. It should be the work of user space application (except the fb emulation) to somehow deal with the 'main' display selection for their needs, but unfortunately they are not capable of diong so for some reason. We have boards with LCD panel and HDMI for example and in DT the LCD is set as display0, but in certain useage scenarios it is desired to have the HDMI as the 'main' display instead of the LCD. With the kernel cmd line parameter it is possible to change the pre defined order without recompiling the kernel/DT. If the board have two active displays: 0 - LCD 1 - HDMI then: omapdrm.displays=0,1 - represents the original order (LCD, HDMI) omapdrm.displays=1,0 - represents reverse order (HDMI, LCD) omapdrm.displays=0 - only the LCD is enabled omapdrm.displays=1 - only the HDMI is enabled omapdrm.displays=-1 - disable all displays The first 6 patch of the series is doing some generic clean up and prepares the code so the display ordering is going to be easy to add. Regards, Peter --- Peter Ujfalusi (7): drm/omap: Use devm_kzalloc() to allocate omap_drm_private drm/omap: Allocate drm_device earlier and unref it as last step drm/omap: Manage the usable omap_dss_device list within omap_drm_private drm/omap: Separate the dssdevs array setup from the connect function drm/omap: Do dss_device (display) ordering in omap_drv.c drm/omap: dss: Remove display ordering from dss/display.c drm/omap: Add kernel parameter to specify the desired display order drivers/gpu/drm/omapdrm/dss/display.c | 15 +-- drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 - drivers/gpu/drm/omapdrm/omap_drv.c| 244 -- drivers/gpu/drm/omapdrm/omap_drv.h| 3 + 4 files changed, 183 insertions(+), 82 deletions(-) -- 2.14.1 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
[RFC 1/7] drm/omap: Use devm_kzalloc() to allocate omap_drm_private
It makes the cleanup paths a bit cleaner.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 9b3c36b48356..903510d8054e 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -548,19 +548,17 @@ static int pdev_probe(struct platform_device *pdev)
return ret;
}
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
omap_crtc_pre_init();
ret = omap_connect_dssdevs();
if (ret)
goto err_crtc_uninit;
- /* Allocate and initialize the driver private structure. */
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- ret = -ENOMEM;
- goto err_disconnect_dssdevs;
- }
-
+ /* Initialize the driver private structure. */
priv->dispc_ops = dispc_get_ops();
soc = soc_device_match(omapdrm_soc_devices);
@@ -574,7 +572,7 @@ static int pdev_probe(struct platform_device *pdev)
ddev = drm_dev_alloc(&omap_drm_driver, &pdev->dev);
if (IS_ERR(ddev)) {
ret = PTR_ERR(ddev);
- goto err_free_priv;
+ goto err_destroy_wq;
}
ddev->dev_private = priv;
@@ -624,10 +622,8 @@ static int pdev_probe(struct platform_device *pdev)
err_free_drm_dev:
omap_gem_deinit(ddev);
drm_dev_unref(ddev);
-err_free_priv:
+err_destroy_wq:
destroy_workqueue(priv->wq);
- kfree(priv);
-err_disconnect_dssdevs:
omap_disconnect_dssdevs();
err_crtc_uninit:
omap_crtc_pre_uninit();
@@ -659,7 +655,6 @@ static int pdev_remove(struct platform_device *pdev)
drm_dev_unref(ddev);
destroy_workqueue(priv->wq);
- kfree(priv);
omap_disconnect_dssdevs();
omap_crtc_pre_uninit();
--
2.14.1
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
[RFC 5/7] drm/omap: Do dss_device (display) ordering in omap_drv.c
Sort the dssdev array based on DT aliases.
With this change we can remove the panel ordering from dss/display.c and
have all sorting related to dssdevs in one place.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 32dc0e88220f..0e100a359d26 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -18,6 +18,8 @@
*/
#include
+#include
+#include
#include
#include
@@ -162,6 +164,22 @@ static void omap_disconnect_dssdevs(struct drm_device
*ddev)
priv->num_dssdevs = 0;
}
+static int omap_compare_dssdevs(const void *a, const void *b)
+{
+ const struct omap_dss_device *dssdev1 = *(struct omap_dss_device **)a;
+ const struct omap_dss_device *dssdev2 = *(struct omap_dss_device **)b;
+ int id1, id2;
+
+ id1 = of_alias_get_id(dssdev1->dev->of_node, "display");
+ id2 = of_alias_get_id(dssdev2->dev->of_node, "display");
+
+ if (id1 > id2)
+ return 1;
+ else if (id1 < id2)
+ return -1;
+ return 0;
+}
+
static void omap_collect_dssdevs(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
@@ -176,6 +194,10 @@ static void omap_collect_dssdevs(struct drm_device *ddev)
break;
}
}
+
+ /* Sort the list by DT aliases */
+ sort(priv->dssdevs, priv->num_dssdevs, sizeof(priv->dssdevs[0]),
+omap_compare_dssdevs, NULL);
}
static int omap_connect_dssdevs(struct drm_device *ddev)
--
2.14.1
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
[RFC 7/7] drm/omap: Add kernel parameter to specify the desired display order
omapdrm.displays (int array) can be used to reorder the displays by id if
needed. It can be also used to disable display.
If the board have two active displays:
0 - LCD
1 - HDMI
then:
omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
omapdrm.displays=0 - only the LCD is enabled
omapdrm.displays=1 - only the HDMI is enabled
omapdrm.displays=-1 - disable all displays
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 55 +++---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 0e100a359d26..ce260c48d686 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -36,6 +36,14 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
+#define MAX_NR_DISPLAYS8
+static int display_order[MAX_NR_DISPLAYS];
+static int display_order_nelm;
+module_param_array_named(displays, display_order, int, &display_order_nelm,
+0444);
+MODULE_PARM_DESC(displays,
+"ID array to specify the order of the active displays");
+
/*
* mode config funcs
*/
@@ -183,12 +191,21 @@ static int omap_compare_dssdevs(const void *a, const void
*b)
static void omap_collect_dssdevs(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
+ struct omap_dss_device *dssdevs[ARRAY_SIZE(priv->dssdevs)];
struct omap_dss_device *dssdev = NULL;
+ int num_dssdevs = 0;
+ unsigned long dssdev_mask = 0;
+ int i;
+
+ /* No displays should be enabled */
+ if (display_order_nelm == 1 && display_order[0] < 0)
+ return;
for_each_dss_dev(dssdev) {
omap_dss_get_device(dssdev);
- priv->dssdevs[priv->num_dssdevs++] = dssdev;
- if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ set_bit(num_dssdevs, &dssdev_mask);
+ dssdevs[num_dssdevs++] = dssdev;
+ if (num_dssdevs == ARRAY_SIZE(dssdevs)) {
/* To balance the 'for_each_dss_dev' loop */
omap_dss_put_device(dssdev);
break;
@@ -196,8 +213,38 @@ static void omap_collect_dssdevs(struct drm_device *ddev)
}
/* Sort the list by DT aliases */
- sort(priv->dssdevs, priv->num_dssdevs, sizeof(priv->dssdevs[0]),
-omap_compare_dssdevs, NULL);
+ sort(dssdevs, num_dssdevs, sizeof(dssdevs[0]), omap_compare_dssdevs,
+NULL);
+
+ /* Do ordering based on the display_order parameter array */
+ for (i = 0; i < display_order_nelm; i++) {
+ int old_index = display_order[i];
+
+ if ((old_index >= 0 && old_index < num_dssdevs) &&
+ (dssdev_mask & BIT(old_index))) {
+ priv->dssdevs[priv->num_dssdevs++] = dssdevs[old_index];
+ clear_bit(old_index, &dssdev_mask);
+ } else {
+ dev_err(ddev->dev,
+ "Ignoring invalid displays module parameter\n");
+ priv->num_dssdevs = 0;
+ break;
+ }
+ }
+
+ /* if the target list is empty, copy the collected dssdevs, if any */
+ if (priv->num_dssdevs == 0) {
+ for (i = 0; i < num_dssdevs; i++)
+ priv->dssdevs[i] = dssdevs[i];
+
+ priv->num_dssdevs = num_dssdevs;
+ } else {
+ u32 idx;
+
+ /* check if we have dssdev which is not carried over */
+ for_each_set_bit(idx, &dssdev_mask, ARRAY_SIZE(dssdevs))
+ omap_dss_put_device(dssdevs[idx]);
+ }
}
static int omap_connect_dssdevs(struct drm_device *ddev)
--
2.14.1
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
[RFC 6/7] drm/omap: dss: Remove display ordering from dss/display.c
The previous patch implements the ordering of the dss_devices based on DT
aliases in omap_drm.c, so there is no need to do the ordering in
dss/display.c anymore.
At the same time remove the alias member of the omap_dss_device struct
since it is no longer needed. The only place it was used is in the
omapdss_register_display() function.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/display.c | 15 +++
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
b/drivers/gpu/drm/omapdrm/dss/display.c
index 42279933790e..0ce18edf6191 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -44,7 +44,6 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev->driver;
- struct list_head *cur;
int id;
/*
@@ -55,26 +54,18 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
if (id < 0)
id = disp_num_counter++;
- snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
-
/* Use 'label' property for name, if it exists */
of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
if (dssdev->name == NULL)
- dssdev->name = dssdev->alias;
+ dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
+ "display%d", id);
if (drv && drv->get_timings == NULL)
drv->get_timings = omapdss_default_get_timings;
mutex_lock(&panel_list_mutex);
- list_for_each(cur, &panel_list) {
- struct omap_dss_device *ldev = list_entry(cur,
-struct omap_dss_device,
-panel_list);
- if (strcmp(ldev->alias, dssdev->alias) > 0)
- break;
- }
- list_add_tail(&dssdev->panel_list, cur);
+ list_add_tail(&dssdev->panel_list, &panel_list);
mutex_unlock(&panel_list_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 47a331670963..b206aa092235 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -475,9 +475,6 @@ struct omap_dss_device {
struct list_head panel_list;
- /* alias in the form of "display%d" */
- char alias[16];
-
enum omap_display_type type;
enum omap_display_type output_type;
--
2.14.1
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
[RFC 2/7] drm/omap: Allocate drm_device earlier and unref it as last step
If we allocate the drm_device earlier we can just return the error code
without the need to use goto.
Do the unref of the drm_device as a last step when cleaning up. This will
make the drm_device available longer for us and makes sure that we only
free up the memory when all other cleanups have been already done.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 903510d8054e..bd7fe317a365 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -552,6 +552,14 @@ static int pdev_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
+ /* Allocate and initialize the DRM device. */
+ ddev = drm_dev_alloc(&omap_drm_driver, &pdev->dev);
+ if (IS_ERR(ddev))
+ return PTR_ERR(ddev);
+
+ ddev->dev_private = priv;
+ platform_set_drvdata(pdev, ddev);
+
omap_crtc_pre_init();
ret = omap_connect_dssdevs();
@@ -568,22 +576,12 @@ static int pdev_probe(struct platform_device *pdev)
spin_lock_init(&priv->list_lock);
INIT_LIST_HEAD(&priv->obj_list);
- /* Allocate and initialize the DRM device. */
- ddev = drm_dev_alloc(&omap_drm_driver, &pdev->dev);
- if (IS_ERR(ddev)) {
- ret = PTR_ERR(ddev);
- goto err_destroy_wq;
- }
-
- ddev->dev_private = priv;
- platform_set_drvdata(pdev, ddev);
-
omap_gem_init(ddev);
ret = omap_modeset_init(ddev);
if (ret) {
dev_err(&pdev->dev, "omap_modeset_init failed: ret=%d\n", ret);
- goto err_free_drm_dev;
+ goto err_gem_deinit;
}
/* Initialize vblank handling, start with all CRTCs disabled. */
@@ -619,14 +617,13 @@ static int pdev_probe(struct platform_device *pdev)
err_cleanup_modeset:
drm_mode_config_cleanup(ddev);
omap_drm_irq_uninstall(ddev);
-err_free_drm_dev:
+err_gem_deinit:
omap_gem_deinit(ddev);
- drm_dev_unref(ddev);
-err_destroy_wq:
destroy_workqueue(priv->wq);
omap_disconnect_dssdevs();
err_crtc_uninit:
omap_crtc_pre_uninit();
+ drm_dev_unref(ddev);
return ret;
}
@@ -652,13 +649,13 @@ static int pdev_remove(struct platform_device *pdev)
omap_drm_irq_uninstall(ddev);
omap_gem_deinit(ddev);
- drm_dev_unref(ddev);
-
destroy_workqueue(priv->wq);
omap_disconnect_dssdevs();
omap_crtc_pre_uninit();
+ drm_dev_unref(ddev);
+
return 0;
}
--
2.14.1
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
Re: [GIT PULL] drm-hisilicon-next
On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote: > Hi Dave, > One fix for next. > Sorry for late pull request. If it can't catch this round, will resend > on next round. drm-misc is always open for features, which makes this a lot simpler. Just in case you want to reconsider moving hisilicon into drm-misc :-) -Daniel > > > Best, > Xinliang > > > The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: > > Merge branch 'drm-vmwgfx-next' of > git://people.freedesktop.org/~syeh/repos_linux into drm-next > (2017-08-29 10:38:14 +1000) > > are available in the git repository at: > > > g...@github.com:xin3liang/linux.git tags/drm-hisilicon-next-2017-08-29 > > for you to fetch changes up to 834fe0f6023a4fad68612dbbe93866c4df32142e: > > drm/hisilicon: Ensure LDI regs are properly configured. (2017-08-29 > 10:17:18 +0800) > > > hisilicon-drm-next > > > Peter Griffin (1): > drm/hisilicon: Ensure LDI regs are properly configured. > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++ > 1 file changed, 3 insertions(+) > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU
https://bugs.freedesktop.org/show_bug.cgi?id=101691 --- Comment #38 from Ethan Hsieh --- Created attachment 133861 --> https://bugs.freedesktop.org/attachment.cgi?id=133861&action=edit Xorg.0.log (ubuntu 17.04 + modeset) -- 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 101691] gfx corruption on windowed 3d-apps running on dGPU
https://bugs.freedesktop.org/show_bug.cgi?id=101691 --- Comment #39 from Ethan Hsieh --- Created attachment 133862 --> https://bugs.freedesktop.org/attachment.cgi?id=133862&action=edit Xorg.0.log (ubuntu 17.04 + intel&amdgpu) I install Ubuntu 17.4 and can reproduce corruption issue in AC/DC mode. Xorg.0.log: [21.309] (II) LoadModule: "modesetting" [21.309] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [21.310] (II) Module modesetting: vendor="X.Org Foundation" But, the issue in DC mode is gone after I add two config files. /usr/share/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "Intel" Option "DRI" "3" EndSection /usr/share/X11/xorg.conf.d/30-amdgpu.conf Section "Device" Identifier "AMDGPU" Driver "amdgpu" Option "DRI" "3" EndSection -- 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: DRM Format Modifiers in v4l2
On Fri, Aug 25, 2017 at 10:14:03AM +0200, Hans Verkuil wrote: On 24/08/17 14:26, Brian Starkey wrote: On Thu, Aug 24, 2017 at 01:37:35PM +0200, Hans Verkuil wrote: On 08/24/17 13:14, Brian Starkey wrote: Hi Hans, On Mon, Aug 21, 2017 at 06:36:29PM +0200, Hans Verkuil wrote: On 08/21/2017 06:01 PM, Daniel Vetter wrote: On Mon, Aug 21, 2017 at 5:52 PM, Brian Starkey wrote: Hi all, I couldn't find this topic talked about elsewhere, but apologies if it's a duplicate - I'll be glad to be steered in the direction of a thread. We'd like to support DRM format modifiers in v4l2 in order to share the description of different (mostly proprietary) buffer formats between e.g. a v4l2 device and a DRM device. DRM format modifiers are defined in include/uapi/drm/drm_fourcc.h and are a vendor-namespaced 64-bit value used to describe various vendor-specific buffer layouts. They are combined with a (DRM) FourCC code to give a complete description of the data contained in a buffer. The same modifier definition is used in the Khronos EGL extension EGL_EXT_image_dma_buf_import_modifiers, and is supported in the Wayland linux-dmabuf protocol. This buffer information could of course be described in the vendor-specific part of V4L2_PIX_FMT_*, but this would duplicate the information already defined in drm_fourcc.h. Additionally, there would be quite a format explosion where a device supports a dozen or more formats, all of which can use one or more different layouts/compression schemes. So, I'm wondering if anyone has views on how/whether this could be incorporated? I spoke briefly about this to Laurent at LPC last year, and he suggested v4l2_control as one approach. I also wondered if could be added in v4l2_pix_format_mplane - looks like there's 8 bytes left before it exceeds the 200 bytes, or could go in the reserved portion of v4l2_plane_pix_format. Thanks for any thoughts, One problem is that the modifers sometimes reference the DRM fourcc codes. v4l has a different (and incompatible set) of fourcc codes, whereas all the protocols and specs (you can add DRI3.1 for Xorg to that list btw) use both drm fourcc and drm modifiers. This might or might not make this proposal unworkable, but it's something I'd at least review carefully. Otherwise I think it'd be great if we could have one namespace for all modifiers, that's pretty much why we have them. Please also note that for drm_fourcc.h we don't require an in-kernel user for a new modifier since a bunch of them might need to be allocated just for userspace-to-userspace buffer sharing (e.g. in EGL/vk). One example for this would be compressed surfaces with fast-clearing, which is planned for i915 (but current hw can't scan it out). And we really want to have one namespace for everything. Who sets these modifiers? Kernel or userspace? Or can it be set by both? I assume any userspace code that sets/reads this is code specific for that hardware? I think normally the modifier would be set by userspace. However it might not necessarily be device-specific code. In DRM the intention is for userspace to query the set of modifiers which are supported, and then use them without necessarily knowing exactly what they mean (insofar as that is possible). e.g. if I have two devices which support MODIFIER_FOO, I could attempt to share a buffer between them which uses MODIFIER_FOO without necessarily knowing exactly what it is/does. I think Laurent's suggestion of using a 64 bit V4L2 control for this makes the most sense. Especially if you can assume that whoever sets this knows the hardware. I think this only makes sense if you pass buffers from one HW device to another. Because you cannot expect generic video capture code to be able to interpret all the zillion different combinations of modifiers. I don't quite follow this last bit. The control could report the set of supported modifiers. What I mean was: an application can use the modifier to give buffers from one device to another without needing to understand it. But a generic video capture application that processes the video itself cannot be expected to know about the modifiers. It's a custom HW specific format that you only use between two HW devices or with software written for that hardware. Yes, makes sense. However, in DRM the API lets you get the supported formats for each modifier as-well-as the modifier list itself. I'm not sure how exactly to provide that in a control. We have support for a 'menu' of 64 bit integers: V4L2_CTRL_TYPE_INTEGER_MENU. You use VIDIOC_QUERYMENU to enumerate the available modifiers. So enumerating these modifiers would work out-of-the-box. Right. So I guess the supported set of formats could be somehow enumerated in the menu item string. In DRM the pairs are (modifier + bitmask) where bits represent formats in the supported formats list (commit db1689aa61bd in drm-next). Printing a hex representation of the bitmask would be functional but I concede not very
[Bug 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)
https://bugs.freedesktop.org/show_bug.cgi?id=102300 --- Comment #9 from f...@mt2015.com --- I updated bunch of packages today (linux-amd-staging,mesa etc) and now DVI-I-1 is not recognized but it is shown as DVI-D-1. This also brought new problem: monitors 'blink' randomly, about every ten seconds and it is VERY annoying. I also left the computer for few hours monitor powered off, and then when I came back and it should've shown lockscreen monitor repeatedly showed "signal not found" and then got it, and lost it immediately again. I couldn't get picture to either monitor but Ctrl-Alt-Del restart did work. -- 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 102300] Missing 1920x1080_59.94Hz mode (Second monitor shows black screen but has signal)
https://bugs.freedesktop.org/show_bug.cgi?id=102300 --- Comment #10 from f...@mt2015.com --- By the way refresh rate 60.00 is used since DVI-I-1 -> DVI-D-1 change. -- 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: DRM Format Modifiers in v4l2
On Mon, Aug 28, 2017 at 10:49:07PM +0200, Daniel Vetter wrote: On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne wrote: Le jeudi 24 ao??t 2017 ?? 13:26 +0100, Brian Starkey a ??crit : > What I mean was: an application can use the modifier to give buffers from > one device to another without needing to understand it. > > But a generic video capture application that processes the video itself > cannot be expected to know about the modifiers. It's a custom HW specific > format that you only use between two HW devices or with software written > for that hardware. > Yes, makes sense. > > > > However, in DRM the API lets you get the supported formats for each > > modifier as-well-as the modifier list itself. I'm not sure how exactly > > to provide that in a control. > > We have support for a 'menu' of 64 bit integers: V4L2_CTRL_TYPE_INTEGER_MENU. > You use VIDIOC_QUERYMENU to enumerate the available modifiers. > > So enumerating these modifiers would work out-of-the-box. Right. So I guess the supported set of formats could be somehow enumerated in the menu item string. In DRM the pairs are (modifier + bitmask) where bits represent formats in the supported formats list (commit db1689aa61bd in drm-next). Printing a hex representation of the bitmask would be functional but I concede not very pretty. The problem is that the list of modifiers depends on the format selected. Having to call S_FMT to obtain this list is quite inefficient. Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think an other one made it the same way recently, something from Mediatek if I remember. Though, unlike the Intel one, the same modifier does not have various result depending on the hardware revision. Note on the intel modifers: On most recent platforms (iirc gen9) the modifier is well defined and always describes the same byte layout. We simply didn't want to rewrite our entire software stack for all the old gunk platforms, hence the language. I guess we could/should describe the layout in detail, but atm we're the only ones using it. On your topic of v4l2 encoding the drm fourcc+modifier combo into a special v4l fourcc: That's exactly the mismatch I was thinking of. There's other examples of v4l2 fourcc being more specific than their drm counters (e.g. specific way the different planes are laid out). I'm not entirely clear on the v4l2 fourccs being more specific than DRM ones - do you mean e.g. NV12 vs NV12M? Specifically in the case of multi-planar formats I think it's a non-issue because modifiers are allowed to alter the number of planes and the meanings of them. Also V4L2 NV12M is a superset of NV12 - so NV12M would always be able to describe a DRM NV12 buffer. I don't see the "special v4l2 format already exists" case as a problem either. It would be up to any drivers that already have special formats to decide if they want to also support it via a more generic modifiers API or not. The fact is, adding special formats for each combination is unmanageable - we're talking dozens in the case of our hardware. Cheers, -Brian -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] drm-hisilicon-next
Hi Dave, On 29 August 2017 at 16:32, Daniel Vetter wrote: > On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote: >> Hi Dave, >> One fix for next. >> Sorry for late pull request. If it can't catch this round, will resend >> on next round. > > drm-misc is always open for features, which makes this a lot simpler. Just > in case you want to reconsider moving hisilicon into drm-misc :-) If moving hisilicon into drm-misc make things simpler, I would like to do it. Just clarify how to do this: I just need to change the git tree to drm-misc? I see a lot of drm drivers maintainers set the their git tree to git://anongit.freedesktop.org/drm/drm-misc. The means to be an drm-misc maintainer, right? I wonder how new driver specific features/fixes patches go into drm-misc then? Do I need to send a pull request to drm-misc tree. I don't think I have a write permission to drm-misc tree. Best, Xinliang > -Daniel > >> >> >> Best, >> Xinliang >> >> >> The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: >> >> Merge branch 'drm-vmwgfx-next' of >> git://people.freedesktop.org/~syeh/repos_linux into drm-next >> (2017-08-29 10:38:14 +1000) >> >> are available in the git repository at: >> >> >> g...@github.com:xin3liang/linux.git tags/drm-hisilicon-next-2017-08-29 >> >> for you to fetch changes up to 834fe0f6023a4fad68612dbbe93866c4df32142e: >> >> drm/hisilicon: Ensure LDI regs are properly configured. (2017-08-29 >> 10:17:18 +0800) >> >> >> hisilicon-drm-next >> >> >> Peter Griffin (1): >> drm/hisilicon: Ensure LDI regs are properly configured. >> >> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++ >> 1 file changed, 3 insertions(+) >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS
On 2017年08月23日 14:26, Sandy Huang wrote:
This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.
Signed-off-by: Sandy Huang
Signed-off-by: Mark yao
Signed-off-by: Heiko Stuebner
---
Looks good for me:
Reviewed-by: Mark Yao
Changes according to Rob Herring's review.
.../bindings/display/rockchip/rockchip-lvds.txt| 99 ++
1 file changed, 99 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..da6939e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,99 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+ - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+ of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output
interface
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+Their connections are modeled using the OF graph bindings specified in
+ Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+ Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- ports for remote LVDS output
+
+Panel optional properties:
+- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
+This describes decribed by:
+ Documentation/devicetree/bindings/display/panel/panel-lvds.txt
+
+Example:
+
+lvds_panel: lvds-panel {
+ compatible = "auo,b101ean01";
+ enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
+ data-mapping = "jeida-24";
+
+ ports {
+ panel_in_lvds: endpoint {
+ remote-endpoint = <&lvds_out_panel>;
+ };
+ };
+};
+
+For Rockchip RK3288:
+
+ lvds: lvds@ff96c000 {
+ compatible = "rockchip,rk3288-lvds";
+ rockchip,grf = <&grf>;
+ reg = <0xff96c000 0x4000>;
+ clocks = <&cru PCLK_LVDS_PHY>;
+ clock-names = "pclk_lvds";
+ pinctrl-names = "lcdc";
+ pinctrl-0 = <&lcdc_ctl>;
+ avdd1v0-supply = <&vdd10_lcd>;
+ avdd1v8-supply = <&vcc18_lcd>;
+ avdd3v3-supply = <&vcca_33>;
+ rockchip,output = "rgb";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in: port@0 {
+ reg = <0>;
+
+ lvds_in_vopb: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_lvds>;
+ };
+ lvds_in_vopl: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_lvds>;
+ };
+ };
+
+ lvds_out: port@1 {
+ reg = <1>;
+
+ lvds_out_panel: endpoint {
+ remote-endpoint = <&panel_in_lvds>;
+ };
+ };
+ };
+ };
--
Ｍark Yao
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS
Am Dienstag, 29. August 2017, 18:17:11 CEST schrieb Mark yao:
> On 2017年08月23日 14:26, Sandy Huang wrote:
> > This patch add Document for Rockchip Soc RK3288 LVDS,
> > This based on the patches from Mark yao and Heiko Stuebner.
> >
> > Signed-off-by: Sandy Huang
> > Signed-off-by: Mark yao
> > Signed-off-by: Heiko Stuebner
> > ---
> Looks good for me:
>
> Reviewed-by: Mark Yao
Signed-off ordering is wrong though ... you add a Signed-off below
all others and you could also drop the one from me, as I don't
think I did provide to much value between Mark's and Sandy's variant
of the patches :-)
Heiko
> > Changes according to Rob Herring's review.
> >
> > .../bindings/display/rockchip/rockchip-lvds.txt| 99
> > ++
> > 1 file changed, 99 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> > b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> > new file mode 100644
> > index 000..da6939e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
> > @@ -0,0 +1,99 @@
> > +Rockchip RK3288 LVDS interface
> > +
> > +
> > +Required properties:
> > +- compatible: matching the soc type, one of
> > + - "rockchip,rk3288-lvds";
> > +
> > +- reg: physical base address of the controller and length
> > + of memory mapped region.
> > +- clocks: must include clock specifiers corresponding to entries in the
> > + clock-names property.
> > +- clock-names: must contain "pclk_lvds"
> > +
> > +- avdd1v0-supply: regulator phandle for 1.0V analog power
> > +- avdd1v8-supply: regulator phandle for 1.8V analog power
> > +- avdd3v3-supply: regulator phandle for 3.3V analog power
> > +
> > +- rockchip,grf: phandle to the general register files syscon
> > +- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output
> > interface
> > +
> > +Optional properties:
> > +- pinctrl-names: must contain a "lcdc" entry.
> > +- pinctrl-0: pin control group to be used for this controller.
> > +
> > +Required nodes:
> > +
> > +The lvds has two video ports as described by
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > +Their connections are modeled using the OF graph bindings specified in
> > + Documentation/devicetree/bindings/graph.txt.
> > +
> > +- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl
> > +- video port 1 for either a panel or subsequent encoder
> > +
> > +the lvds panel described by
> > + Documentation/devicetree/bindings/display/panel/simple-panel.txt
> > +
> > +Panel required properties:
> > +- ports for remote LVDS output
> > +
> > +Panel optional properties:
> > +- data-mapping: should be "vesa-24","jeida-24" or "jeida-18".
> > +This describes decribed by:
> > + Documentation/devicetree/bindings/display/panel/panel-lvds.txt
> > +
> > +Example:
> > +
> > +lvds_panel: lvds-panel {
> > + compatible = "auo,b101ean01";
> > + enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>;
> > + data-mapping = "jeida-24";
> > +
> > + ports {
> > + panel_in_lvds: endpoint {
> > + remote-endpoint = <&lvds_out_panel>;
> > + };
> > + };
> > +};
> > +
> > +For Rockchip RK3288:
> > +
> > + lvds: lvds@ff96c000 {
> > + compatible = "rockchip,rk3288-lvds";
> > + rockchip,grf = <&grf>;
> > + reg = <0xff96c000 0x4000>;
> > + clocks = <&cru PCLK_LVDS_PHY>;
> > + clock-names = "pclk_lvds";
> > + pinctrl-names = "lcdc";
> > + pinctrl-0 = <&lcdc_ctl>;
> > + avdd1v0-supply = <&vdd10_lcd>;
> > + avdd1v8-supply = <&vcc18_lcd>;
> > + avdd3v3-supply = <&vcca_33>;
> > + rockchip,output = "rgb";
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + lvds_in: port@0 {
> > + reg = <0>;
> > +
> > + lvds_in_vopb: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&vopb_out_lvds>;
> > + };
> > + lvds_in_vopl: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&vopl_out_lvds>;
> > + };
> > + };
> > +
> > + lvds_out: port@1 {
> > + reg = <1>;
> > +
> > + lvds_out_panel: endpoint {
> > + remote-endpoint = <&panel_in_lvds>;
> > + };
> > + };
> > + };
> > + };
>
>
>
___
dri-devel mailing list
dri-d
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #6 from Walther Pelser (w.pel...@web.de) --- Created attachment 258143 --> https://bugzilla.kernel.org/attachment.cgi?id=258143&action=edit lsinitrd kernel 4.13.0-rc6 parts the firmware is there -- 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 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #7 from Walther Pelser (w.pel...@web.de) --- (In reply to Takashi Iwai from comment #5) > It doesn't matter what zypper says. Simply check initrd content via > lsinitrd. > If the target firmware file is found there, it's OK. If not, that's the > problem. As I said in my description kernel 4.13.0-rc2-1.gb545b87 was booting with out any problems. So my conclusion is, that radeon.ko has become broken in the meantime, and that is. what dracut printed out for me. -- 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
Re: [PATCH] drm/amd: Remove null check before kfree
Am 29.08.2017 um 15:21 schrieb Himanshu Jha:
Kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8d1cf2d..f51b41f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -346,10 +346,8 @@ static void amdgpu_connector_free_edid(struct
drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
- if (amdgpu_connector->edid) {
- kfree(amdgpu_connector->edid);
- amdgpu_connector->edid = NULL;
- }
+ kfree(amdgpu_connector->edid);
+ amdgpu_connector->edid = NULL;
}
static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index 76347ff..00075c2 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -606,10 +606,8 @@ int smu7_init(struct pp_smumgr *smumgr)
int smu7_smu_fini(struct pp_smumgr *smumgr)
{
- if (smumgr->backend) {
- kfree(smumgr->backend);
- smumgr->backend = NULL;
- }
+ kfree(smumgr->backend);
+ smumgr->backend = NULL;
cgs_rel_firmware(smumgr->device, CGS_UCODE_ID_SMU);
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt
On Fri, Jul 28, 2017 at 04:58:27PM +0100, Russell King - ARM Linux wrote: > On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > > initialise without an interrupt present. > > > > > > > > Signed-off-by: Russell King > > > > > > > Hi Russell, > > > > Sorry for my silence, I was on holiday this week and just came back > > today. > > > > > This isn't fully functional on ARM MPS platforms yet, but at least > > > gets us further. Without any display connected: > > > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > > [ 14.557038] tda998x 2-0070: found TDA19988 > > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd > > > on minor 0 > > > > > > With a TV connected, the driver doesn't initialise: > > > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > > [ 14.657227] tda998x 2-0070: found TDA19988 > > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw > > > configuration. > > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > > > I don't think this is correct behaviour - if we fail to set an initial > > > configuration (which will be based on the resolution of the connected > > > display) why should the driver fail to probe - it's not that there is > > > no device, it's (in this case) that there aren't the resources for the > > > chosen mode. Userspace could always try setting a different mode. > > > > > > I suspect the above failure is down to either (a) not having enough > > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > > (yet) being able to program the hdlcd pixel clock for this platform, > > > which is currently hard-coded in DT at 23.75MHz. > > > > I don't think it is the clock, if that fails then you would not see the > > r0p0 version number being printed. Due to the fact that until now HDLCD > > has run mostly on platforms that have SCP, which takes care of actual > > setup of the clocks, it is pretty lax on errors on pixel clock setup. > > Note, however, that in this case, the clock is a fixed frequency clock. > I wasn't meaning a failure to obtain the clock, I was meaning a failure > to set the appropriate rate. > > > Also, may I ask what MPS platform you are trying to use? I might be able > > to source one internally and try to reproduce your problems. > > I'll point you in the direction of Ian Rickards in ARM for that > information. (I'm not sure if I can mention the board publically > yet as its early days...) Hi Russell, I've worked with Vladimir Murzin inside ARM to try to sort out problems on the board like the one that you have. He's got to a point where the HDLCD starts correctly after adding a non-fixed pxlclk source, but then the rest of the setup is semi-useless without a working IRQ because DRM atomic calls will give you a vblank timeout splat everytime you invoke them. So I'm not sure how you want to progress with this patch, as not having an IRQ line means you will not get any vblank interrupts and you can't use the driver with userspace that calls DRM API. The RTL guys are apparently working on a fix, but I have no ETA or details on when they are going to do. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] drm-hisilicon-next
On Tue, Aug 29, 2017 at 11:54 AM, Xinliang Liu wrote: > Hi Dave, > > On 29 August 2017 at 16:32, Daniel Vetter wrote: >> On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote: >>> Hi Dave, >>> One fix for next. >>> Sorry for late pull request. If it can't catch this round, will resend >>> on next round. >> >> drm-misc is always open for features, which makes this a lot simpler. Just >> in case you want to reconsider moving hisilicon into drm-misc :-) > > If moving hisilicon into drm-misc make things simpler, I would like to do it. > Just clarify how to do this: > I just need to change the git tree to drm-misc? I see a lot of drm > drivers maintainers set the their git tree to > git://anongit.freedesktop.org/drm/drm-misc. > The means to be an drm-misc maintainer, right? > I wonder how new driver specific features/fixes patches go into drm-misc then? > Do I need to send a pull request to drm-misc tree. I don't think I > have a write permission to drm-misc tree. You'll need to become drm-misc committer, and patches are pushed directly using the scripts we have: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html Here's the rules for how drm-misc works: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html drm-misc is essentially a service provided to take care of some of the maintainer chores, but review and patch merging still needs to be done by the individual driver owners (i.e. we won't take a new driver without a committer for it). Cheers, Daniel > > Best, > Xinliang > >> -Daniel >> >>> >>> >>> Best, >>> Xinliang >>> >>> >>> The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: >>> >>> Merge branch 'drm-vmwgfx-next' of >>> git://people.freedesktop.org/~syeh/repos_linux into drm-next >>> (2017-08-29 10:38:14 +1000) >>> >>> are available in the git repository at: >>> >>> >>> g...@github.com:xin3liang/linux.git tags/drm-hisilicon-next-2017-08-29 >>> >>> for you to fetch changes up to 834fe0f6023a4fad68612dbbe93866c4df32142e: >>> >>> drm/hisilicon: Ensure LDI regs are properly configured. (2017-08-29 >>> 10:17:18 +0800) >>> >>> >>> hisilicon-drm-next >>> >>> >>> Peter Griffin (1): >>> drm/hisilicon: Ensure LDI regs are properly configured. >>> >>> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/atomic: Move drm_crtc_commit to drm_crtc_state.
Most code only cares about the current commit or previous commit.
Fortunately we already have a place to track those. Move it to
drm_crtc_state where it belongs. :)
The per-crtc commit_list is kept for places where we have to look
deeper than the current or previous commit for checking whether to stall
on unpin. This is used in drm_atomic_helper_setup_commit and
intel_has_pending_fb_unpin.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 7 ---
drivers/gpu/drm/drm_atomic_helper.c | 92 ++---
include/drm/drm_atomic.h| 1 -
include/drm/drm_crtc.h | 9
4 files changed, 32 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2fd383d7253a..2cce48f203e0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -163,13 +163,6 @@ void drm_atomic_state_default_clear(struct
drm_atomic_state *state)
crtc->funcs->atomic_destroy_state(crtc,
state->crtcs[i].state);
- if (state->crtcs[i].commit) {
- kfree(state->crtcs[i].commit->event);
- state->crtcs[i].commit->event = NULL;
- drm_crtc_commit_put(state->crtcs[i].commit);
- }
-
- state->crtcs[i].commit = NULL;
state->crtcs[i].ptr = NULL;
state->crtcs[i].state = NULL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4e53aae9a1fb..9c2888cb4081 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1262,12 +1262,12 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
void drm_atomic_helper_wait_for_flip_done(struct drm_device *dev,
struct drm_atomic_state *old_state)
{
- struct drm_crtc_state *unused;
+ struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
int i;
- for_each_new_crtc_in_state(old_state, crtc, unused, i) {
- struct drm_crtc_commit *commit = old_state->crtcs[i].commit;
+ for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i) {
+ struct drm_crtc_commit *commit = new_crtc_state->commit;
int ret;
if (!commit)
@@ -1388,11 +1388,10 @@ int drm_atomic_helper_async_check(struct drm_device
*dev,
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
- struct drm_crtc_commit *commit;
struct drm_plane *__plane, *plane = NULL;
struct drm_plane_state *__plane_state, *plane_state = NULL;
const struct drm_plane_helper_funcs *funcs;
- int i, j, n_planes = 0;
+ int i, n_planes = 0;
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state))
@@ -1420,33 +1419,10 @@ int drm_atomic_helper_async_check(struct drm_device
*dev,
return -EINVAL;
/*
-* Don't do an async update if there is an outstanding commit modifying
+* XXX: Don't do an async update if there is an outstanding commit
modifying
* the plane. This prevents our async update's changes from getting
* overridden by a previous synchronous update's state.
*/
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- if (plane->crtc != crtc)
- continue;
-
- spin_lock(&crtc->commit_lock);
- commit = list_first_entry_or_null(&crtc->commit_list,
- struct drm_crtc_commit,
- commit_entry);
- if (!commit) {
- spin_unlock(&crtc->commit_lock);
- continue;
- }
- spin_unlock(&crtc->commit_lock);
-
- if (!crtc->state->state)
- continue;
-
- for_each_plane_in_state(crtc->state->state, __plane,
- __plane_state, j) {
- if (__plane == plane)
- return -EINVAL;
- }
- }
return funcs->atomic_async_check(plane, plane_state);
}
@@ -1731,7 +1707,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
kref_init(&commit->ref);
commit->crtc = crtc;
- state->crtcs[i].commit = commit;
+ new_crtc_state->commit = commit;
ret = stall_checks(crtc, nonblock);
if (ret)
@@ -1769,22 +1745,6 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
-
-static struct drm_crtc_commit *preceeding_commit(struct drm_crtc *crtc)
-{
- str
[PATCH 2/2] drm/atomic: Fix freeing connector/plane state too early by tracking commits
Currently we neatly track the crtc state, but forget to look at
plane/connector state.
When doing a nonblocking modeset, immediately followed by a setprop
before the modeset completes, the setprop will see the modesets new
state as the old state and free it.
This has to be solved by waiting for hw_done on the connector, even
if it's not assigned to a crtc. When a connector is unbound we take
the last crtc commit, and when it stays unbound we create a new
crtc commit for the connector that gets signaled on hw_done.
We wait for it the same way as we do for crtc's, which will make
sure we never run into a use-after-free situation.
Signed-off-by: Maarten Lankhorst
Testcase: kms_atomic_transition.plane-use-after-nonblocking-unbind*
Cc: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 171 ++--
include/drm/drm_connector.h | 7 ++
include/drm/drm_plane.h | 7 ++
3 files changed, 179 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9c2888cb4081..a4fd500d6200 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1644,6 +1644,39 @@ static void release_crtc_commit(struct completion
*completion)
drm_crtc_commit_put(commit);
}
+static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc *crtc)
+{
+ init_completion(&commit->flip_done);
+ init_completion(&commit->hw_done);
+ init_completion(&commit->cleanup_done);
+ INIT_LIST_HEAD(&commit->commit_entry);
+ kref_init(&commit->ref);
+ commit->crtc = crtc;
+}
+
+static struct drm_crtc_commit *
+init_or_ref_crtc_commit(struct drm_atomic_state *state, struct drm_crtc *crtc)
+{
+ struct drm_crtc_commit *commit;
+
+ if (crtc) {
+ struct drm_crtc_state *new_crtc_state;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+
+ commit = new_crtc_state->commit;
+ drm_crtc_commit_get(commit);
+ } else {
+ commit = kzalloc(sizeof(*commit), GFP_KERNEL);
+ if (!commit)
+ return NULL;
+
+ init_commit(commit, NULL);
+ }
+
+ return commit;
+}
+
/**
* drm_atomic_helper_setup_commit - setup possibly nonblocking commit
* @state: new modeset state to be committed
@@ -1692,6 +1725,10 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
{
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_connector *conn;
+ struct drm_connector_state *old_conn_state, *new_conn_state;
+ struct drm_plane *plane;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_crtc_commit *commit;
int i, ret;
@@ -1700,12 +1737,7 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
if (!commit)
return -ENOMEM;
- init_completion(&commit->flip_done);
- init_completion(&commit->hw_done);
- init_completion(&commit->cleanup_done);
- INIT_LIST_HEAD(&commit->commit_entry);
- kref_init(&commit->ref);
- commit->crtc = crtc;
+ init_commit(commit, crtc);
new_crtc_state->commit = commit;
@@ -1741,6 +1773,36 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
drm_crtc_commit_get(commit);
}
+ for_each_oldnew_connector_in_state(state, conn, old_conn_state,
new_conn_state, i) {
+ if (new_conn_state->crtc)
+ continue;
+
+ if (nonblock && old_conn_state->commit &&
+
!try_wait_for_completion(&old_conn_state->commit->flip_done))
+ return -EBUSY;
+
+ commit = init_or_ref_crtc_commit(state, old_conn_state->crtc);
+ if (!commit)
+ return -ENOMEM;
+
+ new_conn_state->commit = commit;
+ }
+
+ for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
+ if (new_plane_state->crtc)
+ continue;
+
+ if (nonblock && old_plane_state->commit &&
+
!try_wait_for_completion(&old_plane_state->commit->flip_done))
+ return -EBUSY;
+
+ commit = init_or_ref_crtc_commit(state, old_plane_state->crtc);
+ if (!commit)
+ return -ENOMEM;
+
+ new_plane_state->commit = commit;
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
@@ -1761,6 +1823,10 @@ void drm_atomic_helper_wait_for_dependencies(struct
drm_atomic_state *old_state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
+ struct drm_plane *p
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- The only reason the firmware would fail to load is if it's not available. From the log, it shows direct fw loading failed. Did you build radeon into your kernel rather than as a module? If so, you need to build the firmware into your kernel as well. -- 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 102013] GTK3 tooltips are corrupted after updating to mesa 17.0.7
https://bugs.freedesktop.org/show_bug.cgi?id=102013 Amr Ibrahim changed: What|Removed |Added Summary|GTK3 tooltips are corrupted |GTK3 tooltips are corrupted |after updating to Radeon|after updating to mesa |7.9.0 |17.0.7 -- 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/amd/powerplay/hwmgr: Remove null check before kfree
Am 29.08.2017 um 15:12 schrieb Himanshu Jha:
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96 --
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 +--
4 files changed, 56 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index bc839ff..9f2c037 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr *hwmgr)
phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
- if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
- kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
- hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
+ hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
kfree(hwmgr->backend);
hwmgr->backend = NULL;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 2716721..a6dbc55 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr
*hwmgr)
if (hwmgr->chip_id == CHIP_RAVEN)
return 0;
- if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
- kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
- hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
+ hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
- if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
- hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
+ hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
- hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
+ hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
- hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
+ hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.valid_mclk_values) {
- kfree(hwmgr->dyn_state.valid_mclk_values);
- hwmgr->dyn_state.valid_mclk_values = NULL;
- }
+ kfree(hwmgr->dyn_state.valid_mclk_values);
+ hwmgr->dyn_state.valid_mclk_values = NULL;
- if (NULL != hwmgr->dyn_state.valid_sclk_values) {
- kfree(hwmgr->dyn_state.valid_sclk_values);
- hwmgr->dyn_state.valid_sclk_values = NULL;
- }
+ kfree(hwmgr->dyn_state.valid_sclk_values);
+ hwmgr->dyn_state.valid_sclk_values = NULL;
- if (NULL != hwmgr->dyn_state.cac_leakage_table) {
- kfree(hwmgr->dyn_state.cac_leakage_table);
- hwmgr->dyn_state.cac_leakage_table = NULL;
- }
+ kfree(hwmgr->dyn_state.cac_leakage_table);
+ hwmgr->dyn_state.cac_leakage_table = NULL;
- if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
- kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
- hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
+ hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
- if (NULL != hwmgr->dyn_state.vce_clock_voltage_dependency_table) {
- kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
- hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
- }
+ kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
+ hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
- if (NULL != hwmgr->dyn_state.uvd_clock_voltage_dependency_table) {
- kfree(hwmgr->dyn_state.uvd_clock_voltage_dependency_table);
- hwmgr->dyn_state.uvd_clock_voltage_dependency_table = NULL;
- }
+ kfree(hwmgr->dyn_state.uvd_clock_voltage_dependency_table);
+ hwmgr->dyn_state.uvd_clock_voltage_dep
Re: [PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree
On 2017-08-29 09:12 AM, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
>
> Signed-off-by: Himanshu Jha
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
> .../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96
> --
> drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 +--
> 4 files changed, 56 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> index bc839ff..9f2c037 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> @@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr
> *hwmgr)
> phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
> phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
>
> - if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
> - kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> - hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> + hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
>
> kfree(hwmgr->backend);
> hwmgr->backend = NULL;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index 2716721..a6dbc55 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr
> *hwmgr)
> if (hwmgr->chip_id == CHIP_RAVEN)
> return 0;
>
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> - hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> + hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> - hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> + hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> - hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> + hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> - hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> + hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.valid_mclk_values) {
> - kfree(hwmgr->dyn_state.valid_mclk_values);
> - hwmgr->dyn_state.valid_mclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_mclk_values);
> + hwmgr->dyn_state.valid_mclk_values = NULL;
>
> - if (NULL != hwmgr->dyn_state.valid_sclk_values) {
> - kfree(hwmgr->dyn_state.valid_sclk_values);
> - hwmgr->dyn_state.valid_sclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_sclk_values);
> + hwmgr->dyn_state.valid_sclk_values = NULL;
>
> - if (NULL != hwmgr->dyn_state.cac_leakage_table) {
> - kfree(hwmgr->dyn_state.cac_leakage_table);
> - hwmgr->dyn_state.cac_leakage_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.cac_leakage_table);
> + hwmgr->dyn_state.cac_leakage_table = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
> - kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> - hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> + hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
>
> - if (NULL != hwmgr->dyn_state.vce_clock_voltage_dependency_table) {
> - kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
> - hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
> + hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
>
> - if (NULL != hwmgr->dyn_state.uvd_clock_voltage_dependency_table) {
> - kfree(hwmgr->dyn_state.uvd_clock_voltage_dependency_table);
> - hwmgr->dyn_state.uvd_clock_voltage_dependency_table
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #9 from Takashi Iwai (ti...@suse.de) --- I guess it's module since Walther is using SUSE kernels. Could you give the full dmesg output from 4.13.0-rc6-vanilla you've installed recently? That has the firmware file in initrd as in comment 6, we can double-check 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
Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
On Fri, Aug 25, 2017 at 03:34:33PM +0200, Daniel Vetter wrote:
On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
Hi,
Thanks for the CC.
On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf Tr??nnes wrote:
> (cc affected parties)
>
>
> Den 18.08.2017 09.46, skrev Daniel Vetter:
> > On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noralf Tr??nnes wrote:
> > > Reject mapping an imported dma-buf since is's an invalid use-case.
> > >
> > > Cc: Philipp Zabel
> > > Cc: Laurent Pinchart
> > > Cc: Sean Paul
> > > Cc: Daniel Vetter
> > > Signed-off-by: Noralf Tr??nnes
> > I think acks from someone using mali would be good too. amdgpu already has
> > such checks, so I think on the desktop side we're ok.
> >
This looks like it would break anyone running the Mali-4xx series GPUs
with the Arm graphics stack (e.g. Hikey board).
I don't know where that sits in terms of policy.
Why would this break this use-case? Is the mali blob somehow using dumb
mmap for it's own buffers it shares with display? That would be rather
backwards ...
If it's running with a DRM display driver (which may or may not be
Mali-DP, they are separate IPs), then its window system code always
uses dumb mmap if it needs a pointer. That might be a native DRM
buffer that the display driver allocated, or a dma-buf which it PRIME
imported (which would now fail).
-Brian
Either way, blob -> meh, not a concern really.
-Daniel
Cheers,
-Brian
> > Acked-by: Daniel Vetter
> >
> > But I think this one here definitely needs a few more acks. I could break
> > uabi if we're unlucky, so let's not rush it.
>
> Ok, I've CC'ed the affected parties to increase the odds that they look
> at this. These are the drivers using drm_gem_dumb_map_offset()
> (hopefully I got the list right):
>
> arc
> atmel-hlcdc
> cirrus
> exynos
> fsl-dcu
> gma500
> hdlcd
> imx
> kirin
> mali-dp
> mediatek
> meson
> mxsfb
> pl111
> rcar-du
> rockchip
> shmobile
> sti
> stm
> sun4i
> tegra
> tilcd
> vc4
> zte
>
>
> Noralf.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_gem.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > > index ad4e9cf..8da5801 100644
> > > --- a/drivers/gpu/drm/drm_gem.c
> > > +++ b/drivers/gpu/drm/drm_gem.c
> > > @@ -333,6 +333,12 @@ int drm_gem_dumb_map_offset(struct drm_file *file,
struct drm_device *dev,
> > > if (!obj)
> > > return -ENOENT;
> > > +/* Don't allow imported objects to be mapped */
> > > +if (obj->import_attach) {
> > > +ret = -EINVAL;
> > > +goto out;
> > > +}
> > > +
> > > ret = drm_gem_create_mmap_offset(obj);
> > > if (ret)
> > > goto out;
> > > --
> > > 2.7.4
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/fb-helper: Support device unplug
Den 28.08.2017 23.41, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:44PM +0200, Noralf Trønnes wrote:
Support device unplug by introducing a new initialization function:
drm_fb_helper_simple_init() which together with
drm_fb_helper_dev_unplug() and drm_fb_helper_fb_destroy() handles open
fbdev fd's after device unplug. There's also a
drm_fb_helper_simple_fini() for drivers who's device won't be removed.
It turns out that fbdev has the necessary ref counting, so
unregister_framebuffer() together with fb_ops->destroy handles unplug
with open fd's. The ref counting doesn't apply to the fb_info structure
itself, but to use of the fbdev framebuffer.
Analysis of entry points after unregister_framebuffer():
- fbcon has been unbound (through notifier)
- sysfs files removed
First we look at possible operations on open fbdev file handles:
static const struct file_operations fb_fops = {
.read = fb_read,
.write =fb_write,
.unlocked_ioctl = fb_ioctl,
.compat_ioctl = fb_compat_ioctl,
.mmap = fb_mmap,
.open = fb_open,
.release = fb_release,
.get_unmapped_area = get_fb_unmapped_area,
.fsync =fb_deferred_io_fsync,
};
Not possible after unregister:
fb_open() -> fb_ops.fb_open
Protected by file_fb_info() (-ENODEV):
fb_read() -> fb_ops.fb_read : drm_fb_helper_sys_read()
fb_write() -> fb_ops.fb_write : drm_fb_helper_sys_write()
fb_ioctl() -> fb_ops.fb_ioctl : drm_fb_helper_ioctl()
fb_compat_ioctl() -> fb_ops.fb_compat_ioctl
fb_mmap() -> fb_ops.fb_mmap
Safe:
fb_release() -> fb_ops.fb_release
get_fb_unmapped_area() : info->screen_base
fb_deferred_io_fsync() : if (info->fbdefio) &info->deferred_work
Active mmap's will need the backing buffer to be present.
If deferred IO is used, mmap writes will via a worker generate calls to
drm_fb_helper_deferred_io() which in turn via a worker calls into
drm_fb_helper_dirty_work().
Secondly we look at the remaining struct fb_ops operations:
Called by fbcon:
- fb_ops.fb_fillrect : drm_fb_helper_{sys,cfb}_fillrect()
- fb_ops.fb_copyarea : drm_fb_helper_{sys,cfb}_copyarea()
- fb_ops.fb_imageblit : drm_fb_helper_{sys,cfb}_imageblit()
Called in fb_set_var() which is called from ioctl, sysfs and fbcon:
- fb_ops.fb_check_var : drm_fb_helper_check_var()
- fb_ops.fb_set_par : drm_fb_helper_set_par()
drm_fb_helper_set_par() is also called from drm_fb_helper_hotplug_event().
Called in fb_set_cmap() which is called from fb_set_var(), ioctl
and fbcon:
- fb_ops.fb_setcolreg
- fb_ops.fb_setcmap : drm_fb_helper_setcmap()
Called in fb_blank() which is called from ioctl and fbcon:
- fb_ops.fb_blank : drm_fb_helper_blank()
Called in fb_pan_display() which is called from fb_set_var(), ioctl,
sysfs and fbcon:
- fb_ops.fb_pan_display : drm_fb_helper_pan_display()
Called by fbcon:
- fb_ops.fb_cursor
Called in fb_read(), fb_write(), and fb_get_buffer_offset() which is
called by fbcon:
- fb_ops.fb_sync
Called by fb_set_var():
- fb_ops.fb_get_caps
Called by fbcon:
- fb_ops.fb_debug_enter : drm_fb_helper_debug_enter()
- fb_ops.fb_debug_leave : drm_fb_helper_debug_leave()
Destroy is safe
- fb_ops.fb_destroy
Finally we look at other call paths:
drm_fb_helper_set_suspend{_unlocked}() and
drm_fb_helper_resume_worker():
Calls into fb_set_suspend(), but that's fine since it just uses the
fbdev notifier.
drm_fb_helper_restore_fbdev_mode_unlocked():
Called from drm_driver.last_close, possibly after drm_fb_helper_fini().
drm_fb_helper_force_kernel_mode():
Triggered by sysrq, possibly after unplug, but before
drm_fb_helper_fini().
drm_fb_helper_hotplug_event():
Called by drm_kms_helper_hotplug_event(). I don't know if this can be
called after drm_dev_unregister(), so add a check to be safe.
Based on this analysis the following functions get a
drm_dev_is_unplugged() check:
- drm_fb_helper_restore_fbdev_mode_unlocked()
- drm_fb_helper_force_kernel_mode()
- drm_fb_helper_hotplug_event()
- drm_fb_helper_dirty_work()
Signed-off-by: Noralf Trønnes
You're mixing in the new simple fbdev helper helpers as a bonus, that's
two things in one patch and makes it harder to review what's really going
on.
My gut feeling is that when we need a helper for the helper the original
helper needs to be improved, but I think that's much easier to decide when
it's a separate patch. Splitting things out would definitely make this
patch much smaller and easier to understand and review.
The only reason for the simple helpers that I could find is the
drm_dev_ref/unref, we should be able to do that in one of the existing
callbacks.
The reason I did that is because I couldn't put it in the existing
helpers since the framebuffer is removed after drm_fb_helper_fini() and
I can't drop the ref on drm_device before the framebuffer is gone.
I can split the patch in two:
1. Add drm_dev_is_unplugged() checks
2. Add drm_fb_helper_simple_init/fini() and drm_fb_helper_fb_destroy()
Maybe there's a way to remove the
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #10 from Walther Pelser (w.pel...@web.de) --- (In reply to Alex Deucher from comment #8) > The only reason the firmware would fail to load is if it's not available. > From the log, it shows direct fw loading failed. Did you build radeon into > your kernel rather than as a module? If so, you need to build the firmware > into your kernel as well. This is an argument, which belongs to my own kernel. I learned from https://wiki.gentoo.org/wiki/Radeon that these 3 firmware files are needed to be build-in in my own localyesconfig kernel. So far, I did not do so. But i filed this bug, because I found an openSUSE kernel with the described problems. -- 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 102468] RX470 powerplay issues on hybrid laptop system (dGPU does not power down)
https://bugs.freedesktop.org/show_bug.cgi?id=102468 Bug ID: 102468 Summary: RX470 powerplay issues on hybrid laptop system (dGPU does not power down) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: taij...@posteo.de Created attachment 133866 --> https://bugs.freedesktop.org/attachment.cgi?id=133866&action=edit relevant dmesg output I have an Alienware 15R3 laptop with hybrid Intel (HD 630) / AMD (RX470) graphics. I run Arch Linux, up to date as of 2017-08-29. My issue is that when booting the laptop with a 'normal' kernel command line, the dGPU *never* turns off, even when it is not normally needed in desktop operations. This is confirmed by running powertop, which reports a power drain of ~36 W even under basically zero load. This is accompanied by various [powerplay] error messages in dmesg. As a side effect, the CPU is blocked from going to power states below pc2. If I blacklist amdgpu in the kcl and then force the dGPU to off with acpi_call, the reported power consumption in powertop drops to ~12 W, with a corresponding increase in battery time. The CPU is now able to reach pc3. Booting into Windows 10 also gives me the same battery time as blacklisting amdgpu in Linux, but also the expected 'on-demand-switching' of the dGPU that I expect from such a setup. This is just to confirm that this is not a hardware issue - it is definitely possible to dynamically switch the dGPU on or off from the OS level, the implementation is just botched in amdgpu. -- 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 102468] RX470 powerplay issues on hybrid laptop system (dGPU does not power down)
https://bugs.freedesktop.org/show_bug.cgi?id=102468 --- Comment #1 from Alex Deucher --- (In reply to taijian from comment #0) > If I blacklist amdgpu in the kcl and then force the dGPU to off with > acpi_call, the reported power consumption in powertop drops to ~12 W, with a > corresponding increase in battery time. The CPU is now able to reach pc3. What acpi call did you use? -- 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 v7 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS
On Wed, Aug 23, 2017 at 02:26:59PM +0800, Sandy Huang wrote: > This patch add Document for Rockchip Soc RK3288 LVDS, > This based on the patches from Mark yao and Heiko Stuebner. > > Signed-off-by: Sandy Huang > Signed-off-by: Mark yao > Signed-off-by: Heiko Stuebner > --- > > Changes according to Rob Herring's review. > > .../bindings/display/rockchip/rockchip-lvds.txt| 99 > ++ > 1 file changed, 99 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/6] drm/fb-cma-helper: Support device unplug
Den 28.08.2017 23.46, skrev Daniel Vetter:
On Mon, Aug 28, 2017 at 07:17:45PM +0200, Noralf Trønnes wrote:
Add drm_fbdev_cma_dev_unplug() and use the drm_fb_helper device unplug
support. Pin driver module on fb_open().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 139 +---
include/drm/drm_fb_cma_helper.h | 1 +
2 files changed, 68 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f2ee883..2b044be 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -25,8 +25,6 @@
#include
#include
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
const struct drm_framebuffer_funcs *fb_funcs;
@@ -238,6 +236,34 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
#endif
+static int drm_fbdev_cma_fb_open(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+
+ /*
+* The fb_ops definition resides in this library, meaning fb_open()
+* will take a ref on the library instead of the driver. Make sure the
+* driver module is pinned. Skip fbcon (user==0) since it can detach
+* itself on unregister_framebuffer().
+*/
+ if (user && !try_module_get(dev->driver->fops->owner))
+ return -ENODEV;
I thought we've fixed this by redoing the fb_ops as a macro? Maybe tinydrm
isn't fixed yet, but then we need to fix up tinydrm. This here otoh kinda
smells a bit like a hack ...
If we need it, then I'd vote to put it into the fbdev helpers, not the cma
specific parts.
This is only necessary in this library atm because it contains this:
static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
Other drivers have this definition in their own module, so fb_open()
takes a ref on the right module.
My shmem gem library will also wrap struct fb_ops and needs to do this.
I can add them to drm_fb_helper with a note that they should only be
used by libraries.
Yes it's kind of a hack, but I find the cma library is very nice in this
respect, that it makes fbdev emulation very easy for drivers. It wraps
up basic fbdev in 3 function calls.
If we were to do this strictly by the book, we would have to add
something like this to every cma driver:
DEFINE_DRM_FBDEV_CMA_FB_OPS(driver_fb_ops);
static int driver_fb_probe(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
return drm_fbdev_cma_create(helper, sizes, &driver_fb_ops);
}
static const struct drm_fb_helper_funcs driver_helper_funcs = {
.fb_probe = driver_fb_probe,
};
static int driver_fbdev_init()
{
- fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count);
+ fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count,
+ &driver_helper_funcs);
}
Well, maybe not so bad after all :-)
Maybe I should do it like this in the shmem gem library.
I can't do refactoring like this, this time around. I need to do that
shmem gem library before I run out of steam. A refactoring like this
will have to wait to later.
+
+ return 0;
+}
+
+static int drm_fbdev_cma_fb_release(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+
+ if (user)
+ module_put(dev->driver->fops->owner);
+
+ return 0;
+}
+
static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
return dma_mmap_writecombine(info->device, vma, info->screen_base,
@@ -247,10 +273,13 @@ static int drm_fb_cma_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
+ .fb_open= drm_fbdev_cma_fb_open,
+ .fb_release = drm_fbdev_cma_fb_release,
.fb_fillrect= drm_fb_helper_sys_fillrect,
.fb_copyarea= drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
.fb_mmap= drm_fb_cma_mmap,
+ .fb_destroy = drm_fb_helper_fb_destroy,
};
static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
@@ -262,52 +291,26 @@ static int drm_fbdev_cma_deferred_io_mmap(struct fb_info
*info,
return 0;
}
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
+static int drm_fbdev_cma_defio_init(struct drm_fb_helper *helper,
struct drm_gem_cma_object *cma_obj)
{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
+ struct fb_info *fbi = helper->fbdev;
+ int ret;
- /*
-* Per device structures are needed because:
-* fbop
Re: [PATCH v2 resend] drm/panel: Add driver for Seiko 43WVF1G panel
Hi Thierry, On Fri, Aug 18, 2017 at 12:08 PM, Thierry Reding wrote: > I've applied, though somewhat reluctantly, this to drm-misc-next without > Rob's Acked-by, but the device tree bindings look trivial enough. Was it really applied? I am not able to find this patch in linux-next. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Why shmem?
Daniel Vetter writes: > On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes wrote: >> Hi, >> >> Currently I'm using the cma library with tinydrm because it was so >> simple to use even though I have to work around the fact that reads are >> uncached. A bigger problem that I have become aware of, is that it >> restricts the dma buffers it can import since they have to be continous. >> >> So I looked to udl and it uses shmem. Fine, let's make a shmem gem >> library similar to the cma library. >> >> Now I have done so and have started to think about the DOC: section, >> explaining what the library does. And I'm stuck, what's the benefit of >> using shmem compared to just using alloc_page()? > > Gives you swapping (and eventually maybe even migration) since there's > a real filesystem behind it. Atm this only works if you register a > shrinker callback, which for display drivers is a bit overkill. See > i915 or msm for examples (or ttm, if you want an entire fancy > framework), and git grep shrinker -- drivers/gpu. The shrinker is only needed if you need some impetus to unbind objects from your page tables, right? If you're just binding the pages for the moment that you're doing SPI transfers to the display, then in the remaining time it could be swapped out, right? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm/tinydrm: Support device unplug
Den 28.08.2017 23.58, skrev Daniel Vetter: Hi Noralf, On Mon, Aug 28, 2017 at 07:17:42PM +0200, Noralf Trønnes wrote: This adds device unplug support to drm_fb_helper, drm_fb_cma_helper (fbdev) and tinydrm. My motivation for doing this is to make tinydrm useable with USB devices. This discussion gave insight into the problem: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge. https://lists.freedesktop.org/archives/dri-devel/2017-August/149376.html Looks a lot less scary than I thought, but I think needs a bit more polish. I'm glad you made me look closer at unregister_framebuffer(), since it did handle this quite good. I was fooled by the 2 usb fbdev drivers that forked out unregistering to a worker. I think it'd be also great if you could co-evolve the udl driver to get this right, since it looks like right now it'll just oops when you unplug when userspace is using the fbdev emulation. That way we'd be at least somewhat consistent with unpluggable drivers, and since it's only 1 other it should be doable. Unplugging is already hard, having 2 drivers do stuff differently (when we only have 2 with unplug support) pretty much guarnatees we'll never get this right. I turns out that udl by default doesn't use fbdev mmap deferred io, because it interferes with shmem's use of page->lru. This means that no one uses it and since fbcon detaches itself on unregister_framebuffer(), udl is in the clear with regards to fbdev. In my shmem gem library I'll work around the page->lru issue by using a shadow fbdev buffer. Since the library will have code from udl, I reckon that udl can switch to using it. Noralf. But maybe good to first develop this using your own driver only. Cheers, Daniel Noralf. Noralf Trønnes (6): drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend() drm/fb-helper: Support device unplug drm/fb-cma-helper: Support device unplug drm/tinydrm: Embed drm_device in tinydrm_device drm/tinydrm/mi0283qt: Let the display pipe handle power drm/tinydrm: Support device unplug drivers/gpu/drm/drm_fb_cma_helper.c | 139 +-- drivers/gpu/drm/drm_fb_helper.c | 207 +++- drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 109 ++- drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- drivers/gpu/drm/tinydrm/mi0283qt.c | 77 +++ drivers/gpu/drm/tinydrm/mipi-dbi.c | 27 ++-- drivers/gpu/drm/tinydrm/repaper.c | 19 ++- drivers/gpu/drm/tinydrm/st7586.c| 25 ++-- include/drm/drm_fb_cma_helper.h | 1 + include/drm/drm_fb_helper.h | 35 + include/drm/tinydrm/tinydrm.h | 14 +- 11 files changed, 460 insertions(+), 195 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102468] RX470 powerplay issues on hybrid laptop system (dGPU does not power down)
https://bugs.freedesktop.org/show_bug.cgi?id=102468 --- Comment #2 from taij...@posteo.de --- I followed the recommendations of this page: https://wiki.archlinux.org/index.php/Hybrid_graphics The call working on my system is: echo "\\_SB.PCI0.PEG0.PEGP._OFF" > /proc/acpi/call If I use this command on a system that does not have amdgpu blacklisted, however, this will lead to unstable system behaviour and a certain crash within ~5 min. -- 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 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 Walther Pelser (w.pel...@web.de) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #11 from Walther Pelser (w.pel...@web.de) --- (In reply to Takashi Iwai from comment #9) > I guess it's module since Walther is using SUSE kernels. > > Could you give the full dmesg output from 4.13.0-rc6-vanilla you've > installed recently? That has the firmware file in initrd as in comment 6, > we can double-check it. There were a lot of updates the last few days for tumblewwed, the latest came from http://download.opensuse.org/update/tumbleweed/ with a updates for Mesa and libvdpau. Maybe this is the reason why: I have to write, that this bug will be closed as fixed. Today kernel 4.13.0-rc6-vanilla boots without problems for the first time! Thank you for your time, but I could not know this development before. P.S. "full dmesg output" seems to be obsolete now. -- 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
Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device
On 08/28/2017 12:17 PM, Noralf Trønnes wrote: Might as well embed drm_device since tinydrm_device (embeds pipe struct and fbdev pointer) needs to stick around after driver-device unbind to handle open fd's after device removal. Cc: David Lechner Signed-off-by: Noralf Trønnes Acked-By: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu and ttm drm-next-4.14
Hi Dave, A few fixes for drm-next for 4.14. Nothing too major. I'll check in again in a week or so. The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f: Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next (2017-08-23 05:32:26 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.14 for you to fetch changes up to 403df1f66cc0457221f3be5c210f128ab87de547: drm/amdgpu: remove duplicate return statement (2017-08-24 14:27:44 -0400) Alex Deucher (5): drm/amdgpu/gfx8: fix spelling typo in mqd allocation drm/amdgpu: add automatic per asic settings for gart_size drm/amdgpu: refine default gart size drm/amdgpu: move default gart size setting into gmc modules drm/amdgpu: set sched_hw_submission higher for KIQ (v3) Christian König (5): drm/amdgpu: fix and cleanup shadow handling drm/amdgpu: discard commands of killed processes drm/amdgpu: remove the GART copy hack drm/amdgpu: fix amdgpu_ttm_bind drm/amdgpu: inline amdgpu_ttm_do_bind again Christophe JAILLET (1): drm/amdgpu: check memory allocation failure Colin Ian King (1): drm/amdgpu: remove duplicate return statement Emily Deng (1): drm/amdgpu/virtual_dce: Virtual display doesn't support disable vblank immediately Evan Quan (2): drm/amd/powerplay: unhalt mec after loading drm/amd/powerplay: ACG frequency added in PPTable Felix Kuehling (1): drm/amdgpu: Fix huge page updates with CPU Monk Liu (2): drm/ttm: fix missing inc bo_count drm/ttm:fix wrong decoding of bo_count Roger He (1): drm/amd/amdgpu: fix BANK_SELECT on Vega10 (v2) drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 12 drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 14 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 46 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 16 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 76 -- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 4 -- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 46 ++--- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 12 ++-- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 5 +- drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 19 +- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 22 ++- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 21 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 16 - drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 5 +- drivers/gpu/drm/amd/include/vi_structs.h | 4 +- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 +++- drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h | 6 +- drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 3 +- drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 23 +-- drivers/gpu/drm/ttm/ttm_bo.c | 4 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 1 + 28 files changed, 236 insertions(+), 156 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree
Reviewed-by: Rex Zhu mailto:rex@amd.com>>
Best Regards
Rex
From: Wentland, Harry
Sent: Tuesday, August 29, 2017 9:34:01 PM
To: Himanshu Jha; airl...@linux.ie
Cc: linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; Deucher, Alexander; Zhu, Rex; Koenig, Christian
Subject: Re: [PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree
On 2017-08-29 09:12 AM, Himanshu Jha wrote:
> kfree on NULL pointer is a no-op and therefore checking is redundant.
>
> Signed-off-by: Himanshu Jha
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
> .../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96
> --
> drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 +--
> 4 files changed, 56 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> index bc839ff..9f2c037 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
> @@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr
> *hwmgr)
>phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
>phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
>
> - if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
> - kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> - hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
> + hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
>
>kfree(hwmgr->backend);
>hwmgr->backend = NULL;
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> index 2716721..a6dbc55 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
> @@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr
> *hwmgr)
>if (hwmgr->chip_id == CHIP_RAVEN)
>return 0;
>
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> - hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
> + hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> - hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
> + hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> - hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
> + hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
> - kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> - hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
> - }
> + kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
> + hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
>
> - if (NULL != hwmgr->dyn_state.valid_mclk_values) {
> - kfree(hwmgr->dyn_state.valid_mclk_values);
> - hwmgr->dyn_state.valid_mclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_mclk_values);
> + hwmgr->dyn_state.valid_mclk_values = NULL;
>
> - if (NULL != hwmgr->dyn_state.valid_sclk_values) {
> - kfree(hwmgr->dyn_state.valid_sclk_values);
> - hwmgr->dyn_state.valid_sclk_values = NULL;
> - }
> + kfree(hwmgr->dyn_state.valid_sclk_values);
> + hwmgr->dyn_state.valid_sclk_values = NULL;
>
> - if (NULL != hwmgr->dyn_state.cac_leakage_table) {
> - kfree(hwmgr->dyn_state.cac_leakage_table);
> - hwmgr->dyn_state.cac_leakage_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.cac_leakage_table);
> + hwmgr->dyn_state.cac_leakage_table = NULL;
>
> - if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
> - kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> - hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
> - }
> + kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
> + hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
>
> - if (NULL != hwmgr->dyn_state.vce_clock_voltage_dependency_table) {
> - kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
> - hwmgr->dyn_state.vce
Re: [PATCH] drm/amd: Remove null check before kfree
On Tue, Aug 29, 2017 at 9:28 AM, Christian König
wrote:
> Am 29.08.2017 um 15:21 schrieb Himanshu Jha:
>>
>> Kfree on NULL pointer is a no-op and therefore checking is redundant.
>>
>> Signed-off-by: Himanshu Jha
>
>
> Reviewed-by: Christian König
>
Applied. thanks!
Alex
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++
>> drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++
>> 2 files changed, 4 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> index 8d1cf2d..f51b41f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>> @@ -346,10 +346,8 @@ static void amdgpu_connector_free_edid(struct
>> drm_connector *connector)
>> {
>> struct amdgpu_connector *amdgpu_connector =
>> to_amdgpu_connector(connector);
>> - if (amdgpu_connector->edid) {
>> - kfree(amdgpu_connector->edid);
>> - amdgpu_connector->edid = NULL;
>> - }
>> + kfree(amdgpu_connector->edid);
>> + amdgpu_connector->edid = NULL;
>> }
>> static int amdgpu_connector_ddc_get_modes(struct drm_connector
>> *connector)
>> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
>> b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
>> index 76347ff..00075c2 100644
>> --- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
>> @@ -606,10 +606,8 @@ int smu7_init(struct pp_smumgr *smumgr)
>> int smu7_smu_fini(struct pp_smumgr *smumgr)
>> {
>> - if (smumgr->backend) {
>> - kfree(smumgr->backend);
>> - smumgr->backend = NULL;
>> - }
>> + kfree(smumgr->backend);
>> + smumgr->backend = NULL;
>> cgs_rel_firmware(smumgr->device, CGS_UCODE_ID_SMU);
>> return 0;
>> }
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree
On Tue, Aug 29, 2017 at 9:34 AM, Harry Wentland wrote:
> On 2017-08-29 09:12 AM, Himanshu Jha wrote:
>> kfree on NULL pointer is a no-op and therefore checking is redundant.
>>
>> Signed-off-by: Himanshu Jha
>
> Reviewed-by: Harry Wentland
Applied. thanks!
Alex
>
> Harry
>
>> ---
>> drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
>> .../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96
>> --
>> drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52
>> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 +--
>> 4 files changed, 56 insertions(+), 110 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
>> index bc839ff..9f2c037 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
>> @@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr
>> *hwmgr)
>> phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
>> phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
>>
>> - if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
>> - kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
>> - hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
>> + hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
>>
>> kfree(hwmgr->backend);
>> hwmgr->backend = NULL;
>> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
>> b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
>> index 2716721..a6dbc55 100644
>> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
>> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
>> @@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr
>> *hwmgr)
>> if (hwmgr->chip_id == CHIP_RAVEN)
>> return 0;
>>
>> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
>> - kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
>> - hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
>> + hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
>> - kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
>> - hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
>> + hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
>> - kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
>> - hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
>> + hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
>> - kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
>> - hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
>> + hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.valid_mclk_values) {
>> - kfree(hwmgr->dyn_state.valid_mclk_values);
>> - hwmgr->dyn_state.valid_mclk_values = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.valid_mclk_values);
>> + hwmgr->dyn_state.valid_mclk_values = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.valid_sclk_values) {
>> - kfree(hwmgr->dyn_state.valid_sclk_values);
>> - hwmgr->dyn_state.valid_sclk_values = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.valid_sclk_values);
>> + hwmgr->dyn_state.valid_sclk_values = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.cac_leakage_table) {
>> - kfree(hwmgr->dyn_state.cac_leakage_table);
>> - hwmgr->dyn_state.cac_leakage_table = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.cac_leakage_table);
>> + hwmgr->dyn_state.cac_leakage_table = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
>> - kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
>> - hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
>> + hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.vce_clock_voltage_dependency_table) {
>> - kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
>> - hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
>> - }
>> + kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
>> + hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
>>
>> - if (NULL != hwmgr->dyn_state.uvd_clock_vo
[Git PULL] vmwgfx-fixes
Hi Dave, The following changes since commit cc4a41fe5541a73019a864883297bd5043aa6d98: Linux 4.13-rc7 (2017-08-27 17:20:40 -0700) are available in the git repository at: git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-fixes for you to fetch changes up to 021aba761f2a6c12158afb9993524c300c01fae2: drm/vmwgfx: Fix F26 Wayland screen update issue (2017-08-29 23:19:03 +0200) Sinclair Yeh (1): drm/vmwgfx: Fix F26 Wayland screen update issue drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 68/819] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:154:10: error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a function)
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: ff14f0dca1f23b2cff41e43440c7952965e5fc1b
commit: 9b37a9b8f6464e3ce1ce59eda1ec7053c8e77ca3 [68/819] drm/amd/dc: Add dc
display driver (v2)
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9b37a9b8f6464e3ce1ce59eda1ec7053c8e77ca3
# save the attached .config to linux build tree
make.cross ARCH=ia64
Note: the radeon-alex/amd-staging-drm-next HEAD
ff14f0dca1f23b2cff41e43440c7952965e5fc1b builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:154:10:
>> error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a
>> function)
.dpms = drm_atomic_helper_connector_dpms,
^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:159:18:
>> error: 'drm_atomic_helper_connector_set_property' undeclared here (not in a
>> function)
.set_property = drm_atomic_helper_connector_set_property,
^~~~
vim +/drm_atomic_helper_connector_dpms +154
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c
152
153 static const struct drm_connector_funcs dm_dp_mst_connector_funcs = {
> 154 .dpms = drm_atomic_helper_connector_dpms,
155 .detect = dm_dp_mst_detect,
156 .fill_modes = drm_helper_probe_single_connector_modes,
157 .destroy = dm_dp_mst_connector_destroy,
158 .reset = amdgpu_dm_connector_funcs_reset,
> 159 .set_property = drm_atomic_helper_connector_set_property,
160 .atomic_duplicate_state =
amdgpu_dm_connector_atomic_duplicate_state,
161 .atomic_destroy_state =
drm_atomic_helper_connector_destroy_state,
162 .atomic_set_property = amdgpu_dm_connector_atomic_set_property
163 };
164
---
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: [radeon-alex:amd-staging-drm-next 68/819] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:154:10: error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a function
I've send a related kernel crash log to amd-devel some days ago without any answer, yet... Was: [amd-staging-drm-next] kernel crash with amdgpu on RX580 in 'drm_object_property_get_value' I get this in _all_ current 'amd-staging-drm-next' versions. ;-( [16301.515079] [ cut here ] [16301.515105] WARNING: CPU: 4 PID: 11871 at drivers/gpu/drm/drm_mode_object.c:294 drm_object_property_get_value+0x22/0x30 [drm] [16301.515106] Modules linked in: fuse rfcomm nf_log_ipv6 xt_comment nf_log_ipv4 nf_log_common xt_LOG xt_limit rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd nfnetlink_cthelper grace nfnetlink sunrpc fscache af_packet ipmi_ssif iscsi_ibft iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 xt_pkttype xt_tcpudp iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack libcrc32c ip6table_filter ip6_tables x_tables jc42 bnep joydev snd_hda_codec_hdmi snd_hda_intel snd_hda_codec btusb snd_hwdep btrtl snd_hda_core btbcm btintel bluetooth snd_pcm e1000e intel_powerclamp iTCO_wdt snd_timer coretemp iTCO_vendor_support hid_generic snd ptp kvm_intel pps_core rfkill [16301.515129] kvm ecdh_generic tpm_infineon soundcore irqbypass tpm_tis tpm_tis_core crc32c_intel pcspkr shpchp ipmi_si tpm usbhid i2c_i801 i7core_edac lpc_ich ipmi_devintf ipmi_msghandler ac button acpi_cpufreq tcp_bbr raid1 md_mod amdkfd amd_iommu_v2 serio_raw sr_mod cdrom amdgpu mpt3sas i2c_algo_bit raid_class scsi_transport_sas drm_kms_helper syscopyarea sysfillrect ehci_pci sysimgblt fb_sys_fops ehci_hcd ttm usbcore drm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua [16301.515147] CPU: 4 PID: 11871 Comm: X Tainted: GW 4.13.0-rc5-1.g7262353-default+ #1 [16301.515148] Hardware name: FUJITSU PRIMERGY TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1 09/26/2012 [16301.515149] task: 90c49525a180 task.stack: b84786ef4000 [16301.515156] RIP: 0010:drm_object_property_get_value+0x22/0x30 [drm] [16301.515157] RSP: 0018:b84786ef7bf8 EFLAGS: 00010282 [16301.515158] RAX: c03f0cc0 RBX: 90c52200 RCX: [16301.515158] RDX: b84786ef7c10 RSI: 90c523837600 RDI: 90c523b19028 [16301.515159] RBP: b84786ef7bf8 R08: 90c41ee28280 R09: 90c515defc00 [16301.515159] R10: 00024bb8 R11: R12: [16301.515160] R13: 90c523b19000 R14: ffea R15: 90c511e8c100 [16301.515161] FS: 7f86f15c9a40() GS:90c53fd0() knlGS: [16301.515162] CS: 0010 DS: ES: CR0: 80050033 [16301.515162] CR2: 000849a98680 CR3: 0005dcc1a000 CR4: 06e0 [16301.515163] Call Trace: [16301.515255] amdgpu_dm_connector_atomic_set_property+0xe8/0x150 [amdgpu] [16301.515292] drm_atomic_set_property+0x164/0x470 [drm] [16301.515300] drm_mode_obj_set_property_ioctl+0x10b/0x240 [drm] [16301.515311] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] [16301.515318] drm_mode_connector_property_set_ioctl+0x30/0x40 [drm] [16301.515324] drm_ioctl_kernel+0x5d/0xb0 [drm] [16301.515332] drm_ioctl+0x31a/0x3d0 [drm] [16301.515339] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] [16301.515342] ? ext4_file_write_iter+0xba/0x390 [16301.515362] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [16301.515365] do_vfs_ioctl+0x92/0x5c0 [16301.515367] ? __fget+0x6e/0x90 [16301.515368] SyS_ioctl+0x79/0x90 [16301.515372] entry_SYSCALL_64_fastpath+0x1e/0xa9 [16301.515373] RIP: 0033:0x7f86eef46507 [16301.515373] RSP: 002b:7fffe5f9dca8 EFLAGS: 3246 ORIG_RAX: 0010 [16301.515374] RAX: ffda RBX: 00084aeea990 RCX: 7f86eef46507 [16301.515375] RDX: 7fffe5f9dce0 RSI: c01064ab RDI: 000d [16301.515375] RBP: 00084b50d830 R08: 00084b07d690 R09: 0001 [16301.515376] R10: 0004 R11: 3246 R12: 00084aeea990 [16301.515376] R13: 0005 R14: 00084aeeedd0 R15: 00084aeeedd0 [16301.515377] Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 46 60 55 48 89 e5 48 8b 80 70 03 00 00 48 83 78 20 00 75 07 e8 60 ff ff ff 5d c3 <0f> ff e8 57 ff ff ff 5d c3 0f 1f 44 00 00 66 66 66 66 90 55 48 [16301.515394] ---[ end trace f957c1d5844ce46f ]--- Thanks, Dieter Am 30.08.2017 00:22, schrieb kbuild test robot: tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: ff14f0dca1f23b2cff41e43440c7952965e5fc1b commit: 9b37a9b8f6464e3ce1ce59eda1ec7053c8e77ca3 [68/819] drm/amd/dc: Add dc display driver (v2) config: ia64-allyesconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
[PATCH 00/13] mmu_notifier kill invalidate_page callback
(Sorry for so many list cross-posting and big cc) Please help testing ! The invalidate_page callback suffered from 2 pitfalls. First it used to happen after page table lock was release and thus a new page might have been setup for the virtual address before the call to invalidate_page(). This is in a weird way fixed by c7ab0d2fdc840266b39db94538f74207ec2afbf6 which moved the callback under the page table lock. Which also broke several existing user of the mmu_notifier API that assumed they could sleep inside this callback. The second pitfall was invalidate_page being the only callback not taking a range of address in respect to invalidation but was giving an address and a page. Lot of the callback implementer assumed this could never be THP and thus failed to invalidate the appropriate range for THP pages. By killing this callback we unify the mmu_notifier callback API to always take a virtual address range as input. There is now 2 clear API (I am not mentioning the youngess API which is seldomly used): - invalidate_range_start()/end() callback (which allow you to sleep) - invalidate_range() where you can not sleep but happen right after page table update under page table lock Note that a lot of existing user feels broken in respect to range_start/ range_end. Many user only have range_start() callback but there is nothing preventing them to undo what was invalidated in their range_start() callback after it returns but before any CPU page table update take place. The code pattern use in kvm or umem odp is an example on how to properly avoid such race. In a nutshell use some kind of sequence number and active range invalidation counter to block anything that might undo what the range_start() callback did. If you do not care about keeping fully in sync with CPU page table (ie you can live with CPU page table pointing to new different page for a given virtual address) then you can take a reference on the pages inside the range_start callback and drop it in range_end or when your driver is done with those pages. Last alternative is to use invalidate_range() if you can do invalidation without sleeping as invalidate_range() callback happens under the CPU page table spinlock right after the page table is updated. Note this is barely tested. I intend to do more testing of next few days but i do not have access to all hardware that make use of the mmu_notifier API. First 2 patches convert existing call of mmu_notifier_invalidate_page() to mmu_notifier_invalidate_range() and bracket those call with call to mmu_notifier_invalidate_range_start()/end(). The next 10 patches remove existing invalidate_page() callback as it can no longer happen. Finaly the last page remove it completely so it can RIP. Jérôme Glisse (13): dax: update to new mmu_notifier semantic mm/rmap: update to new mmu_notifier semantic powerpc/powernv: update to new mmu_notifier semantic drm/amdgpu: update to new mmu_notifier semantic IB/umem: update to new mmu_notifier semantic IB/hfi1: update to new mmu_notifier semantic iommu/amd: update to new mmu_notifier semantic iommu/intel: update to new mmu_notifier semantic misc/mic/scif: update to new mmu_notifier semantic sgi-gru: update to new mmu_notifier semantic xen/gntdev: update to new mmu_notifier semantic KVM: update to new mmu_notifier semantic mm/mmu_notifier: kill invalidate_page Cc: Kirill A. Shutemov Cc: Linus Torvalds Cc: Andrew Morton Cc: Andrea Arcangeli Cc: Joerg Roedel Cc: Dan Williams Cc: Sudeep Dutt Cc: Ashutosh Dixit Cc: Dimitri Sivanich Cc: Jack Steiner Cc: Paolo Bonzini Cc: Radim Krčmář Cc: linuxppc-...@lists.ozlabs.org Cc: dri-devel@lists.freedesktop.org Cc: amd-...@lists.freedesktop.org Cc: linux-r...@vger.kernel.org Cc: io...@lists.linux-foundation.org Cc: xen-de...@lists.xenproject.org Cc: k...@vger.kernel.org arch/powerpc/platforms/powernv/npu-dma.c | 10 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 31 -- drivers/infiniband/core/umem_odp.c | 19 -- drivers/infiniband/hw/hfi1/mmu_rb.c | 9 --- drivers/iommu/amd_iommu_v2.c | 8 -- drivers/iommu/intel-svm.c| 9 --- drivers/misc/mic/scif/scif_dma.c | 11 drivers/misc/sgi-gru/grutlbpurge.c | 12 - drivers/xen/gntdev.c | 8 -- fs/dax.c | 19 -- include/linux/mm.h | 1 + include/linux/mmu_notifier.h | 25 -- mm/memory.c | 26 +++ mm/mmu_notifier.c| 14 -- mm/rmap.c| 44 +--- virt/kvm/kvm_main.c | 42 -- 16 files changed, 74 insertions(+), 214 deletions(-) -- 2.13.5 ___ dri-devel mailing list dri-devel
Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback
On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > Note this is barely tested. I intend to do more testing of next few days > but i do not have access to all hardware that make use of the mmu_notifier > API. Thanks for doing this. > First 2 patches convert existing call of mmu_notifier_invalidate_page() > to mmu_notifier_invalidate_range() and bracket those call with call to > mmu_notifier_invalidate_range_start()/end(). Ok, those two patches are a bit more complex than I was hoping for, but not *too* bad. And the final end result certainly looks nice: > 16 files changed, 74 insertions(+), 214 deletions(-) Yeah, removing all those invalidate_page() notifiers certainly makes for a nice patch. And I actually think you missed some more lines that can now be removed: kvm_arch_mmu_notifier_invalidate_page() should no longer be needed either, so you can remove all of those too (most of them are empty inline functions, but x86 has one that actually does something. So there's an added 30 or so dead lines that should be removed in the kvm patch, I think. But from a _very_ quick read-through this looks fine. But it obviously needs testing. People - *especially* the people who saw issues under KVM - can you try out Jérôme's patch-series? I aded some people to the cc, the full series is on lkml. Jérôme - do you have a git branch for people to test that they could easily pull and try out? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay/hwmgr: Remove null check before kfree
kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 6 +-
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 96 --
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 52
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 12 +--
4 files changed, 56 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index bc839ff..9f2c037 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -1225,10 +1225,8 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr *hwmgr)
phm_destroy_table(hwmgr, &(hwmgr->power_down_asic));
phm_destroy_table(hwmgr, &(hwmgr->setup_asic));
- if (NULL != hwmgr->dyn_state.vddc_dep_on_dal_pwrl) {
- kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
- hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dep_on_dal_pwrl);
+ hwmgr->dyn_state.vddc_dep_on_dal_pwrl = NULL;
kfree(hwmgr->backend);
hwmgr->backend = NULL;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
index 2716721..a6dbc55 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
@@ -1615,85 +1615,53 @@ static int pp_tables_uninitialize(struct pp_hwmgr
*hwmgr)
if (hwmgr->chip_id == CHIP_RAVEN)
return 0;
- if (NULL != hwmgr->dyn_state.vddc_dependency_on_sclk) {
- kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
- hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dependency_on_sclk);
+ hwmgr->dyn_state.vddc_dependency_on_sclk = NULL;
- if (NULL != hwmgr->dyn_state.vddci_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
- hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddci_dependency_on_mclk);
+ hwmgr->dyn_state.vddci_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.vddc_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
- hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_dependency_on_mclk);
+ hwmgr->dyn_state.vddc_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.mvdd_dependency_on_mclk) {
- kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
- hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
- }
+ kfree(hwmgr->dyn_state.mvdd_dependency_on_mclk);
+ hwmgr->dyn_state.mvdd_dependency_on_mclk = NULL;
- if (NULL != hwmgr->dyn_state.valid_mclk_values) {
- kfree(hwmgr->dyn_state.valid_mclk_values);
- hwmgr->dyn_state.valid_mclk_values = NULL;
- }
+ kfree(hwmgr->dyn_state.valid_mclk_values);
+ hwmgr->dyn_state.valid_mclk_values = NULL;
- if (NULL != hwmgr->dyn_state.valid_sclk_values) {
- kfree(hwmgr->dyn_state.valid_sclk_values);
- hwmgr->dyn_state.valid_sclk_values = NULL;
- }
+ kfree(hwmgr->dyn_state.valid_sclk_values);
+ hwmgr->dyn_state.valid_sclk_values = NULL;
- if (NULL != hwmgr->dyn_state.cac_leakage_table) {
- kfree(hwmgr->dyn_state.cac_leakage_table);
- hwmgr->dyn_state.cac_leakage_table = NULL;
- }
+ kfree(hwmgr->dyn_state.cac_leakage_table);
+ hwmgr->dyn_state.cac_leakage_table = NULL;
- if (NULL != hwmgr->dyn_state.vddc_phase_shed_limits_table) {
- kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
- hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
- }
+ kfree(hwmgr->dyn_state.vddc_phase_shed_limits_table);
+ hwmgr->dyn_state.vddc_phase_shed_limits_table = NULL;
- if (NULL != hwmgr->dyn_state.vce_clock_voltage_dependency_table) {
- kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
- hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
- }
+ kfree(hwmgr->dyn_state.vce_clock_voltage_dependency_table);
+ hwmgr->dyn_state.vce_clock_voltage_dependency_table = NULL;
- if (NULL != hwmgr->dyn_state.uvd_clock_voltage_dependency_table) {
- kfree(hwmgr->dyn_state.uvd_clock_voltage_dependency_table);
- hwmgr->dyn_state.uvd_clock_voltage_dependency_table = NULL;
- }
+ kfree(hwmgr->dyn_state.uvd_clock_voltage_dependency_table);
+ hwmgr->dyn_state.uvd_clock_voltage_dependency_table = NULL;
-
[PATCH] drm/amdkfd: remove memset before memcpy
calling memcpy immediately after memset with the same region of memory makes memset redundant. Signed-off-by: Himanshu Jha --- drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c index 1cae95e..03bec76 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c @@ -143,7 +143,6 @@ int pqm_create_queue(struct process_queue_manager *pqm, int num_queues = 0; struct queue *cur; - memset(&q_properties, 0, sizeof(struct queue_properties)); memcpy(&q_properties, properties, sizeof(struct queue_properties)); q = NULL; kq = NULL; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd: Remove null check before kfree
Kfree on NULL pointer is a no-op and therefore checking is redundant.
Signed-off-by: Himanshu Jha
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 6 ++
drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8d1cf2d..f51b41f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -346,10 +346,8 @@ static void amdgpu_connector_free_edid(struct
drm_connector *connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
- if (amdgpu_connector->edid) {
- kfree(amdgpu_connector->edid);
- amdgpu_connector->edid = NULL;
- }
+ kfree(amdgpu_connector->edid);
+ amdgpu_connector->edid = NULL;
}
static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index 76347ff..00075c2 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -606,10 +606,8 @@ int smu7_init(struct pp_smumgr *smumgr)
int smu7_smu_fini(struct pp_smumgr *smumgr)
{
- if (smumgr->backend) {
- kfree(smumgr->backend);
- smumgr->backend = NULL;
- }
+ kfree(smumgr->backend);
+ smumgr->backend = NULL;
cgs_rel_firmware(smumgr->device, CGS_UCODE_ID_SMU);
return 0;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts
On Tue, Aug 29, 2017 at 4:52 AM, Hoegeun Kwon wrote:
> Hi Krzysztof,
>
> The driver has been merged into exynos-drm-misc.
> Could you please check this patch(3/3).
Hi, OK, no problems for me but it is too late for current cycle so it
will go in for v4.15.
Best regards,
Krzysztof
>
> Best regards,
> Hoegeun
>
>
> On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:
>>
>> The display-timing and delay are included in the panel driver. So it
>> should be removed in dts.
>>
>> Signed-off-by: Hoegeun Kwon
>> ---
>> arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
>> 1 file changed, 22 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>> index 443e0c9..6b70c8d 100644
>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>> @@ -242,28 +242,6 @@
>> vci-supply = <&ldo20_reg>;
>> reset-gpios = <&gpe0 1 GPIO_ACTIVE_LOW>;
>> te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
>> - power-on-delay= <30>;
>> - power-off-delay= <120>;
>> - reset-delay = <5>;
>> - init-delay = <100>;
>> - flip-horizontal;
>> - flip-vertical;
>> - panel-width-mm = <29>;
>> - panel-height-mm = <29>;
>> -
>> - display-timings {
>> - timing-0 {
>> - clock-frequency = <460>;
>> - hactive = <320>;
>> - vactive = <320>;
>> - hfront-porch = <1>;
>> - hback-porch = <1>;
>> - hsync-len = <1>;
>> - vfront-porch = <150>;
>> - vback-porch = <1>;
>> - vsync-len = <2>;
>> - };
>> - };
>> port {
>> dsi_in: endpoint {
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: omapdrm: hdmi: Use PTR_ERR_OR_ZERO
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Signed-off-by: Himanshu Jha --- drivers/gpu/drm/omapdrm/dss/hdmi4.c | 5 + drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 5 + drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 5 + drivers/gpu/drm/omapdrm/dss/hdmi_phy.c | 5 + 4 files changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c index f169348..3bf81e1 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c @@ -676,10 +676,7 @@ static int hdmi_audio_register(struct device *dev) dev, "omap-hdmi-audio", PLATFORM_DEVID_AUTO, &pdata, sizeof(pdata)); - if (IS_ERR(hdmi.audio_pdev)) - return PTR_ERR(hdmi.audio_pdev); - - return 0; + return PTR_ERR_OR_ZERO(hdmi.audio_pdev); } /* HDMI HW IP initialisation */ diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index 365cf07..aafd723 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -922,8 +922,5 @@ int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core) res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core"); core->base = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(core->base)) - return PTR_ERR(core->base); - - return 0; + return PTR_ERR_OR_ZERO(core->base); } diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c index ab179ec..45c7b0f 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c @@ -911,8 +911,5 @@ int hdmi5_core_init(struct platform_device *pdev, struct hdmi_core_data *core) res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "core"); core->base = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(core->base)) - return PTR_ERR(core->base); - - return 0; + return PTR_ERR_OR_ZERO(core->base); } diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c index a156292..12a85cb 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi_phy.c @@ -194,8 +194,5 @@ int hdmi_phy_init(struct platform_device *pdev, struct hdmi_phy_data *phy, res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy"); phy->base = devm_ioremap_resource(&pdev->dev, res); - if (IS_ERR(phy->base)) - return PTR_ERR(phy->base); - - return 0; + return PTR_ERR_OR_ZERO(phy->base); } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sun4i: Use PTR_ERR_OR_ZERO
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Signed-off-by: Himanshu Jha --- drivers/gpu/drm/sun4i/sun4i_dotclock.c | 5 + drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 5 + drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 5 + 3 files changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c b/drivers/gpu/drm/sun4i/sun4i_dotclock.c index d401156..35929b3 100644 --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c @@ -178,10 +178,7 @@ int sun4i_dclk_create(struct device *dev, struct sun4i_tcon *tcon) dclk->hw.init = &init; tcon->dclk = clk_register(dev, &dclk->hw); - if (IS_ERR(tcon->dclk)) - return PTR_ERR(tcon->dclk); - - return 0; + return PTR_ERR_OR_ZERO(tcon->dclk); } EXPORT_SYMBOL(sun4i_dclk_create); diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c index 4692e8c..882c80a 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c @@ -120,8 +120,5 @@ int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *parent) ddc->hw.init = &init; hdmi->ddc_clk = devm_clk_register(hdmi->dev, &ddc->hw); - if (IS_ERR(hdmi->ddc_clk)) - return PTR_ERR(hdmi->ddc_clk); - - return 0; + return PTR_ERR_OR_ZERO(hdmi->ddc_clk); } diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c index 5cf2527..44aa870 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c @@ -218,8 +218,5 @@ int sun4i_tmds_create(struct sun4i_hdmi *hdmi) tmds->hw.init = &init; hdmi->tmds_clk = devm_clk_register(hdmi->dev, &tmds->hw); - if (IS_ERR(hdmi->tmds_clk)) - return PTR_ERR(hdmi->tmds_clk); - - return 0; + return PTR_ERR_OR_ZERO(hdmi->tmds_clk); } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt
On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote: > I've worked with Vladimir Murzin inside ARM to try to sort out problems > on the board like the one that you have. He's got to a point where the HDLCD > starts correctly after adding a non-fixed pxlclk source, but then the rest of > the setup is semi-useless without a working IRQ because DRM atomic calls > will give you a vblank timeout splat everytime you invoke them. So I'm > not sure how you want to progress with this patch, as not having an IRQ > line means you will not get any vblank interrupts and you can't use the > driver with userspace that calls DRM API. > > The RTL guys are apparently working on a fix, but I have no ETA or > details on when they are going to do. It sounds then like this patch doesn't make sense - so I'm happy for it to be dropped. It's something to bear in mind in the future when folk decide whether to adopt fbdev or DRM support for hardware that gets used in MMU-less hardware... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/13] mmu_notifier kill invalidate_page callback
On Tue, Aug 29, 2017 at 05:11:24PM -0700, Linus Torvalds wrote: > On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote: > > > > Note this is barely tested. I intend to do more testing of next few days > > but i do not have access to all hardware that make use of the mmu_notifier > > API. > > Thanks for doing this. > > > First 2 patches convert existing call of mmu_notifier_invalidate_page() > > to mmu_notifier_invalidate_range() and bracket those call with call to > > mmu_notifier_invalidate_range_start()/end(). > > Ok, those two patches are a bit more complex than I was hoping for, > but not *too* bad. > > And the final end result certainly looks nice: > > > 16 files changed, 74 insertions(+), 214 deletions(-) > > Yeah, removing all those invalidate_page() notifiers certainly makes > for a nice patch. > > And I actually think you missed some more lines that can now be > removed: kvm_arch_mmu_notifier_invalidate_page() should no longer be > needed either, so you can remove all of those too (most of them are > empty inline functions, but x86 has one that actually does something. > > So there's an added 30 or so dead lines that should be removed in the > kvm patch, I think. Yes i missed that. I will wait for people to test and for result of my own test before reposting if need be, otherwise i will post as separate patch. > > But from a _very_ quick read-through this looks fine. But it obviously > needs testing. > > People - *especially* the people who saw issues under KVM - can you > try out Jérôme's patch-series? I aded some people to the cc, the full > series is on lkml. Jérôme - do you have a git branch for people to > test that they could easily pull and try out? https://cgit.freedesktop.org/~glisse/linux mmu-notifier branch git://people.freedesktop.org/~glisse/linux (Sorry if that tree is bit big it has a lot of dead thing i need to push a clean and slim one) Jérôme ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fixing the udl driver: issues and questions
Hi, all, I recently bough a bunch of udl-compatible DisplayLink adapters and have been trying to use them in Linux, but have been running into some issues: - Output is limited to 16-bit color, but the device is capable of 24-bit color. - X providers (not sure if that's the right term--it's the output of `xrandr --listproviders`) often linger when plugging and unplugging multiple adapters. e.g., I normally have one provider (my main GPU) with no adapters plugged in, then I'll plug in three DisplayLink adapters and there will be four (or five!) providers, and then I'll unplug one and there will still be four (or five), and if I plug it in again it'll add another provider, etc. - The driver only uses RLE to compress data, but the devices are capable of (better?) Huffman coding-based compression. - Not exactly a udl issue, but the udlfb module has to be blacklisted to enable the use of udl. - The entire driver hangs if you plug in the adapter while preventing the DisplayLink SoC from reading the adapter's internal I2C EEPROM. Yes, I realize this happened because I was messing around with the electronics inside the adapter, but a USB device should probably not be permitted to cause a driver to hang in the first place. - Not really a functional issue, but the driver is very "chatty" in its dmesg output, printing a bunch of non-fatal error messages when things go wrong. - When things do go wrong, the driver creates the X provider even if there's a bunch of errors in the kernel log. This is just my opinion, but I think if a problem is so bad it prints an error message, the device init should fail and not result in the X provider being created. If it's really not that bad, then it should probably be just a warning. - The driver seems to check for the EDID of connected monitors on all adapters whenever a new adapter is connected, regardless of whether there are any monitors connected to any of those adapters, and then it outputs error messages when it fails to read the EDIDs of the unconnected monitors. - The vendor descriptor is output with DRM_INFO when a new device is connected, which seems unnecessarily verbose. Since I haven't done any kernel dev before, I thought that fixing some of these issues might be a good introduction. However, I'm not entirely sure what I'm doing, and the commit history of the driver doesn't seem to tell the whole story as to why certain design decisions were made, so I have a few questions: - Why only 16-bit color? I realize that the lower 8 bits need to be stored and transferred in another buffer, but is there a technical reason why this isn't already implemented? Or was there just not much interest in adding that functionality at the time? - Why isn't there support for the Huffman coding compression? Was it for technical reasons, e.g., more things need to be reverse engineered, performance, etc.? Or just lack of interest/developer time? - Why are there two drivers for these devices (udl and udlfb)? Would it be possible to merge all the functionality into udl so I don't have to blacklist udlfb on every computer I want to use these adapters with? - What parts of the driver should I be looking into to fix the X provider duplication issue? - Why is there so much pointer math? (e.g., `*cmd++ = val;`). Is this normal for kernel code? - Why is the driver version still "0.0.1" and the driver date "20120220"? Should these be updated? I apologize if any of the questions I'm asking sound silly--as I said before, I'm new to this and I'm still learning how it all works. I figured that fixing the 16-bit/24-bit issue wouldn't be too difficult, so I've already done a little driver hacking and managed to add a bunch of code to output the lower 8-bits of pixel data to the device. Unfortunately, it's all very hacky, crashes pretty often, and doesn't actually work. I know how to use libusb pretty well, but the kernel USB API is new to me, so I'm pretty sure that's where most of my problems are right now. Then again, I also just might not fully understand the hardware yet, either. If anyone has any answers/comments/advice on how to fix those issues, I'd love to hear them! Also, if you need more detailed issue descriptions, I can do some more testing and provide those as well. Thanks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [radeon-alex:amd-staging-drm-next 68/819] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:154:10: error: 'drm_atomic_helper_connector_dpms' undeclared here (not in a function
On Tue, Aug 29, 2017 at 6:39 PM, Dieter Nützel wrote: > I've send a related kernel crash log to amd-devel some days ago without any > answer, yet... > > Was: > [amd-staging-drm-next] kernel crash with amdgpu on RX580 in > 'drm_object_property_get_value' > > I get this in _all_ current 'amd-staging-drm-next' versions. ;-( It's not a crash, just a warning. It's due to a recent change in the drm core, but we haven't gotten around to sorting it out yet. Alex > > [16301.515079] [ cut here ] > [16301.515105] WARNING: CPU: 4 PID: 11871 at > drivers/gpu/drm/drm_mode_object.c:294 > drm_object_property_get_value+0x22/0x30 [drm] > [16301.515106] Modules linked in: fuse rfcomm nf_log_ipv6 xt_comment > nf_log_ipv4 nf_log_common xt_LOG xt_limit rpcsec_gss_krb5 auth_rpcgss nfsv4 > dns_resolver nfs lockd nfnetlink_cthelper grace nfnetlink sunrpc fscache > af_packet ipmi_ssif iscsi_ibft iscsi_boot_sysfs ip6t_REJECT nf_reject_ipv6 > nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 xt_pkttype > xt_tcpudp iptable_filter ip6table_mangle nf_conntrack_netbios_ns > nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables > xt_conntrack nf_conntrack libcrc32c ip6table_filter ip6_tables x_tables jc42 > bnep joydev snd_hda_codec_hdmi snd_hda_intel snd_hda_codec btusb snd_hwdep > btrtl snd_hda_core btbcm btintel bluetooth snd_pcm e1000e intel_powerclamp > iTCO_wdt snd_timer coretemp iTCO_vendor_support hid_generic snd ptp > kvm_intel pps_core rfkill > [16301.515129] kvm ecdh_generic tpm_infineon soundcore irqbypass tpm_tis > tpm_tis_core crc32c_intel pcspkr shpchp ipmi_si tpm usbhid i2c_i801 > i7core_edac lpc_ich ipmi_devintf ipmi_msghandler ac button acpi_cpufreq > tcp_bbr raid1 md_mod amdkfd amd_iommu_v2 serio_raw sr_mod cdrom amdgpu > mpt3sas i2c_algo_bit raid_class scsi_transport_sas drm_kms_helper > syscopyarea sysfillrect ehci_pci sysimgblt fb_sys_fops ehci_hcd ttm usbcore > drm sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua > [16301.515147] CPU: 4 PID: 11871 Comm: X Tainted: GW > 4.13.0-rc5-1.g7262353-default+ #1 > [16301.515148] Hardware name: FUJITSU PRIMERGY > TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1 > 09/26/2012 > [16301.515149] task: 90c49525a180 task.stack: b84786ef4000 > [16301.515156] RIP: 0010:drm_object_property_get_value+0x22/0x30 [drm] > [16301.515157] RSP: 0018:b84786ef7bf8 EFLAGS: 00010282 > [16301.515158] RAX: c03f0cc0 RBX: 90c52200 RCX: > > [16301.515158] RDX: b84786ef7c10 RSI: 90c523837600 RDI: > 90c523b19028 > [16301.515159] RBP: b84786ef7bf8 R08: 90c41ee28280 R09: > 90c515defc00 > [16301.515159] R10: 00024bb8 R11: R12: > > [16301.515160] R13: 90c523b19000 R14: ffea R15: > 90c511e8c100 > [16301.515161] FS: 7f86f15c9a40() GS:90c53fd0() > knlGS: > [16301.515162] CS: 0010 DS: ES: CR0: 80050033 > [16301.515162] CR2: 000849a98680 CR3: 0005dcc1a000 CR4: > 06e0 > [16301.515163] Call Trace: > [16301.515255] amdgpu_dm_connector_atomic_set_property+0xe8/0x150 [amdgpu] > [16301.515292] drm_atomic_set_property+0x164/0x470 [drm] > [16301.515300] drm_mode_obj_set_property_ioctl+0x10b/0x240 [drm] > [16301.515311] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] > [16301.515318] drm_mode_connector_property_set_ioctl+0x30/0x40 [drm] > [16301.515324] drm_ioctl_kernel+0x5d/0xb0 [drm] > [16301.515332] drm_ioctl+0x31a/0x3d0 [drm] > [16301.515339] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] > [16301.515342] ? ext4_file_write_iter+0xba/0x390 > [16301.515362] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] > [16301.515365] do_vfs_ioctl+0x92/0x5c0 > [16301.515367] ? __fget+0x6e/0x90 > [16301.515368] SyS_ioctl+0x79/0x90 > [16301.515372] entry_SYSCALL_64_fastpath+0x1e/0xa9 > [16301.515373] RIP: 0033:0x7f86eef46507 > [16301.515373] RSP: 002b:7fffe5f9dca8 EFLAGS: 3246 ORIG_RAX: > 0010 > [16301.515374] RAX: ffda RBX: 00084aeea990 RCX: > 7f86eef46507 > [16301.515375] RDX: 7fffe5f9dce0 RSI: c01064ab RDI: > 000d > [16301.515375] RBP: 00084b50d830 R08: 00084b07d690 R09: > 0001 > [16301.515376] R10: 0004 R11: 3246 R12: > 00084aeea990 > [16301.515376] R13: 0005 R14: 00084aeeedd0 R15: > 00084aeeedd0 > [16301.515377] Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 46 60 > 55 48 89 e5 48 8b 80 70 03 00 00 48 83 78 20 00 75 07 e8 60 ff ff ff 5d c3 > <0f> ff e8 57 ff ff ff 5d c3 0f 1f 44 00 00 66 66 66 66 90 55 48 > [16301.515394] ---[ end trace f957c1d5844ce46f ]--- > > Thanks, > Dieter > > > Am 30.08.2017 00:22, schrieb kbuild test robot: >> >> tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next >> head: ff14f0dca1f23b2cff41e43440c7952965e5fc1b >> commit: 9b37a9b8f6
[Bug 102013] GTK3 tooltips are corrupted after updating to mesa 17.0.7
https://bugs.freedesktop.org/show_bug.cgi?id=102013 --- Comment #16 from Michel Dänzer --- Does the bug summary change mean you've confirmed that the problem doesn't happen with an older version of Mesa? If so, which version? -- 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 102391] x11-libs/libdrm-2.4.83: fatal error: uve_ib.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=102391 Matt Turner changed: What|Removed |Added QA Contact||dri-devel@lists.freedesktop ||.org Assignee|dri-devel@lists.freedesktop |boyuan.zh...@amd.com |.org| CC||alexdeuc...@gmail.com, ||deathsim...@vodafone.de --- Comment #1 from Matt Turner --- This is because the headers added in commit 9d133dd08720d80dfc8ce098bf0972ebd05c454d Author: Boyuan Zhang Date: Tue Aug 15 11:33:43 2017 -0400 tests/amdgpu: add uvd encode unit tests were not added to the relevant _SOURCES variable, so they were not included in the tarball by make dist. It wasn't caught by make distcheck because of the "automagic" dependency on cunit. The tests are silently disabled if cunit is not found. -- 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: [GIT PULL] drm-hisilicon-next
On 29 August 2017 at 21:57, Daniel Vetter wrote: > On Tue, Aug 29, 2017 at 11:54 AM, Xinliang Liu > wrote: >> Hi Dave, >> >> On 29 August 2017 at 16:32, Daniel Vetter wrote: >>> On Tue, Aug 29, 2017 at 10:46:33AM +0800, Xinliang Liu wrote: Hi Dave, One fix for next. Sorry for late pull request. If it can't catch this round, will resend on next round. >>> >>> drm-misc is always open for features, which makes this a lot simpler. Just >>> in case you want to reconsider moving hisilicon into drm-misc :-) >> >> If moving hisilicon into drm-misc make things simpler, I would like to do >> it. >> Just clarify how to do this: >> I just need to change the git tree to drm-misc? I see a lot of drm >> drivers maintainers set the their git tree to >> git://anongit.freedesktop.org/drm/drm-misc. >> The means to be an drm-misc maintainer, right? >> I wonder how new driver specific features/fixes patches go into drm-misc >> then? >> Do I need to send a pull request to drm-misc tree. I don't think I >> have a write permission to drm-misc tree. > > You'll need to become drm-misc committer, and patches are pushed > directly using the scripts we have: > > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html > > Here's the rules for how drm-misc works: > > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > > drm-misc is essentially a service provided to take care of some of the > maintainer chores, but review and patch merging still needs to be done > by the individual driver owners (i.e. we won't take a new driver > without a committer for it). Thanks Daniel, We are considering switch to a stable maintainer for hisilicon. After that we will move hisilicon to drm-misc. Best, Xinliang > > Cheers, Daniel > >> >> Best, >> Xinliang >> >>> -Daniel >>> Best, Xinliang The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 10:38:14 +1000) are available in the git repository at: g...@github.com:xin3liang/linux.git tags/drm-hisilicon-next-2017-08-29 for you to fetch changes up to 834fe0f6023a4fad68612dbbe93866c4df32142e: drm/hisilicon: Ensure LDI regs are properly configured. (2017-08-29 10:17:18 +0800) hisilicon-drm-next Peter Griffin (1): drm/hisilicon: Ensure LDI regs are properly configured. drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++ 1 file changed, 3 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> -- >>> Daniel Vetter >>> Software Engineer, Intel Corporation >>> http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
