[PATCH v4 0/5] replace hwmon_device_register for hwmon_device_register_with_info
Kbuild sent me an e-mail due to a fixup I introduced in v3. It complains due to an incompatible pointer type and it doesn't build. This version reverts it. Versions: v1 -> v2: * Keep temp attrs as read only v2 -> v3: * Code fix-ups: struct and string as const and add return within switch due to fallthrough * Add Signed-off-by to all commits v3 -> v4: * Rever const to struct attribute. Kbuild complains. This patchseries replaces the deprecated hwmon_device_register function with the new one hwmon_device_register_with_info. It also does some cleanup. Oscar Salvador (5): nouveau_hwmon: Add config for all sensors and their settings nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string nouveau_hwmon: Remove old code, add .write/.read operations nouveau_hwmon: Add support for auto_point attributes nouveau_hwmon: Change permissions to numeric drivers/gpu/drm/nouveau/nouveau_hwmon.c | 954 +--- 1 file changed, 500 insertions(+), 454 deletions(-) -- 2.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] nouveau_hwmon: Add config for all sensors and their settings
This is a preparation for the next patches. It just adds the sensors with
their possible configurable settings and then fills the struct
hwmon_channel_info
with all this information.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 +
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 23b1670..24b40c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -692,6 +692,78 @@ static const struct attribute_group hwmon_power_attrgroup
= {
static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
};
+
+static const u32 nouveau_config_chip[] = {
+ HWMON_C_UPDATE_INTERVAL,
+ 0
+};
+
+static const u32 nouveau_config_in[] = {
+ HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+ 0
+};
+
+static const u32 nouveau_config_temp[] = {
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+ HWMON_T_EMERGENCY_HYST,
+ 0
+};
+
+static const u32 nouveau_config_fan[] = {
+ HWMON_F_INPUT,
+ 0
+};
+
+static const u32 nouveau_config_pwm[] = {
+ HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+ 0
+};
+
+static const u32 nouveau_config_power[] = {
+ HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+ 0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+ .type = hwmon_chip,
+ .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+ .type = hwmon_temp,
+ .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+ .type = hwmon_fan,
+ .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+ .type = hwmon_in,
+ .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+ .type = hwmon_pwm,
+ .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+ .type = hwmon_power,
+ .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+ &nouveau_chip,
+ &nouveau_temp,
+ &nouveau_fan,
+ &nouveau_in,
+ &nouveau_pwm,
+ &nouveau_power,
+ NULL
+};
#endif
int
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string
This patch introduces the nouveau_hwmon_ops structure, sets up
.is_visible and .read_string operations and adds all the functions
for these operations.
This is also a preparation for the next patches, where most of the
work is being done.
This code doesn't interacture with the old one.
It's just to make easier the review of all patches.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 171
1 file changed, 171 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 24b40c5..6e9bcfe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -764,6 +764,177 @@ static const struct hwmon_channel_info *nouveau_info[] = {
&nouveau_power,
NULL
};
+
+static umode_t
+nouveau_chip_is_visible(const void *data, u32 attr, int channel)
+{
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_power_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_iccsense *iccsense = nvxx_iccsense(&drm->client.device);
+
+ if (!iccsense)
+ return 0;
+
+ switch (attr) {
+ case hwmon_power_input:
+ if (iccsense->data_valid &&
+ !list_empty(&iccsense->rails))
+ return 0444;
+ return 0;
+ case hwmon_power_max:
+ if (iccsense->power_w_max)
+ return 0444;
+ return 0;
+ case hwmon_power_crit:
+ if (iccsense->power_w_crit)
+ return 0444;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_temp_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm &&
+ therm->attr_get &&
+ therm->attr_set &&
+ nvkm_therm_temp_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_max:
+ case hwmon_temp_max_hyst:
+ case hwmon_temp_crit:
+ case hwmon_temp_crit_hyst:
+ case hwmon_temp_emergency:
+ case hwmon_temp_emergency_hyst:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm &&
+ therm->attr_get &&
+ therm->fan_get &&
+ therm->fan_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_pwm_enable:
+ case hwmon_pwm_input:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_input_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_volt *volt = nvxx_volt(&drm->client.device);
+
+ if (!volt || nvkm_volt_get(volt) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ case hwmon_in_min:
+ case hwmon_in_max:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_fan_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
+ int channel)
+{
+ switch (type) {
+ case hwmon_chip:
+ return nouveau_chip_is_visible(data, attr, channel);
+ case hwmon_temp:
+ return nouveau_temp_is_visible(data, attr, channel);
+ case hwmon_fan:
+ return nouveau_fan_is_visible(data, attr, channel);
+ case hwmon_in:
+ return nouveau_input_is_visible(data, attr, channel);
+ case hwmon_pwm:
+ return nouveau_pwm_is_visible(data, attr, channel);
+ case hwmon_power:
+ return nouveau_power_is_visible(data, attr, channel);
+ default:
+
[PATCH v4 4/5] nouveau_hwmon: Add support for auto_point attributes
This patch creates a special group attributes for attrs like "*auto_point*".
We check if we have support for them, and if we do, we gather them all in
an attribute_group's structure which is the parameter regarding special groups
of hwmon_device_register_with_info.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 57296cb..d6b34f4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -358,6 +358,23 @@ nouveau_hwmon_get_power1_crit(struct nouveau_drm *drm)
return iccsense->power_w_crit;
}
+static struct attribute *pwm_fan_sensor_attrs[] = {
+ &sensor_dev_attr_pwm1_min.dev_attr.attr,
+ &sensor_dev_attr_pwm1_max.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(pwm_fan_sensor);
+
+static struct attribute *temp1_auto_point_sensor_attrs[] = {
+ &sensor_dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
+
+#define N_ATTR_GROUPS 3
+
static const u32 nouveau_config_chip[] = {
HWMON_C_UPDATE_INTERVAL,
0
@@ -793,17 +810,27 @@ nouveau_hwmon_init(struct drm_device *dev)
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+ const struct attribute_group *special_groups[N_ATTR_GROUPS];
struct nouveau_hwmon *hwmon;
struct device *hwmon_dev;
int ret = 0;
+ int i = 0;
hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return -ENOMEM;
hwmon->dev = dev;
+ if (therm && therm->attr_get && therm->attr_set) {
+ if (nvkm_therm_temp_get(therm) >= 0)
+ special_groups[i++] = &temp1_auto_point_sensor_group;
+ if (therm->fan_get && therm->fan_get(therm) >= 0)
+ special_groups[i++] = &pwm_fan_sensor_group;
+ }
+
+ special_groups[i] = 0;
hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
- &nouveau_chip_info, NULL);
+ &nouveau_chip_info, special_groups);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] nouveau_hwmon: Remove old code, add .write/.read operations
This patch removes old code related to the old api and transforms the
functions for the new api. It also adds the .write and .read operations.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 722 +++-
1 file changed, 249 insertions(+), 473 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 6e9bcfe..57296cb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -38,21 +38,17 @@
#include
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
-static ssize_t
-nouveau_hwmon_show_temp(struct device *d, struct device_attribute *a, char
*buf)
+static int
+nouveau_hwmon_show_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
int temp = nvkm_therm_temp_get(therm);
if (temp < 0)
return temp;
- return snprintf(buf, PAGE_SIZE, "%d\n", temp * 1000);
+ return (temp * 1000);
}
-static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, nouveau_hwmon_show_temp,
- NULL, 0);
static ssize_t
nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
@@ -129,312 +125,100 @@ static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst,
S_IRUGO | S_IWUSR,
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
-static ssize_t
-nouveau_hwmon_max_temp(struct device *d, struct device_attribute *a, char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
-
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+static int
+nouveau_hwmon_max_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
-
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK, value / 1000);
-
- return count;
+ return therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000;
}
-static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO | S_IWUSR, nouveau_hwmon_max_temp,
- nouveau_hwmon_set_max_temp,
- 0);
-static ssize_t
-nouveau_hwmon_max_temp_hyst(struct device *d, struct device_attribute *a,
- char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
-
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_max_temp_hyst(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+static int
+nouveau_hwmon_max_temp_hyst(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
-
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST,
- value / 1000);
-
- return count;
+ return therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) *
1000;
}
-static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IRUGO | S_IWUSR,
- nouveau_hwmon_max_temp_hyst,
- nouveau_hwmon_set_max_temp_hyst, 0);
-
-static ssize_t
-nouveau_hwmon_critical_temp(struct device *d, struct device_attribute *a,
- char *buf)
-{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_CRITICAL) * 1000);
-}
-static ssize_t
-nouveau_hwmon_set_critical_temp(struct device *d, struct device_attribute *a,
- const char *buf,
-
[PATCH v4 5/5] nouveau_hwmon: Change permissions to numeric
This patch replaces the symbolic permissions with the numeric ones,
and adds me to the authors too.
Signed-off-by: Oscar Salvador
---
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index d6b34f4..d129408 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -1,5 +1,6 @@
/*
- * Copyright 2010 Red Hat Inc.
+ * Copyright 2010 Red Hat Inc. (Ben Skeggs)
+ * Copyright 2017 Oscar Salvador
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,7 +20,6 @@
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
- * Authors: Ben Skeggs
*/
#ifdef CONFIG_ACPI
@@ -56,7 +56,7 @@ nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
{
return snprintf(buf, PAGE_SIZE, "%d\n", 100);
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, S_IRUGO,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444,
nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0);
static ssize_t
@@ -88,7 +88,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, 0644,
nouveau_hwmon_temp1_auto_point1_temp,
nouveau_hwmon_set_temp1_auto_point1_temp, 0);
@@ -121,7 +121,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct device
*d,
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 0644,
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
@@ -255,7 +255,7 @@ nouveau_hwmon_set_pwm1_min(struct device *d, struct
device_attribute *a,
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_min, 0644,
nouveau_hwmon_get_pwm1_min,
nouveau_hwmon_set_pwm1_min, 0);
@@ -295,7 +295,7 @@ nouveau_hwmon_set_pwm1_max(struct device *d, struct
device_attribute *a,
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_max, 0644,
nouveau_hwmon_get_pwm1_max,
nouveau_hwmon_set_pwm1_max, 0);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98629] OpenGL applications warns "MESA-LOADER: failed to retrieve device information"
https://bugs.freedesktop.org/show_bug.cgi?id=98629 --- Comment #10 from Joachim Frieben --- For current Fedora 25 plus testing updates, I do still get this error message when using VirGL in a virtual machine: $ glxgears libGL error: MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information MESA-LOADER: failed to retrieve device information Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. Installed packages include: kernel-4.10.11-200.fc25 libdrm-2.4.79-1.fc25 mesa-13.0.4-3.fc25 Furthermore, permissions for /dev/libdri* read: $ ls -l /dev/dri* total 0 crw-rw+ 1 root video 226, 0 Apr 22 11:27 card0 crw-rw+ 1 root video 226, 128 Apr 22 11:24 renderD128 -- 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: fourcc byteorder: brings header file comments in line with reality.
On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote: > On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä > wrote: > > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: > >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: > >> > While working on graphics support for virtual machines on ppc64 (which > >> > exists in both little and big endian variants) I've figured the comments > >> > for various drm fourcc formats in the header file don't match reality. > >> > > >> > Comments says the RGB formats are little endian, but in practice they > >> > are native endian. Look at the drm_mode_legacy_fb_format() helper. It > >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter > >> > whenever the machine is little endian or big endian. The users of this > >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer > >> > is native endian, not little endian. Most userspace also operates on > >> > native endian only. > >> > > >> > So, go update the comments for all 16+24+32 bpp RGB formats. > >> > > >> > Leaving the yuv formats as-is. I have no idea if and how those are used > >> > on bigendian machines. > >> > >> I think this is premature. The current situation is that I can't get > >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just > >> the colors displayed are wrong). I believe that currently it packs > >> things in "cpu native endian". I've tried futzing with that without > >> much success, although I didn't spend too much time on it. I have a > >> NV34 plugged into my LE setup as well although I haven't tested to > >> double-check that it all works there. However I'm quite sure it used > >> to, as I used modetest to help develop the YUV overlay support for > >> those GPUs. > > > > I just took a quick stab at fixing modetest to respect the current > > wording in drm_fourcc.h: > > > > git://github.com/vsyrjala/libdrm.git modetest_endian > > Looks like there was some careless testing on my part :( So ... it > looks like the current modetest without those changes does, in fact, > work on NV34/BE. With the changes, it breaks (and the handling of the > b* modes is a little broken in those patches -- they're not selectable > from the cmdline.) Which means that, as Michel & co predicted, it > appears to be taking BE input not LE input. This is very surprising to > me, but it is what it is. As I mentioned before, the details of how > the "BE" mode works on the GPUs is largely unknown to us beyond a few > basics. Note that only XR24 works, AR24 ends up with all black > displayed. This also happens on LE. Did you try 8bpp or 16bpp formats? I expect that if you've just blindly enabled some magic byte swapper in the hardware it will only for a specific pixel size. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Fri, Apr 21, 2017 at 06:14:31PM +0200, Gerd Hoffmann wrote: > Hi, > > > > My personal opinion is that formats in drm_fourcc.h should be > > > independent of the CPU byte order and the function > > > drm_mode_legacy_fb_format() and drivers depending on that incorrect > > > assumption be fixed instead. > > > > The problem is this isn't a kernel-internal thing any more. With the > > addition of the ADDFB2 ioctl the fourcc codes became part of the > > kernel/userspace abi ... > > Ok, added some printk's to the ADDFB and ADDFB2 code paths and tested a > bit. Apparently pretty much all userspace still uses the ADDFB ioctl. > xorg (modesetting driver) does. gnome-shell in wayland mode does. > Seems the big transition to ADDFB2 didn't happen yet. > > I guess that makes changing drm_mode_legacy_fb_format + drivers a > reasonable option ... Yeah, I came to the same conclusion after chatting with some folks on irc. So my current idea is that we change any driver that wants to follow the CPU endianness to declare support for big endian formats if the CPU is big endian. Presumably these are mostly the virtual GPU drivers. Additonally we'll make the mapping performed by drm_mode_legacy_fb_format() driver controlled. That way drivers that got changed to follow CPU endianness can return a framebuffer that matches CPU endianness. And drivers that expect the GPU endianness to not depend on the CPU endianness will keep working as they do now. The downside is that users of the legacy addfb ioctl will need to magically know which endianness they will get, but that is apparently already the case. And users of addfb2 will keep on specifying the endianness explicitly with DRM_FORMAT_BIG_ENDIAN vs. 0. Does that sound like a workable solution? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Probing modes and validating them
On Fri, Apr 21, 2017 at 02:29:12PM +0100, Jose Abreu wrote:
> ++ Daniel
>
> ++ Dave
>
>
> On 21-04-2017 13:59, Jose Abreu wrote:
> > Hi All,
> >
> >
> > Is there any callback available, at the crtc level, that can
> > validate the probed modes before making them available for
> > userspace? I mean: I know that there is connector->mode_valid(),
> > but I couldn't find any equivalent crtc->mode_valid(). I found
> > mode_fixup() but this is called after giving the mode to
> > userspace, which is not what I need.
> >
> > For reference here is the situation I'm facing:
> >
> > ARCPGU is a DRM driver that uses ADV7511 as connector/bridge. The
> > PGU encodes raw video into a stream that ADV can understands and
> > in order to do this it needs a pixel clock. Currently this pixel
> > clock value is fixed, so technically arcpgu driver supports only
> > one video mode. There is a patch currently on discussion that
> > adds more supported frequencies for arcpgu, but there are still
> > some frequencies that will not be supported. This is NOT a
> > limitation in ADV7511, so it doesn't make sense to limit the
> > available modes in adv, we could instead limit the modes in the
> > crtc level (i.e. the pgu).
> >
> > In order to know if a mode can be displayed or not it is as
> > simple as call clk_round_rate() and check if the returned
> > frequency is the same. But in order to do this I need some sort
> > of callback that is called at the crtc level and before
> > delivering modes to userspace.
> >
> > I believe this would be a good addition to arcpgu because this
> > way we wouldn't "fool" userspace by delivering modes that will
> > fail in atomic check. The user may still specify manually a mode,
> > this will still fail in atomic check, but the difference is that
> > this mode will not be in the probed list.
> >
> >
> > Best regards,
> >
> > Jose Miguel Abreu
> >
>
> With this simple patch I could fix my problem, what do you think?
> Is this ok to be added? I guess some connectors may not have the
> crtc linked at probbing stage but this is handled.
>
> From 252b7cb5adeaf16be95988d17468eea2895b Mon Sep 17 00:00:00
> 2001
> Message-Id:
> <252b7cb5adeaf16be95988d17468eea2895b.1492781127.git.joab...@synopsys.com>
> From: Jose Abreu
> Date: Fri, 21 Apr 2017 14:24:16 +0100
> Subject: [PATCH] drm: Introduce crtc->mode_valid() callback
>
> Introduce a new crtc callback which validates the probbed modes,
> just like connector->mode_valid() does.
>
> Signed-off-by: Jose Abreu
> ---
> drivers/gpu/drm/arc/arcpgu_crtc.c| 14 ++
> drivers/gpu/drm/drm_probe_helper.c | 12
> include/drm/drm_modeset_helper_vtables.h | 3 +++
> 3 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index 7130b04..e43e8d6 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -63,6 +63,19 @@ static void arc_pgu_set_pxl_fmt(struct
> drm_crtc *crtc)
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> };
>
> +enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
> + struct drm_display_mode *mode)
> +{
> +struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> +long rate, clk_rate = mode->clock * 1000;
> +
> +rate = clk_round_rate(arcpgu->clk, clk_rate);
> +if (rate != clk_rate)
> +return MODE_NOCLOCK;
> +
> +return MODE_OK;
> +}
> +
> static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
> {
> struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> @@ -157,6 +170,7 @@ static void arc_pgu_crtc_atomic_begin(struct
> drm_crtc *crtc,
> }
>
> static const struct drm_crtc_helper_funcs
> arc_pgu_crtc_helper_funcs = {
> +.mode_valid= arc_pgu_crtc_mode_valid,
> .mode_set= drm_helper_crtc_mode_set,
> .mode_set_base= drm_helper_crtc_mode_set_base,
> .mode_set_nofb= arc_pgu_crtc_mode_set_nofb,
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index cf8f012..6c9af88 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -233,6 +233,8 @@ int
> drm_helper_probe_single_connector_modes(struct drm_connector
> *connector,
> struct drm_display_mode *mode;
> const struct drm_connector_helper_funcs *connector_funcs =
> connector->helper_private;
> +struct drm_crtc *crtc = NULL;
> +const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
> int count = 0;
> int mode_flags = 0;
> bool verbose_prune = true;
> @@ -242,6 +244,13 @@ int
> drm_helper_probe_single_connector_modes(struct drm_connector
> *connector,
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> connector->name);
> +
> +if (connector->encoder && connector->encoder->crtc &&
Basing this decision on whichever crtc might happen to be driv
[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git
https://bugs.freedesktop.org/show_bug.cgi?id=100593 --- Comment #9 from tarp...@gmx.de --- Oibaf still has problems on my R9 290. But with Padoka the issue is fixed now. However, Padoka is now installing mesa 17.2 git, so I have no idea, if it is fixed in the 17.1 branch. -- 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: fourcc byteorder: brings header file comments in line with reality.
On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä wrote: > On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote: >> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä >> wrote: >> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote: >> >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote: >> >> > While working on graphics support for virtual machines on ppc64 (which >> >> > exists in both little and big endian variants) I've figured the comments >> >> > for various drm fourcc formats in the header file don't match reality. >> >> > >> >> > Comments says the RGB formats are little endian, but in practice they >> >> > are native endian. Look at the drm_mode_legacy_fb_format() helper. It >> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter >> >> > whenever the machine is little endian or big endian. The users of this >> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer >> >> > is native endian, not little endian. Most userspace also operates on >> >> > native endian only. >> >> > >> >> > So, go update the comments for all 16+24+32 bpp RGB formats. >> >> > >> >> > Leaving the yuv formats as-is. I have no idea if and how those are used >> >> > on bigendian machines. >> >> >> >> I think this is premature. The current situation is that I can't get >> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just >> >> the colors displayed are wrong). I believe that currently it packs >> >> things in "cpu native endian". I've tried futzing with that without >> >> much success, although I didn't spend too much time on it. I have a >> >> NV34 plugged into my LE setup as well although I haven't tested to >> >> double-check that it all works there. However I'm quite sure it used >> >> to, as I used modetest to help develop the YUV overlay support for >> >> those GPUs. >> > >> > I just took a quick stab at fixing modetest to respect the current >> > wording in drm_fourcc.h: >> > >> > git://github.com/vsyrjala/libdrm.git modetest_endian >> >> Looks like there was some careless testing on my part :( So ... it >> looks like the current modetest without those changes does, in fact, >> work on NV34/BE. With the changes, it breaks (and the handling of the >> b* modes is a little broken in those patches -- they're not selectable >> from the cmdline.) Which means that, as Michel & co predicted, it >> appears to be taking BE input not LE input. This is very surprising to >> me, but it is what it is. As I mentioned before, the details of how >> the "BE" mode works on the GPUs is largely unknown to us beyond a few >> basics. Note that only XR24 works, AR24 ends up with all black >> displayed. This also happens on LE. > > Did you try 8bpp or 16bpp formats? I expect that if you've just blindly > enabled some magic byte swapper in the hardware it will only for > a specific pixel size. Thankfully dispnv04 exposes no such madness - just XR24 (and AR24, although that doesn't appear functional). Yes, it's likely that there's a byteswap happening somewhere. In fact the copy engines have parameters somewhere to tell how the swap should be done (basically what the element size is). I don't quite know how to set that though on this generation. I should poke at VRAM via the mmio peephole and see what's actually being stored. Although of course MMIO accesses are also auto-byteswapped. It's all just one big massive headache. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100695] Texture artifacts in Deus Ex: Mankind Divided
https://bugs.freedesktop.org/show_bug.cgi?id=100695 --- Comment #5 from Hadrien --- (In reply to Michel Dänzer from comment #4) > Bug 100681 was fixed by LLVM SVN r300791, how about this? I got an update of the padoka package today. It ships with llvm-5.0 r301038 but unfortunately the problem is still there :( -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
> wrote:
>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>>> wrote:
>>> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>>> >> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
>>> >> > While working on graphics support for virtual machines on ppc64 (which
>>> >> > exists in both little and big endian variants) I've figured the
>>> >> > comments
>>> >> > for various drm fourcc formats in the header file don't match reality.
>>> >> >
>>> >> > Comments says the RGB formats are little endian, but in practice they
>>> >> > are native endian. Look at the drm_mode_legacy_fb_format() helper. It
>>> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no
>>> >> > matter
>>> >> > whenever the machine is little endian or big endian. The users of this
>>> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>>> >> > is native endian, not little endian. Most userspace also operates on
>>> >> > native endian only.
>>> >> >
>>> >> > So, go update the comments for all 16+24+32 bpp RGB formats.
>>> >> >
>>> >> > Leaving the yuv formats as-is. I have no idea if and how those are
>>> >> > used
>>> >> > on bigendian machines.
>>> >>
>>> >> I think this is premature. The current situation is that I can't get
>>> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>>> >> the colors displayed are wrong). I believe that currently it packs
>>> >> things in "cpu native endian". I've tried futzing with that without
>>> >> much success, although I didn't spend too much time on it. I have a
>>> >> NV34 plugged into my LE setup as well although I haven't tested to
>>> >> double-check that it all works there. However I'm quite sure it used
>>> >> to, as I used modetest to help develop the YUV overlay support for
>>> >> those GPUs.
>>> >
>>> > I just took a quick stab at fixing modetest to respect the current
>>> > wording in drm_fourcc.h:
>>> >
>>> > git://github.com/vsyrjala/libdrm.git modetest_endian
>>>
>>> Looks like there was some careless testing on my part :( So ... it
>>> looks like the current modetest without those changes does, in fact,
>>> work on NV34/BE. With the changes, it breaks (and the handling of the
>>> b* modes is a little broken in those patches -- they're not selectable
>>> from the cmdline.) Which means that, as Michel & co predicted, it
>>> appears to be taking BE input not LE input. This is very surprising to
>>> me, but it is what it is. As I mentioned before, the details of how
>>> the "BE" mode works on the GPUs is largely unknown to us beyond a few
>>> basics. Note that only XR24 works, AR24 ends up with all black
>>> displayed. This also happens on LE.
>>
>> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
>> enabled some magic byte swapper in the hardware it will only for
>> a specific pixel size.
>
> Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
> although that doesn't appear functional). Yes, it's likely that
> there's a byteswap happening somewhere. In fact the copy engines have
> parameters somewhere to tell how the swap should be done (basically
> what the element size is). I don't quite know how to set that though
> on this generation. I should poke at VRAM via the mmio peephole and
> see what's actually being stored. Although of course MMIO accesses are
> also auto-byteswapped. It's all just one big massive headache.
Or it could just be the obvious:
static void nv_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
nouveau_hw_load_state(dev, nv_crtc->index,
&nv04_display(dev)->mode_reg);
nv04_crtc_mode_set_base(crtc, crtc->x, crtc->y, NULL);
#ifdef __BIG_ENDIAN
/* turn on LFB swapping */
{
uint8_t tmp = NVReadVgaCrtc(dev, nv_crtc->index,
NV_CIO_CRE_RCR);
tmp |= MASK(NV_CIO_CRE_RCR_ENDIAN_BIG);
NVWriteVgaCrtc(dev, nv_crtc->index, NV_CIO_CRE_RCR, tmp);
}
#endif
funcs->dpms(crtc, DRM_MODE_DPMS_ON);
drm_crtc_vblank_on(crtc);
}
So presumably instead of that __BIG_ENDIAN thing, it should instead be
if crtc->primary->fb->fourcc & BIG_ENDIAN. (Although that's probably
going to break the universe.) There's also some questionable support
for 16-bit modes in the code, I'm going to see how easy it is to flip
on.
-ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100759] [r600] System freeze on resume from sleep on battery with DPM enabled and linux 4.10
https://bugs.freedesktop.org/show_bug.cgi?id=100759 Bug ID: 100759 Summary: [r600] System freeze on resume from sleep on battery with DPM enabled and linux 4.10 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: nicolam...@aol.com Created attachment 130983 --> https://bugs.freedesktop.org/attachment.cgi?id=130983&action=edit journalctl log for failed resume Since linux 4.10.1 my system freezes every time when resuming from sleep (suspend to ram) while on battery. The screen either remains black or displays garbage, and the only thing to do is a hard poweroff. The problem does not show up when either: - running on AC or - using linux 4.9 (tested with 4.9.11) or - DPM is not enabled (radeon.dpm=0) I checked journalctl but it does not contain anything useful. I attach the last part of the log, starting from the suspend request; it seems nothing from the failed resume process is logged. System details: - Archlinux x86_64 - Mobility Radeon HD 3470 - Plasma desktop 5.9.4 -- 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: fourcc byteorder: brings header file comments in line with reality.
On Sat, Apr 22, 2017 at 9:48 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
>> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
>> wrote:
>>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
wrote:
> On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann
>> wrote:
>> > While working on graphics support for virtual machines on ppc64 (which
>> > exists in both little and big endian variants) I've figured the
>> > comments
>> > for various drm fourcc formats in the header file don't match reality.
>> >
>> > Comments says the RGB formats are little endian, but in practice they
>> > are native endian. Look at the drm_mode_legacy_fb_format() helper.
>> > It
>> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no
>> > matter
>> > whenever the machine is little endian or big endian. The users of
>> > this
>> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the
>> > framebuffer
>> > is native endian, not little endian. Most userspace also operates on
>> > native endian only.
>> >
>> > So, go update the comments for all 16+24+32 bpp RGB formats.
>> >
>> > Leaving the yuv formats as-is. I have no idea if and how those are
>> > used
>> > on bigendian machines.
>>
>> I think this is premature. The current situation is that I can't get
>> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>> the colors displayed are wrong). I believe that currently it packs
>> things in "cpu native endian". I've tried futzing with that without
>> much success, although I didn't spend too much time on it. I have a
>> NV34 plugged into my LE setup as well although I haven't tested to
>> double-check that it all works there. However I'm quite sure it used
>> to, as I used modetest to help develop the YUV overlay support for
>> those GPUs.
>
> I just took a quick stab at fixing modetest to respect the current
> wording in drm_fourcc.h:
>
> git://github.com/vsyrjala/libdrm.git modetest_endian
Looks like there was some careless testing on my part :( So ... it
looks like the current modetest without those changes does, in fact,
work on NV34/BE. With the changes, it breaks (and the handling of the
b* modes is a little broken in those patches -- they're not selectable
from the cmdline.) Which means that, as Michel & co predicted, it
appears to be taking BE input not LE input. This is very surprising to
me, but it is what it is. As I mentioned before, the details of how
the "BE" mode works on the GPUs is largely unknown to us beyond a few
basics. Note that only XR24 works, AR24 ends up with all black
displayed. This also happens on LE.
>>>
>>> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
>>> enabled some magic byte swapper in the hardware it will only for
>>> a specific pixel size.
>>
>> Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
>> although that doesn't appear functional). Yes, it's likely that
>> there's a byteswap happening somewhere. In fact the copy engines have
>> parameters somewhere to tell how the swap should be done (basically
>> what the element size is). I don't quite know how to set that though
>> on this generation. I should poke at VRAM via the mmio peephole and
>> see what's actually being stored. Although of course MMIO accesses are
>> also auto-byteswapped. It's all just one big massive headache.
>
> Or it could just be the obvious:
>
> static void nv_crtc_commit(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
> struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
>
> nouveau_hw_load_state(dev, nv_crtc->index,
> &nv04_display(dev)->mode_reg);
> nv04_crtc_mode_set_base(crtc, crtc->x, crtc->y, NULL);
>
> #ifdef __BIG_ENDIAN
> /* turn on LFB swapping */
> {
> uint8_t tmp = NVReadVgaCrtc(dev, nv_crtc->index,
> NV_CIO_CRE_RCR);
> tmp |= MASK(NV_CIO_CRE_RCR_ENDIAN_BIG);
> NVWriteVgaCrtc(dev, nv_crtc->index, NV_CIO_CRE_RCR, tmp);
> }
> #endif
>
> funcs->dpms(crtc, DRM_MODE_DPMS_ON);
> drm_crtc_vblank_on(crtc);
> }
>
> So presumably instead of that __BIG_ENDIAN thing, it should instead be
> if crtc->primary->fb->fourcc & BIG_ENDIAN. (Although that's probably
> going to break the universe.) There's also some questionable support
> for 16-bit modes in the code, I'm going to see how easy it is to flip
> on.
OK, so just to follow up, I'd like to note a few things that were not
obvious to me, but perhaps were to all of you
[Bug 100695] Texture artifacts in Deus Ex: Mankind Divided
https://bugs.freedesktop.org/show_bug.cgi?id=100695 --- Comment #6 from network...@rkmail.ru --- I can't reproduce this with opensuse + RX480 + Mesa-git 17.2 (d1608d6982) + llvm 5.0 revision 300864 + linux 4.10.11 -- 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 100067] [OpenCL] const int in argument list crashes build
https://bugs.freedesktop.org/show_bug.cgi?id=100067 Mig changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Mig --- With updated Mesa and llvm to version 4.0.0 I can compile and run the programs without any errors. [mig@antergos ~]$ clinfo Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform VersionOpenCL 1.1 Mesa 17.0.4 Platform ProfileFULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name Clover Number of devices 1 Device Name AMD TONGA (DRM 3.9.0 / 4.10.10-1-ARCH, LLVM 4.0.0) Device Vendor AMD Device Vendor ID0x1002 Device Version OpenCL 1.1 Mesa 17.0.4 Driver Version 17.0.4 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device AvailableYes Device Profile FULL_PROFILE Max compute units 28 Max clock frequency 990MHz Max work item dimensions3 Max work item sizes 256x256x256 Max work group size 256 Compiler Available Yes Preferred work group size multiple 64 -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 100067, which changed state. Bug 100067 Summary: [OpenCL] const int in argument list crashes build https://bugs.freedesktop.org/show_bug.cgi?id=100067 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 100695] Texture artifacts in Deus Ex: Mankind Divided
https://bugs.freedesktop.org/show_bug.cgi?id=100695 --- Comment #7 from Hadrien --- Created attachment 130984 --> https://bugs.freedesktop.org/attachment.cgi?id=130984&action=edit Loading screen glitches Other screenshot showing glitches -- 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 100695] Texture artifacts in Deus Ex: Mankind Divided
https://bugs.freedesktop.org/show_bug.cgi?id=100695 --- Comment #8 from Hadrien --- Some in-game bad textures disappeared. The Talos Principle is fixed too. I think those glitches were actually related to bug 100681. The textures looked dirty, but they were not complete garbage as seen in the screenshots attached to this bug. So now I think it is a different problem. So far I have only seen the glitch on user interface textures. I am still learning to build my own version of Mesa with a specific version of LLVM in order to find the bad revision. -- 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: fourcc byteorder: brings header file comments in line with reality.
Hi, > > I guess that makes changing drm_mode_legacy_fb_format + drivers a > > reasonable option ... > > Yeah, I came to the same conclusion after chatting with some > folks on irc. > > So my current idea is that we change any driver that wants to follow the > CPU endianness to declare support for big endian formats if the CPU is > big endian. Presumably these are mostly the virtual GPU drivers. Agree. Easy. > Additonally we'll make the mapping performed by drm_mode_legacy_fb_format() > driver controlled. I don't think this is useful. IMO drm_mode_legacy_fb_format should return host endian formats unconditionally. > That way drivers that got changed to follow CPU > endianness can return a framebuffer that matches CPU endianness. And > drivers that expect the GPU endianness to not depend on the CPU > endianness will keep working as they do now. The downside is that users > of the legacy addfb ioctl will need to magically know which endianness > they will get, but that is apparently already the case. Existing userspace expects host endian, and IMO we should maintain that behavior. > And users of > addfb2 will keep on specifying the endianness explicitly with > DRM_FORMAT_BIG_ENDIAN vs. 0. I'd drop DRM_FORMAT_BIG_ENDIAN. At least for the virt drivers it doesn't buy us anything. They support 32bpp / 8 bpc formats only[1], and for those I can specify the byteswapped format version without a bigendian flag because we have fourccs for everything we need. There is a WIP patch series at https://www.kraxel.org/cgit/linux/log/?h=drm-byteorder Needs more testing and better commit messages. /me plans to polish & post next week, but feel free to look and comment. cheers, Gerd [1] Everything else is a PITA to deal with on the host side because I can't offload that to pixman. There is no support for PIXMAN_r5g6b5 or PIXMAN_x2b10g10r10 in non-host byte order. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
