Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 10, 2012 at 05:19:48PM -0500, Seth Forshee wrote: > First, I don't have a solution for the ordering of initialization. It > just happens to work out for me right now. Okay, I've got a proof-of-concept implementation of delaying secondary GPU initialization until the i2c can be muxed over to that card. It's not exactly pretty, but it is working. I'd really like to get some feedback on the concept and implementation before spending more time on it. Patches follow. One problem I'm aware of is if the switcheroo handler is in the driver for the secondary GPU. I think this was the case for a machine I used to have with Optimus graphics. In that scenario the secondary graphics device is never initialized because the switcheroo handler is registered during initialization of the secondary device. The driver load method would need to be split up to cope with this. Thanks, Seth ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/7] vga_switcheroo: Add support for switching only the DDC
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM to mux
only the DDC.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 39 +-
include/linux/vga_switcheroo.h |4
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e25cf31..ea6bcc2 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -252,6 +252,29 @@ void vga_switcheroo_client_fb_set(struct pci_dev *pdev,
}
EXPORT_SYMBOL(vga_switcheroo_client_fb_set);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev)
+{
+ int ret = 0;
+ int id;
+
+ mutex_lock(&vgasr_mutex);
+
+ if (!vgasr_priv.handler) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (vgasr_priv.handler->switch_ddc) {
+ id = vgasr_priv.handler->get_client_id(pdev);
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+
+out:
+ mutex_unlock(&vgasr_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(vga_switcheroo_switch_ddc);
+
static int vga_switcheroo_show(struct seq_file *m, void *v)
{
struct vga_switcheroo_client *client;
@@ -342,9 +365,15 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
fb_notifier_call_chain(FB_EVENT_REMAP_ALL_CONSOLE, &event);
}
+ if (vgasr_priv.handler->switch_ddc) {
+ ret = vgasr_priv.handler->switch_ddc(new_client->id);
+ if (ret)
+ return ret;
+ }
+
ret = vgasr_priv.handler->switchto(new_client->id);
if (ret)
- return ret;
+ goto restore_ddc;
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
@@ -356,6 +385,14 @@ static int vga_switchto_stage2(struct
vga_switcheroo_client *new_client)
new_client->active = true;
return 0;
+
+restore_ddc:
+ if (vgasr_priv.handler->switch_ddc) {
+ int id = (new_client->id == VGA_SWITCHEROO_IGD) ?
+ VGA_SWITCHEROO_DIS : VGA_SWITCHEROO_IGD;
+ ret = vgasr_priv.handler->switch_ddc(id);
+ }
+ return ret;
}
static bool check_can_switch(void)
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index ddb419c..b0d0839 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -29,6 +29,7 @@ enum vga_switcheroo_client_id {
};
struct vga_switcheroo_handler {
+ int (*switch_ddc)(enum vga_switcheroo_client_id id);
int (*switchto)(enum vga_switcheroo_client_id id);
int (*power_state)(enum vga_switcheroo_client_id id,
enum vga_switcheroo_state state);
@@ -53,6 +54,8 @@ int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
void vga_switcheroo_client_fb_set(struct pci_dev *dev,
struct fb_info *info);
+int vga_switcheroo_switch_ddc(struct pci_dev *pdev);
+
int vga_switcheroo_register_handler(struct vga_switcheroo_handler *handler);
void vga_switcheroo_unregister_handler(void);
@@ -66,6 +69,7 @@ static inline void vga_switcheroo_unregister_client(struct
pci_dev *dev) {}
static inline int vga_switcheroo_register_client(struct pci_dev *dev,
const struct vga_switcheroo_client_ops *ops) { return 0; }
static inline void vga_switcheroo_client_fb_set(struct pci_dev *dev, struct
fb_info *info) {}
+static inline void vga_switcheroo_switch_ddc(struct pci_dev *pdev) { return
NULL; }
static inline int vga_switcheroo_register_handler(struct
vga_switcheroo_handler *handler) { return 0; }
static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
const struct vga_switcheroo_client_ops *ops,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/7] vga_switcheroo: Add helper function to get the active client
Add vga_switcheroo_get_active_client() to allow drivers to get the
active video client. This will be used by drivers wishing to temporarily
mux only the DDC to the inactive client.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 14 ++
include/linux/vga_switcheroo.h |2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index ea6bcc2..e53f67d 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -205,6 +205,20 @@ find_active_client(struct list_head *head)
return NULL;
}
+struct pci_dev *vga_switcheroo_get_active_client(void)
+{
+ struct vga_switcheroo_client *client;
+ struct pci_dev *pdev = NULL;
+
+ mutex_lock(&vgasr_mutex);
+ client = find_active_client(&vgasr_priv.clients);
+ if (client)
+ pdev = client->pdev;
+ mutex_unlock(&vgasr_mutex);
+ return pdev;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_active_client);
+
int vga_switcheroo_get_client_state(struct pci_dev *pdev)
{
struct vga_switcheroo_client *client;
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index b0d0839..e361858 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -61,6 +61,7 @@ void vga_switcheroo_unregister_handler(void);
int vga_switcheroo_process_delayed_switch(void);
+struct pci_dev *vga_switcheroo_get_active_client(void);
int vga_switcheroo_get_client_state(struct pci_dev *dev);
#else
@@ -76,6 +77,7 @@ static inline int vga_switcheroo_register_audio_client(struct
pci_dev *pdev,
int id, bool active) { return 0; }
static inline void vga_switcheroo_unregister_handler(void) {}
static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
+static inline struct pci_dev *vga_switcheroo_get_active_client(void) { return
NULL; }
static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) {
return VGA_SWITCHEROO_ON; }
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 3/7] vga_switcheroo: Add notifier call chain for switcheroo events
DRM needs to be notified of client and handler registration in order to
defer initialization of the secondary GPU until the EDID can be read
from the LVDS panel. To support this add a notifier call chain to
vga_switcheroo for subscribing to switcheroo events. Events are
generated for registration and unregistration of handlers and clients.
Signed-off-by: Seth Forshee
---
drivers/gpu/vga/vga_switcheroo.c | 34 ++
include/linux/vga_switcheroo.h | 14 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index e53f67d..d5cd274 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -70,6 +71,28 @@ static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
};
+static BLOCKING_NOTIFIER_HEAD(vga_switcheroo_notifier_list);
+
+int vga_switcheroo_register_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&vga_switcheroo_notifier_list,
+ nb);
+}
+EXPORT_SYMBOL(vga_switcheroo_register_notifier);
+
+int vga_switcheroo_unregister_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&vga_switcheroo_notifier_list,
+ nb);
+}
+EXPORT_SYMBOL(vga_switcheroo_unregister_notifier);
+
+static int vga_switcheroo_notifier_call_chain(enum vga_switcheroo_event event)
+{
+ return blocking_notifier_call_chain(&vga_switcheroo_notifier_list,
+ event, NULL);
+}
+
static bool vga_switcheroo_ready(void)
{
/* we're ready if we get two clients + handler */
@@ -113,10 +136,18 @@ int vga_switcheroo_register_handler(struct
vga_switcheroo_handler *handler)
vga_switcheroo_enable();
}
mutex_unlock(&vgasr_mutex);
+
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_HANDLER_REGISTERED);
return 0;
}
EXPORT_SYMBOL(vga_switcheroo_register_handler);
+bool vga_switcheroo_handler_registered(void)
+{
+ return !!vgasr_priv.handler;
+}
+EXPORT_SYMBOL(vga_switcheroo_handler_registered);
+
void vga_switcheroo_unregister_handler(void)
{
mutex_lock(&vgasr_mutex);
@@ -127,6 +158,7 @@ void vga_switcheroo_unregister_handler(void)
vgasr_priv.active = false;
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_HANDLER_UNREGISTERED);
}
EXPORT_SYMBOL(vga_switcheroo_unregister_handler);
@@ -156,6 +188,7 @@ static int register_client(struct pci_dev *pdev,
vga_switcheroo_enable();
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_CLIENT_REGISTERED);
return 0;
}
@@ -250,6 +283,7 @@ void vga_switcheroo_unregister_client(struct pci_dev *pdev)
vgasr_priv.active = false;
}
mutex_unlock(&vgasr_mutex);
+ vga_switcheroo_notifier_call_chain(VGA_SWITCHEROO_CLIENT_UNREGISTERED);
}
EXPORT_SYMBOL(vga_switcheroo_unregister_client);
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index e361858..c3d7c6f 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -11,6 +11,7 @@
#define _LINUX_VGA_SWITCHEROO_H_
#include
+#include
struct pci_dev;
@@ -28,6 +29,13 @@ enum vga_switcheroo_client_id {
VGA_SWITCHEROO_MAX_CLIENTS,
};
+enum vga_switcheroo_event {
+ VGA_SWITCHEROO_CLIENT_REGISTERED,
+ VGA_SWITCHEROO_CLIENT_UNREGISTERED,
+ VGA_SWITCHEROO_HANDLER_REGISTERED,
+ VGA_SWITCHEROO_HANDLER_UNREGISTERED,
+};
+
struct vga_switcheroo_handler {
int (*switch_ddc)(enum vga_switcheroo_client_id id);
int (*switchto)(enum vga_switcheroo_client_id id);
@@ -44,6 +52,9 @@ struct vga_switcheroo_client_ops {
};
#if defined(CONFIG_VGA_SWITCHEROO)
+int vga_switcheroo_register_notifier(struct notifier_block *nb);
+int vga_switcheroo_unregister_notifier(struct notifier_block *nb);
+bool vga_switcheroo_handler_registered(void);
void vga_switcheroo_unregister_client(struct pci_dev *dev);
int vga_switcheroo_register_client(struct pci_dev *dev,
const struct vga_switcheroo_client_ops *ops);
@@ -66,6 +77,9 @@ int vga_switcheroo_get_client_state(struct pci_dev *dev);
#else
+static inline int vga_switcheroo_register_notifier(struct notifier_block *nb)
{ return 0; }
+static inline int vga_switcheroo_unregister_notifier(struct notifier_block
*nb) { return 0; }
+static inline bool vga_switcheroo_handler_registered(void) { return false; }
static inline void vga_switcheroo_unregister_client(struct pci_dev *dev) {}
static inline int vga_switcheroo_register_client(struct pci_dev *dev,
const struct
[RFC PATCH 4/7] apple-gmux: Add switch_ddc support
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a VBT
or have invalid mode data in the VBT.
Signed-off-by: Seth Forshee
---
drivers/platform/x86/apple-gmux.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index c72e81e..f702e90 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -269,14 +269,21 @@ static const struct backlight_ops gmux_bl_ops = {
.update_status = gmux_update_status,
};
+static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
+{
+ if (id == VGA_SWITCHEROO_IGD)
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+ else
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+ return 0;
+}
+
static int gmux_switchto(enum vga_switcheroo_client_id id)
{
if (id == VGA_SWITCHEROO_IGD) {
- gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 2);
} else {
- gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DISPLAY, 3);
gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_EXTERNAL, 3);
}
@@ -343,6 +350,7 @@ gmux_active_client(struct apple_gmux_data *gmux_data)
}
static struct vga_switcheroo_handler gmux_handler = {
+ .switch_ddc = gmux_switch_ddc,
.switchto = gmux_switchto,
.power_state = gmux_set_power_state,
.get_client_id = gmux_get_client_id,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/7] drm/edid: Switch DDC when reading the EDID
Some dual graphics machines support muxing the DDC separately from the
display, so make use of this functionality when reading the EDID on the
inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races
on the DDC mux state.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_edid.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..1a4b661 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "drmP.h"
#include "drm_edid.h"
#include "drm_edid_modes.h"
@@ -82,6 +83,8 @@ struct detailed_mode_closure {
#define LEVEL_GTF2 2
#define LEVEL_CVT 3
+static DEFINE_MUTEX(drm_edid_mutex);
+
static struct edid_quirk {
char vendor[4];
int product_id;
@@ -395,12 +398,26 @@ struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid = NULL;
+ struct pci_dev *pdev = connector->dev->pdev;
+ struct pci_dev *active_pdev = NULL;
+
+ mutex_lock(&drm_edid_mutex);
+
+ if (pdev) {
+ active_pdev = vga_switcheroo_get_active_client();
+ if (active_pdev != pdev)
+ vga_switcheroo_switch_ddc(pdev);
+ }
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (active_pdev && active_pdev != pdev)
+ vga_switcheroo_switch_ddc(active_pdev);
+
connector->display_info.raw_edid = (char *)edid;
+ mutex_unlock(&drm_edid_mutex);
return edid;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 6/7] drm/pci: Add drm_put_pci_dev()
When deferred initialization support for pci devices is added some
additional cleanup will be needed. Add a pci-specific put function to
serve this purpose, and convert the pci drivers over to using it. For
now it just calls drm_put_dev(), so this commit has no functional
change.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/ast/ast_drv.c |2 +-
drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-
drivers/gpu/drm/drm_pci.c |6 ++
drivers/gpu/drm/gma500/psb_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/mgag200/mgag200_drv.c |2 +-
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drmP.h|1 +
10 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index d0c4574..001298d 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -72,7 +72,7 @@ ast_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index 7053140..c7ca02b 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -64,7 +64,7 @@ static void cirrus_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct file_operations cirrus_driver_fops = {
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 5320364..4896c96 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -388,6 +388,12 @@ err_g1:
}
EXPORT_SYMBOL(drm_get_pci_dev);
+void drm_put_pci_dev(struct drm_device *dev)
+{
+ drm_put_dev(dev);
+}
+EXPORT_SYMBOL(drm_put_pci_dev);
+
/**
* PCI device initialization. Called direct from modules at load time.
*
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 0c47374..d7c3c9c 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -585,7 +585,7 @@ static void psb_driver_preclose(struct drm_device *dev,
struct drm_file *priv)
static void psb_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct dev_pm_ops psb_pm_ops = {
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a24ffbe..86ae5a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -856,7 +856,7 @@ i915_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static int i915_pm_suspend(struct device *dev)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index ea1024d..a3b0a4a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -73,7 +73,7 @@ static void mga_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static const struct file_operations mgag200_driver_fops = {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index 9a36f5f..b74b02a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -168,7 +168,7 @@ nouveau_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
int
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index d7269f4..298697a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -308,7 +308,7 @@ radeon_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static int
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4d9edea..cf901cc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -982,7 +982,7 @@ static void vmw_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
- drm_put_dev(dev);
+ drm_put_pci_dev(dev);
}
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..eb99e96 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1748,6 +1748,7 @@ extern void drm_pci_exit(struct drm_driver *driver,
struct pci_driver *pdriver);
extern int drm_get_pci_dev(struct
[RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
Deferring initiailzation of the secondary GPU until switcheroo is ready
will allow successfully reading the EDID in systems which support muxing
the DDC seperately from the display.
Signed-off-by: Seth Forshee
---
drivers/gpu/drm/drm_drv.c |3 +
drivers/gpu/drm/drm_pci.c | 141 +++--
include/drm/drmP.h|2 +
3 files changed, 129 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..124fd8a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -276,6 +276,8 @@ static int __init drm_core_init(void)
goto err_p3;
}
+ drm_pci_module_init();
+
DRM_INFO("Initialized %s %d.%d.%d %s\n",
CORE_NAME, CORE_MAJOR, CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
return 0;
@@ -291,6 +293,7 @@ err_p1:
static void __exit drm_core_exit(void)
{
+ drm_pci_module_exit();
remove_proc_entry("dri", NULL);
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 4896c96..9da0cd2 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -40,6 +40,9 @@
#include
#include
#include
+#include
+#include
+#include
#include "drmP.h"
/**/
@@ -297,19 +300,8 @@ static struct drm_bus drm_pci_bus = {
.agp_init = drm_pci_agp_init,
};
-/**
- * Register.
- *
- * \param pdev - PCI device structure
- * \param ent entry from the PCI ID table with device type flags
- * \return zero on success or a negative number on failure.
- *
- * Attempt to gets inter module "drm" information. If we are first
- * then register the character device and inter module information.
- * Try and register, if we fail to register, backout previous work.
- */
-int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
- struct drm_driver *driver)
+int __drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
+ struct drm_driver *driver)
{
struct drm_device *dev;
int ret;
@@ -334,8 +326,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
dev->hose = pdev->sysdata;
#endif
- mutex_lock(&drm_global_mutex);
-
if ((ret = drm_fill_in_dev(dev, ent, driver))) {
printk(KERN_ERR "DRM: Fill_in_dev failed.\n");
goto err_g2;
@@ -371,7 +361,6 @@ int drm_get_pci_dev(struct pci_dev *pdev, const struct
pci_device_id *ent,
driver->name, driver->major, driver->minor, driver->patchlevel,
driver->date, pci_name(pdev), dev->primary->index);
- mutex_unlock(&drm_global_mutex);
return 0;
err_g4:
@@ -386,10 +375,116 @@ err_g1:
mutex_unlock(&drm_global_mutex);
return ret;
}
+
+struct deferred_init_data {
+ struct list_head list;
+ struct pci_dev *pdev;
+ const struct pci_device_id *ent;
+ struct drm_driver *driver;
+};
+
+static LIST_HEAD(deferred_init_list);
+
+static void drm_deferred_init_work_fn(struct work_struct *work)
+{
+ struct deferred_init_data *di_data, *temp;
+
+ mutex_lock(&drm_global_mutex);
+
+ if (!vga_switcheroo_handler_registered() ||
+ !vga_switcheroo_get_active_client()) {
+ mutex_unlock(&drm_global_mutex);
+ return;
+ }
+
+ list_for_each_entry_safe(di_data, temp, &deferred_init_list, list) {
+ if (__drm_get_pci_dev(di_data->pdev, di_data->ent,
+ di_data->driver))
+ DRM_ERROR("pci device initialization failed\n");
+ list_del(&di_data->list);
+ kfree(di_data);
+ }
+ mutex_unlock(&drm_global_mutex);
+}
+static DECLARE_WORK(deferred_init_work, drm_deferred_init_work_fn);
+
+static int drm_switcheroo_notifier_fn(struct notifier_block *nb,
+ unsigned long val, void *unused)
+{
+ if (val == VGA_SWITCHEROO_CLIENT_REGISTERED ||
+ val == VGA_SWITCHEROO_HANDLER_REGISTERED)
+ queue_work(system_nrt_wq, &deferred_init_work);
+ return NOTIFY_OK;
+}
+static struct notifier_block drm_switcheroo_notifier = {
+ .notifier_call = drm_switcheroo_notifier_fn,
+};
+
+/**
+ * Register.
+ *
+ * \param pdev - PCI device structure
+ * \param ent entry from the PCI ID table with device type flags
+ * \return zero on success or a negative number on failure.
+ *
+ * Attempt to gets inter module "drm" information. If we are first
+ * then register the character device and inter module information.
+ * Try and register, if we fail to register, backout previous work.
+ */
+int drm_get_pci_dev(struct pci_dev *pdev, const struct pci_device_id *ent,
+ struct drm_driver *driver)
+{
+
Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote: > On Mon, Aug 20, 2012 at 10:31:04AM -0500, Seth Forshee wrote: > > + /* > > +* For secondary graphics devices shouldn't be initialized > > +* until the handler and primary graphics device have been > > +* registered with vga_switcheroo. > > +* > > +* FIXME: Is vga_default_device() reliable enough for this > > +* purpose? > > +* > > +* FIXME: If vga_switcheroo is disabled secondary devices > > +* never gets initialized. Is this okay? Maybe it is, since > > +* we can't switch to the secondary GPU anyway. > > +*/ > > Won't this break the multiple cards with independent outputs case? Yes, if they don't have a switcheroo handler. I only have experience with one such machine, which had optimus graphics. My recollection is that it did have a switcheroo handler, which was only capable of controlling power to the discrete card. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 7/7] drm/pci: Defer initialization of secondary graphics devices until switcheroo is ready
On Mon, Aug 20, 2012 at 04:57:41PM +0100, Matthew Garrett wrote: > On Mon, Aug 20, 2012 at 10:56:33AM -0500, Seth Forshee wrote: > > On Mon, Aug 20, 2012 at 04:36:40PM +0100, Matthew Garrett wrote: > > > Won't this break the multiple cards with independent outputs case? > > > > Yes, if they don't have a switcheroo handler. I only have experience > > with one such machine, which had optimus graphics. My recollection is > > that it did have a switcheroo handler, which was only capable of > > controlling power to the discrete card. > > So if I have a desktop machine and install two graphics cards? Yeah, that would likely be broken. I'm not sure how we support both of these cases without doing something more like what I originally proposed, i.e. registering the LVDS connector even if it doesn't look like a panel is attached. I still honestly favor that approach, although it does come with its own set of challenges. The only other option I can come up with is to reprobe LVDS after switcheroo and add the connector at that time. I haven't investigated this option in detail, but at first glance it looks like there are at least some places where DRM isn't prepared to cope with adding connectors after initialization. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] gpu/mfd/usb: Fix USB randconfig problems
Fix config warning: warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) and build error: ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB which is due to drivers/usb/Kconfig: config USB_ARCH_HAS_OHCI ... default y if ARCH_PNX4008 && I2C Fix by dropping I2C from the above dependency; logic is that this is not a platform dependency but a configuration dependency: the _architecture_ still supports USB even is I2C is not selected. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by FB_VIA drivers/video/Kconfig:1560: symbol FB_VIA depends on FB which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on it. Signed-off-by: Guenter Roeck --- The USB build problem causes 15-20% of my randconfig builds to fail (6 of 36 failures last night). I'll be happy to split the patch into three if it helps to get it accepted. drivers/gpu/drm/Kconfig |1 + drivers/gpu/drm/udl/Kconfig |1 + drivers/mfd/Kconfig |3 ++- drivers/usb/Kconfig |2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..90e2808 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -22,6 +22,7 @@ menuconfig DRM config DRM_USB tristate depends on DRM + depends on USB_ARCH_HAS_HCD select USB config DRM_KMS_HELPER diff --git a/drivers/gpu/drm/udl/Kconfig b/drivers/gpu/drm/udl/Kconfig index 0b5e096..56e0bf3 100644 --- a/drivers/gpu/drm/udl/Kconfig +++ b/drivers/gpu/drm/udl/Kconfig @@ -1,6 +1,7 @@ config DRM_UDL tristate "DisplayLink" depends on DRM && EXPERIMENTAL + depends on USB_ARCH_HAS_HCD select DRM_USB select FB_SYS_FILLRECT select FB_SYS_COPYAREA diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d1facef..b1a1462 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -395,7 +395,8 @@ config MFD_TC6387XB config MFD_TC6393XB bool "Support Toshiba TC6393XB" - depends on GPIOLIB && ARM && HAVE_CLK + depends on ARM && HAVE_CLK + select GPIOLIB select MFD_CORE select MFD_TMIO help diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index a7773a3..7065df6 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -13,7 +13,7 @@ config USB_ARCH_HAS_OHCI default y if PXA3xx default y if ARCH_EP93XX default y if ARCH_AT91 - default y if ARCH_PNX4008 && I2C + default y if ARCH_PNX4008 default y if MFD_TC6393XB default y if ARCH_W90X900 default y if ARCH_DAVINCI_DA8XX -- 1.7.9.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] gpu/mfd/usb: Fix USB randconfig problems
On Mon, Aug 20, 2012 at 11:23:16AM -0700, Guenter Roeck wrote: > Fix config warning: > > warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies > (USB_SUPPORT && USB_ARCH_HAS_HCD) > > and build error: > ERROR: "usb_speed_string" [drivers/usb/core/usbcore.ko] undefined! > > by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. I'll take this, sorry for the delay. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
---
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..2c2996e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned
char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
*/
do {
struct i2c_msg msgs[] = {
- {
+ { /*set segment pointer */
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = segFlags,
+ .len= 1,
+ .buf= &start,
+ }, { /*set offset */
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
.buf= &start,
- }, {
+ }, { /*set data */
.addr = DDC_ADDR,
.flags = I2C_M_RD,
.len= len,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+ ret = i2c_transfer(adapter, msgs, 3);
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != 3 && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == 3 ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > > > used for non-panel devices (at least in theory). The future mipi-dsi-bus > > > certainly will. > > > > They are both display busses. So while they could be used for anything, > > I find it quite unlikely as there are much better alternatives for > > generic bus needs. > > My point is that they could be used for display devices other than panels. > This is especially true for DSI, as there are DSI to HDMI converters. > Technically speaking that's also true for DBI, as DBI chips convert from DBI > to DPI, but we can group both the DBI-to-DPI chip and the panel in a single > panel object. Ah, ok. I thought "panels" would include these buffer/converter chips. I think we should have one driver for one indivisible hardware entity. So if you've got a panel module that contains DBI receiver, buffer memory and a DPI panel, let's just have one "DBI panel" driver for it. If we get lots of different panel modules containing the same DBI RX IP, we could have the DBI IP part as a common library, but still have one panel driver per panel module. But how do you see the case for separate converter/buffer chips? Are they part of the generic panel framework? I guess they kinda have to be. On one side they use the "panel" API control the bus they are connected to, and on the other they offer an API for the connected panel to use the bus they provide. Did you just mean we should have a separate directory for them, while still part of the same framework, or...? Tomi signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: fix race condition between console lock and cursor timer
So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load)Thread B (timer thread) unbind_con_driver -> | bind_con_driver ->| vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock()| | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. Signed-off-by: David Airlie --- drivers/video/console/fbcon.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 2e471c2..f8a79fc 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work) struct vc_data *vc = NULL; int c; int mode; + int ret; + + ret = console_trylock(); + if (ret == 0) + return; - console_lock(); if (ops && ops->currcon != -1) vc = vc_cons[ops->currcon].d; -- 1.7.10.2 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix bo creation retry path
On Fre, 2012-07-13 at 07:54 +0200, Michel Dänzer wrote: > On Don, 2012-07-12 at 18:23 -0400, j.gli...@gmail.com wrote: > > From: Jerome Glisse > > > > Retry label was at wrong place in function leading to memory > > leak. > > > > Cc: > > Signed-off-by: Jerome Glisse > > --- > > drivers/gpu/drm/radeon/radeon_object.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/radeon/radeon_object.c > > b/drivers/gpu/drm/radeon/radeon_object.c > > index 6ecb200..f71e472 100644 > > --- a/drivers/gpu/drm/radeon/radeon_object.c > > +++ b/drivers/gpu/drm/radeon/radeon_object.c > > @@ -138,7 +138,6 @@ int radeon_bo_create(struct radeon_device *rdev, > > acc_size = ttm_bo_dma_acc_size(&rdev->mman.bdev, size, > >sizeof(struct radeon_bo)); > > > > -retry: > > bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); > > if (bo == NULL) > > return -ENOMEM; > > @@ -152,6 +151,8 @@ retry: > > bo->surface_reg = -1; > > INIT_LIST_HEAD(&bo->list); > > INIT_LIST_HEAD(&bo->va); > > + > > +retry: > > radeon_ttm_placement_from_domain(bo, domain); > > /* Kernel allocation are uninterruptible */ > > down_read(&rdev->pm.mclk_lock); > > Reviewed-by: Michel Dänzer Actually, this is wrong: ttm_bo_init() destroys the BO on failure. So this patch makes the retry path work with freed memory. I see on IRC that this is causing panics with some piglit tests for several people, please submit a patch to revert this. Sorry I didn't remember this when reviewing the patch. :( -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 --- Comment #4 from Michel Dänzer 2012-08-21 08:14:28 --- (In reply to comment #1) > My active graphics card is the Intel one of these: Alan, I think you picked the wrong component. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Component|Video(DRI - non Intel) |Video(DRI - Intel) AssignedTo|drivers_video-dri@kernel-bu |drivers_video-dri-intel@ker |gs.osdl.org |nel-bugs.osdl.org --- Comment #5 from Alan 2012-08-21 09:12:58 --- Indeed - moved. And that would make more sense as there is another 'squares' report. in i915 space. Wonder if someone isn't always clearing up sprites and overlays ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
Hi Tomi, On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > > Hi Tomi, > > > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it > > > > can be used for non-panel devices (at least in theory). The future > > > > mipi-dsi-bus certainly will. > > > > > > They are both display busses. So while they could be used for anything, > > > I find it quite unlikely as there are much better alternatives for > > > generic bus needs. > > > > My point is that they could be used for display devices other than panels. > > This is especially true for DSI, as there are DSI to HDMI converters. > > Technically speaking that's also true for DBI, as DBI chips convert from > > DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a > > single panel object. > > Ah, ok. I thought "panels" would include these buffer/converter chips. > > I think we should have one driver for one indivisible hardware entity. > So if you've got a panel module that contains DBI receiver, buffer > memory and a DPI panel, let's just have one "DBI panel" driver for it. > > If we get lots of different panel modules containing the same DBI RX IP, > we could have the DBI IP part as a common library, but still have one > panel driver per panel module. Sounds good to me. > But how do you see the case for separate converter/buffer chips? Are > they part of the generic panel framework? I guess they kinda have to be. > On one side they use the "panel" API control the bus they are connected > to, and on the other they offer an API for the connected panel to use > the bus they provide. The DBI/DSI APIs will not be panel-specific (they won't contain any reference to "panel") I'm thus thinking of moving them from drivers/video/panel/ to drivers/video/. Furthermore, a DSI-to-HDMI converter chip is not a panel, but needs to expose display-related operations in a way similar to panels. I was thus wondering if we shouldn't replace the panel structure with some kind of video entity structure that would expose operations similar to panels. We could then extend that structure with converter-specific operations later. The framework would become a bit more generic, while remaining display-specific. > Did you just mean we should have a separate directory for them, while > still part of the same framework, or...? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
> So after much tracing with direct netconsole writes (printks > under console_lock not so useful), I think I found the race. Direct netconsole write would be a useful patch to have mainline I think 8) > Hopefully this fixes the problem for anyone seeing vesafb->kms > driver handoff. Not really the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ on the patch however. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Tomasz,
Thanks for the patch.
Just a couple of small comments below.
On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 204 +
> 1 file changed, 204 insertions(+)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> +{
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + /* stealing dmabuf mutex to serialize map/unmap operations */
Why isn't this operation serialized by the dma-buf core itself ?
> + struct mutex *lock = &db_attach->dmabuf->lock;
> + struct sg_table *sgt;
> + int ret;
> +
> + mutex_lock(lock);
> +
> + sgt = &attach->sgt;
> + /* return previously mapped sg table */
> + if (attach->dir == dir) {
> + mutex_unlock(lock);
> + return sgt;
> + }
> +
> + /* release any previous cache */
> + if (attach->dir != DMA_NONE) {
> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> + attach->dir);
> + attach->dir = DMA_NONE;
> + }
> +
> + /* mapping to the client with new direction */
> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> + if (ret <= 0) {
> + pr_err("failed to map scatterlist\n");
> + mutex_unlock(lock);
> + return ERR_PTR(-EIO);
> + }
> +
> + attach->dir = dir;
> +
> + mutex_unlock(lock);
> +
> + return sgt;
> +}
[snip]
> +static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
> + struct vm_area_struct *vma)
> +{
> + /* Dummy support for mmap */
> + return -ENOTTY;
What about calling the dma-contig mmap handler here ? Is there a specific
reason why you haven't implemented mmap support for dmabuf ?
> +}
> +
> +static struct dma_buf_ops vb2_dc_dmabuf_ops = {
> + .attach = vb2_dc_dmabuf_ops_attach,
> + .detach = vb2_dc_dmabuf_ops_detach,
> + .map_dma_buf = vb2_dc_dmabuf_ops_map,
> + .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> + .kmap = vb2_dc_dmabuf_ops_kmap,
> + .kmap_atomic = vb2_dc_dmabuf_ops_kmap,
> + .vmap = vb2_dc_dmabuf_ops_vmap,
> + .mmap = vb2_dc_dmabuf_ops_mmap,
> + .release = vb2_dc_dmabuf_ops_release,
> +};
> +
> +static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
> +{
> + int ret;
> + struct sg_table *sgt;
> +
> + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
> + if (!sgt) {
> + dev_err(buf->dev, "failed to alloc sg table\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + ret = dma_get_sgtable(buf->dev, sgt, buf->vaddr, buf->dma_addr,
> + buf->size);
> + if (ret < 0) {
> + dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
> + kfree(sgt);
> + return ERR_PTR(ret);
> + }
As this function is only used below, where the exact value of the error code
is ignored, what about just returning NULL on failure ? Another option is to
return the error code in vb2_dc_get_dmabuf (not sure if that would be useful
though).
> +
> + return sgt;
> +}
> +
> +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
> +{
> + struct vb2_dc_buf *buf = buf_priv;
> + struct dma_buf *dbuf;
> + struct sg_table *sgt = buf->sgt_base;
> +
> + if (!sgt)
> + sgt = vb2_dc_get_base_sgt(buf);
> + if (WARN_ON(IS_ERR(sgt)))
> + return NULL;
> +
> + /* cache base sgt for future use */
> + buf->sgt_base = sgt;
You can move this assignment inside the first if, there's no need to execute
it every time. The WARN_ON can also be moved inside the first if, as buf-
>sgt_base will either be NULL or valid. You can then get rid of the sgt
variable initialization by testing if (!buf->sgt_base).
> + dbuf = dma_buf_export(buf, &vb2_dc_dmabuf_ops, buf->size, 0);
> + if (IS_ERR(dbuf))
> + return NULL;
> +
> + /* dmabuf keeps reference to vb2 buffer */
> + atomic_inc(&buf->refcount);
> +
> + return dbuf;
> +}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
Am Dienstag, den 21.08.2012, 12:40 +0530 schrieb Shirish S: > The current logic for probing ddc is limited to > 2 blocks (256 bytes), this patch adds support > for the 4 block (512) data. > > To do this, a single 8-bit segment index is > passed to the display via the I2C address 30h. > Data from the selected segment is then immediately > read via the regular DDC2 address using a repeated > I2C 'START' signal. > > Signed-off-by: Shirish S Please add your full last name, if there is no reason not to, and resend as [PATCH v2]. > --- > drivers/gpu/drm/drm_edid.c | 17 - > 1 files changed, 12 insertions(+), 5 deletions(-) […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/drm_edid.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..2c2996e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> int block, int len)
> {
> unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
Have you tested this on i915 with gmbus enabled? I'm asking since we
don't implement the IGNORE_NAK flag and hence I'd expect spurious
failures on displays that don't support E-DDC ...
Cheers, Daniel
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> */
> do {
> struct i2c_msg msgs[] = {
> - {
> + { /*set segment pointer */
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = segFlags,
> + .len= 1,
> + .buf= &start,
> + }, { /*set offset */
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> .buf= &start,
> - }, {
> + }, { /*set data */
> .addr = DDC_ADDR,
> .flags = I2C_M_RD,
> .len= len,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> + ret = i2c_transfer(adapter, msgs, 3);
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != 3 && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == 3 ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > The current logic for probing ddc is limited to > 2 blocks (256 bytes), this patch adds support > for the 4 block (512) data. A patch for this was already sent a long time ago: http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm-intel-fixes
Hi Dave, Nothing too major: - A few fixes around the edid handling from Jani, also fixing a regression in 3.5 due to us using gmbus by default. - Fixup hsw uncached pte flags. - Fix suspend/resume crash when using hw contexts, from Ben. - Try to tune gpu turbo a bit better, seems to help with some oddball power regressions. Also nothing major outstanding afaik. Cheers, Daniel The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c: drm/i915: use hsw rps tuning values everywhere on gen6+ (2012-08-20 20:49:19 +0200) Ben Widawsky (1): drm/i915/contexts: fix list corruption Daniel Vetter (2): drm/i915: fix hsw uncached pte drm/i915: use hsw rps tuning values everywhere on gen6+ Jani Nikula (3): drm/i915: fix EDID memory leak in SDVO drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads drivers/char/agp/intel-agp.h|1 + drivers/char/agp/intel-gtt.c| 105 +++ drivers/gpu/drm/i915/i915_gem.c |8 +-- drivers/gpu/drm/i915/i915_gem_gtt.c |5 +- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_crt.c| 36 +++- drivers/gpu/drm/i915/intel_drv.h|2 + drivers/gpu/drm/i915/intel_modes.c | 31 --- drivers/gpu/drm/i915/intel_pm.c | 15 ++--- drivers/gpu/drm/i915/intel_sdvo.c |1 + 10 files changed, 141 insertions(+), 64 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: make VM handling async v2
On 20.08.2012 20:58, Alex Deucher wrote: On Mon, Aug 20, 2012 at 4:08 AM, Christian König wrote: Second and hopefully last round for this patchset. v2: Fix suspend/resume, and incorporate Jeromes comments. Looks good to me. Can you put up a git branch somewhere? Sure: git://people.freedesktop.org/~deathsimple/linux wip Christian. Reviewed-by: Alex Deucher Cheers, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Laurent,
Thank you for your comments.
On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> Just a couple of small comments below.
>
> On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
>> This patch adds support for exporting a dma-contig buffer using
>> DMABUF interface.
>>
>> Signed-off-by: Tomasz Stanislawski
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 204 +
>> 1 file changed, 204 insertions(+)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
>> +static struct sg_table *vb2_dc_dmabuf_ops_map(
>> +struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
>> +{
>> +struct vb2_dc_attachment *attach = db_attach->priv;
>> +/* stealing dmabuf mutex to serialize map/unmap operations */
>
> Why isn't this operation serialized by the dma-buf core itself ?
>
Indeed, it is a very good question. The lock was introduced in RFCv3 of
DMABUF patches. It was dedicated to serialize attach/detach calls.
No requirements for map/unmap serialization were stated so serialization
was delegated to an exporter.
A deadlock could occur if dma_map_attachment is called from inside
of attach ops. IMO, such an operation is invalid because an attachment
list is not in a valid state while attach ops is being processed.
Do you think that stealing a lock from dma-buf internals is too hacky?
I prefer not to introduce any extra locks in dma-contig allocator
but it is not a big deal to add it.
>> +struct mutex *lock = &db_attach->dmabuf->lock;
>> +struct sg_table *sgt;
>> +int ret;
>> +
>> +mutex_lock(lock);
>> +
>> +sgt = &attach->sgt;
>> +/* return previously mapped sg table */
>> +if (attach->dir == dir) {
>> +mutex_unlock(lock);
>> +return sgt;
>> +}
>> +
>> +/* release any previous cache */
>> +if (attach->dir != DMA_NONE) {
>> +dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> +attach->dir);
>> +attach->dir = DMA_NONE;
>> +}
>> +
>> +/* mapping to the client with new direction */
>> +ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
>> +if (ret <= 0) {
>> +pr_err("failed to map scatterlist\n");
>> +mutex_unlock(lock);
>> +return ERR_PTR(-EIO);
>> +}
>> +
>> +attach->dir = dir;
>> +
>> +mutex_unlock(lock);
>> +
>> +return sgt;
>> +}
>
> [snip]
>
>> +static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
>> +struct vm_area_struct *vma)
>> +{
>> +/* Dummy support for mmap */
>> +return -ENOTTY;
>
> What about calling the dma-contig mmap handler here ? Is there a specific
> reason why you haven't implemented mmap support for dmabuf ?
>
The mmap ops is mandatory in the latest DMABUF api.
I added a stub function to make DC work with DMABUF without any big effort.
Calling vb2_dc_mmap from mmap ops seams to be a simple and safe way to
handle mmap functionality. Thank you for spotting this :)
>> +}
>> +
>> +static struct dma_buf_ops vb2_dc_dmabuf_ops = {
>> +.attach = vb2_dc_dmabuf_ops_attach,
>> +.detach = vb2_dc_dmabuf_ops_detach,
>> +.map_dma_buf = vb2_dc_dmabuf_ops_map,
>> +.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
>> +.kmap = vb2_dc_dmabuf_ops_kmap,
>> +.kmap_atomic = vb2_dc_dmabuf_ops_kmap,
>> +.vmap = vb2_dc_dmabuf_ops_vmap,
>> +.mmap = vb2_dc_dmabuf_ops_mmap,
>> +.release = vb2_dc_dmabuf_ops_release,
>> +};
>> +
>> +static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
>> +{
>> +int ret;
>> +struct sg_table *sgt;
>> +
>> +sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
>> +if (!sgt) {
>> +dev_err(buf->dev, "failed to alloc sg table\n");
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +ret = dma_get_sgtable(buf->dev, sgt, buf->vaddr, buf->dma_addr,
>> +buf->size);
>> +if (ret < 0) {
>> +dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
>> +kfree(sgt);
>> +return ERR_PTR(ret);
>> +}
>
> As this function is only used below, where the exact value of the error code
> is ignored, what about just returning NULL on failure ? Another option is to
> return the error code in vb2_dc_get_dmabuf (not sure if that would be useful
> though).
>
>> +
>> +return sgt;
>> +}
>> +
>> +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
>> +{
>> +struct vb2_dc_buf *buf = buf_priv;
>> +struct dma_buf *dbuf;
>> +struct sg_table *sgt = buf->sgt_base;
>> +
>> +if (!sgt)
>> +sgt = vb2_dc_get_base_sgt(buf);
>> +if (WARN_ON(IS_ERR(sgt)))
>> +return NULL;
>> +
>> +/* cache base
Re: radeon testing
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
>> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
>> > I see a big slow down during radeon driver initialization when the
>> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
>> > screen just flickers during boot). With initcall_debug I see:
>> >
>> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
>> > ...
>> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
>> > 3102147 usecs
>> >
>> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
>> > very
>> > informative, I'll try and get more info...
>>
>> Can you bisect?
>
> I've put in some printk, this is the result:
>
> [2.403138] evergreen_mc_program
> [2.403196] evergreen_mc_stop
> ...
> [4.268491] evergreen_mc_resume done
> [4.268548] evergreen_mc_program done
>
> This is the patch:
>
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
> u32 tmp;
> int i, j;
>
> + printk(KERN_INFO "%s\n", __func__);
> +
> /* Initialize HDP */
> for (i = 0, j = 0; i < 32; i++, j += 0x18) {
> WREG32((0x2c14 + j), 0x);
> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
> }
> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
>
> + printk(KERN_INFO "evergreen_mc_stop\n");
> evergreen_mc_stop(rdev, &save);
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
> +
> /* Lockout access through VGA aperture*/
> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
> /* Update configuration */
> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
> WREG32(MC_VM_AGP_TOP, 0x0FFF);
> WREG32(MC_VM_AGP_BOT, 0x0FFF);
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_resume\n");
> evergreen_mc_resume(rdev, &save);
> + printk(KERN_INFO "evergreen_mc_resume done\n");
> /* we need to own VRAM, so turn off the VGA renderer here
> * to stop it overwriting our objects */
> rv515_vga_render_disable(rdev);
>
>
> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
>
> commit 023e188ec102330eb05ad264f675e869637478eb
> Author: Alex Deucher
> Date: Wed Aug 15 17:18:42 2012 -0400
>
> drm/radeon: properly handle mc_stop/mc_resume on evergreen+
>
> - Stop the displays from accessing the FB
> - Block CPU access
> - Turn off MC client access
>
> This should fix issues some users have seen, especially
> with UEFI, when changing the MC FB location that result
> in hangs or display corruption.
>
>
>
> I haven't tried backing out the commit yet, but looking at the diff I
> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
> but evergreen_mc_program is called way before IRQ is set up. Is the
> vblank counter running? Looks like we just hitting the timeout here...
>
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
>
>
>
> Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
Hello Daniel,
On Tue, Aug 21, 2012 at 4:18 AM, Daniel Vetter wrote:
> On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S
> > ---
> > drivers/gpu/drm/drm_edid.c | 17 -
> > 1 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index a8743c3..2c2996e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > int block, int len)
> > {
> > unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
>
> Have you tested this on i915 with gmbus enabled? I'm asking since we
> don't implement the IGNORE_NAK flag and hence I'd expect spurious
> failures on displays that don't support E-DDC ...
>
> I have verified this on samsung exynos5 platform, and it passed the HDMI
compliance test for the same.
I also verified this on HDMI analyser- Agilent N5988A , this analyser
does not support 4 block EDID data(EDDC),
it passed in this analyser as well.
Is there any specific reason why you dont implement IGNORE_NAK?
Infact if i think for EDDC, if one does not pass IGNORE_NAK flag it might
give errors.
> Cheers, Daniel
>
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > */
> > do {
> > struct i2c_msg msgs[] = {
> > - {
> > + { /*set segment pointer */
> > + .addr = DDC_SEGMENT_ADDR,
> > + .flags = segFlags,
> > + .len= 1,
> > + .buf= &start,
> > + }, { /*set offset */
> > .addr = DDC_ADDR,
> > .flags = 0,
> > .len= 1,
> > .buf= &start,
> > - }, {
> > + }, { /*set data */
> > .addr = DDC_ADDR,
> > .flags = I2C_M_RD,
> > .len= len,
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > + ret = i2c_transfer(adapter, msgs, 3);
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > - } while (ret != 2 && --retries);
> > + } while (ret != 3 && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == 3 ? 0 : -1;
> > }
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Regards,
Shirish S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
Hello Ville Syrjälä, On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > > The current logic for probing ddc is limited to > > 2 blocks (256 bytes), this patch adds support > > for the 4 block (512) data. > > A patch for this was already sent a long time ago: > http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html > > I tried the patch you have mentioned,but its not working in my setup. Also did anyone else test this!! I find that although the author asks the i2c to read for 3 msgs, it verifies only for 2.Kindly correct me if i am wrong. My patch i have verified on the analyser for exynos5 platform. > -- > Ville Syrjälä > Intel OTC > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Regards, Shirish S ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Tomasz,
On Tuesday 21 August 2012 15:47:13 Tomasz Stanislawski wrote:
> On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> >> This patch adds support for exporting a dma-contig buffer using
> >> DMABUF interface.
> >>
> >> Signed-off-by: Tomasz Stanislawski
> >> Signed-off-by: Kyungmin Park
> >> ---
> >>
> >> drivers/media/video/videobuf2-dma-contig.c | 204 ++
> >> 1 file changed, 204 insertions(+)
> >>
> >> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> >> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8
> >> 100644
> >> --- a/drivers/media/video/videobuf2-dma-contig.c
> >> +++ b/drivers/media/video/videobuf2-dma-contig.c
> >
> > [snip]
> >
> >> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> >> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> >> +{
> >> + struct vb2_dc_attachment *attach = db_attach->priv;
> >> + /* stealing dmabuf mutex to serialize map/unmap operations */
> >
> > Why isn't this operation serialized by the dma-buf core itself ?
>
> Indeed, it is a very good question. The lock was introduced in RFCv3 of
> DMABUF patches. It was dedicated to serialize attach/detach calls.
> No requirements for map/unmap serialization were stated so serialization
> was delegated to an exporter.
>
> A deadlock could occur if dma_map_attachment is called from inside
> of attach ops. IMO, such an operation is invalid because an attachment
> list is not in a valid state while attach ops is being processed.
>
> Do you think that stealing a lock from dma-buf internals is too hacky?
No, I would be OK with that, but I'd like to make sure that it won't bite us
back later. If there's a specific reason why the lock is not taken by the
dmabuf core around map/unmap calls, stealing the same lock might cause
unforeseen problems. That's why I would like to understand why the core
doesn't perform locking on its own.
> I prefer not to introduce any extra locks in dma-contig allocator
Agreed.
> but it is not a big deal to add it.
>
> >> + struct mutex *lock = &db_attach->dmabuf->lock;
> >> + struct sg_table *sgt;
> >> + int ret;
> >> +
> >> + mutex_lock(lock);
> >> +
> >> + sgt = &attach->sgt;
> >> + /* return previously mapped sg table */
> >> + if (attach->dir == dir) {
> >> + mutex_unlock(lock);
> >> + return sgt;
> >> + }
> >> +
> >> + /* release any previous cache */
> >> + if (attach->dir != DMA_NONE) {
> >> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> >> + attach->dir);
> >> + attach->dir = DMA_NONE;
> >> + }
> >> +
> >> + /* mapping to the client with new direction */
> >> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> >> + if (ret <= 0) {
> >> + pr_err("failed to map scatterlist\n");
> >> + mutex_unlock(lock);
> >> + return ERR_PTR(-EIO);
> >> + }
> >> +
> >> + attach->dir = dir;
> >> +
> >> + mutex_unlock(lock);
> >> +
> >> + return sgt;
> >> +}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Add missing static storage class specifiers in drm_proc.c file
Hi,
Any comments on this series?
On 1 August 2012 17:15, Sachin Kamat wrote:
> Fixes the following sparse warning:
> drivers/gpu/drm/drm_proc.c:92:5:
> warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
> drivers/gpu/drm/drm_proc.c:175:5:
> warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/drm_proc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
> index 371c695..da457b1 100644
> --- a/drivers/gpu/drm/drm_proc.c
> +++ b/drivers/gpu/drm/drm_proc.c
> @@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
> * Create a given set of proc files represented by an array of
> * gdm_proc_lists in the given root directory.
> */
> -int drm_proc_create_files(struct drm_info_list *files, int count,
> +static int drm_proc_create_files(struct drm_info_list *files, int count,
> struct proc_dir_entry *root, struct drm_minor
> *minor)
> {
> struct drm_device *dev = minor->dev;
> @@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
> return 0;
> }
>
> -int drm_proc_remove_files(struct drm_info_list *files, int count,
> +static int drm_proc_remove_files(struct drm_info_list *files, int count,
> struct drm_minor *minor)
> {
> struct list_head *pos, *q;
> --
> 1.7.4.1
>
--
With warm regards,
Sachin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: > On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: >> Hello! >> >> I have been working on prototypes for the ASoC OMAP HDMI audio driver to >> propagate events from the HDMI output (e.g., display getting >> enabled/disabled/suspended). This for the users of the driver to react >> to such events. For instance, if the display is disabled or disconected, >> audio could be stopped, rerouted or whatever other decision the user >> makes. This is needed because, if, for instance, the HDMI IP goes off, >> audio will stall and the audio users will only see a "playback write >> error (DMA or IRQ trouble?)" >> >> In my prototypes I have used snd_soc_jack for this purpose and I have >> some questions: >> >> *I see snd_soc_jack is used mostly for headsets and microphones with >> actual external mechanical connections. Strictly, in my case I propagate >> events originated by the OMAP display driver (changes in the power >> state), and not from external events. Some of these events are generated >> from an actual HDMI cable connection/disconnection, though. >> >> *Maybe the event should be propagated by omapdss/omapdrm/drm and the >> entity in charge of the audio policy should listen those events instead. >> >> *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is >> feasible for an audio driver to report events from an AV output. >> >> I was wondering about how much sense does it make to you guys use a >> snd_soc_jack in this case? > > How does DRM handle audio? I made a quick grep, but I see the drm > drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? >From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. BR, -R > If there's a common generic way to handle this, we should obviously use > that. But if we need to choose between doing something custom or doing > it in omapdrm driver, I think we should go for drm the only solution and > forget about audio with omapfb. > > Tomi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 07:39:55AM -0500, Clark, Rob wrote: > Does ASoC support 'hotplug' of audio devices? If so, maybe it makes > some sense to have some support in drm core. At least all the edid > parsing stuff to determine if the display supports audio should be > generic and not driver specific. Not really (except on a card level), and it'd probably confuse most userspaces. What I'd expect to happen currently is that the current state of the connector would get reported via extcon. signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix bo creation retry path
On Tue, Aug 21, 2012 at 3:03 AM, Michel Dänzer wrote: > On Fre, 2012-07-13 at 07:54 +0200, Michel Dänzer wrote: >> On Don, 2012-07-12 at 18:23 -0400, j.gli...@gmail.com wrote: >> > From: Jerome Glisse >> > >> > Retry label was at wrong place in function leading to memory >> > leak. >> > >> > Cc: >> > Signed-off-by: Jerome Glisse >> > --- >> > drivers/gpu/drm/radeon/radeon_object.c |3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/radeon/radeon_object.c >> > b/drivers/gpu/drm/radeon/radeon_object.c >> > index 6ecb200..f71e472 100644 >> > --- a/drivers/gpu/drm/radeon/radeon_object.c >> > +++ b/drivers/gpu/drm/radeon/radeon_object.c >> > @@ -138,7 +138,6 @@ int radeon_bo_create(struct radeon_device *rdev, >> > acc_size = ttm_bo_dma_acc_size(&rdev->mman.bdev, size, >> >sizeof(struct radeon_bo)); >> > >> > -retry: >> > bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); >> > if (bo == NULL) >> > return -ENOMEM; >> > @@ -152,6 +151,8 @@ retry: >> > bo->surface_reg = -1; >> > INIT_LIST_HEAD(&bo->list); >> > INIT_LIST_HEAD(&bo->va); >> > + >> > +retry: >> > radeon_ttm_placement_from_domain(bo, domain); >> > /* Kernel allocation are uninterruptible */ >> > down_read(&rdev->pm.mclk_lock); >> >> Reviewed-by: Michel Dänzer > > Actually, this is wrong: ttm_bo_init() destroys the BO on failure. So > this patch makes the retry path work with freed memory. I see on IRC > that this is causing panics with some piglit tests for several people, > please submit a patch to revert this. > > Sorry I didn't remember this when reviewing the patch. :( Reverted in my -fixes queue. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On 21.08.2012 15:51, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very
informative, I'll try and get more info...
Can you bisect?
I've put in some printk, this is the result:
[2.403138] evergreen_mc_program
[2.403196] evergreen_mc_stop
...
[4.268491] evergreen_mc_resume done
[4.268548] evergreen_mc_program done
This is the patch:
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
u32 tmp;
int i, j;
+ printk(KERN_INFO "%s\n", __func__);
+
/* Initialize HDP */
for (i = 0, j = 0; i < 32; i++, j += 0x18) {
WREG32((0x2c14 + j), 0x);
@@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
}
WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
+ printk(KERN_INFO "evergreen_mc_stop\n");
evergreen_mc_stop(rdev, &save);
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
+
/* Lockout access through VGA aperture*/
WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
/* Update configuration */
@@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
WREG32(MC_VM_AGP_TOP, 0x0FFF);
WREG32(MC_VM_AGP_BOT, 0x0FFF);
}
+// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
if (evergreen_mc_wait_for_idle(rdev)) {
dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
}
+// printk(KERN_INFO "evergreen_mc_resume\n");
evergreen_mc_resume(rdev, &save);
+ printk(KERN_INFO "evergreen_mc_resume done\n");
/* we need to own VRAM, so turn off the VGA renderer here
* to stop it overwriting our objects */
rv515_vga_render_disable(rdev);
Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
IIRC we have a rw-semaphore that you can writelock to prevent anything
from accessing vram.
But if you try to access VRAM from within the critical section (by using
a printk that tries to write something to the console) you probably end
up deadlocking the kernel.
Christian.
commit 023e188ec102330eb05ad264f675e869637478eb
Author: Alex Deucher
Date: Wed Aug 15 17:18:42 2012 -0400
drm/radeon: properly handle mc_stop/mc_resume on evergreen+
- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access
This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.
I haven't tried backing out the commit yet, but looking at the diff I
see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
but evergreen_mc_program is called way before IRQ is set up. Is the
vblank counter running? Looks like we just hitting the timeout here...
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote: > > So after much tracing with direct netconsole writes (printks > > under console_lock not so useful), I think I found the race. > > Direct netconsole write would be a useful patch to have mainline I think > 8) could we make that use the earlyprintk infrastructure? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote: > So after much tracing with direct netconsole writes (printks > under console_lock not so useful) I always use earlyprintk on serial.. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53884] New: gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Bug #: 53884
Summary: gl_FragCoord gets corrupted in some camera angles
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: cur...@operamail.com
Created attachment 65891
--> https://bugs.freedesktop.org/attachment.cgi?id=65891
Screenshot of the issue, bad camera angle
In certain camera angles, gl_FragCoord.xy seem to have bogus/corrupted values.
I tried to make a simple example but couldn't, so uploading an apitrace of the
bigger app and screenshots. The apitrace is 60mb XZ-compressed, that's why the
need to use a third-party service - upload limits here.
This shader:
void main() {
gl_FragColor = vec4(gl_FragCoord.xy / vec2(640, 480), 0.0, 0.0);
}
should always create values from 0 to 1 in a window of that size. In the
apitrace the only difference is that the size is passed in an uniform.
This bug happens on both r600g and llvmpipe. I didn't have the patience to wait
for softpipe to render it. I don't have anything else on this machine to
compare to (swrast, blobs).
Mesa 8.0.3
Linux 3.2.23
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53884] gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884 --- Comment #1 from Lauri Kasanen 2012-08-21 14:43:19 UTC --- Created attachment 65892 --> https://bugs.freedesktop.org/attachment.cgi?id=65892 Same scene, good camera angle -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53884] gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884 --- Comment #2 from Lauri Kasanen 2012-08-21 14:46:53 UTC --- Apitrace (60mb): http://www.ziddu.com/download/20164691/fragcoord.trace.zip.html Renamed as a zip to let it be uploaded. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
Any objections from the ACPI folks to this patch going into 3.6 and stable? Alex On Mon, Aug 20, 2012 at 11:19 AM, wrote: > From: Alex Deucher > > We need it in the radeon drm module to fetch > and verify the vbios image on UEFI systems. > > Signed-off-by: Alex Deucher > Cc: sta...@vger.kernel.org > --- > drivers/acpi/acpica/tbxface.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c > index ea4c6d5..29e51bc 100644 > --- a/drivers/acpi/acpica/tbxface.c > +++ b/drivers/acpi/acpica/tbxface.c > @@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature, > > return (AE_NOT_FOUND); > } > +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) > > acpi_status > acpi_get_table(char *signature, > -- > 1.7.7.5 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
On Tue, Aug 21, 2012 at 10:50:35AM -0400, Alex Deucher wrote: > Any objections from the ACPI folks to this patch going into 3.6 and stable? Looks good to me. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > Hello Ville Syrjälä, > > On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä < > ville.syrj...@linux.intel.com> wrote: > > > On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > > > The current logic for probing ddc is limited to > > > 2 blocks (256 bytes), this patch adds support > > > for the 4 block (512) data. > > > > A patch for this was already sent a long time ago: > > http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html > > > > I tried the patch you have mentioned,but its not working in my setup. > Also did anyone else test this!! Not that I know. > I find that although the author asks the i2c to read for 3 msgs, it > verifies only for 2.Kindly correct me if i am wrong. Yeah, it looks like the return value isn't checked correctly. > My patch i have verified on the analyser for exynos5 platform. Your patch always sends the segment which seems a bit pointless, and possibly questionable in case a non-EDDC display gets confused by the segment information. Jean's patch only sends the segment when needed, which feels like the safer option, and it would also avoid increasing the amount of i2c traffic. Here are my earlier comments on Jean's patch: http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53884] gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884 Ian Romanick changed: What|Removed |Added AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #3 from Ian Romanick 2012-08-21 18:59:15 UTC --- I'm also able to reproduce this on Intel hardware with i965_dri.so. Since this doesn't seem specific to r600 hardware or even to Gallium-based drivers, I'm switching the component to 'Mesa core'. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> > the machine. The likely culprit is commit 023e188e:
>
> yeah, vram is locked out at that point. I guess we probably need to
> block anyone from trying to access it.
I see; the 2 dev_warn would probably lock up the machine as well right?
> > I haven't tried backing out the commit yet, but looking at the diff I
> > see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
> > but evergreen_mc_program is called way before IRQ is set up. Is the
> > vblank counter running? Looks like we just hitting the timeout here...
>
> We aren't waiting for an interrupt, just polling the current crtc
> status until it enters the vblank region. The status and counters
> should be working as we only wait on displays that are enabled.
It appears that all the crtcs are considered active:
[4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
[4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
[4.260766] crtc 0: waited 33 [10] (number of loops of
radeon_get_vblank_counter)
[4.260766] crtc 1 enabled 272630544
[4.260766] crtc 1 wait for vblank 0x1
[4.260766] crtc 1: waited 10 [10]
[4.260766] crtc 2 enabled 4195088
[4.260766] crtc 2 wait for vblank 0x1
[4.260766] crtc 2: waited 10 [10]
[4.260766] crtc 3 enabled 4195088
[4.260766] crtc 3 wait for vblank 0x1
[4.260766] crtc 3: waited 10 [10]
[4.260766] crtc 4 enabled 4195088
[4.260766] crtc 4 wait for vblank 0x1
[4.260766] crtc 4: waited 10 [10]
[4.260766] crtc 5 enabled 4195088
[4.260766] crtc 5 wait for vblank 0x1
[4.260766] crtc 5: waited 10 [10]
Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
I'm testing this patch and the boot is fast again:
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 2308c7d..72bf721 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev, struct
evergreen_mc_save *sav
WREG32(VGA_RENDER_CONTROL, 0);
/* blank the display controllers */
for (i = 0; i < rdev->num_crtc; i++) {
- crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]);
+ crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i])
&
+ EVERGREEN_CRTC_MASTER_EN;
if (crtc_enabled) {
save->crtc_enabled[i] = true;
if (ASIC_IS_DCE6(rdev)) {
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon testing
On Tue, Aug 21, 2012 at 4:33 PM, Luca Tettamanti wrote:
> On Tue, Aug 21, 2012 at 09:51:46AM -0400, Alex Deucher wrote:
>> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
>> > Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
>> > the machine. The likely culprit is commit 023e188e:
>>
>> yeah, vram is locked out at that point. I guess we probably need to
>> block anyone from trying to access it.
>
> I see; the 2 dev_warn would probably lock up the machine as well right?
>
>> > I haven't tried backing out the commit yet, but looking at the diff I
>> > see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
>> > but evergreen_mc_program is called way before IRQ is set up. Is the
>> > vblank counter running? Looks like we just hitting the timeout here...
>>
>> We aren't waiting for an interrupt, just polling the current crtc
>> status until it enters the vblank region. The status and counters
>> should be working as we only wait on displays that are enabled.
>
> It appears that all the crtcs are considered active:
>
> [4.260766] crtc 0 enabled 272696081 (this is the value of crtc_enabled)
> [4.260766] crtc 0 wait for vblank 0x1 (0x1 means no timeout)
> [4.260766] crtc 0: waited 33 [10] (number of loops of
> radeon_get_vblank_counter)
> [4.260766] crtc 1 enabled 272630544
> [4.260766] crtc 1 wait for vblank 0x1
> [4.260766] crtc 1: waited 10 [10]
> [4.260766] crtc 2 enabled 4195088
> [4.260766] crtc 2 wait for vblank 0x1
> [4.260766] crtc 2: waited 10 [10]
> [4.260766] crtc 3 enabled 4195088
> [4.260766] crtc 3 wait for vblank 0x1
> [4.260766] crtc 3: waited 10 [10]
> [4.260766] crtc 4 enabled 4195088
> [4.260766] crtc 4 wait for vblank 0x1
> [4.260766] crtc 4: waited 10 [10]
> [4.260766] crtc 5 enabled 4195088
> [4.260766] crtc 5 wait for vblank 0x1
> [4.260766] crtc 5: waited 10 [10]
>
> Maybe the code should be checking EVERGREEN_CRTC_MASTER_EN?
>
> I'm testing this patch and the boot is fast again:
Yes, that's correct. I'll fix that up.
Alex
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 2308c7d..72bf721 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1251,7 +1251,8 @@ void evergreen_mc_stop(struct radeon_device *rdev,
> struct evergreen_mc_save *sav
> WREG32(VGA_RENDER_CONTROL, 0);
> /* blank the display controllers */
> for (i = 0; i < rdev->num_crtc; i++) {
> - crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
> crtc_offsets[i]);
> + crtc_enabled = RREG32(EVERGREEN_CRTC_CONTROL +
> crtc_offsets[i]) &
> + EVERGREEN_CRTC_MASTER_EN;
> if (crtc_enabled) {
> save->crtc_enabled[i] = true;
> if (ASIC_IS_DCE6(rdev)) {
>
>
> Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.6
From: Alex Deucher Hi Dave, This is the current set of radeon fixes for 3.6. Nothing too major. Highlights: - fix vbios fetch on pure uefi systems - fix vbios fetch on thunderbolt systems - MSAA fixes - lockup timeout fix - modesetting fix The following changes since commit 2e26c73a1e410448fbd2c0fbd34f06d98eaf8e48: Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-08-15 20:31:22 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 Alex Deucher (4): ACPI: export symbol acpi_get_table_with_size drm/radeon: convert radeon vfct code to use acpi_get_table_with_size drm/radeon: split ATRM support out from the ATPX handler (v3) Revert "drm/radeon: fix bo creation retry path" Christian König (1): drm/radeon: init lockup timeout on ring init David Lamparter (1): drm/radeon: implement ACPI VFCT vbios fetch (v3) Jerome Glisse (1): drm/radeon: avoid turning off spread spectrum for used pll Marek Olšák (2): drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700 drm/radeon: fix checking of MSAA renderbuffers on r600-r700 Tvrtko Ursulin (1): drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping drivers/acpi/acpica/tbxface.c|1 + drivers/gpu/drm/radeon/atombios_crtc.c | 25 - drivers/gpu/drm/radeon/r600_cs.c | 105 --- drivers/gpu/drm/radeon/r600d.h | 17 +++ drivers/gpu/drm/radeon/radeon.h | 15 --- drivers/gpu/drm/radeon/radeon_atombios.c |2 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56 +-- drivers/gpu/drm/radeon/radeon_bios.c | 138 +- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/radeon/radeon_object.c |3 +- drivers/gpu/drm/radeon/radeon_ring.c |1 + drivers/gpu/drm/radeon/reg_srcs/r600 |8 -- 12 files changed, 267 insertions(+), 107 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] console_lock debug improvements
Hi all, After Dave Airlie blew through a few days to track down a deadlock at boot-up when handing over from the firmware fb to the kms/drm framebuffer driver (1), I've figured that lockdep /should/ have caught this. And indeed, by adding proper annotations to the console_lock it complains about the potential deadlock when exercising the entire driver life-cycle of just one fb driver (i.e. not even a handover required). While at it, I've replaced the existing in_interrupt check with the more paranoid might_sleep. Comments, flames and review highly welcome. Yours, Daniel [1]: https://lkml.org/lkml/2012/8/21/36 Daniel Vetter (2): console: use might_sleep in console_lock console: implement lockdep support for console_lock kernel/printk.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] console: use might_sleep in console_lock
Instead of BUG_ON(in_interrupt()), since that doesn't check for all
the newfangled stuff like preempt.
Note that this is valid since the console_sem is essentially used like
a real mutex with only two twists:
- we allow trylock from hardirq context
- across suspend/resume we lock the logical console_lock, but drop the
semaphore protecting the locking state.
Now that doesn't guarantee that no one is playing tricks in
single-thread atomic contexts at suspend/resume/boot time, but
- I couldn't find anything suspicious with some grepping,
- might_sleep shouldn't die,
- and I think the upside of catching more potential issues is worth
the risk of getting a might_sleep backtrace that would have been
save (and then dealing with that fallout).
Cc: Dave Airlie
Cc: Thomas Gleixner
Signed-off-by: Daniel Vetter
---
kernel/printk.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 66a2ea3..ed9af6a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1909,7 +1909,8 @@ static int __cpuinit console_cpu_notify(struct
notifier_block *self,
*/
void console_lock(void)
{
- BUG_ON(in_interrupt());
+ might_sleep();
+
down(&console_sem);
if (console_suspended)
return;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] console: implement lockdep support for console_lock
Dave Airlie recently discovered a locking bug in the fbcon layer,
where a timer_del_sync (for the blinking cursor) deadlocks with the
timer itself, since both (want to) hold the console_lock:
https://lkml.org/lkml/2012/8/21/36
Unfortunately the console_lock isn't a plain mutex and hence has no
lockdep support. Which resulted in a few days wasted of tracking down
this bug (complicated by the fact that printk doesn't show anything
when the console is locked) instead of noticing the bug much earlier
with the lockdep splat.
Hence I've figured I need to fix that for the next deadlock involving
console_lock - and with kms/drm growing ever more complex locking
that'll eventually happen.
Now the console_lock has rather funky semantics, so after a quick irc
discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
the original idead of switching to a real mutex (since it won't work)
and instead opted to annotate the console_lock with lockdep
information manually.
There are a few special cases:
- The console_lock state is protected by the console_sem, and usually
grabbed/dropped at _lock/_unlock time. But the suspend/resume code
drops the semaphore without dropping the console_lock (see
suspend_console/resume_console). But since the same thread that did
the suspend will do the resume, we don't need to fix up anything.
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
- The console_lock can also be acquired form irq context (but only
with a trylock). lockdep already handles that.
This all leaves us with annotating the normal console_lock, _unlock
and _trylock functions.
And yes, it works - simply unloading a drm kms driver resulted in
lockdep complaining about the deadlock in fbcon_deinit:
==
[ INFO: possible circular locking dependency detected ]
3.6.0-rc2+ #552 Not tainted
---
kms-reload/3577 is trying to acquire lock:
((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
but task is already holding lock:
(console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (console_lock){+.+.+.}:
[] lock_acquire+0x95/0x105
[] console_lock+0x59/0x5b
[] fb_flashcursor+0x2e/0x12c
[] process_one_work+0x1d9/0x3b4
[] worker_thread+0x1a7/0x24b
[] kthread+0x7f/0x87
[] kernel_thread_helper+0x4/0x10
-> #0 ((&info->queue)){+.+...}:
[] __lock_acquire+0x999/0xcf6
[] lock_acquire+0x95/0x105
[] wait_on_work+0x3b/0xa7
[] __cancel_work_timer+0xbf/0x102
[] cancel_work_sync+0xb/0xd
[] fbcon_deinit+0x11c/0x1dc
[] bind_con_driver+0x145/0x263
[] unbind_con_driver+0x14f/0x195
[] store_bind+0x1ad/0x1c1
[] dev_attr_store+0x13/0x1f
[] sysfs_write_file+0xe9/0x121
[] vfs_write+0x9b/0xfd
[] sys_write+0x3e/0x6b
[] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(console_lock);
lock((&info->queue));
lock(console_lock);
lock((&info->queue));
*** DEADLOCK ***
Cc: Dave Airlie
Cc: Thomas Gleixner
Signed-off-by: Daniel Vetter
---
kernel/printk.c |9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/printk.c b/kernel/printk.c
index ed9af6a..ab2ab24 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -87,6 +87,12 @@ static DEFINE_SEMAPHORE(console_sem);
struct console *console_drivers;
EXPORT_SYMBOL_GPL(console_drivers);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map console_lock_dep_map = {
+ .name = "console_lock"
+};
+#endif
+
/*
* This is used for debugging the mess that is the VT code by
* keeping track if we have the console semaphore held. It's
@@ -1916,6 +1922,7 @@ void console_lock(void)
return;
console_locked = 1;
console_may_schedule = 1;
+ mutex_acquire(&console_lock_dep_map, 0, 0, _RET_IP_);
}
EXPORT_SYMBOL(console_lock);
@@ -1937,6 +1944,7 @@ int console_trylock(void)
}
console_locked = 1;
console_may_schedule = 0;
+ mutex_acquire(&console_lock_dep_map, 0, 1, _RET_IP_);
return 1;
}
EXPORT_SYMBOL(console_trylock);
@@ -2097,6 +2105,7 @@ skip:
local_irq_restore(flags);
}
console_locked = 0;
+ mutex_release(&console_lock_dep_map, 1, _RET_IP_);
/* Release the exclusive_console once it is used */
if (unlikely(exclusive_console))
--
1.7.10.4
___
dri-devel mailing list
Re: [pull] radeon drm-fixes-3.6
On additional small fix I just pushed: drm/radeon/ss: use num_crtc rather than hardcoded 6 On Tue, Aug 21, 2012 at 4:53 PM, wrote: > From: Alex Deucher > > Hi Dave, > > This is the current set of radeon fixes for 3.6. Nothing too major. > > Highlights: > - fix vbios fetch on pure uefi systems > - fix vbios fetch on thunderbolt systems > - MSAA fixes > - lockup timeout fix > - modesetting fix > > The following changes since commit 2e26c73a1e410448fbd2c0fbd34f06d98eaf8e48: > > Merge branch 'drm-nouveau-fixes' of > git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2012-08-15 > 20:31:22 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~agd5f/linux drm-fixes-3.6 > > Alex Deucher (4): > ACPI: export symbol acpi_get_table_with_size > drm/radeon: convert radeon vfct code to use acpi_get_table_with_size > drm/radeon: split ATRM support out from the ATPX handler (v3) > Revert "drm/radeon: fix bo creation retry path" > > Christian König (1): > drm/radeon: init lockup timeout on ring init > > David Lamparter (1): > drm/radeon: implement ACPI VFCT vbios fetch (v3) > > Jerome Glisse (1): > drm/radeon: avoid turning off spread spectrum for used pll > > Marek Olšák (2): > drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700 > drm/radeon: fix checking of MSAA renderbuffers on r600-r700 > > Tvrtko Ursulin (1): > drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to > cover later silicon stepping > > drivers/acpi/acpica/tbxface.c|1 + > drivers/gpu/drm/radeon/atombios_crtc.c | 25 - > drivers/gpu/drm/radeon/r600_cs.c | 105 --- > drivers/gpu/drm/radeon/r600d.h | 17 +++ > drivers/gpu/drm/radeon/radeon.h | 15 --- > drivers/gpu/drm/radeon/radeon_atombios.c |2 +- > drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56 +-- > drivers/gpu/drm/radeon/radeon_bios.c | 138 > +- > drivers/gpu/drm/radeon/radeon_drv.c |3 +- > drivers/gpu/drm/radeon/radeon_object.c |3 +- > drivers/gpu/drm/radeon/radeon_ring.c |1 + > drivers/gpu/drm/radeon/reg_srcs/r600 |8 -- > 12 files changed, 267 insertions(+), 107 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 7:56 AM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Tue, Aug 21, 2012 at 06:55:53AM -0700, Shirish S wrote: > > Hello Ville Syrjälä, > > > > On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrjälä < > > ville.syrj...@linux.intel.com> wrote: > > > > > On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > > > > The current logic for probing ddc is limited to > > > > 2 blocks (256 bytes), this patch adds support > > > > for the 4 block (512) data. > > > > > > A patch for this was already sent a long time ago: > > > > http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html > > > > > > I tried the patch you have mentioned,but its not working in my setup. > > Also did anyone else test this!! > > Not that I know. > > > I find that although the author asks the i2c to read for 3 msgs, it > > verifies only for 2.Kindly correct me if i am wrong. > > Yeah, it looks like the return value isn't checked correctly. > > > My patch i have verified on the analyser for exynos5 platform. > > Your patch always sends the segment which seems a bit pointless, and > possibly questionable in case a non-EDDC display gets confused by the > segment information. Jean's patch only sends the segment when needed, > which feels like the safer option, and it would also avoid increasing > the amount of i2c traffic. > > As per the spec we need to pass a single 8-bit segment index to the display via the I2C address 30h which is DDC_SEGMENT_ADDR, and the ACK is mandatory on the same for block 2 and 3. (the first of i2c_msg). Although the verification of this is not required or mandatory for non-EDDC(block 0 and 1), i have verified that its presence does not affect non-EDDC displays.(Using HDMI analyser- Agilent N5988A) Another option to avoid i2c traffic would be to add another function to probe EDDC blocks,but beg to differ i dont think current method would affect i2c traffic to an alarming extent. Here are my earlier comments on Jean's patch: > http://lists.freedesktop.org/archives/dri-devel/2012-February/019069.html > > If i am not wrong am doing exactly what you have said in you comments. This seems a bit wrong to me. The spec says that the ack for the segment address is "don't care", but for the segment pointer the ack is required (when segment != 0). The variable segFlags is "dont care for block 0 and 1 wheras". With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a non E-DDC display, if we try to read segment != 0 from it. Of course we shouldn't do that unless the display lied to us about what extension blocks it provides. So I'm not sure if it would be better to trust that the display never lies about the extension blocks, or if we should just assume all E-DDC displays ack both segment addr and pointer. The no-ack feature seems to there for backwards compatibility, for cases where the host always sends the segment addr/pointer even when reading segment 0 (which your code doesn't do). To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split into two flags (one for addr, other for data). Hence i have split the i2c_msg into 3, segment pointer,offset(addr) and data pointer. "a single 8-bit segment index is passed to the display via the I2C address 30h(segment pointer). Data from the selected segment is then immediately read via the regular DDC2 address using a repeated I2C 'START' signal" -- > Ville Syrjälä > Intel OTC > Regards, Shirish S ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #17 from Alexandre Demers 2012-08-22 03:02:45 UTC --- (In reply to comment #13) > (In reply to comment #12) > > I tried to trace RenderFeatTest (one of the other applications locking my > > system). It did as with the piglit test: it didn't crash. However, the > > rendering is corrupted where it locks when launched from a terminal. Trace > > is > > 75MB when compressed if you want me to upload it somewhere. > > I forgot to say: it doesn't lock anymore at all. I should have written "... > where it locked when launched from a terminal". It was locking at test 7. I'm > attaching a screenshot from that test. > > I'll bisect to see if I can find which commit "fixed" the lock. I was not able to figure out the combination that fixed the thing. Well, let's focus on the piglit test that locks the beast. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, Aug 21, 2012 at 7:15 PM, Alan Cox wrote: >> So after much tracing with direct netconsole writes (printks >> under console_lock not so useful), I think I found the race. > > Direct netconsole write would be a useful patch to have mainline I think > 8) Well I used a one line wrapper around the netconsole write_msg, which just passed NULL as the first arg, then sprinkled netconsole_write_msg around the place, not having printf stuff could be an annoyance for some people, for this it didn't matter. Peter I wish I had a serial port to work with :-) > > Not really the proper fix but its clear and is probably the best thing to > go in initially with a cc: stable. Can you at least stick a large > > + /* FIXME: we should sort out the unbind locking instead */ Done, and cc stable, I'll send this to Linus via my tree as its fairly urgent from my pov. Dave. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes + one fbcon one
Hi Linus, Intel: edid fixes, power consumption fix, s/r fix, haswell fix radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA validation, lockup timeout fixes, modesetting fixes one udl dpms fix, one vmwgfx fix, couple of trivial core changes There is an export added to ACPI as part of the radeon bios fixes, I've also included the fbcon flashing cursor vs deinit race fix, that seems the simplest place to start, so that distros can pick it up easier. Dave. The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-fixes for you to fetch changes up to d8636a2717bb3da2a7ce2154bf08de90bb8c87b0: fbcon: fix race condition between console lock and cursor timer (v1.1) (2012-08-22 14:00:35 +1000) Alan Cox (1): drm: stop vmgfx driver explosion Alex Deucher (5): ACPI: export symbol acpi_get_table_with_size drm/radeon: convert radeon vfct code to use acpi_get_table_with_size drm/radeon: split ATRM support out from the ATPX handler (v3) Revert "drm/radeon: fix bo creation retry path" drm/radeon/ss: use num_crtc rather than hardcoded 6 Ben Widawsky (1): drm/i915/contexts: fix list corruption Christian König (1): drm/radeon: init lockup timeout on ring init Damien Lespiau (1): drm: Remove two unused fields from struct drm_display_mode Daniel Vetter (2): drm/i915: fix hsw uncached pte drm/i915: use hsw rps tuning values everywhere on gen6+ Dave Airlie (4): Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes drm/udl: dpms off the crtc when disabled. fbcon: fix race condition between console lock and cursor timer (v1.1) David Lamparter (1): drm/radeon: implement ACPI VFCT vbios fetch (v3) Jani Nikula (3): drm/i915: fix EDID memory leak in SDVO drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads Jerome Glisse (1): drm/radeon: avoid turning off spread spectrum for used pll Marek Olšák (2): drm/radeon: allow CMASK and FMASK in the CS checker on r600-r700 drm/radeon: fix checking of MSAA renderbuffers on r600-r700 Sachin Kamat (1): drm: Add missing static storage class specifiers in drm_proc.c file Tvrtko Ursulin (1): drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping drivers/acpi/acpica/tbxface.c|1 + drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c | 105 +--- drivers/gpu/drm/drm_modes.c |3 - drivers/gpu/drm/drm_proc.c |4 +- drivers/gpu/drm/i915/i915_gem.c |8 +- drivers/gpu/drm/i915/i915_gem_gtt.c |5 +- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_crt.c | 36 ++- drivers/gpu/drm/i915/intel_drv.h |2 + drivers/gpu/drm/i915/intel_modes.c | 31 -- drivers/gpu/drm/i915/intel_pm.c | 15 +-- drivers/gpu/drm/i915/intel_sdvo.c|1 + drivers/gpu/drm/radeon/atombios_crtc.c | 25 - drivers/gpu/drm/radeon/r600_cs.c | 105 drivers/gpu/drm/radeon/r600d.h | 17 drivers/gpu/drm/radeon/radeon.h | 15 --- drivers/gpu/drm/radeon/radeon_atombios.c |2 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 56 +-- drivers/gpu/drm/radeon/radeon_bios.c | 138 +- drivers/gpu/drm/radeon/radeon_drv.c |3 +- drivers/gpu/drm/radeon/radeon_object.c |3 +- drivers/gpu/drm/radeon/radeon_ring.c |1 + drivers/gpu/drm/radeon/reg_srcs/r600 |8 -- drivers/gpu/drm/udl/udl_modeset.c|3 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |6 +- drivers/video/console/fbcon.c|9 +- include/drm/drm_crtc.h |2 - 28 files changed, 424 insertions(+), 182 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/exynos: fix EDID memory leak in HDMI
2012/8/15 Jani Nikula :
> The EDID returned by drm_get_edid() was never freed.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 409e2ec..b55335b 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1282,6 +1282,7 @@ static int hdmi_get_edid(void *ctx, struct
> drm_connector *connector,
> DRM_DEBUG_KMS("%s : width[%d] x height[%d]\n",
> (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
> raw_edid->width_cm, raw_edid->height_cm);
> + kfree(raw_edid);
Applied, Thanks.
> } else {
> return -ENODEV;
> }
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: remove the raw_edid field from struct drm_display_info
Acked-by: Inki Dae
2012/8/15 Jani Nikula :
> Neither the drm core nor any of the drivers really need the raw_edid field
> of struct drm_display_info for anything. Instead of being useful, it
> creates confusion about who is responsible for freeing the memory it points
> to and setting the field to NULL afterwards, leading to memory leaks and
> dangling pointers.
>
> Remove the raw_edid field, and fix drivers as necessary.
>
> Reported-by: Russell King
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_edid.c|3 ---
> drivers/gpu/drm/drm_edid_load.c | 23 +--
> drivers/gpu/drm/exynos/exynos_drm_connector.c |4 +---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 13 -
> drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 --
> drivers/gpu/drm/gma500/oaktrail_hdmi.c|1 -
> drivers/gpu/drm/gma500/psb_intel_sdvo.c |3 ---
> drivers/gpu/drm/i915/intel_dp.c |4
> drivers/gpu/drm/i915/intel_hdmi.c |3 ---
> drivers/gpu/drm/i915/intel_modes.c|1 -
> drivers/gpu/drm/i915/intel_sdvo.c |3 ---
> drivers/gpu/drm/mgag200/mgag200_mode.c|1 -
> drivers/gpu/drm/udl/udl_connector.c |3 ---
> drivers/staging/omapdrm/omap_connector.c |5 +
> include/drm/drm_crtc.h|2 --
> 15 files changed, 15 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..bcc4725 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -399,10 +399,7 @@ struct edid *drm_get_edid(struct drm_connector
> *connector,
> if (drm_probe_ddc(adapter))
> edid = (struct edid *)drm_do_get_edid(connector, adapter);
>
> - connector->display_info.raw_edid = (char *)edid;
> -
> return edid;
> -
> }
> EXPORT_SYMBOL(drm_get_edid);
>
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 0303935..186832e 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -114,8 +114,8 @@ static u8 generic_edid[GENERIC_EDIDS][128] = {
> },
> };
>
> -static int edid_load(struct drm_connector *connector, char *name,
> -char *connector_name)
> +static u8 *edid_load(struct drm_connector *connector, char *name,
> + char *connector_name)
> {
> const struct firmware *fw;
> struct platform_device *pdev;
> @@ -205,7 +205,6 @@ static int edid_load(struct drm_connector *connector,
> char *name,
> edid = new_edid;
> }
>
> - connector->display_info.raw_edid = edid;
> DRM_INFO("Got %s EDID base block and %d extension%s from "
> "\"%s\" for connector \"%s\"\n", builtin ? "built-in" :
> "external", valid_extensions, valid_extensions == 1 ? "" : "s",
> @@ -215,7 +214,10 @@ relfw_out:
> release_firmware(fw);
>
> out:
> - return err;
> + if (err)
> + return ERR_PTR(err);
> +
> + return edid;
> }
>
> int drm_load_edid_firmware(struct drm_connector *connector)
> @@ -223,6 +225,7 @@ int drm_load_edid_firmware(struct drm_connector
> *connector)
> char *connector_name = drm_get_connector_name(connector);
> char *edidname = edid_firmware, *last, *colon;
> int ret;
> + struct edid *edid;
>
> if (*edidname == '\0')
> return 0;
> @@ -240,13 +243,13 @@ int drm_load_edid_firmware(struct drm_connector
> *connector)
> if (*last == '\n')
> *last = '\0';
>
> - ret = edid_load(connector, edidname, connector_name);
> - if (ret)
> + edid = (struct edid *) edid_load(connector, edidname, connector_name);
> + if (IS_ERR_OR_NULL(edid))
> return 0;
>
> - drm_mode_connector_update_edid_property(connector,
> - (struct edid *) connector->display_info.raw_edid);
> + drm_mode_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
>
> - return drm_add_edid_modes(connector, (struct edid *)
> - connector->display_info.raw_edid);
> + return ret;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index d956819..9dce3b9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -147,9 +147,7 @@ static int exynos_drm_connector_get_modes(struct
> drm_connector *connector)
>
> drm_mode_connector_update_edid_property(connector, edid);
> count = drm_add_edid_modes(connector, edid);
> -
> - kfree(connector->display_info.raw_edid);
> - connector->display_info.raw_edid = edid;
> + kfree(edid);
>
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #18 from Alexandre Demers 2012-08-22 05:32:58 UTC --- (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #10) > > > Well, it seems running it through qapitrace doesn't lock. > > > > The apitrace looks incomplete: it doesn't contain any actual rendering > > operations. > > I'll rerun it at home tonight. You were right, I had missed a ";" between the arguments. Bam, locked. I was unable to retrieve a trace. Well, I may try to run it in debug mode to see where it stops later this week. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes + one fbcon one
On Wed, Aug 22, 2012 at 2:06 PM, Dave Airlie wrote: > > Hi Linus, > > Intel: edid fixes, power consumption fix, s/r fix, haswell fix > radeon: BIOS loading fixes for UEFI and Thunderbolt machines, better MSAA > validation, lockup timeout fixes, modesetting fixes > one udl dpms fix, > one vmwgfx fix, > couple of trivial core changes > > There is an export added to ACPI as part of the radeon bios fixes, > > I've also included the fbcon flashing cursor vs deinit race fix, that > seems the simplest place to start, so that distros can pick it up easier. Me notices now you've already pulled the fbcon fix, let me know if you want me to drop my one, or just pull in the commit above it in my tree, 27fc4f1c0be917b1e5cef934783f9b09e28e92ea also now a branch in the same tree called drm-fixes-no-fbcon. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Add dependency for G2D in Kconfig
Applied, Thanks. 2012/8/14 Sachin Kamat : > Select Exynos DRM based G2D only if non-DRM based Exynos G2D driver > is not selected. > > Signed-off-by: Sachin Kamat > --- > drivers/gpu/drm/exynos/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig > index 7f50967..59a26e5 100644 > --- a/drivers/gpu/drm/exynos/Kconfig > +++ b/drivers/gpu/drm/exynos/Kconfig > @@ -36,6 +36,6 @@ config DRM_EXYNOS_VIDI > > config DRM_EXYNOS_G2D > bool "Exynos DRM G2D" > - depends on DRM_EXYNOS > + depends on DRM_EXYNOS && !VIDEO_SAMSUNG_S5P_G2D > help > Choose this option if you want to use Exynos G2D for DRM. > -- > 1.7.4.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, Aug 21, 2012 at 2:40 AM, Dave Airlie wrote: > So we've had a fair few reports of fbcon handover breakage between > efi/vesafb and i915 surface recently, so I dedicated a couple of > days to finding the problem. > > Essentially the last thing we saw was the conflicting framebuffer > message and that was all. > > So after much tracing with direct netconsole writes (printks > under console_lock not so useful), I think I found the race. > > Thread A (driver load)Thread B (timer thread) > unbind_con_driver -> | > bind_con_driver ->| > vc->vc_sw->con_deinit -> | > fbcon_deinit -> | > console_lock()| > | | > | fbcon_flashcursor timer fires > | console_lock() <- blocked for A > | > | > fbcon_del_cursor_timer -> > del_timer_sync > (BOOM) > > Of course because all of this is under the console lock, > we never see anything, also since we also just unbound the active > console guess what we never see anything. > > Hopefully this fixes the problem for anyone seeing vesafb->kms > driver handoff. > > Signed-off-by: David Airlie > --- > drivers/video/console/fbcon.c |6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index 2e471c2..f8a79fc 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work) > struct vc_data *vc = NULL; > int c; > int mode; > + int ret; > + > + ret = console_trylock(); > + if (ret == 0) > + return; > > - console_lock(); > if (ops && ops->currcon != -1) > vc = vc_cons[ops->currcon].d; > I have a Dell XPS 8300 machine with a Radeon card in it that started showing this problem yesterday with 3.6-rc2 kernels. I tested this patch on top of v3.6-rc2-206-g10c63c9 this morning and the problem seems to have been cleared up for me. That includes making sure the grub2 file has the gfxterm set, etc. I know we've been seeing this quite a bit more on Fedora 17, so we'll want to have some people test a 3.5 build with it but things are looking better. josh -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
-- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On 08/21/2012 07:39 AM, Clark, Rob wrote: On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: Hello! I have been working on prototypes for the ASoC OMAP HDMI audio driver to propagate events from the HDMI output (e.g., display getting enabled/disabled/suspended). This for the users of the driver to react to such events. For instance, if the display is disabled or disconected, audio could be stopped, rerouted or whatever other decision the user makes. This is needed because, if, for instance, the HDMI IP goes off, audio will stall and the audio users will only see a "playback write error (DMA or IRQ trouble?)" In my prototypes I have used snd_soc_jack for this purpose and I have some questions: *I see snd_soc_jack is used mostly for headsets and microphones with actual external mechanical connections. Strictly, in my case I propagate events originated by the OMAP display driver (changes in the power state), and not from external events. Some of these events are generated from an actual HDMI cable connection/disconnection, though. *Maybe the event should be propagated by omapdss/omapdrm/drm and the entity in charge of the audio policy should listen those events instead. *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is feasible for an audio driver to report events from an AV output. I was wondering about how much sense does it make to you guys use a snd_soc_jack in this case? How does DRM handle audio? I made a quick grep, but I see the drm drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? At least for the case of the ASoC HDMI audio driver (but hopefully for other audio drivers as well), it needs to detect whether an HDMI output is available, if the display's current configuration supports audio (e.g., a 1080p display configured as VGA should be reported as not supporting audio). It also needs interfaces to configure/prepare/start/stop audio. Also, of course, needs to know if the display is off/on/suspended and when transitions occur. For OMAP, omapdss provide an interface for this functionality for ALSA or any other interested user. From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Yes, it seems to me that every driver makes its own audio implementation, mainly focused on configuration. I could not find any audio common interface so that users like ALSA can take advantage of. Also, I could not see any ALSA driver using functionality provided by a drm driver. Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support? Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. drm already supports generic edid parsing to check for audio support. This is a good example of how an audio driver could just use that functionality to probe audio support. Ricardo BR, -R If there's a common generic way to handle this, we should obviously use that. But if we need to choose between doing something custom or doing it in omapdrm driver, I think we should go for drm the only solution and forget about audio with omapfb. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 0/5] Generic panel framework
Hi Tomi, On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > Hi Tomi, > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > > used for non-panel devices (at least in theory). The future mipi-dsi-bus > > certainly will. > > They are both display busses. So while they could be used for anything, > I find it quite unlikely as there are much better alternatives for > generic bus needs. My point is that they could be used for display devices other than panels. This is especially true for DSI, as there are DSI to HDMI converters. Technically speaking that's also true for DBI, as DBI chips convert from DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a single panel object. > > Would you be able to send incremental patches on top of v2 to implement > > the solution you have in mind ? It would be neat if you could also > > implement mipi- dsi-bus for the OMAP DSS and test the code with a real > > device :-) > > Yes, I'd like to try this out on OMAP, both DBI and DSI. However, I fear > it'll be quite complex due to the dependencies all around we have in the > current driver. We're working on simplifying things so that it'll be > easier to try thing like the panel framework, though, so we're going in > the right direction. If you want the panel framework to support your use cases I'm afraid you will need to work on that ;-) > > > Generally about locks, if we define that panel ops may only be called > > > exclusively, does it simplify things? I think we can make such > > > requirements, as there should be only one display framework that handles > > > the panel. Then we don't need locking for things like enable/disable. > > > > Pushing locking to callers would indeed simplify panel drivers, but we > > need to make sure we won't need to expose a panel to several callers in > > the future. > > I have a feeling that would be a bad idea. > > Display related stuff are quite sensitive to any delays, so any extra > transactions over, say, DSI bus could cause a noticeable glitch on the > screen. I'm not sure what are all the possible ops that a panel can > offer, but I think all that affect the display or could cause delays > should be handled by one controlling entity (drm or such). The > controlling entity needs to handle locking anyway, so in that sense I > don't think it's an extra burden for it. > > The things that come to my mind that could possibly cause calls to the > panel outside drm: debugfs, sysfs, audio, backlight. Of those, I think > backlight should go through drm. Audio, no idea. debugfs and sysfs > locking needs to be handled by the panel driver, and they are a bit > problematic as I guess having them requires full locking. -- Regards, Laurent Pinchart
3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Tue, Aug 21, 2012 at 8:45 AM, Randy Dunlap wrote: > On 08/19/2012 10:22 PM, Dave Airlie wrote: > >> On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap >> wrote: >>> On 08/17/12 15:55, Dave Airlie wrote: >>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap > wrote: >> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >> >>> for , we have verified cases on inteldrmfb, radeondrmfb, and >>> cirrusdrmfb. >>> >>> This is the last message displayed before the system hangs. This seems >>> to be hitting a large number of users in Fedora, though certainly not >>> everyone. This started happening with the 3.5 updates, and is still an >>> issue. It appears to be a race condition, because various things have >>> allowed boot to continue for some users, though there is no clear work >>> around. Has anyone else run across this? Any ideas. For more >>> background we have the following bugs: >>> >>> inteldrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >>> >>> radeondrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >>> >>> cirrusdrmfb : >>> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >>> >>> It should be noted that the conflicting fb hw usage message is not new, >>> it has been around for a while, but this is the last message seen before >>> the hang. >> >> >> Hi, (adding dri-devel mailing list) >> >> >> I started seeing this problem on 3.5-rc6. >> >> AFAICT, the system is not actually hung, it's just that no output >> is showing up on the real (physical) output device (display) -- it's >> going somewhere else (or to the bit bucket). >> > > Can we bisect this at all? >>> >>> I guess I'll have to try again. My first attempt did not >>> prove anything, I think because the conflict does not happen >>> 100% of the time (i.e., it feels like a timing problem). >>> > I worry the intel one will bisect to where we moved the conflict > resolution earlier, but I'd like to see if applying that patch earlier > causes the issue, since radeon has it. >>> >>> Do you know of a specific commit that I could revert and test? >> >> 9f846a16d213523fbe6daea17e20df6b8ac5a1e5 >> >> might work, but it just changes the timing mostly. >> >> also testing 3.4 with that on top would be good. > > > That commit doesn't apply cleanly to 3.4, but reverting > it on 3.5-rc6 (where I first saw the problem) allows me to boot > 3.5-rc6 multiple times without a problem. > > Maybe Justin can get more stable testing done also.. Randy do you have a vga= on your kernel command line? Dave.
[PATCH v2] drm/exynos: add wait_for_vblank callback interface.
Changelog v2:
fixed comments.
Changelog v1:
this interface can be used to make sure that hardware overlay is disabled
to avoid that memory region is accessed by dma after gem buffer was released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..eec77aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define _wait_for(COND, MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
struct drm_device;
struct exynos_drm_overlay;
struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
* @commit: apply hardware specific overlay data to registers.
* @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * hardware overlay is disabled.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+ void (*wait_for_vblank)(struct device *subdrv_dev);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 08ba62f..f453116 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -430,4 +430,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+ /*
+* wait for vblank interrupt
+* - this makes sure that hardware overlay is disabled to avoid
+* for the dma accesses to memory after gem buffer was released
+* because the setting for disabling the overlay will be updated
+* at vsync.
+*/
+ if (overlay_ops->wait_for_vblank)
+ overlay_ops->wait_for_vblank(manager->dev);
}
--
1.7.4.1
[PATCH v2] drm/exynos: separated subdrv_probe function into two parts.
Changelog v2:
fixed the issue that when sub driver is probed, no kms drivers such as
fimd or hdmi are failed. no kms drivers have no manager so if manager is
null then encoder and connector creation should be ignored.
Changelog v1:
this patch separates exynos_drm_subdrv_probe function into sub driver's probe
call
and encoder/connector creation so that exynos drm core module can take exception
when some operation was failed properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 100 -
1 files changed, 69 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..7b0432b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,33 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
- if (subdrv->probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
- ret = subdrv->probe(dev, subdrv->dev);
- if (ret)
- return ret;
- }
-
- if (!subdrv->manager)
- return 0;
-
subdrv->manager->dev = subdrv->dev;
/* create and initialize a encoder for this sub driver. */
@@ -78,24 +60,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
- encoder->funcs->destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv->encoder = encoder;
subdrv->connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder->funcs->destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
- if (subdrv->remove)
- subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +89,43 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv->probe) {
+ int ret;
+
+ subdrv->drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+ ret = subdrv->probe(dev, subdrv->dev);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (subdrv->remove)
+ subdrv->remove(dev, subdrv->dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +134,36 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
- subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+ continue;
+ }
+
+ /*
+* if manager is null then it means that this sub driver
+* does
[RFC 0/5] Generic panel framework
On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > Hi Tomi, > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it can be > > > used for non-panel devices (at least in theory). The future mipi-dsi-bus > > > certainly will. > > > > They are both display busses. So while they could be used for anything, > > I find it quite unlikely as there are much better alternatives for > > generic bus needs. > > My point is that they could be used for display devices other than panels. > This is especially true for DSI, as there are DSI to HDMI converters. > Technically speaking that's also true for DBI, as DBI chips convert from DBI > to DPI, but we can group both the DBI-to-DPI chip and the panel in a single > panel object. Ah, ok. I thought "panels" would include these buffer/converter chips. I think we should have one driver for one indivisible hardware entity. So if you've got a panel module that contains DBI receiver, buffer memory and a DPI panel, let's just have one "DBI panel" driver for it. If we get lots of different panel modules containing the same DBI RX IP, we could have the DBI IP part as a common library, but still have one panel driver per panel module. But how do you see the case for separate converter/buffer chips? Are they part of the generic panel framework? I guess they kinda have to be. On one side they use the "panel" API control the bus they are connected to, and on the other they offer an API for the connected panel to use the bus they provide. Did you just mean we should have a separate directory for them, while still part of the same framework, or...? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/4be56086/attachment.pgp>
[PATCH] fbcon: fix race condition between console lock and cursor timer
So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load)Thread B (timer thread) unbind_con_driver -> | bind_con_driver ->| vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock()| | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. Signed-off-by: David Airlie --- drivers/video/console/fbcon.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 2e471c2..f8a79fc 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -372,8 +372,12 @@ static void fb_flashcursor(struct work_struct *work) struct vc_data *vc = NULL; int c; int mode; + int ret; + + ret = console_trylock(); + if (ret == 0) + return; - console_lock(); if (ops && ops->currcon != -1) vc = vc_cons[ops->currcon].d; -- 1.7.10.2 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: edid: add support for E-DDC
The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.
To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: Shirish S
---
drivers/gpu/drm/drm_edid.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a8743c3..2c2996e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned
char *buf,
int block, int len)
{
unsigned char start = block * EDID_LENGTH;
+ unsigned char segment = block >> 1;
+ unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
int ret, retries = 5;
/* The core i2c driver will automatically retry the transfer if the
@@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
unsigned char *buf,
*/
do {
struct i2c_msg msgs[] = {
- {
+ { /*set segment pointer */
+ .addr = DDC_SEGMENT_ADDR,
+ .flags = segFlags,
+ .len= 1,
+ .buf= &start,
+ }, { /*set offset */
.addr = DDC_ADDR,
.flags = 0,
.len= 1,
.buf= &start,
- }, {
+ }, { /*set data */
.addr = DDC_ADDR,
.flags = I2C_M_RD,
.len= len,
.buf= buf,
}
};
- ret = i2c_transfer(adapter, msgs, 2);
+ ret = i2c_transfer(adapter, msgs, 3);
if (ret == -ENXIO) {
DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
adapter->name);
break;
}
- } while (ret != 2 && --retries);
+ } while (ret != 3 && --retries);
- return ret == 2 ? 0 : -1;
+ return ret == 3 ? 0 : -1;
}
static bool drm_edid_is_zero(u8 *in_edid, int length)
--
1.7.0.4
[PATCH] drm: edid: add support for E-DDC
This patch adds support in probing 4 block edid data, for E-DDC. This is the first test case in CTS, for HDMI compliance. Based on drm-next branch Shirish S (1): drm: edid: add support for E-DDC drivers/gpu/drm/drm_edid.c | 17 - 1 files changed, 12 insertions(+), 5 deletions(-)
[PATCH] drm/radeon: fix bo creation retry path
On Fre, 2012-07-13 at 07:54 +0200, Michel D?nzer wrote: > On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote: > > From: Jerome Glisse > > > > Retry label was at wrong place in function leading to memory > > leak. > > > > Cc: > > Signed-off-by: Jerome Glisse > > --- > > drivers/gpu/drm/radeon/radeon_object.c |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/radeon/radeon_object.c > > b/drivers/gpu/drm/radeon/radeon_object.c > > index 6ecb200..f71e472 100644 > > --- a/drivers/gpu/drm/radeon/radeon_object.c > > +++ b/drivers/gpu/drm/radeon/radeon_object.c > > @@ -138,7 +138,6 @@ int radeon_bo_create(struct radeon_device *rdev, > > acc_size = ttm_bo_dma_acc_size(&rdev->mman.bdev, size, > >sizeof(struct radeon_bo)); > > > > -retry: > > bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); > > if (bo == NULL) > > return -ENOMEM; > > @@ -152,6 +151,8 @@ retry: > > bo->surface_reg = -1; > > INIT_LIST_HEAD(&bo->list); > > INIT_LIST_HEAD(&bo->va); > > + > > +retry: > > radeon_ttm_placement_from_domain(bo, domain); > > /* Kernel allocation are uninterruptible */ > > down_read(&rdev->pm.mclk_lock); > > Reviewed-by: Michel D?nzer Actually, this is wrong: ttm_bo_init() destroys the BO on failure. So this patch makes the retry path work with freed memory. I see on IRC that this is causing panics with some piglit tests for several people, please submit a patch to revert this. Sorry I didn't remember this when reviewing the patch. :( -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 --- Comment #4 from Michel D?nzer 2012-08-21 08:14:28 --- (In reply to comment #1) > My active graphics card is the Intel one of these: Alan, I think you picked the wrong component. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 31862] 3.4(and earlier): White text blocks shown during boot-up
https://bugzilla.kernel.org/show_bug.cgi?id=31862 Alan changed: What|Removed |Added Component|Video(DRI - non Intel) |Video(DRI - Intel) AssignedTo|drivers_video-dri at kernel-bu |drivers_video-dri-intel at ker |gs.osdl.org |nel-bugs.osdl.org --- Comment #5 from Alan 2012-08-21 09:12:58 --- Indeed - moved. And that would make more sense as there is another 'squares' report. in i915 space. Wonder if someone isn't always clearing up sprites and overlays ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC 0/5] Generic panel framework
Hi Tomi, On Tuesday 21 August 2012 08:49:57 Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 01:29 +0200, Laurent Pinchart wrote: > > On Monday 20 August 2012 14:39:30 Tomi Valkeinen wrote: > > > On Sat, 2012-08-18 at 03:16 +0200, Laurent Pinchart wrote: > > > > Hi Tomi, > > > > > > > > mipi-dbi-bus might not belong to include/video/panel/ though, as it > > > > can be used for non-panel devices (at least in theory). The future > > > > mipi-dsi-bus certainly will. > > > > > > They are both display busses. So while they could be used for anything, > > > I find it quite unlikely as there are much better alternatives for > > > generic bus needs. > > > > My point is that they could be used for display devices other than panels. > > This is especially true for DSI, as there are DSI to HDMI converters. > > Technically speaking that's also true for DBI, as DBI chips convert from > > DBI to DPI, but we can group both the DBI-to-DPI chip and the panel in a > > single panel object. > > Ah, ok. I thought "panels" would include these buffer/converter chips. > > I think we should have one driver for one indivisible hardware entity. > So if you've got a panel module that contains DBI receiver, buffer > memory and a DPI panel, let's just have one "DBI panel" driver for it. > > If we get lots of different panel modules containing the same DBI RX IP, > we could have the DBI IP part as a common library, but still have one > panel driver per panel module. Sounds good to me. > But how do you see the case for separate converter/buffer chips? Are > they part of the generic panel framework? I guess they kinda have to be. > On one side they use the "panel" API control the bus they are connected > to, and on the other they offer an API for the connected panel to use > the bus they provide. The DBI/DSI APIs will not be panel-specific (they won't contain any reference to "panel") I'm thus thinking of moving them from drivers/video/panel/ to drivers/video/. Furthermore, a DSI-to-HDMI converter chip is not a panel, but needs to expose display-related operations in a way similar to panels. I was thus wondering if we shouldn't replace the panel structure with some kind of video entity structure that would expose operations similar to panels. We could then extend that structure with converter-specific operations later. The framework would become a bit more generic, while remaining display-specific. > Did you just mean we should have a separate directory for them, while > still part of the same framework, or...? -- Regards, Laurent Pinchart
[PATCH] fbcon: fix race condition between console lock and cursor timer
> So after much tracing with direct netconsole writes (printks > under console_lock not so useful), I think I found the race. Direct netconsole write would be a useful patch to have mainline I think 8) > Hopefully this fixes the problem for anyone seeing vesafb->kms > driver handoff. Not really the proper fix but its clear and is probably the best thing to go in initially with a cc: stable. Can you at least stick a large + /* FIXME: we should sort out the unbind locking instead */ on the patch however. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Tomasz,
Thanks for the patch.
Just a couple of small comments below.
On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> This patch adds support for exporting a dma-contig buffer using
> DMABUF interface.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf2-dma-contig.c | 204 +
> 1 file changed, 204 insertions(+)
>
> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8 100644
> --- a/drivers/media/video/videobuf2-dma-contig.c
> +++ b/drivers/media/video/videobuf2-dma-contig.c
[snip]
> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> +{
> + struct vb2_dc_attachment *attach = db_attach->priv;
> + /* stealing dmabuf mutex to serialize map/unmap operations */
Why isn't this operation serialized by the dma-buf core itself ?
> + struct mutex *lock = &db_attach->dmabuf->lock;
> + struct sg_table *sgt;
> + int ret;
> +
> + mutex_lock(lock);
> +
> + sgt = &attach->sgt;
> + /* return previously mapped sg table */
> + if (attach->dir == dir) {
> + mutex_unlock(lock);
> + return sgt;
> + }
> +
> + /* release any previous cache */
> + if (attach->dir != DMA_NONE) {
> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> + attach->dir);
> + attach->dir = DMA_NONE;
> + }
> +
> + /* mapping to the client with new direction */
> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> + if (ret <= 0) {
> + pr_err("failed to map scatterlist\n");
> + mutex_unlock(lock);
> + return ERR_PTR(-EIO);
> + }
> +
> + attach->dir = dir;
> +
> + mutex_unlock(lock);
> +
> + return sgt;
> +}
[snip]
> +static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
> + struct vm_area_struct *vma)
> +{
> + /* Dummy support for mmap */
> + return -ENOTTY;
What about calling the dma-contig mmap handler here ? Is there a specific
reason why you haven't implemented mmap support for dmabuf ?
> +}
> +
> +static struct dma_buf_ops vb2_dc_dmabuf_ops = {
> + .attach = vb2_dc_dmabuf_ops_attach,
> + .detach = vb2_dc_dmabuf_ops_detach,
> + .map_dma_buf = vb2_dc_dmabuf_ops_map,
> + .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> + .kmap = vb2_dc_dmabuf_ops_kmap,
> + .kmap_atomic = vb2_dc_dmabuf_ops_kmap,
> + .vmap = vb2_dc_dmabuf_ops_vmap,
> + .mmap = vb2_dc_dmabuf_ops_mmap,
> + .release = vb2_dc_dmabuf_ops_release,
> +};
> +
> +static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
> +{
> + int ret;
> + struct sg_table *sgt;
> +
> + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
> + if (!sgt) {
> + dev_err(buf->dev, "failed to alloc sg table\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + ret = dma_get_sgtable(buf->dev, sgt, buf->vaddr, buf->dma_addr,
> + buf->size);
> + if (ret < 0) {
> + dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
> + kfree(sgt);
> + return ERR_PTR(ret);
> + }
As this function is only used below, where the exact value of the error code
is ignored, what about just returning NULL on failure ? Another option is to
return the error code in vb2_dc_get_dmabuf (not sure if that would be useful
though).
> +
> + return sgt;
> +}
> +
> +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
> +{
> + struct vb2_dc_buf *buf = buf_priv;
> + struct dma_buf *dbuf;
> + struct sg_table *sgt = buf->sgt_base;
> +
> + if (!sgt)
> + sgt = vb2_dc_get_base_sgt(buf);
> + if (WARN_ON(IS_ERR(sgt)))
> + return NULL;
> +
> + /* cache base sgt for future use */
> + buf->sgt_base = sgt;
You can move this assignment inside the first if, there's no need to execute
it every time. The WARN_ON can also be moved inside the first if, as buf-
>sgt_base will either be NULL or valid. You can then get rid of the sgt
variable initialization by testing if (!buf->sgt_base).
> + dbuf = dma_buf_export(buf, &vb2_dc_dmabuf_ops, buf->size, 0);
> + if (IS_ERR(dbuf))
> + return NULL;
> +
> + /* dmabuf keeps reference to vb2 buffer */
> + atomic_inc(&buf->refcount);
> +
> + return dbuf;
> +}
--
Regards,
Laurent Pinchart
[PATCH] drm: edid: add support for E-DDC
Am Dienstag, den 21.08.2012, 12:40 +0530 schrieb Shirish S: > The current logic for probing ddc is limited to > 2 blocks (256 bytes), this patch adds support > for the 4 block (512) data. > > To do this, a single 8-bit segment index is > passed to the display via the I2C address 30h. > Data from the selected segment is then immediately > read via the regular DDC2 address using a repeated > I2C 'START' signal. > > Signed-off-by: Shirish S Please add your full last name, if there is no reason not to, and resend as [PATCH v2]. > --- > drivers/gpu/drm/drm_edid.c | 17 - > 1 files changed, 12 insertions(+), 5 deletions(-) [?] Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/b4d7be94/attachment.pgp>
[PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> The current logic for probing ddc is limited to
> 2 blocks (256 bytes), this patch adds support
> for the 4 block (512) data.
>
> To do this, a single 8-bit segment index is
> passed to the display via the I2C address 30h.
> Data from the selected segment is then immediately
> read via the regular DDC2 address using a repeated
> I2C 'START' signal.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/drm/drm_edid.c | 17 -
> 1 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..2c2996e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> int block, int len)
> {
> unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
Have you tested this on i915 with gmbus enabled? I'm asking since we
don't implement the IGNORE_NAK flag and hence I'd expect spurious
failures on displays that don't support E-DDC ...
Cheers, Daniel
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> */
> do {
> struct i2c_msg msgs[] = {
> - {
> + { /*set segment pointer */
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = segFlags,
> + .len= 1,
> + .buf= &start,
> + }, { /*set offset */
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> .buf= &start,
> - }, {
> + }, { /*set data */
> .addr = DDC_ADDR,
> .flags = I2C_M_RD,
> .len= len,
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> + ret = i2c_transfer(adapter, msgs, 3);
> if (ret == -ENXIO) {
> DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> adapter->name);
> break;
> }
> - } while (ret != 2 && --retries);
> + } while (ret != 3 && --retries);
>
> - return ret == 2 ? 0 : -1;
> + return ret == 3 ? 0 : -1;
> }
>
> static bool drm_edid_is_zero(u8 *in_edid, int length)
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[PATCH] drm: edid: add support for E-DDC
On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > The current logic for probing ddc is limited to > 2 blocks (256 bytes), this patch adds support > for the 4 block (512) data. A patch for this was already sent a long time ago: http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html -- Ville Syrj?l? Intel OTC
[pull] drm-intel-fixes
Hi Dave, Nothing too major: - A few fixes around the edid handling from Jani, also fixing a regression in 3.5 due to us using gmbus by default. - Fixup hsw uncached pte flags. - Fix suspend/resume crash when using hw contexts, from Ben. - Try to tune gpu turbo a bit better, seems to help with some oddball power regressions. Also nothing major outstanding afaik. Cheers, Daniel The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c: drm/i915: use hsw rps tuning values everywhere on gen6+ (2012-08-20 20:49:19 +0200) Ben Widawsky (1): drm/i915/contexts: fix list corruption Daniel Vetter (2): drm/i915: fix hsw uncached pte drm/i915: use hsw rps tuning values everywhere on gen6+ Jani Nikula (3): drm/i915: fix EDID memory leak in SDVO drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads drivers/char/agp/intel-agp.h|1 + drivers/char/agp/intel-gtt.c| 105 +++ drivers/gpu/drm/i915/i915_gem.c |8 +-- drivers/gpu/drm/i915/i915_gem_gtt.c |5 +- drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_crt.c| 36 +++- drivers/gpu/drm/i915/intel_drv.h|2 + drivers/gpu/drm/i915/intel_modes.c | 31 --- drivers/gpu/drm/i915/intel_pm.c | 15 ++--- drivers/gpu/drm/i915/intel_sdvo.c |1 + 10 files changed, 141 insertions(+), 64 deletions(-) -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
make VM handling async v2
On 20.08.2012 20:58, Alex Deucher wrote: > On Mon, Aug 20, 2012 at 4:08 AM, Christian K?nig > wrote: >> Second and hopefully last round for this patchset. >> >> v2: Fix suspend/resume, and incorporate Jeromes comments. > Looks good to me. Can you put up a git branch somewhere? Sure: git://people.freedesktop.org/~deathsimple/linux wip Christian. > > Reviewed-by: Alex Deucher > > >> Cheers, >> Christian. >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/0f6526f4/attachment.html>
[PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Laurent,
Thank you for your comments.
On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> Hi Tomasz,
>
> Thanks for the patch.
>
> Just a couple of small comments below.
>
> On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
>> This patch adds support for exporting a dma-contig buffer using
>> DMABUF interface.
>>
>> Signed-off-by: Tomasz Stanislawski
>> Signed-off-by: Kyungmin Park
>> ---
>> drivers/media/video/videobuf2-dma-contig.c | 204 +
>> 1 file changed, 204 insertions(+)
>>
>> diff --git a/drivers/media/video/videobuf2-dma-contig.c
>> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8 100644
>> --- a/drivers/media/video/videobuf2-dma-contig.c
>> +++ b/drivers/media/video/videobuf2-dma-contig.c
>
> [snip]
>
>> +static struct sg_table *vb2_dc_dmabuf_ops_map(
>> +struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
>> +{
>> +struct vb2_dc_attachment *attach = db_attach->priv;
>> +/* stealing dmabuf mutex to serialize map/unmap operations */
>
> Why isn't this operation serialized by the dma-buf core itself ?
>
Indeed, it is a very good question. The lock was introduced in RFCv3 of
DMABUF patches. It was dedicated to serialize attach/detach calls.
No requirements for map/unmap serialization were stated so serialization
was delegated to an exporter.
A deadlock could occur if dma_map_attachment is called from inside
of attach ops. IMO, such an operation is invalid because an attachment
list is not in a valid state while attach ops is being processed.
Do you think that stealing a lock from dma-buf internals is too hacky?
I prefer not to introduce any extra locks in dma-contig allocator
but it is not a big deal to add it.
>> +struct mutex *lock = &db_attach->dmabuf->lock;
>> +struct sg_table *sgt;
>> +int ret;
>> +
>> +mutex_lock(lock);
>> +
>> +sgt = &attach->sgt;
>> +/* return previously mapped sg table */
>> +if (attach->dir == dir) {
>> +mutex_unlock(lock);
>> +return sgt;
>> +}
>> +
>> +/* release any previous cache */
>> +if (attach->dir != DMA_NONE) {
>> +dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
>> +attach->dir);
>> +attach->dir = DMA_NONE;
>> +}
>> +
>> +/* mapping to the client with new direction */
>> +ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
>> +if (ret <= 0) {
>> +pr_err("failed to map scatterlist\n");
>> +mutex_unlock(lock);
>> +return ERR_PTR(-EIO);
>> +}
>> +
>> +attach->dir = dir;
>> +
>> +mutex_unlock(lock);
>> +
>> +return sgt;
>> +}
>
> [snip]
>
>> +static int vb2_dc_dmabuf_ops_mmap(struct dma_buf *dbuf,
>> +struct vm_area_struct *vma)
>> +{
>> +/* Dummy support for mmap */
>> +return -ENOTTY;
>
> What about calling the dma-contig mmap handler here ? Is there a specific
> reason why you haven't implemented mmap support for dmabuf ?
>
The mmap ops is mandatory in the latest DMABUF api.
I added a stub function to make DC work with DMABUF without any big effort.
Calling vb2_dc_mmap from mmap ops seams to be a simple and safe way to
handle mmap functionality. Thank you for spotting this :)
>> +}
>> +
>> +static struct dma_buf_ops vb2_dc_dmabuf_ops = {
>> +.attach = vb2_dc_dmabuf_ops_attach,
>> +.detach = vb2_dc_dmabuf_ops_detach,
>> +.map_dma_buf = vb2_dc_dmabuf_ops_map,
>> +.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
>> +.kmap = vb2_dc_dmabuf_ops_kmap,
>> +.kmap_atomic = vb2_dc_dmabuf_ops_kmap,
>> +.vmap = vb2_dc_dmabuf_ops_vmap,
>> +.mmap = vb2_dc_dmabuf_ops_mmap,
>> +.release = vb2_dc_dmabuf_ops_release,
>> +};
>> +
>> +static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
>> +{
>> +int ret;
>> +struct sg_table *sgt;
>> +
>> +sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
>> +if (!sgt) {
>> +dev_err(buf->dev, "failed to alloc sg table\n");
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +ret = dma_get_sgtable(buf->dev, sgt, buf->vaddr, buf->dma_addr,
>> +buf->size);
>> +if (ret < 0) {
>> +dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
>> +kfree(sgt);
>> +return ERR_PTR(ret);
>> +}
>
> As this function is only used below, where the exact value of the error code
> is ignored, what about just returning NULL on failure ? Another option is to
> return the error code in vb2_dc_get_dmabuf (not sure if that would be useful
> though).
>
>> +
>> +return sgt;
>> +}
>> +
>> +static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
>> +{
>> +struct vb2_dc_buf *buf = buf_priv;
>> +struct dma_buf *dbuf;
>> +struct sg_table *sgt = buf->sgt_base;
>> +
>> +if (!sgt)
>> +sgt = vb2_dc_get_base_sgt(buf);
>> +if (WARN_ON(IS_ERR(sgt)))
>> +return NULL;
>> +
>> +/* cache base
radeon testing
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote:
> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
>> > I just tested the rebased acpi_patches branch: ACPI part works fine, but
>> > I see a big slow down during radeon driver initialization when the
>> > screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
>> > screen just flickers during boot). With initcall_debug I see:
>> >
>> > [2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
>> > ...
>> > [5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
>> > 3102147 usecs
>> >
>> > For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
>> > very
>> > informative, I'll try and get more info...
>>
>> Can you bisect?
>
> I've put in some printk, this is the result:
>
> [2.403138] evergreen_mc_program
> [2.403196] evergreen_mc_stop
> ...
> [4.268491] evergreen_mc_resume done
> [4.268548] evergreen_mc_program done
>
> This is the patch:
>
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
> u32 tmp;
> int i, j;
>
> + printk(KERN_INFO "%s\n", __func__);
> +
> /* Initialize HDP */
> for (i = 0, j = 0; i < 32; i++, j += 0x18) {
> WREG32((0x2c14 + j), 0x);
> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
> }
> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
>
> + printk(KERN_INFO "evergreen_mc_stop\n");
> evergreen_mc_stop(rdev, &save);
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
> +
> /* Lockout access through VGA aperture*/
> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
> /* Update configuration */
> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
> WREG32(MC_VM_AGP_TOP, 0x0FFF);
> WREG32(MC_VM_AGP_BOT, 0x0FFF);
> }
> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
> if (evergreen_mc_wait_for_idle(rdev)) {
> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
> }
> +// printk(KERN_INFO "evergreen_mc_resume\n");
> evergreen_mc_resume(rdev, &save);
> + printk(KERN_INFO "evergreen_mc_resume done\n");
> /* we need to own VRAM, so turn off the VGA renderer here
> * to stop it overwriting our objects */
> rv515_vga_render_disable(rdev);
>
>
> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
> the machine. The likely culprit is commit 023e188e:
yeah, vram is locked out at that point. I guess we probably need to
block anyone from trying to access it.
>
> commit 023e188ec102330eb05ad264f675e869637478eb
> Author: Alex Deucher
> Date: Wed Aug 15 17:18:42 2012 -0400
>
> drm/radeon: properly handle mc_stop/mc_resume on evergreen+
>
> - Stop the displays from accessing the FB
> - Block CPU access
> - Turn off MC client access
>
> This should fix issues some users have seen, especially
> with UEFI, when changing the MC FB location that result
> in hangs or display corruption.
>
>
>
> I haven't tried backing out the commit yet, but looking at the diff I
> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
> but evergreen_mc_program is called way before IRQ is set up. Is the
> vblank counter running? Looks like we just hitting the timeout here...
>
We aren't waiting for an interrupt, just polling the current crtc
status until it enters the vblank region. The status and counters
should be working as we only wait on displays that are enabled. I'll
double check the code however. Thanks for testing.
Alex
>
>
>
> Luca
[PATCH] drm: edid: add support for E-DDC
Hello Daniel,
On Tue, Aug 21, 2012 at 4:18 AM, Daniel Vetter wrote:
> On Tue, Aug 21, 2012 at 9:10 AM, Shirish S wrote:
> > The current logic for probing ddc is limited to
> > 2 blocks (256 bytes), this patch adds support
> > for the 4 block (512) data.
> >
> > To do this, a single 8-bit segment index is
> > passed to the display via the I2C address 30h.
> > Data from the selected segment is then immediately
> > read via the regular DDC2 address using a repeated
> > I2C 'START' signal.
> >
> > Signed-off-by: Shirish S
> > ---
> > drivers/gpu/drm/drm_edid.c | 17 -
> > 1 files changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index a8743c3..2c2996e 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -254,6 +254,8 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > int block, int len)
> > {
> > unsigned char start = block * EDID_LENGTH;
> > + unsigned char segment = block >> 1;
> > + unsigned short segFlags = segment ? 0 : I2C_M_IGNORE_NAK;
>
> Have you tested this on i915 with gmbus enabled? I'm asking since we
> don't implement the IGNORE_NAK flag and hence I'd expect spurious
> failures on displays that don't support E-DDC ...
>
> I have verified this on samsung exynos5 platform, and it passed the HDMI
compliance test for the same.
I also verified this on HDMI analyser- Agilent N5988A , this analyser
does not support 4 block EDID data(EDDC),
it passed in this analyser as well.
Is there any specific reason why you dont implement IGNORE_NAK?
Infact if i think for EDDC, if one does not pass IGNORE_NAK flag it might
give errors.
> Cheers, Daniel
>
> > int ret, retries = 5;
> >
> > /* The core i2c driver will automatically retry the transfer if
> the
> > @@ -264,27 +266,32 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
> unsigned char *buf,
> > */
> > do {
> > struct i2c_msg msgs[] = {
> > - {
> > + { /*set segment pointer */
> > + .addr = DDC_SEGMENT_ADDR,
> > + .flags = segFlags,
> > + .len= 1,
> > + .buf= &start,
> > + }, { /*set offset */
> > .addr = DDC_ADDR,
> > .flags = 0,
> > .len= 1,
> > .buf= &start,
> > - }, {
> > + }, { /*set data */
> > .addr = DDC_ADDR,
> > .flags = I2C_M_RD,
> > .len= len,
> > .buf= buf,
> > }
> > };
> > - ret = i2c_transfer(adapter, msgs, 2);
> > + ret = i2c_transfer(adapter, msgs, 3);
> > if (ret == -ENXIO) {
> > DRM_DEBUG_KMS("drm: skipping non-existent
> adapter %s\n",
> > adapter->name);
> > break;
> > }
> > - } while (ret != 2 && --retries);
> > + } while (ret != 3 && --retries);
> >
> > - return ret == 2 ? 0 : -1;
> > + return ret == 3 ? 0 : -1;
> > }
> >
> > static bool drm_edid_is_zero(u8 *in_edid, int length)
> > --
> > 1.7.0.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Regards,
Shirish S
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/4dff7d91/attachment-0001.html>
[PATCH] drm: edid: add support for E-DDC
Hello Ville Syrj?l?, On Tue, Aug 21, 2012 at 4:26 AM, Ville Syrj?l? < ville.syrjala at linux.intel.com> wrote: > On Tue, Aug 21, 2012 at 12:40:48PM +0530, Shirish S wrote: > > The current logic for probing ddc is limited to > > 2 blocks (256 bytes), this patch adds support > > for the 4 block (512) data. > > A patch for this was already sent a long time ago: > http://lists.freedesktop.org/archives/dri-devel/2011-December/017246.html > > I tried the patch you have mentioned,but its not working in my setup. Also did anyone else test this!! I find that although the author asks the i2c to read for 3 msgs, it verifies only for 2.Kindly correct me if i am wrong. My patch i have verified on the analyser for exynos5 platform. > -- > Ville Syrj?l? > Intel OTC > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Regards, Shirish S -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/c0b7ae13/attachment.html>
[PATCHv8 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Tomasz,
On Tuesday 21 August 2012 15:47:13 Tomasz Stanislawski wrote:
> On 08/21/2012 12:03 PM, Laurent Pinchart wrote:
> > On Tuesday 14 August 2012 17:34:50 Tomasz Stanislawski wrote:
> >> This patch adds support for exporting a dma-contig buffer using
> >> DMABUF interface.
> >>
> >> Signed-off-by: Tomasz Stanislawski
> >> Signed-off-by: Kyungmin Park
> >> ---
> >>
> >> drivers/media/video/videobuf2-dma-contig.c | 204 ++
> >> 1 file changed, 204 insertions(+)
> >>
> >> diff --git a/drivers/media/video/videobuf2-dma-contig.c
> >> b/drivers/media/video/videobuf2-dma-contig.c index 7fc71a0..bb2b4ac8
> >> 100644
> >> --- a/drivers/media/video/videobuf2-dma-contig.c
> >> +++ b/drivers/media/video/videobuf2-dma-contig.c
> >
> > [snip]
> >
> >> +static struct sg_table *vb2_dc_dmabuf_ops_map(
> >> + struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
> >> +{
> >> + struct vb2_dc_attachment *attach = db_attach->priv;
> >> + /* stealing dmabuf mutex to serialize map/unmap operations */
> >
> > Why isn't this operation serialized by the dma-buf core itself ?
>
> Indeed, it is a very good question. The lock was introduced in RFCv3 of
> DMABUF patches. It was dedicated to serialize attach/detach calls.
> No requirements for map/unmap serialization were stated so serialization
> was delegated to an exporter.
>
> A deadlock could occur if dma_map_attachment is called from inside
> of attach ops. IMO, such an operation is invalid because an attachment
> list is not in a valid state while attach ops is being processed.
>
> Do you think that stealing a lock from dma-buf internals is too hacky?
No, I would be OK with that, but I'd like to make sure that it won't bite us
back later. If there's a specific reason why the lock is not taken by the
dmabuf core around map/unmap calls, stealing the same lock might cause
unforeseen problems. That's why I would like to understand why the core
doesn't perform locking on its own.
> I prefer not to introduce any extra locks in dma-contig allocator
Agreed.
> but it is not a big deal to add it.
>
> >> + struct mutex *lock = &db_attach->dmabuf->lock;
> >> + struct sg_table *sgt;
> >> + int ret;
> >> +
> >> + mutex_lock(lock);
> >> +
> >> + sgt = &attach->sgt;
> >> + /* return previously mapped sg table */
> >> + if (attach->dir == dir) {
> >> + mutex_unlock(lock);
> >> + return sgt;
> >> + }
> >> +
> >> + /* release any previous cache */
> >> + if (attach->dir != DMA_NONE) {
> >> + dma_unmap_sg(db_attach->dev, sgt->sgl, sgt->orig_nents,
> >> + attach->dir);
> >> + attach->dir = DMA_NONE;
> >> + }
> >> +
> >> + /* mapping to the client with new direction */
> >> + ret = dma_map_sg(db_attach->dev, sgt->sgl, sgt->orig_nents, dir);
> >> + if (ret <= 0) {
> >> + pr_err("failed to map scatterlist\n");
> >> + mutex_unlock(lock);
> >> + return ERR_PTR(-EIO);
> >> + }
> >> +
> >> + attach->dir = dir;
> >> +
> >> + mutex_unlock(lock);
> >> +
> >> + return sgt;
> >> +}
--
Regards,
Laurent Pinchart
[PATCH 1/3] drm: Add missing static storage class specifiers in drm_proc.c file
Hi,
Any comments on this series?
On 1 August 2012 17:15, Sachin Kamat wrote:
> Fixes the following sparse warning:
> drivers/gpu/drm/drm_proc.c:92:5:
> warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
> drivers/gpu/drm/drm_proc.c:175:5:
> warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/drm_proc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
> index 371c695..da457b1 100644
> --- a/drivers/gpu/drm/drm_proc.c
> +++ b/drivers/gpu/drm/drm_proc.c
> @@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
> * Create a given set of proc files represented by an array of
> * gdm_proc_lists in the given root directory.
> */
> -int drm_proc_create_files(struct drm_info_list *files, int count,
> +static int drm_proc_create_files(struct drm_info_list *files, int count,
> struct proc_dir_entry *root, struct drm_minor
> *minor)
> {
> struct drm_device *dev = minor->dev;
> @@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
> return 0;
> }
>
> -int drm_proc_remove_files(struct drm_info_list *files, int count,
> +static int drm_proc_remove_files(struct drm_info_list *files, int count,
> struct drm_minor *minor)
> {
> struct list_head *pos, *q;
> --
> 1.7.4.1
>
--
With warm regards,
Sachin
[RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 1:01 AM, Tomi Valkeinen wrote: > On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote: >> Hello! >> >> I have been working on prototypes for the ASoC OMAP HDMI audio driver to >> propagate events from the HDMI output (e.g., display getting >> enabled/disabled/suspended). This for the users of the driver to react >> to such events. For instance, if the display is disabled or disconected, >> audio could be stopped, rerouted or whatever other decision the user >> makes. This is needed because, if, for instance, the HDMI IP goes off, >> audio will stall and the audio users will only see a "playback write >> error (DMA or IRQ trouble?)" >> >> In my prototypes I have used snd_soc_jack for this purpose and I have >> some questions: >> >> *I see snd_soc_jack is used mostly for headsets and microphones with >> actual external mechanical connections. Strictly, in my case I propagate >> events originated by the OMAP display driver (changes in the power >> state), and not from external events. Some of these events are generated >> from an actual HDMI cable connection/disconnection, though. >> >> *Maybe the event should be propagated by omapdss/omapdrm/drm and the >> entity in charge of the audio policy should listen those events instead. >> >> *I do see SND_JACK_VIDEOOUT and SND_JACK_AVOUT types so maybe it is >> feasible for an audio driver to report events from an AV output. >> >> I was wondering about how much sense does it make to you guys use a >> snd_soc_jack in this case? > > How does DRM handle audio? I made a quick grep, but I see the drm > drivers only enabling the audio in the HW, nothing else. I confess to not knowing too much about audio/alsa, but what does audio driver need from hdmi? Just hotplug events? >From a quick look, it seems most of what the existing drm drivers are doing is detecting if the display supports audio, and then turning on/off the hw.. (and some infoframe stuff in some cases). Does ASoC support 'hotplug' of audio devices? If so, maybe it makes some sense to have some support in drm core. At least all the edid parsing stuff to determine if the display supports audio should be generic and not driver specific. BR, -R > If there's a common generic way to handle this, we should obviously use > that. But if we need to choose between doing something custom or doing > it in omapdrm driver, I think we should go for drm the only solution and > forget about audio with omapfb. > > Tomi >
[RFC] ASoC: snd_soc_jack for HDMI audio: does it make sense?
On Tue, Aug 21, 2012 at 07:39:55AM -0500, Clark, Rob wrote: > Does ASoC support 'hotplug' of audio devices? If so, maybe it makes > some sense to have some support in drm core. At least all the edid > parsing stuff to determine if the display supports audio should be > generic and not driver specific. Not really (except on a card level), and it'd probably confuse most userspaces. What I'd expect to happen currently is that the current state of the connector would get reported via extcon. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120821/3900444c/attachment.pgp>
[PATCH] drm/radeon: fix bo creation retry path
On Tue, Aug 21, 2012 at 3:03 AM, Michel D?nzer wrote: > On Fre, 2012-07-13 at 07:54 +0200, Michel D?nzer wrote: >> On Don, 2012-07-12 at 18:23 -0400, j.glisse at gmail.com wrote: >> > From: Jerome Glisse >> > >> > Retry label was at wrong place in function leading to memory >> > leak. >> > >> > Cc: >> > Signed-off-by: Jerome Glisse >> > --- >> > drivers/gpu/drm/radeon/radeon_object.c |3 ++- >> > 1 file changed, 2 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/radeon/radeon_object.c >> > b/drivers/gpu/drm/radeon/radeon_object.c >> > index 6ecb200..f71e472 100644 >> > --- a/drivers/gpu/drm/radeon/radeon_object.c >> > +++ b/drivers/gpu/drm/radeon/radeon_object.c >> > @@ -138,7 +138,6 @@ int radeon_bo_create(struct radeon_device *rdev, >> > acc_size = ttm_bo_dma_acc_size(&rdev->mman.bdev, size, >> >sizeof(struct radeon_bo)); >> > >> > -retry: >> > bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL); >> > if (bo == NULL) >> > return -ENOMEM; >> > @@ -152,6 +151,8 @@ retry: >> > bo->surface_reg = -1; >> > INIT_LIST_HEAD(&bo->list); >> > INIT_LIST_HEAD(&bo->va); >> > + >> > +retry: >> > radeon_ttm_placement_from_domain(bo, domain); >> > /* Kernel allocation are uninterruptible */ >> > down_read(&rdev->pm.mclk_lock); >> >> Reviewed-by: Michel D?nzer > > Actually, this is wrong: ttm_bo_init() destroys the BO on failure. So > this patch makes the retry path work with freed memory. I see on IRC > that this is causing panics with some piglit tests for several people, > please submit a patch to revert this. > > Sorry I didn't remember this when reviewing the patch. :( Reverted in my -fixes queue. Alex
radeon testing
On 21.08.2012 15:51, Alex Deucher wrote:
> On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti
> wrote:
>> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote:
I just tested the rebased acpi_patches branch: ACPI part works fine, but
I see a big slow down during radeon driver initialization when the
screen goes black for a couple of seconds (with 3.5.0 + acpi patches the
screen just flickers during boot). With initcall_debug I see:
[2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552
...
[5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after
3102147 usecs
For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not
very
informative, I'll try and get more info...
>>> Can you bisect?
>> I've put in some printk, this is the result:
>>
>> [2.403138] evergreen_mc_program
>> [2.403196] evergreen_mc_stop
>> ...
>> [4.268491] evergreen_mc_resume done
>> [4.268548] evergreen_mc_program done
>>
>> This is the patch:
>>
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> u32 tmp;
>> int i, j;
>>
>> + printk(KERN_INFO "%s\n", __func__);
>> +
>> /* Initialize HDP */
>> for (i = 0, j = 0; i < 32; i++, j += 0x18) {
>> WREG32((0x2c14 + j), 0x);
>> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> }
>> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0);
>>
>> + printk(KERN_INFO "evergreen_mc_stop\n");
>> evergreen_mc_stop(rdev, &save);
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
>> if (evergreen_mc_wait_for_idle(rdev)) {
>> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
>> }
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n");
>> +
>> /* Lockout access through VGA aperture*/
>> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE);
>> /* Update configuration */
>> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev)
>> WREG32(MC_VM_AGP_TOP, 0x0FFF);
>> WREG32(MC_VM_AGP_BOT, 0x0FFF);
>> }
>> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n");
>> if (evergreen_mc_wait_for_idle(rdev)) {
>> dev_warn(rdev->dev, "Wait for MC idle timedout !\n");
>> }
>> +// printk(KERN_INFO "evergreen_mc_resume\n");
>> evergreen_mc_resume(rdev, &save);
>> + printk(KERN_INFO "evergreen_mc_resume done\n");
>> /* we need to own VRAM, so turn off the VGA renderer here
>> * to stop it overwriting our objects */
>> rv515_vga_render_disable(rdev);
>>
>>
>> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up
>> the machine. The likely culprit is commit 023e188e:
> yeah, vram is locked out at that point. I guess we probably need to
> block anyone from trying to access it.
IIRC we have a rw-semaphore that you can writelock to prevent anything
from accessing vram.
But if you try to access VRAM from within the critical section (by using
a printk that tries to write something to the console) you probably end
up deadlocking the kernel.
Christian.
>
>> commit 023e188ec102330eb05ad264f675e869637478eb
>> Author: Alex Deucher
>> Date: Wed Aug 15 17:18:42 2012 -0400
>>
>> drm/radeon: properly handle mc_stop/mc_resume on evergreen+
>>
>> - Stop the displays from accessing the FB
>> - Block CPU access
>> - Turn off MC client access
>>
>> This should fix issues some users have seen, especially
>> with UEFI, when changing the MC FB location that result
>> in hangs or display corruption.
>>
>>
>>
>> I haven't tried backing out the commit yet, but looking at the diff I
>> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter,
>> but evergreen_mc_program is called way before IRQ is set up. Is the
>> vblank counter running? Looks like we just hitting the timeout here...
>>
> We aren't waiting for an interrupt, just polling the current crtc
> status until it enters the vblank region. The status and counters
> should be working as we only wait on displays that are enabled. I'll
> double check the code however. Thanks for testing.
>
> Alex
>
>>
>>
>>
>> Luca
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, 2012-08-21 at 10:15 +0100, Alan Cox wrote: > > So after much tracing with direct netconsole writes (printks > > under console_lock not so useful), I think I found the race. > > Direct netconsole write would be a useful patch to have mainline I think > 8) could we make that use the earlyprintk infrastructure? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fbcon: fix race condition between console lock and cursor timer
On Tue, 2012-08-21 at 16:40 +1000, Dave Airlie wrote: > So after much tracing with direct netconsole writes (printks > under console_lock not so useful) I always use earlyprintk on serial.. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 53884] New: gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884
Bug #: 53884
Summary: gl_FragCoord gets corrupted in some camera angles
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: curaga at operamail.com
Created attachment 65891
--> https://bugs.freedesktop.org/attachment.cgi?id=65891
Screenshot of the issue, bad camera angle
In certain camera angles, gl_FragCoord.xy seem to have bogus/corrupted values.
I tried to make a simple example but couldn't, so uploading an apitrace of the
bigger app and screenshots. The apitrace is 60mb XZ-compressed, that's why the
need to use a third-party service - upload limits here.
This shader:
void main() {
gl_FragColor = vec4(gl_FragCoord.xy / vec2(640, 480), 0.0, 0.0);
}
should always create values from 0 to 1 in a window of that size. In the
apitrace the only difference is that the size is passed in an uniform.
This bug happens on both r600g and llvmpipe. I didn't have the patience to wait
for softpipe to render it. I don't have anything else on this machine to
compare to (swrast, blobs).
Mesa 8.0.3
Linux 3.2.23
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[Bug 53884] gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884 --- Comment #1 from Lauri Kasanen 2012-08-21 14:43:19 UTC --- Created attachment 65892 --> https://bugs.freedesktop.org/attachment.cgi?id=65892 Same scene, good camera angle -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53884] gl_FragCoord gets corrupted in some camera angles
https://bugs.freedesktop.org/show_bug.cgi?id=53884 --- Comment #2 from Lauri Kasanen 2012-08-21 14:46:53 UTC --- Apitrace (60mb): http://www.ziddu.com/download/20164691/fragcoord.trace.zip.html Renamed as a zip to let it be uploaded. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/4] ACPI: export symbol acpi_get_table_with_size
Any objections from the ACPI folks to this patch going into 3.6 and stable? Alex On Mon, Aug 20, 2012 at 11:19 AM, wrote: > From: Alex Deucher > > We need it in the radeon drm module to fetch > and verify the vbios image on UEFI systems. > > Signed-off-by: Alex Deucher > Cc: stable at vger.kernel.org > --- > drivers/acpi/acpica/tbxface.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c > index ea4c6d5..29e51bc 100644 > --- a/drivers/acpi/acpica/tbxface.c > +++ b/drivers/acpi/acpica/tbxface.c > @@ -387,6 +387,7 @@ acpi_get_table_with_size(char *signature, > > return (AE_NOT_FOUND); > } > +ACPI_EXPORT_SYMBOL(acpi_get_table_with_size) > > acpi_status > acpi_get_table(char *signature, > -- > 1.7.7.5 >
