[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 --- Comment #27 from lct at mail.ru --- Yes, in 35457 in post 37 gnome-shell text corruption is exactly which I experience and is exactly same with screens in this bug. These two are the same critical bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/7c4a463f/attachment.html>
[Bug 35998] RS600: Texture alignment issues under Gnome Shell
https://bugs.freedesktop.org/show_bug.cgi?id=35998 lct at mail.ru changed: What|Removed |Added Severity|normal |major --- Comment #26 from lct at mail.ru --- Affects me as well, OpenSuse 12.3 - Tumbleweed (kernel 3.7-3.11); for my report and details (Samsung R60, hardly any different from people here) see http://phoronix.com/forums/showthread.php?89174-Radeon-Gnome-3-AMD-Xpress-1250-%28Samsung-R60%29-Driver-Glitches&p=374780 Also see https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/751828 Affects a LOT of people. :((( I dump importance to medium-major, because its really distracting as it corrupts whole working area of gnome 3 / gnome shell (time, calender, system control (settings, power options)) With 3.11 kernel one gets a colorful triangle show, screen is tiled into four flashing triangle stips, after 3-4 seconds they vanish, but the font corruption stays same. This bug might be linked with 35457 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/ed7b26e3/attachment-0001.html>
[PATCH 2/2] drm/nouveau/hwmon: Convert to use devm_hwmon_device_register_with_groups
Simplify the code and resolve race conditions seen because
attribute files are created after hwmon device registration,
and removed before hwmon device removal.
Signed-off-by: Guenter Roeck
---
Compile tested only; unfortunately I don't have the the necessary hardware.
drivers/gpu/drm/nouveau/nouveau_hwmon.c | 243 +++
drivers/gpu/drm/nouveau/nouveau_hwmon.h | 11 --
2 files changed, 84 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
index 38a4db5..d4144b8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
@@ -42,9 +42,7 @@
static ssize_t
nouveau_hwmon_show_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 nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
int temp = therm->temp_get(therm);
if (temp < 0)
@@ -68,9 +66,7 @@ static ssize_t
nouveau_hwmon_temp1_auto_point1_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 nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
return snprintf(buf, PAGE_SIZE, "%d\n",
therm->attr_get(therm, NOUVEAU_THERM_ATTR_THRS_FAN_BOOST) * 1000);
@@ -80,9 +76,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp(struct device *d,
struct device_attribute *a,
const char *buf, size_t count)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
long value;
if (kstrtol(buf, 10, &value) == -EINVAL)
@@ -101,9 +95,7 @@ static ssize_t
nouveau_hwmon_temp1_auto_point1_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 nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
return snprintf(buf, PAGE_SIZE, "%d\n",
therm->attr_get(therm, NOUVEAU_THERM_ATTR_THRS_FAN_BOOST_HYST) * 1000);
@@ -113,9 +105,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp_hyst(struct device
*d,
struct device_attribute *a,
const char *buf, size_t count)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
long value;
if (kstrtol(buf, 10, &value) == -EINVAL)
@@ -133,9 +123,7 @@ static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst,
S_IRUGO | S_IWUSR,
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 nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
return snprintf(buf, PAGE_SIZE, "%d\n",
therm->attr_get(therm, NOUVEAU_THERM_ATTR_THRS_DOWN_CLK) * 1000);
@@ -144,9 +132,7 @@ static ssize_t
nouveau_hwmon_set_max_temp(struct device *d, struct device_attribute *a,
const char *buf, size_t count)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
- struct nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
long value;
if (kstrtol(buf, 10, &value) == -EINVAL)
@@ -164,9 +150,7 @@ 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 nouveau_therm *therm = nouveau_therm(drm->device);
+ struct nouveau_therm *therm = dev_get_drvdata(d);
return snprintf(buf, PAGE_SIZE, "%d\n",
therm->attr_get(therm, NOUVEAU_THERM_ATTR_THRS_DOWN_CLK_HYST) * 1000);
@@ -175,9 +159,7 @@ static ssize_t
nouveau_hwmon_set_max_temp_hyst(struct device *d, struct device_attribute *a,
const char *buf, size_t count)
{
- struct drm_device *dev = d
[PATCH 1/2] drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups
Simplify the code and fix race condition seen because
attribute files were created after hwmon device registration.
Signed-off-by: Guenter Roeck
---
Compile tested only; unfortunately I don't have the the necessary hardware.
drivers/gpu/drm/radeon/radeon_pm.c | 49 +---
1 file changed, 12 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index d1385cc..dc75bb6 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -537,8 +537,7 @@ static ssize_t radeon_hwmon_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = dev_get_drvdata(dev);
- struct radeon_device *rdev = ddev->dev_private;
+ struct radeon_device *rdev = dev_get_drvdata(dev);
int temp;
if (rdev->asic->pm.get_temperature)
@@ -566,23 +565,14 @@ static ssize_t radeon_hwmon_show_temp_thresh(struct
device *dev,
return snprintf(buf, PAGE_SIZE, "%d\n", temp);
}
-static ssize_t radeon_hwmon_show_name(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- return sprintf(buf, "radeon\n");
-}
-
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, radeon_hwmon_show_temp, NULL,
0);
static SENSOR_DEVICE_ATTR(temp1_crit, S_IRUGO, radeon_hwmon_show_temp_thresh,
NULL, 0);
static SENSOR_DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
radeon_hwmon_show_temp_thresh, NULL, 1);
-static SENSOR_DEVICE_ATTR(name, S_IRUGO, radeon_hwmon_show_name, NULL, 0);
static struct attribute *hwmon_attributes[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
&sensor_dev_attr_temp1_crit.dev_attr.attr,
&sensor_dev_attr_temp1_crit_hyst.dev_attr.attr,
- &sensor_dev_attr_name.dev_attr.attr,
NULL
};
@@ -607,11 +597,15 @@ static const struct attribute_group hwmon_attrgroup = {
.is_visible = hwmon_attributes_visible,
};
+static const struct attribute_group *hwmon_groups[] = {
+ &hwmon_attrgroup,
+ NULL
+};
+
static int radeon_hwmon_init(struct radeon_device *rdev)
{
int err = 0;
-
- rdev->pm.int_hwmon_dev = NULL;
+ struct device *hwmon_dev;
switch (rdev->pm.int_thermal_type) {
case THERMAL_TYPE_RV6XX:
@@ -624,20 +618,13 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_KV:
if (rdev->asic->pm.get_temperature == NULL)
return err;
- rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
- if (IS_ERR(rdev->pm.int_hwmon_dev)) {
- err = PTR_ERR(rdev->pm.int_hwmon_dev);
+ hwmon_dev = hwmon_device_register_with_groups(rdev->dev,
+ "radeon", rdev,
+ hwmon_groups);
+ if (IS_ERR(hwmon_dev)) {
+ err = PTR_ERR(hwmon_dev);
dev_err(rdev->dev,
"Unable to register hwmon device: %d\n", err);
- break;
- }
- dev_set_drvdata(rdev->pm.int_hwmon_dev, rdev->ddev);
- err = sysfs_create_group(&rdev->pm.int_hwmon_dev->kobj,
-&hwmon_attrgroup);
- if (err) {
- dev_err(rdev->dev,
- "Unable to create hwmon sysfs file: %d\n", err);
- hwmon_device_unregister(rdev->dev);
}
break;
default:
@@ -647,14 +634,6 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
return err;
}
-static void radeon_hwmon_fini(struct radeon_device *rdev)
-{
- if (rdev->pm.int_hwmon_dev) {
- sysfs_remove_group(&rdev->pm.int_hwmon_dev->kobj,
&hwmon_attrgroup);
- hwmon_device_unregister(rdev->pm.int_hwmon_dev);
- }
-}
-
static void radeon_dpm_thermal_work_handler(struct work_struct *work)
{
struct radeon_device *rdev =
@@ -1337,8 +1316,6 @@ static void radeon_pm_fini_old(struct radeon_device *rdev)
if (rdev->pm.power_state)
kfree(rdev->pm.power_state);
-
- radeon_hwmon_fini(rdev);
}
static void radeon_pm_fini_dpm(struct radeon_device *rdev)
@@ -1358,8 +1335,6 @@ static void radeon_pm_fini_dpm(struct radeon_device *rdev)
if (rdev->pm.power_state)
kfree(rdev->pm.power_state);
-
- radeon_hwmon_fini(rdev);
}
void radeon_pm_fini(struct radeon_device *rdev)
--
1.7.9.7
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #24 from Tom Stellard --- (In reply to comment #23) > Created attachment 89640 [details] > steam's log (SS3) > > My PC hung. This is log from the game - nothing exciting as far as i know. > When i find out anything useful i will call you. If you could get a dump with the environment variable R600_DEBUG=ps,vs That would help. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/0be08ae0/attachment.html>
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote: > > Daniel Vetter writes: > > > >> Hm, where do we have the canonical source for all these fourcc codes? I'm > >> asking since we have our own copy in the kernel as drm_fourcc.h, and that > >> one is part of the userspace ABI since we use it to pass around > >> framebuffer formats and format lists. > > > > I think it's the kernel? I really don't know, as the whole notion of > > fourcc codes seems crazy to me... > > > > Feel free to steal this code and stick it in the kernel if you like. > > Well, I wasn't ever in favour of using fourcc codes since they're just > not standardized at all, highly redundant in some cases and also miss > lots of stuff we actually need (like all the rgb formats). I also argued against them, but some people wanted them for whatever reason. And since I didn't want to argue for several years about the subject, I just gave in and made the drm pixel formats fourcss. But given that I just pulled the fourccs out of my ass, we can't really cross use them between different subsystems anyway. So if we just consider all the different fourcc namespaces totally distinct, we're not going to have any problems. Personally I can promise that I will _not_ be checking Mesa/whatever code for conflicting fourccs when I need to add a new one to drm_fourcc.h. There, now I've given fair warning and if things explode later it won't be my fault. However if someone wants to emulate the drm fourcc style for whatever reason, there is a distinct pattern how I cooked them up. Well, a few different patterns depending whether it's RGB,YUV,packed,planar etc. > > Cc'ing the heck out of this to get kernel people to hopefully notice. > Maybe someone takes charge of this ... Otherwise meh. > > >> Just afraid to create long-term maintainance madness here with the > >> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely > >> we'll ever accept srgb for framebuffers though. > > > > Would suck to collide with something we do want though. > > Yeah, it'd suck. But given how fourcc works we probably have that > already, just haven't noticed yet :( > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel OTC
[Bug 71817] Git Mesa r600g driver crashes while using llvm
https://bugs.freedesktop.org/show_bug.cgi?id=71817 Krzysztof A. Sobiecki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Krzysztof A. Sobiecki --- Sorry for the problem. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/5648bb90/attachment.html>
[PATCH] of: Add simple panel device tree binding
This binding specifies a set of common properties for display panels. It
can be used as a basis by bindings for specific panels.
Bindings for three specific panels are provided to show how the simple
panel binding can be used.
Signed-off-by: Thierry Reding
---
This binding has already been discussed earlier. Both Laurent and Tomi
seemed to be generally fine with this. The fact that the binding targets
simple (dumb) panels only and the reduced set of properties make it easy
to be extended in backwards-compatible ways should the need arise, while
at the same time allowing to support a wide variety of panels out there.
.../devicetree/bindings/panel/auo,b101aw03.txt | 7 +++
.../bindings/panel/chunghwa,claa101wb03.txt | 7 +++
.../bindings/panel/panasonic,vvx10f004b00.txt | 7 +++
.../devicetree/bindings/panel/simple-panel.txt | 21 +
4 files changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
create mode 100644
Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
create mode 100644
Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
create mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
new file mode 100644
index ..72e088a4fb3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,b101aw03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
new file mode 100644
index ..0ab2c05a4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa101wb03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
new file mode 100644
index ..d328b0341bf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
@@ -0,0 +1,7 @@
+Panasonic Corporation 10.1" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "panasonic,vvx10f004b00"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
b/Documentation/devicetree/bindings/panel/simple-panel.txt
new file mode 100644
index ..1341bbf4aa3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
@@ -0,0 +1,21 @@
+Simple display panel
+
+Required properties:
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ panel: panel {
+ compatible = "cptt,claa101wb01";
+ ddc-i2c-bus = <&panelddc>;
+
+ power-supply = <&vdd_pnl_reg>;
+ enable-gpios = <&gpio 90 0>;
+
+ backlight = <&backlight>;
+ };
--
1.8.4.2
[Bug 71796] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup - Radeon HD6950
https://bugs.freedesktop.org/show_bug.cgi?id=71796 --- Comment #2 from Universam at gmx.de --- Created attachment 89653 --> https://bugs.freedesktop.org/attachment.cgi?id=89653&action=edit DMESG output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/0eb9af1e/attachment.html>
[Bug 71796] Hardware assisted (VDPAU) decoding of MPEG-2 causes GPU lockup - Radeon HD6950
https://bugs.freedesktop.org/show_bug.cgi?id=71796 --- Comment #1 from Universam at gmx.de --- Same GPU lockup with [AMD/ATI] Caicos [Radeon HD 6450] which has UVD3. Happens upon start of playback of mpeg-2 files, 90% chance of lockup. On some files it seems better, on other worse. Maybe some frame errors are causing this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/df0660de/attachment.html>
[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support
the bus won't have been initialized yet when that
driver is probed and registering a device or bus with it will fail.
> +MODULE_LICENSE("GPL v2");
I think this needs to be "GPL and additional rights" to be used within
DRM.
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
[...]
> +#ifndef __DRM_MIPI_DSI_H__
> +#define __DRM_MIPI_DSI_H__
> +
> +#include
> +#include
> +
> +struct mipi_dsi_bus;
> +struct mipi_dsi_device;
> +
> +struct mipi_dsi_msg {
> + u8 channel;
> + u8 type;
> +
> + size_t tx_len;
> + const void *tx_buf;
> +
> + size_t rx_len;
> + void *rx_buf;
> +};
> +
> +struct mipi_dsi_bus_ops {
> + int (*init)(struct mipi_dsi_bus *bus, struct mipi_dsi_device *dev);
> + int (*set_stream)(struct mipi_dsi_bus *bus, struct mipi_dsi_device *dev,
> + bool on);
Again, these should really be documented. I can somewhat guess what
.init() is supposed to do. But I have no idea what .set_stream() is,
though I think I've seen that in CDF patches. Perhaps that's a relic
from when this was based on CDF?
> + ssize_t (*transfer)(struct mipi_dsi_bus *bus,
> + struct mipi_dsi_device *dev,
> + struct mipi_dsi_msg *msg);
Why do we need the dev parameter? There's already a channel field in the
mipi_dsi_msg structure. Isn't that all that the transfer function needs
to know about the device?
> +#define DSI_MODE_VIDEO (1 << 0)
> +#define DSI_MODE_VIDEO_BURST (1 << 1)
> +#define DSI_MODE_VIDEO_SYNC_PULSE(1 << 2)
> +#define DSI_MODE_VIDEO_AUTO_VERT (1 << 3)
> +#define DSI_MODE_VIDEO_HSE (1 << 4)
> +#define DSI_MODE_VIDEO_HFP (1 << 5)
> +#define DSI_MODE_VIDEO_HBP (1 << 6)
> +#define DSI_MODE_VIDEO_HSA (1 << 7)
> +#define DSI_MODE_VSYNC_FLUSH (1 << 8)
> +#define DSI_MODE_EOT_PACKET (1 << 9)
It should be documented how these are used.
> +enum mipi_dsi_pixel_format {
> + DSI_FMT_RGB888,
> + DSI_FMT_RGB666,
> + DSI_FMT_RGB666_PACKED,
> + DSI_FMT_RGB565,
> +};
> +
> +struct mipi_dsi_interface_params {
> + enum mipi_dsi_pixel_format format;
> + unsigned long mode;
I assume this is a bitmask of DSI_MODE_*. In that case perhaps "modes"
would be a more accurate name?
> + unsigned long hs_clk_freq;
> + unsigned long esc_clk_freq;
How are these interface parameters? The frequencies can certainly vary
depending on the display mode, so why would a device specify that as a
parameter?
> + unsigned char data_lanes;
> + unsigned char cmd_allow;
What's cmd_allow?
> +};
Any reason these parameters cannot be moved to the mipi_dsi_device
structure?
> +struct mipi_dsi_bus {
I'd prefer this to be called mipi_dsi_host, because that's the name used
everywhere in the specification.
> + struct device *dev;
> + const struct mipi_dsi_bus_ops *ops;
> +};
> +
> +#define MIPI_DSI_MODULE_PREFIX "mipi-dsi:"
> +#define MIPI_DSI_NAME_SIZE 32
Do we really need this? Can't we allocate the name dynamically...
> +struct mipi_dsi_device_id {
> + char name[MIPI_DSI_NAME_SIZE];
... or use const char * here?
> + __kernel_ulong_t driver_data/* Data private to the driver */
> + __aligned(sizeof(__kernel_ulong_t));
I don't think the explicit aligned attribute is necessary here.
> +};
> +
> +struct mipi_dsi_device {
> + char name[MIPI_DSI_NAME_SIZE];
> + int id;
> + struct device dev;
> +
> + const struct mipi_dsi_device_id *id_entry;
> + struct mipi_dsi_bus *bus;
> + struct videomode vm;
Why is the videomode part of this structure? What if a device supports
more than a single mode?
> +int of_mipi_dsi_register_devices(struct mipi_dsi_bus *bus);
Perhaps there ought to be a dummy implementation for this in case OF
isn't selected?
In fact, I think we should be hiding all those details from users. They
shouldn't bother about manually registering with OF. Instead this should
be mipi_dsi_register_bus/host()...
> +void mipi_dsi_unregister_devices(struct mipi_dsi_bus *bus);
... and this mipi_dsi_unregister_bus/host(). That way registration with
OF (and instantiation of devices from DT) can be done automatically as
needed.
> +
> +/* module_mipi_dsi_driver() - Helper macro for drivers that don't do
> + * anything special in module init/exit. This eliminates a lot of
> + * boilerplate. Each module may only use this macro once, and
> + * calling it replaces module_init() and module_exit()
> + */
The correct style for block comments for kernel-doc is:
/**
* module_mipi_dsi_driver() - ...
* ...
*/
> +#define mipi_dsi_dcs_write_seq(dev, channel, seq...) \
> +({\
> + const u8 d[] = { seq };\
> + BUILD_BUG_ON_MSG(ARRAY_SIZE(d) > 64, "DCS sequence too long for
> stack");\
> + mipi_dsi_dcs_write(dev, channel, d, ARRAY_SIZE(d));\
> +})
> +
> +#define mipi_dsi_dcs_write_static_seq(dev, channel, seq...) \
> +({\
> + static const u8 d[] = { seq };\
> + mipi_dsi_dcs_write(dev, channel, d, ARRAY_SIZE(d));\
> +})
Can we drop these please? I'd rather have drivers construct buffers
explicitly than use these.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/f9a36ecc/attachment-0001.pgp>
Patch
2013-11-22 17:35, Arthur Schwalbenberg: > > From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001 > From: Arthur Schwalbenberg > Date: Thu, 21 Nov 2013 19:42:44 -0500 > Subject: [PATCH] Staging: Fixed compilar warnings and coding style > issues in i915_debugfs.c > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > This is a patch fixing both a compilar warning: > ?val? may be used uninitialized in this function > and various coding style issues which include line length > warnings and a few errors as defined by 'checkpatch.pl' tool > > Signed-off-by: Arthur Schwalbenberg Hi, When you break 80+ lines into two lines, you should also indent the newly created line so that it shows that it is a part of something. I as well don't think it is worth splitting lines that are 84 characters long into two lines, that just doesn't make sense. Also, your patch seems (atleast to me) a 'bit' whitespace damaged. -- Regards, Levente Kurusa
[i915] BUG: Bad page state in process Xorg
On 11/22/2013 05:18 PM, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer wrote: >>> Am 22.11.2013 um 11:55 schrieb Daniel Vetter : >>> >>> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: > Hi, cc'ing mailing list, Daniel any ideas? >>> Nope, not really :( And no ideas how to triage this further - if it >>> takes 9 days to hit it eventually we'll have a real hard time. Or does >>> this happen even after just a short X run? >> Seems to happen every time while stopping the x server. Also after a short >> run time. >> >> The current fedora 3.11 kernel doesn't show this bug. I'm using fedora 19, >> with a self compiled kernel. >> >> I did turn on config-debug-pagealloc but this didn't show any wrongness. > In that case I think the bisect is the fastest way to insight - atm > I'm really at loss what could be wrong here. From the error messages it looks like whatever's responsible for clearing page->mapping doesn't do it for these pages, (shmem code?). /Thomas > -Daniel
[RFCv3 12/14] drm: Atomic modeset ioctl
Hi Rob and Ville,
2013/11/21 Rob Clark :
> From: Ville Syrj?l?
>
> The atomic modeset ioctl cna be used to push any number of new values
> for object properties. The driver can then check the full device
> configuration as single unit, and try to apply the changes atomically.
>
> The ioctl simply takes a list of object IDs and property IDs and their
> values. For setting values to blob properties, the property value
> indicates the length of the data, and the actual data is passed via
> another blob pointer.
>
> The caller can demand non-blocking operation from the ioctl, and if the
> driver can't satisfy that requirement an error will be returned.
>
> The caller can also request to receive asynchronous completion events
> after the operation has reached the hardware. An event is sent for each
> object specified by the caller, whether or not the actual state of
> that object changed. Each event also carries a framebuffer ID, which
> indicates to user space that the specified object is no longer
> accessing that framebuffer.
>
> TODO: detailed error reporting?
>
> v1: original
> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
> v4: drop atomic event, align flags w/ pageflip (atomic flags should be
> a strick superset of pageflip flags to keep things easier for the
> drivers)
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_crtc.c | 157
> +++-
> drivers/gpu/drm/drm_drv.c | 1 +
> include/drm/drmP.h | 6 ++
> include/drm/drm_crtc.h | 2 +
> include/uapi/drm/drm.h | 12
> include/uapi/drm/drm_mode.h | 21 ++
> 6 files changed, 198 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4b40a39..8368ef5 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4037,7 +4037,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> return -ENOENT;
> crtc = obj_to_crtc(obj);
>
> - state = dev->driver->atomic_begin(dev, page_flip->flags);
> + state = dev->driver->atomic_begin(dev,
> + page_flip->flags | DRM_MODE_ATOMIC_NONBLOCK);
> if (IS_ERR(state))
> return PTR_ERR(state);
>
> @@ -4451,3 +4452,157 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> idr_destroy(&dev->mode_config.crtc_idr);
> }
> EXPORT_SYMBOL(drm_mode_config_cleanup);
> +
> +int drm_mode_atomic_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv)
> +{
Build error at this function like below,
drivers/built-in.o: In function `drm_mode_atomic_ioctl':
of_iommu.c:(.text+0x6d854): undefined reference to `__get_user_bad'
of_iommu.c:(.text+0x6d940): undefined reference to `__get_user_bad'
And built correctly with the below change,
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..0f4f469 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -66,7 +66,7 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
-__get_user_bad:
+ENTRY(__get_user_bad)
mov r2, #0
mov r0, #-EFAULT
mov pc, lr
I guess __get_user_bad is not global but drm_mode_atomic_ioctl
function tries to refer this function as extern.
Is it build error only I can see?
Thanks,
Inki Dae
[i915] BUG: Bad page state in process Xorg
On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer wrote: >> Am 22.11.2013 um 11:55 schrieb Daniel Vetter : >> >> On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: Hi, >>> >>> cc'ing mailing list, >>> >>> Daniel any ideas? >> >> Nope, not really :( And no ideas how to triage this further - if it >> takes 9 days to hit it eventually we'll have a real hard time. Or does >> this happen even after just a short X run? > > Seems to happen every time while stopping the x server. Also after a short > run time. > > The current fedora 3.11 kernel doesn't show this bug. I'm using fedora 19, > with a self compiled kernel. > > I did turn on config-debug-pagealloc but this didn't show any wrongness. In that case I think the bisect is the fastest way to insight - atm I'm really at loss what could be wrong here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote: > Daniel Vetter writes: > >> Hm, where do we have the canonical source for all these fourcc codes? I'm >> asking since we have our own copy in the kernel as drm_fourcc.h, and that >> one is part of the userspace ABI since we use it to pass around >> framebuffer formats and format lists. > > I think it's the kernel? I really don't know, as the whole notion of > fourcc codes seems crazy to me... > > Feel free to steal this code and stick it in the kernel if you like. Well, I wasn't ever in favour of using fourcc codes since they're just not standardized at all, highly redundant in some cases and also miss lots of stuff we actually need (like all the rgb formats). Cc'ing the heck out of this to get kernel people to hopefully notice. Maybe someone takes charge of this ... Otherwise meh. >> Just afraid to create long-term maintainance madness here with the >> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely >> we'll ever accept srgb for framebuffers though. > > Would suck to collide with something we do want though. Yeah, it'd suck. But given how fourcc works we probably have that already, just haven't noticed yet :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] i915, debugfs: Fix uninitialized warning
On Thu, Nov 21, 2013 at 05:25:35PM +0100, Borislav Petkov wrote:
> On Thu, Nov 21, 2013 at 05:10:30PM +0100, Richard Weinberger wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 6ed45a984230..1191aa47adc9 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2347,7 +2347,7 @@ static int pipe_crc_set_source(struct drm_device
> > > *dev, enum pipe pipe,
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
> > > - u32 val;
> > > + u32 val = 0; /* shut up gcc */
> >
> > Wouldn't it be better to use uninitialized_var() here?
>
> I remember Linus' rant about this macro so that's why I don't use it
> anymore.
>
> In this specific case, it doesn't matter whichever we do so I'll let the
> maintainer make a wish :)
IIRC this warning was there for me too on gcc 4.6, but it disappeared
on gcc 4.7, which is why I decided not to send a patch for it.
--
Ville Syrj?l?
Intel OTC
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #5 from ?ukasz Skocz --- (In reply to comment #4) > Please provide a sample video where this is happening. This one seems to cause the same error as my files (can't upload mine due to copyright restrains): http://www.cccp-project.net/beta/test_files/KAA_fumoffu_old_x264_breaks_lavc.mkv I noticed that the playback sometimes finishes sucessfully if i stop moving the mouse completly, but as soon as i start moving it, the breakage is certain. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/9bc2a447/attachment.html>
[i915] BUG: Bad page state in process Xorg
> Am 22.11.2013 um 11:55 schrieb Chris Wilson : > >> On Wed, Nov 20, 2013 at 09:55:28PM +0100, Thomas Meyer wrote: >> Hi, >> >> I reported this bug a few days ago, but nobody did respond to my bug >> report: >> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html >> >> Every time I restart the X server I will run into this bug with 3.12.0. > > I think whilst we scratch our heads wondering about what could cause > corruption in our struct page, we would welcome a bisection. If it dies > during X startup, it would seems like a bisection would progress > quickly. Thanks, No, but on every(?) shutdown of the Xorg server. So I'll try to bisect this. Hopefully I'll find some time this weekend. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
[i915] BUG: Bad page state in process Xorg
> Am 22.11.2013 um 11:55 schrieb Daniel Vetter : > > On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: >>> Hi, >> >> cc'ing mailing list, >> >> Daniel any ideas? > > Nope, not really :( And no ideas how to triage this further - if it > takes 9 days to hit it eventually we'll have a real hard time. Or does > this happen even after just a short X run? Seems to happen every time while stopping the x server. Also after a short run time. The current fedora 3.11 kernel doesn't show this bug. I'm using fedora 19, with a self compiled kernel. I did turn on config-debug-pagealloc but this didn't show any wrongness. > > Also is this a regression, i.e. please test a few older kernels, too. > -Daniel > >> >> Dave. >> >>> I reported this bug a few days ago, but nobody did respond to my bug >>> report: >>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html >>> >>> Every time I restart the X server I will run into this bug with 3.12.0. >>> >>> Help is welcome. >>> >>> [ 9913.719551] BUG: Bad page state in process Xorg pfn:20f2bb >>> [ 9913.721755] page:ea00083caec0 count:0 mapcount:0 >>> mapping:8802357975f8 index:0xe >>> [ 9913.733741] page flags: >>> 0x8008001c(referenced|uptodate|dirty|swapbacked) >>> [ 9913.741062] Modules linked in: tcp_lp fuse ipt_MASQUERADE ip6t_REJECT >>> xt_conntrack bluetooth ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 >>> nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat >>> nf_conntrack iptable_mangle iptable_security iptable_raw arc4 iwldvm >>> snd_usb_audio mac80211 snd_hda_codec_hdmi iwlwifi snd_hda_codec_realtek >>> snd_usbmidi_lib snd_hda_intel kvm_intel asix snd_hda_codec usbnet kvm atl1c >>> snd_hwdep mii snd_seq acer_wmi acerhdf sparse_keymap snd_pcm joydev pcspkr >>> cfg80211 rfkill acpi_cpufreq freq_table snd_rawmidi snd_seq_device >>> snd_page_alloc snd_timer snd wmi soundcore uinput ipv6 xts gf128mul udl >>> syscopyarea sysfillrect sysimgblt drm_usb usb_storage >>> [ 9913.741125] CPU: 0 PID: 723 Comm: Xorg Tainted: GB3.12.0 #2 >>> [ 9913.741128] Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310 >>> 03/25/2010 >>> [ 9913.741130] 880213127cc0 8154dc8b >>> 880213127cd8 >>> [ 9913.741135] 8154b6e7 ea00083caec0 880213127d10 >>> 810c6955 >>> [ 9913.741139] ea00083caec0 8008001c >>> 88023408 >>> [ 9913.741143] Call Trace: >>> [ 9913.741151] [] dump_stack+0x19/0x1b >>> [ 9913.741155] [] bad_page+0xc9/0xe2 >>> [ 9913.741160] [] free_pages_prepare+0xd5/0xe0 >>> [ 9913.741165] [] free_hot_cold_page+0x1d/0x120 >>> [ 9913.741169] [] __put_single_page+0x1e/0x30 >>> [ 9913.741172] [] put_page+0x25/0x40 >>> [ 9913.741178] [] >>> i915_gem_object_put_pages_gtt+0xc3/0x1a0 >>> [ 9913.741183] [] i915_gem_object_put_pages+0x78/0xd0 >>> [ 9913.741187] [] i915_gem_free_object+0xe7/0x220 >>> [ 9913.741192] [] drm_gem_object_free+0x25/0x30 >>> [ 9913.741196] [] drm_gem_dmabuf_release+0x4b/0x70 >>> [ 9913.741201] [] dma_buf_release+0x27/0x90 >>> [ 9913.741205] [] __fput+0xcb/0x240 >>> [ 9913.741209] [] fput+0x9/0x10 >>> [ 9913.741214] [] task_work_run+0x9c/0xc0 >>> [ 9913.741219] [] do_exit+0x6d5/0x9d0 >>> [ 9913.741223] [] ? __schedule+0x243/0x5e0 >>> [ 9913.741227] [] ? task_work_run+0x84/0xc0 >>> [ 9913.741232] [] do_group_exit+0x35/0x90 >>> [ 9913.741236] [] SyS_exit_group+0xf/0x10 >>> [ 9913.741241] [] system_call_fastpath+0x16/0x1b >>> [ 9913.741246] BUG: Bad page state in process Xorg pfn:20f2bc >>> [ 9913.749565] page:ea00083caf00 count:0 mapcount:0 >>> mapping:8802357975f8 index:0xf >>> >>> with kind regards >>> thomas >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #4 from Christian K?nig --- Please provide a sample video where this is happening. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/4cdc75f0/attachment.html>
[PATCH] drm: add DRM_ERROR_RATELIMITED
On Thu, Nov 21, 2013 at 02:29:51PM -0500, Rob Clark wrote: > For error traces in situations that can run away, it is nice to have a > rate-limited version of DRM_ERROR() to avoid massing log flooding. s/massing/massive/? Other than that, looks good: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/1d28f9ab/attachment.pgp>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
Ville Syrj?l? writes: > What is this format anyway? -ENODOCS Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-) > If its just an srgb version of ARGB, then I wouldn't really want it > in drm_fourcc.h. I expect colorspacy stuff will be handled by various > crtc/plane properties in the kernel so we don't need to encode that > stuff into the fb format. It's not any different from splitting YUV codes from RGB codes; a different color encoding with the same bitfields. And, for mesa, it's necessary to differentiate between ARGB and SARGB within the same format code given how the API is structured. So, we have choices: 1) Let Mesa define it's own fourcc codes and risk future accidental collisions 2) Rewrite piles of mesa code to split out the color encoding from the bitfield information and pass it separately. 3) Add "reasonable" format codes like this to the kernel fourcc list. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/cf280b75/attachment-0001.pgp>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
Kristian H?gsberg writes:
> I already explained to Keith why we use different sets of format codes
> in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage interfaces use *both*
__DRI_IMAGE_FOURCC and __DRI_IMAGE_FORMAT at different times.
Ok, here's a fine thing we can actually fix -- the pattern that mesa
uses all over the place in converting formats looks like this (not to
pick on anyone, it's repeated everywhere, this is just the first one I
found in gbm_dri.c):
static uint32_t
gbm_dri_to_gbm_format(uint32_t dri_format)
{
uint32_t ret = 0;
switch (dri_format) {
case __DRI_IMAGE_FORMAT_RGB565:
ret = GBM_FORMAT_RGB565;
break;
case __DRI_IMAGE_FORMAT_XRGB:
ret = GBM_FORMAT_XRGB;
break;
case __DRI_IMAGE_FORMAT_ARGB:
ret = GBM_FORMAT_ARGB;
break;
case __DRI_IMAGE_FORMAT_ABGR:
ret = GBM_FORMAT_ABGR;
break;
default:
ret = 0;
break;
}
return ret;
}
The problem here is that any unknown incoming formats get translated to
garbage (0) outgoing. With fourcc codes, there is the slight advantage
that 0 is never a legal value, but it sure would be nice to print a
warning or even abort if you get a format code you don't understand as
there's no way 0 is ever going to do what you want.
Anyone have a preference? Abort? Print an error? Silently continue to do
the wrong thing?
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/c4e036f0/attachment.pgp>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #3 from ?ukasz Skocz --- Comment on attachment 89642 --> https://bugs.freedesktop.org/attachment.cgi?id=89642 vdpauinfo output display: :0.0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types --- 420 8192 8192 NV12 422 8192 8192 NV12 444 8192 8192 NV12 Decoder capabilities: name level macbs width height --- MPEG116 9216 2048 1152 MPEG2_SIMPLE 16 9216 2048 1152 MPEG2_MAIN 16 9216 2048 1152 H264_BASELINE16 9216 2048 1152 H264_MAIN16 9216 2048 1152 H264_HIGH16 9216 2048 1152 VC1_SIMPLE 16 9216 2048 1152 VC1_MAIN 16 9216 2048 1152 VC1_ADVANCED 16 9216 2048 1152 Output surface: name width height nat types B8G8R8A8 8192 8192y NV12 R8G8B8A8 8192 8192y NV12 R10G10B10A2 8192 8192y NV12 B10G10R10A2 8192 8192y NV12 Bitmap surface: name width height -- B8G8R8A8 8192 8192 R8G8B8A8 8192 8192 R10G10B10A2 8192 8192 B10G10R10A2 8192 8192 A88192 8192 Video mixer: feature namesup DEINTERLACE_TEMPORAL - DEINTERLACE_TEMPORAL_SPATIAL - INVERSE_TELECINE - NOISE_REDUCTION y SHARPNESSy LUMA_KEY - HIGH QUALITY SCALING - L1- HIGH QUALITY SCALING - L2- HIGH QUALITY SCALING - L3- HIGH QUALITY SCALING - L4- HIGH QUALITY SCALING - L5- HIGH QUALITY SCALING - L6- HIGH QUALITY SCALING - L7- HIGH QUALITY SCALING - L8- HIGH QUALITY SCALING - L9- parameter name sup min max - VIDEO_SURFACE_WIDTH y48 2048 VIDEO_SURFACE_HEIGHT y48 1152 CHROMA_TYPE y LAYERS y 04 attribute name sup min max - BACKGROUND_COLOR y CSC_MATRIX y NOISE_REDUCTION_LEVELy 0.00 1.00 SHARPNESS_LEVEL y -1.00 1.00 LUMA_KEY_MIN_LUMAy LUMA_KEY_MAX_LUMAy Inconsistency detected by ld.so: dl-close.c: 771: _dl_close: Assertion `map->l_init_called' failed! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/72f37a6f/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 ?ukasz Skocz changed: What|Removed |Added Attachment #89643|application/octet-stream|text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/7575cd53/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 Alex Deucher changed: What|Removed |Added Attachment #89642|application/octet-stream|text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/da6d011a/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #2 from ?ukasz Skocz --- Created attachment 89643 --> https://bugs.freedesktop.org/attachment.cgi?id=89643&action=edit glxinfo output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/30e6be11/attachment.html>
[Bug 71923] Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 --- Comment #1 from ?ukasz Skocz --- Created attachment 89642 --> https://bugs.freedesktop.org/attachment.cgi?id=89642&action=edit vdpauinfo output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/bb7664cd/attachment-0001.html>
[Bug 71923] New: Screen corruption when watching VDPAU-accelerated H264 video
https://bugs.freedesktop.org/show_bug.cgi?id=71923 Priority: medium Bug ID: 71923 Assignee: dri-devel at lists.freedesktop.org Summary: Screen corruption when watching VDPAU-accelerated H264 video Severity: normal Classification: Unclassified OS: Linux (All) Reporter: kaszak696 at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.2 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 89641 --> https://bugs.freedesktop.org/attachment.cgi?id=89641&action=edit Dmesg log with the described errors Hi, i have a trouble watching some H264 videos when using VDPAU acceleration. What happens is the screen gets completly corrupted (gray bars cover the whole screen) when player plays a certain frame in the video. It always happens at the same point of the video, for some videos it doesn't happen at all. I managed to blindly save smesg output to a file when this happened, and it's filled with these kinds of messages: [ 47.595028] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 48.303022] Forbidden register 0x0020 in cs at 9 [ 48.303029] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 56.146022] Forbidden register 0x0024 in cs at 9 [ 56.146029] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 57.148021] Forbidden register 0x0028 in cs at 9 [ 57.148028] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 57.523022] Forbidden register 0x0024 in cs at 9 [ 57.523030] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! I'm using Arch Linux with 3.12.1-ck at the moment, but it also happened on 3.11-ck and 3.11 vanilla. lspci reports this card name, it's a Radeon 4570: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v] I'm using the newest stable mesa 9.2.3 and xf86-video-ati 7.2.0. The issue happens with mpv and mplayer. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/2d6c1225/attachment.html>
[Bug 61941] Random GPU lockups/resets on Mobility Radeon HD 3650 with radeon.dpm=1
https://bugzilla.kernel.org/show_bug.cgi?id=61941 --- Comment #15 from Shawn Starr --- My Theory is incorrect, but what is interesting was I could get the GPU to reset quicker, still, using EXA is unreliable use GLAMOR in your xorg.conf (if you dont have a newer stack). This was stable even if its masking the real issue going on. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71864] [RS690] GPU Lockup CP Stall and Resulting Kernel Oops (Kernel 3.2.0)
https://bugs.freedesktop.org/show_bug.cgi?id=71864 --- Comment #12 from Alex Deucher --- (In reply to comment #11) > (In reply to comment #10) > > Is this still an issue with a newer kernel? Did you also update your > > userspace stack (mesa, xf86-video-ati)? > > We used Ubuntu update manager to upgrade to kernel 3.2. It's part of > Ubuntu's long term support release 12.04. > From the attached logs I can see following installed versions: > 1. xserver-xorg-video-ati (Ubuntu's xf86-video-ati) > [ 107.230] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so > [ 107.230] (II) Module ati: vendor="X.Org Foundation" > [ 107.230] compiled for 1.11.3, module version = 6.14.99 > [ 107.230] Module class: X.Org Video Driver > [ 107.230] ABI class: X.Org Video Driver, version 11.0 > [ 107.230] (II) LoadModule: "radeon" > [ 107.230] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so > [ 107.231] (II) Module radeon: vendor="X.Org Foundation" > [ 107.231] compiled for 1.11.3, module version = 6.14.99 > [ 107.231] Module class: X.Org Video Driver > [ 107.231] ABI class: X.Org Video Driver, version 11.0 > 2. OpenGL version string: 2.1 Mesa 8.0.4 > > Are these the expected versions? I'm not sure what ubuntu ships off hand. > > I can try to install also a newer kernel. But as we talk about a 24/7 > server, I need some guidance. Newer kernel also requires newer userspace > stack? Which kernel version would you recommend? The kernels and userspace stacks are generally compatible, so for the most part you can mix and match userspace and kernel versions as long as both support your asics. > > Do you have any ideas on possible root causes of this kernel oops? Some combination of commands from the userspace components is causing a a GPU hang. The driver attempts to reset the GPU, but fails. I would suggest trying upgrading or downgrading your userspace gfx components to see if that helps. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/21853c9e/attachment.html>
[GIT PULL] exynos-drm-fixes
Hi Dave, This pull request includes two fixup patches. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 760c960bd6880cf22a57c0af9ff60c96250aad39: drm/sysfs: fix hotplug regression since lifetime changes (2013-11-21 21:10:00 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-fixes for you to fetch changes up to 09fe49e83ddce2f1c2141f3af3968b4b54722f08: drm/exynos: release unhandled page flip events at postclose. (2013-11-22 14:47:16 +0900) Inki Dae (1): drm/exynos: release unhandled page flip events at postclose. Sachin Kamat (1): drm/exynos: Fix trivial typo in exynos_drm_fimd.c drivers/gpu/drm/exynos/exynos_drm_drv.c | 35 +++--- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- 2 files changed, 23 insertions(+), 14 deletions(-)
[Bug 71864] [RS690] GPU Lockup CP Stall and Resulting Kernel Oops (Kernel 3.2.0)
https://bugs.freedesktop.org/show_bug.cgi?id=71864 --- Comment #11 from reimth at gmail.com --- (In reply to comment #10) > Is this still an issue with a newer kernel? Did you also update your > userspace stack (mesa, xf86-video-ati)? We used Ubuntu update manager to upgrade to kernel 3.2. It's part of Ubuntu's long term support release 12.04. >From the attached logs I can see following installed versions: 1. xserver-xorg-video-ati (Ubuntu's xf86-video-ati) [ 107.230] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so [ 107.230] (II) Module ati: vendor="X.Org Foundation" [ 107.230] compiled for 1.11.3, module version = 6.14.99 [ 107.230] Module class: X.Org Video Driver [ 107.230] ABI class: X.Org Video Driver, version 11.0 [ 107.230] (II) LoadModule: "radeon" [ 107.230] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [ 107.231] (II) Module radeon: vendor="X.Org Foundation" [ 107.231] compiled for 1.11.3, module version = 6.14.99 [ 107.231] Module class: X.Org Video Driver [ 107.231] ABI class: X.Org Video Driver, version 11.0 2. OpenGL version string: 2.1 Mesa 8.0.4 Are these the expected versions? I can try to install also a newer kernel. But as we talk about a 24/7 server, I need some guidance. Newer kernel also requires newer userspace stack? Which kernel version would you recommend? Do you have any ideas on possible root causes of this kernel oops? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/90d00c11/attachment.html>
[Mesa-dev] [PATCH] gallium: Use base.stamp for all drawable invalidation checks.
Reviewed-by: Marek Ol??k
Marek
On Fri, Nov 22, 2013 at 5:20 AM, Keith Packard wrote:
> Upper levels of the stack use base.stamp to tell when a drawable needs to be
> revalidated, but the dri state tracker was using dPriv->lastStamp. Those two,
> along with dri2.stamp, all get simultaneously incremented when a dri2
> invalidate event was delivered, and so end up containing precisely the same
> value.
>
> This patch doesn't change the fact that there are three variables, rather it
> switches all of the tests to use only base.stamp, which is functionally
> equivalent to the previous code.
>
> Then, it passes base.stamp to the image loader getBuffers function so that the
> one which is checked will get updated by the XCB special event queue used by
> DRI3.
>
> Signed-off-by: Keith Packard
> ---
>
> This patch makes sure that drawables get invalidated when the window
> changes size or when SwapBuffers is called; dri3 has only a single
> location to smite when things change, so we need to make sure the
> upper levels all share that location.
>
> This should permit the elimination of the dri2.stamp and lastStamp
> variables, which would be a nice further cleanup.
>
> src/gallium/state_trackers/dri/common/dri_drawable.c | 4 ++--
> src/gallium/state_trackers/dri/drm/dri2.c| 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/common/dri_drawable.c
> b/src/gallium/state_trackers/dri/common/dri_drawable.c
> index f255108..734bca2 100644
> --- a/src/gallium/state_trackers/dri/common/dri_drawable.c
> +++ b/src/gallium/state_trackers/dri/common/dri_drawable.c
> @@ -73,7 +73,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
> * checked.
> */
> do {
> - lastStamp = drawable->dPriv->lastStamp;
> + lastStamp = drawable->base.stamp;
>new_stamp = (drawable->texture_stamp != lastStamp);
>
>if (new_stamp || new_mask || screen->broken_invalidate) {
> @@ -91,7 +91,7 @@ dri_st_framebuffer_validate(struct st_context_iface *stctx,
> drawable->texture_stamp = lastStamp;
> drawable->texture_mask = statt_mask;
>}
> - } while (lastStamp != drawable->dPriv->lastStamp);
> + } while (lastStamp != drawable->base.stamp);
>
> if (!out)
>return TRUE;
> diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
> b/src/gallium/state_trackers/dri/drm/dri2.c
> index 6a56cd4..c7e4151 100644
> --- a/src/gallium/state_trackers/dri/drm/dri2.c
> +++ b/src/gallium/state_trackers/dri/drm/dri2.c
> @@ -545,7 +545,7 @@ dri_image_allocate_textures(struct dri_context *ctx,
>
> (*sPriv->image.loader->getBuffers) (dPriv,
> image_format,
> - &dPriv->dri2.stamp,
> + (uint32_t *) &drawable->base.stamp,
> dPriv->loaderPrivate,
> buffer_mask,
> &images);
> --
> 1.8.4.2
>
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #23 from Arek Ru?niak --- Created attachment 89640 --> https://bugs.freedesktop.org/attachment.cgi?id=89640&action=edit steam's log (SS3) My PC hung. This is log from the game - nothing exciting as far as i know. When i find out anything useful i will call you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/45c7366b/attachment-0001.html>
possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?
Am 15.11.2013 09:27, schrieb Michel D?nzer:
> On Fre, 2013-11-15 at 08:49 +0100, Jochen Rollwagen wrote:
>> I think there are two issues here: the first is the missing alignment
>> workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some
>> diagnostic messages in radeon_device.c and see what happens.
> Yes, please do that before speculating more about the problem.
>
>
>> But i'm pretty certain now that this isn't the cause for the lockups.
>> They are probably (quite certainly) caused by the dynamic
>> binding/unbinding of AGP memory which the Uninorth chipset used in
>> 32-bit powermacs obviously doesn't support.
> "doesn't support" is too strong; it's working fine on this PowerBook5,8.
> But the older the revision of UniNorth, the more quirks.
>
>> All it supports seems to be statically allocating a 256 MB contigouous
>> non-cacheable AGP aperture and using that (since the chipset doesn't
>> do any address mapping via the GART as indicated in the OpenBSD code).
> It does address mapping for the GPU, that's the whole point of the GART.
> What UniNorth doesn't do in contrast to most AGP bridges is provide a
> linear aperture to the CPU as well. But that shouldn't be an issue per
> se.
>
>> So to get AGP mode working again on those machines one would have to
>> disable the dynamic memory stuff. Question: Would that require changes
>> in the driver only or also in the DRM ?
> It's not really possible with radeon KMS.
>
>
the relevant syslog part is:
/var/log/syslog:Nov 22 11:32:08 mac-mini kernel: [3.363099] [drm]
Initialized radeon 2.16.0 20080528 for :00:10.0 on minor 0
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.476580] radeon
:00:10.0: GPU lockup CP stall for more than 1msec
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.477629] radeon
:00:10.0: GPU reset succeed
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.655218] kernel
BUG at drivers/gpu/drm/radeon/radeon_object.c:410!
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.660331] Modules
linked in: dm_crypt arc4 btusb parport_pc ppdev b43 bnep joydev
bluetooth lp mac_hid parport rtc_generic mac80211 snd_aoa_codec_onyx
snd_aoa_codec_tas snd_aoa_codec_toonie cfg80211 snd_aoa_fabric_layout
snd_aoa snd_aoa_i2sbus snd_aoa_soundbus bcma snd_powermac snd_pcm
snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer
snd_seq_device snd soundcore snd_page_alloc usbhid hid radeon
firewire_ohci sungem firewire_core crc_itu_t sungem_phy ttm
drm_kms_helper ssb drm
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664059] NIP
[f15b5158] radeon_bo_get_surface_reg+0x30/0x144 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664313] LR
[f159b7b8] radeon_surface_init+0x3c/0xac [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664657]
[eba63c10] [f15d10bc] r100_pll_rreg+0x58/0x70 [radeon] (unreliable)
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664931]
[eba63c30] [f159b7b8] radeon_surface_init+0x3c/0xac [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665184]
[eba63c50] [f15d2edc] r100_resume+0x68/0x104 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665414]
[eba63c70] [f159d54c] radeon_gpu_reset+0x120/0x164 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665661]
[eba63c90] [f15b2544] radeon_fence_wait+0x3d8/0x404 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665914]
[eba63d00] [f15c7618] radeon_ib_get+0x250/0x2d0 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.666155]
[eba63d50] [f15c9c80] radeon_cs_ioctl+0x3c4/0x6e0 [radeon]
the code where the kernel bug seems to hit is
int radeon_bo_get_surface_reg(struct radeon_bo *bo)
{
struct radeon_device *rdev = bo->rdev;
struct radeon_surface_reg *reg;
struct radeon_bo *old_object;
int steal;
int i;
BUG_ON(!atomic_read(&bo->tbo.reserved));
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/8fa8d241/attachment-0001.html>
[Bug 71817] Git Mesa r600g driver crashes while using llvm
https://bugs.freedesktop.org/show_bug.cgi?id=71817 --- Comment #3 from vincent --- You need at least revision @@194425 of llvm 3.4 to have the commit labeled : commit 70a7d5ddb4f00bbb61afe7b536c6f599f771ab9a Author: Vincent Lejeune Date: Mon Nov 11 22:10:24 2013 + R600: Use function inputs to represent data stored in gpr git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 194425 91177308-0d3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/df0dc787/attachment.html>
[Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Fri, Nov 22, 2013 at 05:17:37PM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 12:01 PM, Keith Packard wrote: > > Daniel Vetter writes: > > > >> Hm, where do we have the canonical source for all these fourcc codes? I'm > >> asking since we have our own copy in the kernel as drm_fourcc.h, and that > >> one is part of the userspace ABI since we use it to pass around > >> framebuffer formats and format lists. > > > > I think it's the kernel? I really don't know, as the whole notion of > > fourcc codes seems crazy to me... > > > > Feel free to steal this code and stick it in the kernel if you like. > > Well, I wasn't ever in favour of using fourcc codes since they're just > not standardized at all, highly redundant in some cases and also miss > lots of stuff we actually need (like all the rgb formats). These drm codes are not fourcc codes in any other way than that they're defined by creating a 32 bit value by picking four characters. I don't know what PTSD triggers people have from hearing "fourcc", but it seems severe. Forget all that, these codes are DRM specific defines that are not inteded to match anything anybody else does. It doesn't matter if these match of conflict with v4l, fourcc.org, wikipedia.org or what the amiga did. They're just tokens that let us define succintly what the pixel format of a kms framebuffer is and tell the kernel. I don't know what else you'd propose? Pass an X visual in the ioctl? An EGL config? This is our name space, we can add stuff as we need (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the canonical source for these values and we should add DRM_FORMAT_SARGB there to make sure we don't clash. Why are these codes in mesa (and gbm and wl_drm protocol) then? Because it turns out that once you have an stable and established namespace for pixel formats (and a kernel userspace header is about as stable and established as it gets) it makes a lot of sense to reuse those values. I already explained to Keith why we use different sets of format codes in the DRI interface, but it's always fun to slam other peoples code. Anyway, it's pretty simple, the __DRI_IMAGE_FORMAT_* defines predate the introduction of drm_fourcc.h. When we later added suport for planar YUV __DRIimages, the kernel had picked up drm_fourcc.h after a long sad bikeshedding flamewar, which included the planar formats we needed. At this point we could continue using our custom __DRI_IMAGE_FORMAT_* defines or we could switch to the tokens that we had finally converged on. But don't let me ruin a good old snide remark. > Cc'ing the heck out of this to get kernel people to hopefully notice. > Maybe someone takes charge of this ... Otherwise meh. I don't know what you want to change. These values are already kernel ABI, we use them in drmAddFB2, and again, I don't understand what problem you're seeing. Kristian > >> Just afraid to create long-term maintainance madness here with the > >> kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely > >> we'll ever accept srgb for framebuffers though. > > > > Would suck to collide with something we do want though. > > Yeah, it'd suck. But given how fourcc works we probably have that > already, just haven't noticed yet :( > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH] of: Add simple panel device tree binding
On Fri, Nov 22, 2013 at 12:41 PM, Thierry Reding
wrote:
> This binding specifies a set of common properties for display panels. It
> can be used as a basis by bindings for specific panels.
>
> Bindings for three specific panels are provided to show how the simple
> panel binding can be used.
>
> Signed-off-by: Thierry Reding
Thanks for a "simple" binding that actually provides specific h/w information.
Acked-by: Rob Herring
Rob
> ---
> This binding has already been discussed earlier. Both Laurent and Tomi
> seemed to be generally fine with this. The fact that the binding targets
> simple (dumb) panels only and the reduced set of properties make it easy
> to be extended in backwards-compatible ways should the need arise, while
> at the same time allowing to support a wide variety of panels out there.
>
> .../devicetree/bindings/panel/auo,b101aw03.txt | 7 +++
> .../bindings/panel/chunghwa,claa101wb03.txt | 7 +++
> .../bindings/panel/panasonic,vvx10f004b00.txt | 7 +++
> .../devicetree/bindings/panel/simple-panel.txt | 21
> +
> 4 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> create mode 100644
> Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> create mode 100644
> Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> create mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt
>
> diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> new file mode 100644
> index ..72e088a4fb3a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
> @@ -0,0 +1,7 @@
> +AU Optronics Corporation 10.1" WSVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "auo,b101aw03"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> new file mode 100644
> index ..0ab2c05a4c22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
> @@ -0,0 +1,7 @@
> +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "chunghwa,claa101wb03"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git
> a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> new file mode 100644
> index ..d328b0341bf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
> @@ -0,0 +1,7 @@
> +Panasonic Corporation 10.1" WUXGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "panasonic,vvx10f004b00"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt
> b/Documentation/devicetree/bindings/panel/simple-panel.txt
> new file mode 100644
> index ..1341bbf4aa3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
> @@ -0,0 +1,21 @@
> +Simple display panel
> +
> +Required properties:
> +- power-supply: regulator to provide the supply voltage
> +
> +Optional properties:
> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> +- enable-gpios: GPIO pin to enable or disable the panel
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + panel: panel {
> + compatible = "cptt,claa101wb01";
> + ddc-i2c-bus = <&panelddc>;
> +
> + power-supply = <&vdd_pnl_reg>;
> + enable-gpios = <&gpio 90 0>;
> +
> + backlight = <&backlight>;
> + };
> --
> 1.8.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 65481] New: Page allocation failure errors on Trinity when playing a HL2 mod (i386 code on 64 bit kernel )
https://bugzilla.kernel.org/show_bug.cgi?id=65481 Bug ID: 65481 Summary: Page allocation failure errors on Trinity when playing a HL2 mod (i386 code on 64 bit kernel ) Product: Drivers Version: 2.5 Kernel Version: 3.12.0 git Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: laszlo.kertesz at gmail.com Regression: No Created attachment 115641 --> https://bugzilla.kernel.org/attachment.cgi?id=115641&action=edit full dmesg showing the errors I use a 64 bit Debian system with kernel (mainline, now 3.12.0-10928-g527d151), mesa, llvm, drm, xf86-ati compiled from git on an A8-5500 APU (radeon/r600 driver, . While i played a Half Life 2 mod called No more room in hell on Steam (32-bit application) i noticed that dmesg is full of errors like: hl2_linux: page allocation failure: order:4, mode:0x2000d0 CPU: 0 PID: 17112 Comm: hl2_linux Not tainted 3.12.0-10928-g527d151-dirty #4 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A85X-D3H, BIOS F1 10/09/2012 880136a03988 8143ae44 002000d0 81100853 0002 88013eff8b00 0001 8111610d 88013eff8b08 0002 Call Trace: [] ? dump_stack+0x41/0x51 [] ? warn_alloc_failed+0xe3/0x130 [] ? next_online_pgdat+0x1d/0x50 [] ? __alloc_pages_nodemask+0x860/0xa30 [] ? kmem_getpages+0x5f/0x1a0 [] ? fallback_alloc+0x16c/0x250 [] ? __kmalloc+0x2b6/0x490 [] ? radeon_cs_ioctl+0x1ee/0x990 [radeon] [] ? radeon_cs_ioctl+0x1ee/0x990 [radeon] [] ? drm_ioctl+0x46d/0x570 [drm] [] ? radeon_drm_ioctl+0x44/0x80 [radeon] [] ? radeon_kms_compat_ioctl+0xb/0x20 [radeon] [] ? compat_sys_ioctl+0xbf/0x1110 [] ? compat_SyS_futex+0x69/0x140 [] ? cstar_dispatch+0x7/0x1a Mem-Info: Node 0 DMA per-cpu: CPU0: hi:0, btch: 1 usd: 0 CPU1: hi:0, btch: 1 usd: 0 CPU2: hi:0, btch: 1 usd: 0 CPU3: hi:0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU0: hi: 186, btch: 31 usd: 0 CPU1: hi: 186, btch: 31 usd: 0 CPU2: hi: 186, btch: 31 usd: 0 CPU3: hi: 186, btch: 31 usd: 0 Node 0 Normal per-cpu: CPU0: hi: 186, btch: 31 usd: 0 CPU1: hi: 186, btch: 31 usd: 0 CPU2: hi: 186, btch: 31 usd: 0 CPU3: hi: 186, btch: 31 usd: 0 active_anon:323486 inactive_anon:159407 isolated_anon:0 active_file:127844 inactive_file:121901 isolated_file:0 unevictable:12 dirty:2 writeback:0 unstable:0 free:42704 slab_reclaimable:13044 slab_unreclaimable:11651 mapped:28143 shmem:1782 pagetables:6574 bounce:0 free_cma:0 Node 0 DMA free:13916kB min:308kB low:384kB high:460kB active_anon:440kB inactive_anon:520kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15988kB managed:15904kB mlocked:0kB dirty:0kB writeback:0kB mapped:8kB shmem:0kB slab_reclaimable:24kB slab_unreclaimable:712kB kernel_stack:16kB pagetables:92kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 2433 3389 3389 Node 0 DMA32 free:116396kB min:48284kB low:60352kB high:72424kB active_anon:1020080kB inactive_anon:363328kB active_file:385068kB inactive_file:366056kB unevictable:40kB isolated(anon):0kB isolated(file):0kB present:2567696kB managed:2494688kB mlocked:40kB dirty:8kB writeback:0kB mapped:80552kB shmem:5240kB slab_reclaimable:34832kB slab_unreclaimable:26316kB kernel_stack:2312kB pagetables:18104kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 956 956 Node 0 Normal free:40504kB min:18988kB low:23732kB high:28480kB active_anon:273424kB inactive_anon:273780kB active_file:126304kB inactive_file:121544kB unevictable:8kB isolated(anon):0kB isolated(file):0kB present:1032188kB managed:979784kB mlocked:8kB dirty:0kB writeback:0kB mapped:32012kB shmem:1888kB slab_reclaimable:17320kB slab_unreclaimable:19576kB kernel_stack:944kB pagetables:8100kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 45*4kB (UEM) 43*8kB (UEM) 17*16kB (UEM) 6*32kB (UM) 4*64kB (UEM) 3*128kB (UEM) 2*256kB (UE) 1*512kB (E) 1*1024kB (E) 3*2048kB (EMR) 1*4096kB (M) = 13916kB Node 0 DMA32: 10239*4kB (UEM) 7669*8kB (UEM) 640*16kB (UEM) 103*32kB (UM) 11*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 116548kB Node 0 Normal: 8793*4kB (UEM) 217*8kB (UEM) 220*16kB (UM) 9*32kB (M) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 40716kB Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB 251617 total pagecache pages 92 pages in swap cache Swap cache stats: add 6
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #8 from Rafael Castillo --- (In reply to comment #7) > Created attachment 89615 [details] [review] > Work Around > > This patch should avoid the crash, but the effect will not be rendered > correctly. Can you test? yes ofc, when i reach home tonight ill test it and report back -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/93938411/attachment-0001.html>
linux-next: Tree for Nov 21 (nouveau)
Hello! > on x86_64: > > CONFIG_HWMON is not enabled. > > drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function 'nouveau_hwmon_init': > drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: 'hwmon' undeclared > (first use in this function) I've attached a patch that fixes the build for me when using this config. -- next part -- A non-text attachment was scrubbed... Name: 0001-nouveau-Fixed-the-hwmon-undeclared-build-error.patch Type: text/x-diff Size: 1550 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/b7cd8d54/attachment.patch>
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 --- Comment #22 from Arek Ru?niak --- Created attachment 89631 --> https://bugs.freedesktop.org/attachment.cgi?id=89631&action=edit dmesg with fix (stalker) Hi, i can't get log from SS3 because GPU crashes and can't get tty or ssh. Wine doesn't give me any usefull logs but gpu was restarted succesfully and i have dmesg output. I applied fix on top on latest llvm(3.5). Should i use 3.4 branch instead? I'll try redirect steam's logs to non-temporary filesystem and maybe that gives me some info. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/850082f7/attachment.html>
[i915] BUG: Bad page state in process Xorg
On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie wrote: >> Hi, > > cc'ing mailing list, > > Daniel any ideas? Nope, not really :( And no ideas how to triage this further - if it takes 9 days to hit it eventually we'll have a real hard time. Or does this happen even after just a short X run? Also is this a regression, i.e. please test a few older kernels, too. -Daniel > > Dave. > >> I reported this bug a few days ago, but nobody did respond to my bug >> report: >> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html >> >> Every time I restart the X server I will run into this bug with 3.12.0. >> >> Help is welcome. >> >> [ 9913.719551] BUG: Bad page state in process Xorg pfn:20f2bb >> [ 9913.721755] page:ea00083caec0 count:0 mapcount:0 >> mapping:8802357975f8 index:0xe >> [ 9913.733741] page flags: >> 0x8008001c(referenced|uptodate|dirty|swapbacked) >> [ 9913.741062] Modules linked in: tcp_lp fuse ipt_MASQUERADE ip6t_REJECT >> xt_conntrack bluetooth ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 >> nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter >> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat >> nf_conntrack iptable_mangle iptable_security iptable_raw arc4 iwldvm >> snd_usb_audio mac80211 snd_hda_codec_hdmi iwlwifi snd_hda_codec_realtek >> snd_usbmidi_lib snd_hda_intel kvm_intel asix snd_hda_codec usbnet kvm atl1c >> snd_hwdep mii snd_seq acer_wmi acerhdf sparse_keymap snd_pcm joydev pcspkr >> cfg80211 rfkill acpi_cpufreq freq_table snd_rawmidi snd_seq_device >> snd_page_alloc snd_timer snd wmi soundcore uinput ipv6 xts gf128mul udl >> syscopyarea sysfillrect sysimgblt drm_usb usb_storage >> [ 9913.741125] CPU: 0 PID: 723 Comm: Xorg Tainted: GB3.12.0 #2 >> [ 9913.741128] Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310 >> 03/25/2010 >> [ 9913.741130] 880213127cc0 8154dc8b >> 880213127cd8 >> [ 9913.741135] 8154b6e7 ea00083caec0 880213127d10 >> 810c6955 >> [ 9913.741139] ea00083caec0 8008001c >> 88023408 >> [ 9913.741143] Call Trace: >> [ 9913.741151] [] dump_stack+0x19/0x1b >> [ 9913.741155] [] bad_page+0xc9/0xe2 >> [ 9913.741160] [] free_pages_prepare+0xd5/0xe0 >> [ 9913.741165] [] free_hot_cold_page+0x1d/0x120 >> [ 9913.741169] [] __put_single_page+0x1e/0x30 >> [ 9913.741172] [] put_page+0x25/0x40 >> [ 9913.741178] [] i915_gem_object_put_pages_gtt+0xc3/0x1a0 >> [ 9913.741183] [] i915_gem_object_put_pages+0x78/0xd0 >> [ 9913.741187] [] i915_gem_free_object+0xe7/0x220 >> [ 9913.741192] [] drm_gem_object_free+0x25/0x30 >> [ 9913.741196] [] drm_gem_dmabuf_release+0x4b/0x70 >> [ 9913.741201] [] dma_buf_release+0x27/0x90 >> [ 9913.741205] [] __fput+0xcb/0x240 >> [ 9913.741209] [] fput+0x9/0x10 >> [ 9913.741214] [] task_work_run+0x9c/0xc0 >> [ 9913.741219] [] do_exit+0x6d5/0x9d0 >> [ 9913.741223] [] ? __schedule+0x243/0x5e0 >> [ 9913.741227] [] ? task_work_run+0x84/0xc0 >> [ 9913.741232] [] do_group_exit+0x35/0x90 >> [ 9913.741236] [] SyS_exit_group+0xf/0x10 >> [ 9913.741241] [] system_call_fastpath+0x16/0x1b >> [ 9913.741246] BUG: Bad page state in process Xorg pfn:20f2bc >> [ 9913.749565] page:ea00083caf00 count:0 mapcount:0 >> mapping:8802357975f8 index:0xf >> >> with kind regards >> thomas >> >> >> >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: add DRM_ERROR_RATELIMITED
On Fri, Nov 22, 2013 at 10:34 AM, Thierry Reding wrote: > On Thu, Nov 21, 2013 at 02:29:51PM -0500, Rob Clark wrote: >> For error traces in situations that can run away, it is nice to have a >> rate-limited version of DRM_ERROR() to avoid massing log flooding. > > s/massing/massive/? errg, yes Dave, let me know if you want me to resend or just smash that spelling fix in yourself BR, -R > Other than that, looks good: > > Reviewed-by: Thierry Reding
Patch
From 340fa01dfe8f699e27ece111996ea088bca6b5c4 Mon Sep 17 00:00:00 2001
From: Arthur Schwalbenberg
Date: Thu, 21 Nov 2013 19:42:44 -0500
Subject: [PATCH] Staging: Fixed compilar warnings and coding style
issues in i915_debugfs.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is a patch fixing both a compilar warning:
?val? may be used uninitialized in this function
and various coding style issues which include line length
warnings and a few errors as defined by 'checkpatch.pl' tool
Signed-off-by: Arthur Schwalbenberg
---
drivers/gpu/drm/i915/i915_debugfs.c | 75 ---
1 file changed, 44 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ed45a9..01135d4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1,5 +1,5 @@
/*
- * Copyright ? 2008 Intel Corporation
+ * Copyright ? 2008 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -87,8 +87,8 @@ static int i915_capabilities(struct seq_file *m, void
*data)
seq_printf(m, "gen: %d\n", info->gen);
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(dev));
-#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x))
-#define SEP_SEMICOLON ;
+#define PRINT_FLAG(x) seq_printf(m, #x ": %s\n", yesno(info->x));
+#define SEP_SEMICOLON
DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG, SEP_SEMICOLON);
#undef PRINT_FLAG
#undef SEP_SEMICOLON
@@ -144,7 +144,7 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
if (obj->pin_count)
seq_printf(m, " (pinned x %d)", obj->pin_count);
if (obj->pin_display)
- seq_printf(m, " (display)");
+ seq_puts(m, " (display)");
if (obj->fence_reg != I915_FENCE_REG_NONE)
seq_printf(m, " (fence: %d)", obj->fence_reg);
list_for_each_entry(vma, &obj->vma_list, vma_link) {
@@ -210,9 +210,9 @@ static int i915_gem_object_list_info(struct seq_file
*m, void *data)
total_obj_size = total_gtt_size = count = 0;
list_for_each_entry(vma, head, mm_list) {
- seq_printf(m, " ");
+ seq_puts(m, " ");
describe_obj(m, vma->obj);
- seq_printf(m, "\n");
+ seq_puts(m, "\n");
total_obj_size += vma->obj->base.size;
total_gtt_size += vma->node.size;
count++;
@@ -333,7 +333,7 @@ static int per_file_stats(int id, void *ptr, void *data)
} \
} while (0)
-static int i915_gem_object_info(struct seq_file *m, void* data)
+static int i915_gem_object_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
@@ -460,6 +460,7 @@ static int i915_gem_gtt_info(struct seq_file *m,
void *data)
static int i915_gem_pageflip_info(struct seq_file *m, void *data)
{
+ struct drm_i915_gem_object *obj = NULL;
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
unsigned long flags;
@@ -487,19 +488,22 @@ static int i915_gem_pageflip_info(struct seq_file
*m, void *data)
seq_puts(m, "Stall check enabled, ");
else
seq_puts(m, "Stall check waiting for page flip ioctl, ");
- seq_printf(m, "%d prepares\n", atomic_read(&work->pending));
+
+ seq_printf(m, "%d prepares\n",
+ atomic_read(&work->pending));
if (work->old_fb_obj) {
- struct drm_i915_gem_object *obj = work->old_fb_obj;
+ obj = work->old_fb_obj;
if (obj)
seq_printf(m, "Old framebuffer gtt_offset 0x%08lx\n",
- i915_gem_obj_ggtt_offset(obj));
+ i915_gem_obj_ggtt_offset(obj));
}
if (work->pending_flip_obj) {
- struct drm_i915_gem_object *obj = work->pending_flip_obj;
+ obj = work->pending_flip_obj;
if (obj)
- seq_printf(m, "New framebuffer gtt_offset 0x%08lx\n",
- i915_gem_obj_ggtt_offset(obj));
+ seq_printf(m,
+ "New framebuffer gtt_offset 0x%08lx\n",
+ i915_gem_obj_ggtt_offset(obj));
}
}
spin_unlock_irqrestore(&dev->event_lock, flags);
@@ -530,9 +534,8 @@ static int i915_gem_request_info(struct seq_file *m,
void *data)
list_for_each_entry(gem_request,
&ring->request_list,
list) {
- seq_printf(m, " %d @ %d\n",
- gem_request->seqno,
- (int) (jiffies - gem_request->emitted_jiffies));
+ seq_printf(m, " %d @ %d\n", gem_request->seqno,
+ (int) (jiffies - gem_request->emitted_jiffies));
}
count++;
}
@@ -909,7 +912,9 @@ static int i915_rstdby_delays(struct seq_file *m,
void *unused)
mutex_unlock(&dev->struct_mutex);
- seq_printf(m, "w/ctx: %d, w/o ctx: %d\n", (crstanddelay >> 8) & 0x3f,
(crstanddelay & 0x3f));
+ seq_printf(m, "w/ctx: %d, w/o ctx: %d\n",
+ (crstanddelay >> 8) & 0x3f,
+ (crstanddelay & 0x3f));
return 0;
}
@@ -929,10 +934,11 @@ static int i915_cur_delayinfo(struct seq_file *m,
void *unused)
seq_printf(m, "Requested P-state: %d\n", (rgvswctl >> 8) & 0xf);
seq_printf(m, "Requested VID: %d\n", rgvswctl & 0x3f);
- seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK) >>
- MEMSTAT_VID_SHIFT);
+ seq_printf(m, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK)
+
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Thu, Nov 21, 2013 at 08:12:04PM -0800, Keith Packard wrote:
> The __DRIimage createImageFromFds function takes a fourcc code, but there was
> no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for
> that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to
> __DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to
> __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers.
>
> I'll refrain from comments on whether I think having two separate sets of
> format defines in dri_interface.h is a good idea or not...
>
> Signed-off-by: Keith Packard
Hm, where do we have the canonical source for all these fourcc codes? I'm
asking since we have our own copy in the kernel as drm_fourcc.h, and that
one is part of the userspace ABI since we use it to pass around
framebuffer formats and format lists.
Just afraid to create long-term maintainance madness here with the
kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely
we'll ever accept srgb for framebuffers though.
-Daniel
> ---
>
> This gets iceweasel running with the GL compositor enabled.
>
> include/GL/internal/dri_interface.h | 1 +
> src/glx/dri3_glx.c | 1 +
> src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
> src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
> 4 files changed, 8 insertions(+)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index b012570..a4387c4 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -1034,6 +1034,7 @@ struct __DRIdri2ExtensionRec {
> #define __DRI_IMAGE_FOURCC_XRGB 0x34325258
> #define __DRI_IMAGE_FOURCC_ABGR 0x34324241
> #define __DRI_IMAGE_FOURCC_XBGR 0x34324258
> +#define __DRI_IMAGE_FOURCC_SARGB0x83324258
> #define __DRI_IMAGE_FOURCC_YUV4100x39565559
> #define __DRI_IMAGE_FOURCC_YUV4110x31315559
> #define __DRI_IMAGE_FOURCC_YUV4200x32315559
> diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
> index b047cc8..5861317 100644
> --- a/src/glx/dri3_glx.c
> +++ b/src/glx/dri3_glx.c
> @@ -890,6 +890,7 @@ image_format_to_fourcc(int format)
>
> /* Convert from __DRI_IMAGE_FORMAT to __DRI_IMAGE_FOURCC (sigh) */
> switch (format) {
> + case __DRI_IMAGE_FORMAT_SARGB8: return __DRI_IMAGE_FOURCC_SARGB;
> case __DRI_IMAGE_FORMAT_RGB565: return __DRI_IMAGE_FOURCC_RGB565;
> case __DRI_IMAGE_FORMAT_XRGB: return __DRI_IMAGE_FOURCC_XRGB;
> case __DRI_IMAGE_FORMAT_ARGB: return __DRI_IMAGE_FOURCC_ARGB;
> diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
> b/src/mesa/drivers/dri/i915/intel_screen.c
> index 7f1fc6b..2dd2bc7 100644
> --- a/src/mesa/drivers/dri/i915/intel_screen.c
> +++ b/src/mesa/drivers/dri/i915/intel_screen.c
> @@ -184,6 +184,9 @@ static struct intel_image_format intel_image_formats[] = {
> { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
>
> + { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> +
> { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
>
> diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
> b/src/mesa/drivers/dri/i965/intel_screen.c
> index e44d0f6..cf8c3e2 100644
> --- a/src/mesa/drivers/dri/i965/intel_screen.c
> +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> @@ -220,6 +220,9 @@ static struct intel_image_format intel_image_formats[] = {
> { __DRI_IMAGE_FOURCC_ARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> { { 0, 0, 0, __DRI_IMAGE_FORMAT_ARGB, 4 } } },
>
> + { __DRI_IMAGE_FOURCC_SARGB, __DRI_IMAGE_COMPONENTS_RGBA, 1,
> + { { 0, 0, 0, __DRI_IMAGE_FORMAT_SARGB8, 4 } } },
> +
> { __DRI_IMAGE_FOURCC_XRGB, __DRI_IMAGE_COMPONENTS_RGB, 1,
> { { 0, 0, 0, __DRI_IMAGE_FORMAT_XRGB, 4 }, } },
>
> --
> 1.8.4.2
>
> ___
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
linux-next: Tree for Nov 21 (nouveau)
On 11/22/13 03:37, Adrian Pop wrote: > Hello! > >> on x86_64: >> >> CONFIG_HWMON is not enabled. >> >> drivers/gpu/drm/nouveau/nouveau_hwmon.c: In function 'nouveau_hwmon_init': >> drivers/gpu/drm/nouveau/nouveau_hwmon.c:633:2: error: 'hwmon' undeclared >> (first use in this function) > > I've attached a patch that fixes the build for me when using this > config. > That works. Thanks. Acked-by: Randy Dunlap -- ~Randy
[i915] BUG: Bad page state in process Xorg
On Wed, Nov 20, 2013 at 09:55:28PM +0100, Thomas Meyer wrote: > Hi, > > I reported this bug a few days ago, but nobody did respond to my bug > report: > http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html > > Every time I restart the X server I will run into this bug with 3.12.0. I think whilst we scratch our heads wondering about what could cause corruption in our struct page, we would welcome a bisection. If it dies during X startup, it would seems like a bisection would progress quickly. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre
[i915] BUG: Bad page state in process Xorg
> Hi, cc'ing mailing list, Daniel any ideas? Dave. > I reported this bug a few days ago, but nobody did respond to my bug > report: > http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00058.html > > Every time I restart the X server I will run into this bug with 3.12.0. > > Help is welcome. > > [ 9913.719551] BUG: Bad page state in process Xorg pfn:20f2bb > [ 9913.721755] page:ea00083caec0 count:0 mapcount:0 > mapping:8802357975f8 index:0xe > [ 9913.733741] page flags: > 0x8008001c(referenced|uptodate|dirty|swapbacked) > [ 9913.741062] Modules linked in: tcp_lp fuse ipt_MASQUERADE ip6t_REJECT > xt_conntrack bluetooth ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 > nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter > ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat > nf_conntrack iptable_mangle iptable_security iptable_raw arc4 iwldvm > snd_usb_audio mac80211 snd_hda_codec_hdmi iwlwifi snd_hda_codec_realtek > snd_usbmidi_lib snd_hda_intel kvm_intel asix snd_hda_codec usbnet kvm atl1c > snd_hwdep mii snd_seq acer_wmi acerhdf sparse_keymap snd_pcm joydev pcspkr > cfg80211 rfkill acpi_cpufreq freq_table snd_rawmidi snd_seq_device > snd_page_alloc snd_timer snd wmi soundcore uinput ipv6 xts gf128mul udl > syscopyarea sysfillrect sysimgblt drm_usb usb_storage > [ 9913.741125] CPU: 0 PID: 723 Comm: Xorg Tainted: GB3.12.0 #2 > [ 9913.741128] Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310 > 03/25/2010 > [ 9913.741130] 880213127cc0 8154dc8b > 880213127cd8 > [ 9913.741135] 8154b6e7 ea00083caec0 880213127d10 > 810c6955 > [ 9913.741139] ea00083caec0 8008001c > 88023408 > [ 9913.741143] Call Trace: > [ 9913.741151] [] dump_stack+0x19/0x1b > [ 9913.741155] [] bad_page+0xc9/0xe2 > [ 9913.741160] [] free_pages_prepare+0xd5/0xe0 > [ 9913.741165] [] free_hot_cold_page+0x1d/0x120 > [ 9913.741169] [] __put_single_page+0x1e/0x30 > [ 9913.741172] [] put_page+0x25/0x40 > [ 9913.741178] [] i915_gem_object_put_pages_gtt+0xc3/0x1a0 > [ 9913.741183] [] i915_gem_object_put_pages+0x78/0xd0 > [ 9913.741187] [] i915_gem_free_object+0xe7/0x220 > [ 9913.741192] [] drm_gem_object_free+0x25/0x30 > [ 9913.741196] [] drm_gem_dmabuf_release+0x4b/0x70 > [ 9913.741201] [] dma_buf_release+0x27/0x90 > [ 9913.741205] [] __fput+0xcb/0x240 > [ 9913.741209] [] fput+0x9/0x10 > [ 9913.741214] [] task_work_run+0x9c/0xc0 > [ 9913.741219] [] do_exit+0x6d5/0x9d0 > [ 9913.741223] [] ? __schedule+0x243/0x5e0 > [ 9913.741227] [] ? task_work_run+0x84/0xc0 > [ 9913.741232] [] do_group_exit+0x35/0x90 > [ 9913.741236] [] SyS_exit_group+0xf/0x10 > [ 9913.741241] [] system_call_fastpath+0x16/0x1b > [ 9913.741246] BUG: Bad page state in process Xorg pfn:20f2bc > [ 9913.749565] page:ea00083caf00 count:0 mapcount:0 > mapping:8802357975f8 index:0xf > > with kind regards > thomas > > > >
[Bug 71887] Garbled output when rendering to a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=71887 --- Comment #6 from Victor Luchits --- Ok, I will update to Mesa 10-dev when I get back home and if it doesn't help, I'll try to bisect. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/a158a32b/attachment.html>
[Bug 71887] Garbled output when rendering to a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=71887 --- Comment #5 from Victor Luchits --- Created attachment 89622 --> https://bugs.freedesktop.org/attachment.cgi?id=89622&action=edit 3.12 + Mesa-dev (Intel) screenshot Same spot on Intel Ivybridge Mobile (HD 4000). Looks identical both in Mesa 9.3 and Mesa 10-dev. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/12a0d232/attachment.html>
[RFCv3 12/14] drm: Atomic modeset ioctl
On Fri, Nov 22, 2013 at 3:35 AM, Inki Dae wrote:
> Hi Rob and Ville,
>
>
> 2013/11/21 Rob Clark :
>> From: Ville Syrj?l?
>>
>> The atomic modeset ioctl cna be used to push any number of new values
>> for object properties. The driver can then check the full device
>> configuration as single unit, and try to apply the changes atomically.
>>
>> The ioctl simply takes a list of object IDs and property IDs and their
>> values. For setting values to blob properties, the property value
>> indicates the length of the data, and the actual data is passed via
>> another blob pointer.
>>
>> The caller can demand non-blocking operation from the ioctl, and if the
>> driver can't satisfy that requirement an error will be returned.
>>
>> The caller can also request to receive asynchronous completion events
>> after the operation has reached the hardware. An event is sent for each
>> object specified by the caller, whether or not the actual state of
>> that object changed. Each event also carries a framebuffer ID, which
>> indicates to user space that the specified object is no longer
>> accessing that framebuffer.
>>
>> TODO: detailed error reporting?
>>
>> v1: original
>> v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
>> v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
>> v4: drop atomic event, align flags w/ pageflip (atomic flags should be
>> a strick superset of pageflip flags to keep things easier for the
>> drivers)
>>
>> Signed-off-by: Ville Syrj?l?
>> ---
>> drivers/gpu/drm/drm_crtc.c | 157
>> +++-
>> drivers/gpu/drm/drm_drv.c | 1 +
>> include/drm/drmP.h | 6 ++
>> include/drm/drm_crtc.h | 2 +
>> include/uapi/drm/drm.h | 12
>> include/uapi/drm/drm_mode.h | 21 ++
>> 6 files changed, 198 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 4b40a39..8368ef5 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -4037,7 +4037,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>> return -ENOENT;
>> crtc = obj_to_crtc(obj);
>>
>> - state = dev->driver->atomic_begin(dev, page_flip->flags);
>> + state = dev->driver->atomic_begin(dev,
>> + page_flip->flags | DRM_MODE_ATOMIC_NONBLOCK);
>> if (IS_ERR(state))
>> return PTR_ERR(state);
>>
>> @@ -4451,3 +4452,157 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>> idr_destroy(&dev->mode_config.crtc_idr);
>> }
>> EXPORT_SYMBOL(drm_mode_config_cleanup);
>> +
>> +int drm_mode_atomic_ioctl(struct drm_device *dev,
>> + void *data, struct drm_file *file_priv)
>> +{
>
> Build error at this function like below,
>
> drivers/built-in.o: In function `drm_mode_atomic_ioctl':
> of_iommu.c:(.text+0x6d854): undefined reference to `__get_user_bad'
> of_iommu.c:(.text+0x6d940): undefined reference to `__get_user_bad'
>
> And built correctly with the below change,
>
> diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
> index 9b06bb4..0f4f469 100644
> --- a/arch/arm/lib/getuser.S
> +++ b/arch/arm/lib/getuser.S
> @@ -66,7 +66,7 @@ ENTRY(__get_user_4)
> mov pc, lr
> ENDPROC(__get_user_4)
>
> -__get_user_bad:
> +ENTRY(__get_user_bad)
> mov r2, #0
> mov r0, #-EFAULT
> mov pc, lr
>
> I guess __get_user_bad is not global but drm_mode_atomic_ioctl
> function tries to refer this function as extern.
no, actually __get_user_bad is (I think) supposed to be a build error.
You need this patch:
http://cgit.freedesktop.org/~robclark/linux/commit/?h=global-thermonuclear-war-5&id=1e94fad78b44d38ee3deca8f0694391e7db0e4cc
(Or I think Russell King had a slightly updated version of that.. I
need to work out with him about getting some version of that patch
merged.)
BR,
-R
> Is it build error only I can see?
>
> Thanks,
> Inki Dae
[Bug 71887] Garbled output when rendering to a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=71887 --- Comment #4 from Michel D?nzer --- If you only changed the kernel, can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/41f0b854/attachment.html>
[Bug 71887] Garbled output when rendering to a framebuffer object
https://bugs.freedesktop.org/show_bug.cgi?id=71887 --- Comment #3 from Victor Luchits --- No I didn't. Do you recommend updating to 9.3/development version of Mesa to see if the bug can not be reproduced there? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/2b251258/attachment.html>
[Mesa-dev] [PATCH 0/2] Minor __DRIimage fixes for i965
On 22 November 2013 05:52, Keith Packard wrote: > While debugging the libdrm duplicate buffer object adventure, I managed to > temporarily understand object lifetimes in the __DRIimage getBuffers path, > and > also to compare that to the DRI2 getBuffers path. Here are a couple of > small > fixes. > > I haven't looked at the i915 code, but I suspect the first one, and parts > of > the second one would apply. > > [PATCH 1/2] i965: Correct check for re-bound buffer in > > The code was attempting to avoid re-creating the miptree when the loader > handed back the same bufffer we already had, but it was confused about how > to > tell -- turns out the object actually shared between the loader and the > driver > is the BO, not the region. And so, we compare BO pointers to see if the > image > buffer needs to have a new miptree. > > [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated > > Here's a chunk of code that was just missing from the __DRIimage path as a > result of rebasing across some new driver additions. > > Both of these fixes are candidates for 10.0 as they affect the __DRIimage > paths now used by Wayland. > For future reference, patches that are candidates for the latest stable branch should include the line Cc: mesa-stable at lists.freedesktop.org in the patch. (see http://lists.freedesktop.org/archives/mesa-dev/2013-August/042667.html) I've forwarded this email to mesa-stable at lists.freedesktop.org, which should also be sufficient. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/c77a9ce5/attachment-0001.html>
[git pull] drm fixes
Hi Linus, was going to leave this until post -rc1 but sysfs fixes broke hotplug in userspace, so I had to fix it harder, otherwise a set of pulls from intel, radeon and vmware, the vmware/ttm changes are bit larger but since its early and they are unlikely to break anything else I put them in, it lets vmware work with dri3. Dave. The following changes since commit 527d1511310a8965081869260394e20c7013: Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2013-11-20 15:13:47 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 760c960bd6880cf22a57c0af9ff60c96250aad39: drm/sysfs: fix hotplug regression since lifetime changes (2013-11-21 21:10:00 +1000) Alex Deucher (4): drm/radeon: cypress_dpm: Fix unused variable warning when CONFIG_ACPI=n drm/radeon/vm: don't attempt to update ptes if ib allocation fails drm/radeon: adjust TN dpm parameters for stability (v2) drm/radeon: enable DPM by default in TN asics Andrew Lewycky (1): drm/radeon: use a single doorbell for cik kms compute Chris Wilson (2): drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: Do not enable package C8 on unsupported hardware Christian K?nig (3): drm/radeon: add semaphore trace point drm/radeon: allow semaphore emission to fail drm/radeon: disable CIK CP semaphores for now Daniel Vetter (7): drm/i915: flush cursors harder Partially revert "drm/i915: tune the RC6 threshold for stability" drm/i915: restore the early forcewake cleanup drm/i915/tv: add ->get_config callback drm/i915: encoder->get_config is no longer optional drm/i915: Replicate BIOS eDP bpp clamping hack for hsw drm/i915: Fix gen3 self-refresh watermarks Dave Airlie (4): Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Merge branch 'vmwgfx-fixes-3.13' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux into drm-fixes David Herrmann (1): drm/sysfs: fix hotplug regression since lifetime changes Duncan Laurie (1): i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7 Fabio Estevam (1): drm: radeon: ni_dpm: Fix unused variable warning when CONFIG_ACPI=n Inki Dae (1): drm/exynos: g2d: fix memory leak to userptr Jani Nikula (1): drm/i915/dp: set sink to power down mode on dp disable Jerome Glisse (2): radeon/i2c: do not count reg index in number of i2c byte we are writing. radeon: workaround pinning failure on low ram gpu Jesse Barnes (1): x86/early quirk: use gen6 stolen detection for VLV Michel D?nzer (2): drm/radeon/cik: Return backend map information to userspace drm/radeon/cik: Add macrotile mode array query Samuel Li (1): drm/radeon: hook up backlight functions for CI and KV family. Thomas Hellstrom (8): drm/ttm: Allow execbuf util reserves without ticket drm/vmwgfx: Fix false lockdep warning drm/ttm: Add a minimal prime implementation for ttm base objects drm/vmwgfx: Hook up the prime ioctls drm/vmwgfx: Make surfaces prime-aware drm/vmwgfx: Make vmwgfx dma buffers prime aware drm/ttm: Don't move non-existing data drm/ttm: Remove set_need_resched from the ttm fault handler arch/x86/kernel/early-quirks.c | 4 +- drivers/gpu/drm/drm_sysfs.c | 40 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_bios.c | 7 +- drivers/gpu/drm/i915/intel_ddi.c| 20 +++ drivers/gpu/drm/i915/intel_display.c| 33 +++- drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 +- drivers/gpu/drm/i915/intel_tv.c | 8 + drivers/gpu/drm/i915/intel_uncore.c | 26 +-- drivers/gpu/drm/radeon/atombios_i2c.c | 6 +- drivers/gpu/drm/radeon/cik.c| 57 --- drivers/gpu/drm/radeon/cik_sdma.c | 13 +- drivers/gpu/drm/radeon/cypress_dpm.c| 2 + drivers/gpu/drm/radeon/evergreen_dma.c | 9 +- drivers/gpu/drm/radeon/ni_dpm.c | 2 +- drivers/gpu/drm/radeon/r100.c | 3 +- drivers/gpu/drm/radeon/r600.c | 13 +- drivers/gpu/drm/radeon/r600_dma.c | 13 +- drivers/gpu/drm/radeon/radeon.h | 38 +++-- drivers/gpu/drm/radeon/radeon_asic.c| 4 + drivers/gpu/drm/radeon/radeon_asic.h| 18 +- drivers/gpu/drm/radeon/radeon_cs.c | 9 +- drivers/gpu/drm/radeon/radeon_de
[PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated image miptrees
Just copying code from the dri2 path to set up the fast color clear state.
This also removes a couple of bogus intel_region_reference calls.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index 884ddef..ca78f32 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -762,7 +762,13 @@ intel_miptree_create_for_image_buffer(struct brw_context
*intel,
if (!singlesample_mt)
return NULL;
- intel_region_reference(&singlesample_mt->region, region);
+ /* If this miptree is capable of supporting fast color clears, set
+* mcs_state appropriately to ensure that fast clears will occur.
+* Allocation of the MCS miptree will be deferred until the first fast
+* clear actually occurs.
+*/
+ if (intel_is_non_msrt_mcs_buffer_supported(intel, singlesample_mt))
+ singlesample_mt->mcs_state = INTEL_MCS_STATE_RESOLVED;
if (num_samples == 0)
return singlesample_mt;
@@ -780,8 +786,6 @@ intel_miptree_create_for_image_buffer(struct brw_context
*intel,
multisample_mt->singlesample_mt = singlesample_mt;
multisample_mt->need_downsample = false;
- intel_region_reference(&multisample_mt->region, region);
-
if (intel->is_front_buffer_rendering && buffer_type ==
__DRI_IMAGE_BUFFER_FRONT) {
intel_miptree_upsample(intel, multisample_mt);
}
--
1.8.4.3
[PATCH 1/2] i965: Correct check for re-bound buffer in intel_update_image_buffer
The buffer-object is the persistent thing passed through the loader, so when
updating an image buffer, check to see if it is already bound to the provided
bo. The region, on the other hand, is allocated separately for the miptree,
and so will never be the same as that passed back from the loader.
Signed-off-by: Keith Packard
---
src/mesa/drivers/dri/i965/brw_context.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index bee98e3..64ff855 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1339,10 +1339,21 @@ intel_update_image_buffer(struct brw_context *intel,
unsigned num_samples = rb->Base.Base.NumSamples;
- if (rb->mt &&
- rb->mt->region &&
- rb->mt->region == region)
- return;
+ /* Check and see if we're already bound to the right
+* buffer object
+*/
+ if (num_samples == 0) {
+ if (rb->mt &&
+ rb->mt->region &&
+ rb->mt->region->bo == region->bo)
+ return;
+ } else {
+ if (rb->mt &&
+ rb->mt->singlesample_mt &&
+ rb->mt->singlesample_mt->region &&
+ rb->mt->singlesample_mt->region->bo == region->bo)
+ return;
+ }
intel_miptree_release(&rb->mt);
rb->mt = intel_miptree_create_for_image_buffer(intel,
--
1.8.4.3
[PATCH 0/2] Minor __DRIimage fixes for i965
While debugging the libdrm duplicate buffer object adventure, I managed to temporarily understand object lifetimes in the __DRIimage getBuffers path, and also to compare that to the DRI2 getBuffers path. Here are a couple of small fixes. I haven't looked at the i915 code, but I suspect the first one, and parts of the second one would apply. [PATCH 1/2] i965: Correct check for re-bound buffer in The code was attempting to avoid re-creating the miptree when the loader handed back the same bufffer we already had, but it was confused about how to tell -- turns out the object actually shared between the loader and the driver is the BO, not the region. And so, we compare BO pointers to see if the image buffer needs to have a new miptree. [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated Here's a chunk of code that was just missing from the __DRIimage path as a result of rebasing across some new driver additions. Both of these fixes are candidates for 10.0 as they affect the __DRIimage paths now used by Wayland. -keith
[PATCH] intel: Track known prime buffers for re-use
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Signed-off-by: Keith Packard
---
This one took a while to find -- multiple bo_gem structs pointing at
the same gem handle would either cause the object to be destroyed
before we were done using it, or we'd end up sending the same
gem_handle for multiple buffers.
This looks a lot like the named object handling stuff, as one would
expect.
intel/intel_bufmgr_gem.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2897bb2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -112,6 +112,7 @@ typedef struct _drm_intel_bufmgr_gem {
drmMMListHead named;
drmMMListHead vma_cache;
+drmMMListHead prime;
int vma_count, vma_open, vma_max;
uint64_t gtt_size;
@@ -2451,8 +2452,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
*bufmgr, int prime_fd, int s
uint32_t handle;
drm_intel_bo_gem *bo_gem;
struct drm_i915_gem_get_tiling get_tiling;
+ drmMMListHead *list;
ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
+
+ /*
+* See if the kernel has already returned this buffer to us. Just as
+* for named buffers, we must not create two bo's pointing at the same
+* kernel object
+*/
+ for (list = bufmgr_gem->prime.next;
+list != &bufmgr_gem->prime;
+list = list->next) {
+ bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+ if (bo_gem->gem_handle == handle) {
+ drm_intel_gem_bo_reference(&bo_gem->bo);
+ return &bo_gem->bo;
+ }
+ }
+
if (ret) {
fprintf(stderr,"ret is %d %d\n", ret, errno);
return NULL;
@@ -2487,8 +2505,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
*bufmgr, int prime_fd, int s
bo_gem->has_error = false;
bo_gem->reusable = false;
- DRMINITLISTHEAD(&bo_gem->name_list);
DRMINITLISTHEAD(&bo_gem->vma_list);
+ DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime);
VG_CLEAR(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
@@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
DRMINITLISTHEAD(&bufmgr_gem->vma_cache);
bufmgr_gem->vma_max = -1; /* unlimited by default */
+ DRMINITLISTHEAD(&bufmgr_gem->prime);
+
return &bufmgr_gem->bufmgr;
}
--
1.8.4.3
[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)
https://bugs.freedesktop.org/show_bug.cgi?id=68224 Tom Stellard changed: What|Removed |Added Attachment #85372|0 |1 is obsolete|| --- Comment #21 from Tom Stellard --- Created attachment 89616 --> https://bugs.freedesktop.org/attachment.cgi?id=89616&action=edit Work Around Hopefully this patch will fix the crash, but it will likely result in some things being rendered incorrectly. Can you test it and let me know if it makes the game playable. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/073fa71c/attachment.html>
[Bug 71285] Xonotic LLVM ERROR
https://bugs.freedesktop.org/show_bug.cgi?id=71285 --- Comment #7 from Tom Stellard --- Created attachment 89615 --> https://bugs.freedesktop.org/attachment.cgi?id=89615&action=edit Work Around This patch should avoid the crash, but the effect will not be rendered correctly. Can you test? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/8cb2e7f1/attachment.html>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
ff7aeb593 in run_test (gl_fw=0x608010, argc=4, argv=0x7fffe188) at /home/dema1701/projects/display/piglit/tests/util/piglit-framework-gl/piglit_fbo_framework.c:52 #28 0x77ae93a9 in piglit_gl_test_run (argc=4, argv=0x7fffe188, config=0x7fffe050) at /home/dema1701/projects/display/piglit/tests/util/piglit-framework-gl.c:191 #29 0x00402b1b in main (argc=4, argv=0x7fffe188) at /home/dema1701/projects/display/piglit/tests/texturing/shaders/texelFetch.c:102 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/634c2f35/attachment-0001.html>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
d=0x844000 | Buffer 65536 bytes
> VM start=0x82D000 end=0x82D080 | Buffer 128 bytes
> VM start=0x82E000 end=0x82E020 | Buffer 32 bytes
> VM start=0x82F000 end=0x82F010 | Buffer 16 bytes
> VM start=0x848000 end=0x868000 | Texture 165x165x1, 1 levels, 1 samples,
> r8g8_unorm
> VM start=0x868000 end=0x87CA00 | Texture 165x165x1, 1 levels, 1 samples,
> r8g8_unorm
> VM start=0x844000 end=0x844078 | Buffer 120 bytes
> VM start=0x845000 end=0x845190 | Buffer 400 bytes
> VM start=0x846000 end=0x8466C0 | Buffer 1728 bytes
> VM start=0x847000 end=0x8473C0 | Buffer 960 bytes
> VM start=0x90 end=0xB8 | Texture 900x600x1, 1 levels, 1 samples,
> b8g8r8x8_unorm
> VM start=0xB8 end=0xF55700 | Texture 900x600x1, 10 levels, 1 samples,
> r8g8b8a8_unorm
> 65x32x1
> VM start=0x88 end=0x889000 | Texture 65x32x1, 1 levels, 1 samples,
> r32g32b32a32_uint
> VM start=0x889000 end=0x899000 | Texture 65x32x1, 1 levels, 1 samples,
> r32g32b32a32_uint
> VM start=0x899000 end=0x899050 | Buffer 80 bytes
> VM start=0x89A000 end=0x8AA000 | Buffer 65536 bytes
> VM start=0x8AA000 end=0x8AA050 | Buffer 80 bytes
> VM start=0x8AB000 end=0x8B3200 | Buffer 33280 bytes
> VM start=0x8B4000 end=0x8BC200 | Buffer 33280 bytes
> VM start=0x8BD000 end=0x8BD0F8 | Buffer 248 bytes
> VM start=0x8BE000 end=0x8BE040 | Buffer 64 bytes
> VM start=0xF56000 end=0x1056000 | Buffer 1048576 bytes
> VM start=0x8BF000 end=0x8BF038 | Buffer 56 bytes
> VM start=0x8C end=0x8C00F8 | Buffer 248 bytes
> VM start=0x8C1000 end=0x8D1000 | Texture 65x32x1, 1 levels, 1 samples,
> r32g32b32a32_float
> [Thread 0x7fffef6e5700 (LWP 7915) exited]
> PIGLIT: {'result': 'pass' }
> [Inferior 1 (process 7911) exited normally]
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/1bd49db0/attachment.html>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
VM start=0x90 end=0xB8 | Texture 900x600x1, 1 levels, 1 samples,
b8g8r8x8_unorm
VM start=0xB8 end=0xF55700 | Texture 900x600x1, 10 levels, 1 samples,
r8g8b8a8_unorm
65x32x1
VM start=0x88 end=0x889000 | Texture 65x32x1, 1 levels, 1 samples,
r32g32b32a32_uint
VM start=0x889000 end=0x899000 | Texture 65x32x1, 1 levels, 1 samples,
r32g32b32a32_uint
VM start=0x899000 end=0x899050 | Buffer 80 bytes
VM start=0x89A000 end=0x8AA000 | Buffer 65536 bytes
VM start=0x8AA000 end=0x8AA050 | Buffer 80 bytes
VM start=0x8AB000 end=0x8B3200 | Buffer 33280 bytes
VM start=0x8B4000 end=0x8BC200 | Buffer 33280 bytes
VM start=0x8BD000 end=0x8BD0F8 | Buffer 248 bytes
VM start=0x8BE000 end=0x8BE040 | Buffer 64 bytes
VM start=0xF56000 end=0x1056000 | Buffer 1048576 bytes
VM start=0x8BF000 end=0x8BF038 | Buffer 56 bytes
VM start=0x8C end=0x8C00F8 | Buffer 248 bytes
VM start=0x8C1000 end=0x8D1000 | Texture 65x32x1, 1 levels, 1 samples,
r32g32b32a32_float
[Thread 0x7fffef6e5700 (LWP 7915) exited]
PIGLIT: {'result': 'pass' }
[Inferior 1 (process 7911) exited normally]
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/1dad9983/attachment-0001.html>
[Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
Daniel Vetter writes: > Hm, where do we have the canonical source for all these fourcc codes? I'm > asking since we have our own copy in the kernel as drm_fourcc.h, and that > one is part of the userspace ABI since we use it to pass around > framebuffer formats and format lists. I think it's the kernel? I really don't know, as the whole notion of fourcc codes seems crazy to me... Feel free to steal this code and stick it in the kernel if you like. > Just afraid to create long-term maintainance madness here with the > kernel's iron thou-shalt-not-break-userspace-ever rule ... Not likely > we'll ever accept srgb for framebuffers though. Would suck to collide with something we do want though. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/6cb24234/attachment.pgp>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=71859 --- Comment #5 from Alexandre Demers --- (In reply to comment #4) > Are you able to get a full backtrace for the crash? I'll see if I can get it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/f67bdd06/attachment.html>
[Bug 71777] R600 stuck while compiling shader for Unigine Heaven 3.0
https://bugs.freedesktop.org/show_bug.cgi?id=71777 --- Comment #1 from Tom Stellard --- Can you post a dump with only the failing shader? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/1a8a2c1b/attachment.html>
[Bug 71859] texelFetch segfault in libLLVM-3.3.so (on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=71859 --- Comment #4 from Tom Stellard --- Are you able to get a full backtrace for the crash? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/061fa116/attachment.html>
[Bug 69321] starting openCL crashes/boots system
https://bugs.freedesktop.org/show_bug.cgi?id=69321 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tom Stellard --- Fixed in Mesa master commit: 7a30cd7085b6879d3858f5c1a6945fbe30c818a6 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131122/b57a2da8/attachment.html>
