[PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart
wrote:
> +The following types and visuals are supported.
> +
> +- FB_TYPE_PACKED_PIXELS
> +
> +- FB_TYPE_PLANES
You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and
FB_TYPE_VGA_PLANES. Ah, that's the "feel free to extend the API doc" :-)
> +The FOURCC-based API replaces format descriptions by four character codes
> +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
> +without explicitly describing it. This is the only API that supports YUV
> +formats. Drivers are also encouraged to implement the FOURCC-based API for
> RGB
> +and grayscale formats.
> +
> +Drivers that support the FOURCC-based API report this capability by setting
> +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
> +
> +FOURCC definitions are located in the linux/videodev2.h header. However, and
> +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to
> V4L2
> +and don't require usage of the V4L2 subsystem. FOURCC documentation is
> +available in Documentation/DocBook/v4l/pixfmt.xml.
> +
> +To select a format, applications set the FB_VMODE_FOURCC bit in the
> +fb_var_screeninfo vmode field, and set the fourcc field to the desired
> FOURCC.
> +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to
> +0 by applications and ignored by drivers. Note that the grayscale and fourcc
> +fields share the same memory location. Application must thus not set the
> +grayscale field to 0.
These are the only parts I don't like: (ab)using the vmode field (this
isn't really a
vmode flag), and the union of grayscale and fourcc (avoid unions where
possible).
What about storing the FOURCC value in nonstd instead?
As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero),
I don't think there are any conflicts with existing values of nonstd.
To make it even safer and easier to parse, you could set bit 31 of
nonstd as a FOURCC
indicator.
Gr{oetje,eeting}s,
? ? ? ? ? ? ? ? ? ? ? ? Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
[Bug 38547] r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 --- Comment #2 from David L. 2011-06-21 22:19:08 PDT --- i hacked up a counter to tell me which instruction is failing, it seems to be 2517: ADD TEMP[161].x, -TEMP[158]., CONST[0]. if i'm not totally wrong. (my counter says 2518, but it is an ADD that fails so i think I'm off by one...) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38547] r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 --- Comment #1 from David L. 2011-06-21 22:07:02 PDT --- Created an attachment (id=48266) --> (https://bugs.freedesktop.org/attachment.cgi?id=48266) R600_DUMP_SHADERS + errors for first failing shader (please note that I added more debug statements, so the line numbers are a few lines off in those last 3 error lines) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38547] New: r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 Summary: r600g fails shader, tries to run with failed shader, freezes. Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: equinox-freedesktopbugs at diac24.net when trying to create a character in EVE Online, after the first few screens I encounter multiple shaders that cannot be translated from TGSI. The error message printed is: "r600_pipe_shader_create - translation from TGSI failed !" I've traced this down to: ^ check_and_set_bank_swizzle (-1) from ^ r600_bc_add_alu_type from ^ r600_shader_from_tgsi from ^ r600_pipe_shader_create (opcode: 0x09 "ADD") Problematically, the application continues running after that, complains about "missing shader" and finally - a whole few seconds later, continuing to draw the loading animation - freezes the GFX card: [ 4996.188064] radeon :03:00.0: GPU lockup CP stall for more than 1msec [ 4996.188072] [ cut here ] [ 4996.188147] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:246 radeon_fence_wait+0x21c/0x2bb [radeon]() [ 4996.188160] GPU lockup (waiting for 0x00011BDD last fence id 0x00011BD9) after that I have to kill my X server and restart it. (So this is basically two bugs, the shader failing, and the driver trying to use a failed shader I assume - though the lockup might also be unrelated) System information: mesa 21972c85ea734dbfcf69629c6b0b940efb42d4ba on Linux 2.6.39.1 32-bit chroot on 64-bit host 03:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600 Series] R600_DUMP_SHADERS output for failed shader following in attachment. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jun 21, 2011 at 9:20 PM, wrote:
> From: Thomas Reim
>
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid() and drm_edid_block_valid()
> periodically dump data and kernel errors into system
> log files and onto terminals, which lead to an unacceptable
> system behaviour.
>
> Tested since kernel 2.35 on Asus M2A-VM HDMI board
>
> Signed-off-by: Thomas Reim
> ---
> ?drivers/gpu/drm/radeon/radeon_connectors.c | ? 21 +--
> ?drivers/gpu/drm/radeon/radeon_display.c ? ?| ? 11 ++
> ?drivers/gpu/drm/radeon/radeon_i2c.c ? ? ? ?| ? 55
>
> ?drivers/gpu/drm/radeon/radeon_mode.h ? ? ? | ? ?1 +
> ?4 files changed, 85 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index cbfca3a..497e32a 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -825,9 +825,24 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
> ? ? ? ?int i;
> ? ? ? ?enum drm_connector_status ret = connector_status_disconnected;
> ? ? ? ?bool dret = false;
> -
> - ? ? ? if (radeon_connector->ddc_bus)
> - ? ? ? ? ? ? ? dret = radeon_ddc_probe(radeon_connector);
> +
> + ? ? ? if (radeon_connector->ddc_bus) {
> + ? ? ? ? ? ? ? /* AMD 690 chipset series HDMI DDC quirk:
> + ? ? ? ? ? ? ? ?* Some integrated ATI Radeon chipset implementations (e. g.
> + ? ? ? ? ? ? ? ?* Asus M2A-VM HDMI) indicate the availability of a DDC even
> + ? ? ? ? ? ? ? ?* when there's no monitor connected to HDMI. For HDMI
> + ? ? ? ? ? ? ? ?* connectors we check for the availability of EDID with
> + ? ? ? ? ? ? ? ?* at least a correct EDID header and EDID version/revision
> + ? ? ? ? ? ? ? ?* information. Only then, DDC is assumed to be available.
> + ? ? ? ? ? ? ? ?* This prevents drm_get_edid() and drm_edid_block_valid() of
> + ? ? ? ? ? ? ? ?* periodically dumping data and kernel errors into the logs
> + ? ? ? ? ? ? ? ?* and onto the terminal, which would lead to an unacceptable
> + ? ? ? ? ? ? ? ?* system behaviour */
> + ? ? ? ? ? ? ? if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)
This is going to enable your quirk on every board with an HDMI port.
If we need to add a quirk for your board, let's make it board
specific. It might be better to just disable edid polling for certain
connectors on certain boards if they cause problems when no monitor is
detected.
Alex
> + ? ? ? ? ? ? ? ? ? ? ? dret = radeon_ddc_edid_probe(radeon_connector);
> + ? ? ? ? ? ? ? else
> + ? ? ? ? ? ? ? ? ? ? ? dret = radeon_ddc_probe(radeon_connector);
> + ? ? ? }
> ? ? ? ?if (dret) {
> ? ? ? ? ? ? ? ?if (radeon_connector->edid) {
> ? ? ? ? ? ? ? ? ? ? ? ?kfree(radeon_connector->edid);
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 292f73f..550f143 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?radeon_setup_encoder_clones(dev);
> ? ? ? ? ? ? ? ?radeon_print_display_setup(dev);
> + ? ? ? ? ? ? ? /* Is this really required here?
> + ? ? ? ? ? ? ? ? ?Seems to just force drm to dump EDID errors
> + ? ? ? ? ? ? ? ? ?to kernel logs */
> ? ? ? ? ? ? ? ?list_for_each_entry(drm_connector,
> >mode_config.connector_list, head)
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_ddc_dump(drm_connector);
> ? ? ? ?}
> @@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
> *connector)
> ? ? ? ?if (!radeon_connector->ddc_bus)
> ? ? ? ? ? ? ? ?return -1;
> ? ? ? ?edid = drm_get_edid(connector, _connector->ddc_bus->adapter);
> + ? ? ? /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
> + ? ? ? ?* instead of periodically dumping data and kernel errors into the
> + ? ? ? ?* logs, if a monitor is not connected to HDMI */
> ? ? ? ?if (edid) {
> + ? ? ? ? ? ? ? DRM_INFO("Radeon display connector %s: Found valid EDID",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? drm_get_connector_name(connector));
> ? ? ? ? ? ? ? ?kfree(edid);
> + ? ? ? } else {
> + ? ? ? ? ? ? ? DRM_INFO("Radeon display connector %s: No display connected
> or invalid EDID",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? drm_get_connector_name(connector));
> ? ? ? ?}
> ? ? ? ?return ret;
> ?}
> diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
> b/drivers/gpu/drm/radeon/radeon_i2c.c
> index 781196d..80b871f 100644
> --- a/drivers/gpu/drm/radeon/radeon_i2c.c
> +++ b/drivers/gpu/drm/radeon/radeon_i2c.c
> @@ -63,6 +63,61 @@ bool radeon_ddc_probe(struct radeon_connector
> *radeon_connector)
> ? ? ? ?return false;
> ?}
>
> +/*
> + * Probe EDID information via I2C:
> + * Try to fetch EDID information by calling i2c_transfer driver function and
> + * probe for valid EDID header and
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Hi Thomas,
On Tue, 21 Jun 2011 17:31:45 +0200, Thomas Reim wrote:
> Some integrated ATI Radeon chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump data and kernel errors into system
> log files and onto terminals, which lead to an unacceptable
> system behaviour.
>
> Tested since kernel 2.35 on Asus M2A-VM HDMI board
I don't like your implementation (see below.) Also, your comment above
suggests that your main problem here is that logging is too verbose.
Maybe that's what you should be fixing.
>
> Signed-off-by: Thomas Reim
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 10 +
> drivers/gpu/drm/radeon/radeon_display.c| 11 +
> drivers/gpu/drm/radeon/radeon_i2c.c| 60
>
> drivers/gpu/drm/radeon/radeon_mode.h |1 +
> 4 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index cbfca3a..7a76e45 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
>
> if (radeon_connector->ddc_bus)
> dret = radeon_ddc_probe(radeon_connector);
> +
> + /* Asus M2A-VM HDMI DDC quirk:
> + * Some integrated ATI Radeon chipset implementations (e. g. Asus
> + * M2A-VM HDMI) indicate the availability of a DDC even when there's
> + * no monitor connected.The following check prevents drm_get_edid()
> + * and drm_edid_block_valid() of periodically dumping data and kernel
> + * errors into the logs and onto the terminal, which would lead to an
> + * unacceptable system behaviour */
> + if (dret && connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)
> + dret = radeon_ddc_edid_probe(radeon_connector);
I don't like this. radeon_ddc_edid_probe() is partly redundant with
radeon_ddc_probe() and also partly redundant with drm_get_edid() and
drm_edid_is_valid(). It will add yet another round of I2C transactions,
and these transactions are slow, so the fewer we have at driver load
time, the happier we are. This is even more true these days when every
graphics card gets 8 I2C buses created.
If nothing else, you should call radeon_ddc_edid_probe() instead of,
not after, radeon_ddc_probe(), to save a transaction.
But the root cause is most certainly that the underlying I2C bus is not
working. I bet that SDA is stuck low, which causes every sent byte
(including the slave address) to look like it was acked [1], and every
read byte to be zero. So the key problem is that radeon_ddc_probe()
isn't able to detect this case. Either the bus should be tested first
(see i2c-algo-bit for a test function) or radeon_ddc_probe() should be
improved to detect this case. It doesn't have to go to the extent of
your new radeon_ddc_edid_probe() function. It would be enough to read 2
bytes from the supposed EDID EEPROM, and check that they are not both 0.
Properly checking for stuck bus would have the advantage that you don't
have to retest later (contrary to missing EDID which can show up later
when a monitor gets plugged.)
[1] Incidentally I had a similar case reported a few days ago:
http://lists.lm-sensors.org/pipermail/lm-sensors/2011-June/032959.html
Further comments below are just for completeness, as I don't think the
route your took is appropriate.
> if (dret) {
> if (radeon_connector->edid) {
> kfree(radeon_connector->edid);
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 292f73f..550f143 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
> if (ret) {
> radeon_setup_encoder_clones(dev);
> radeon_print_display_setup(dev);
> + /* Is this really required here?
> +Seems to just force drm to dump EDID errors
> +to kernel logs */
> list_for_each_entry(drm_connector,
> >mode_config.connector_list, head)
> radeon_ddc_dump(drm_connector);
> }
> @@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
> *connector)
> if (!radeon_connector->ddc_bus)
> return -1;
> edid = drm_get_edid(connector, _connector->ddc_bus->adapter);
> + /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
> + * instead of periodically dumping data and kernel errors into the
> + * logs, if a monitor is not connected to HDMI */
> if (edid) {
> + DRM_INFO("Radeon display connector %s: Found valid EDID",
> +
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often. In
order to handle the case where the event is read off the queue by
another thread before we dequeue the event, we delay the actual checking
for EAGAIN to under the spinlock and so inline drm_dequeue_event().
Signed-off-by: Chris Wilson
---
v3: Compilation. Remember to at least test changes before hitting send.
-Chris
---
drivers/gpu/drm/drm_fops.c | 79 +---
1 files changed, 38 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2ec7d48..8efc07f 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -580,61 +580,58 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
-static bool
-drm_dequeue_event(struct drm_file *file_priv,
- size_t total, size_t max, struct drm_pending_event **out)
+ssize_t drm_read(struct file *filp, char __user *buffer,
+size_t count, loff_t *offset)
{
+ struct drm_file *file_priv = filp->private_data;
struct drm_device *dev = file_priv->minor->dev;
struct drm_pending_event *e;
unsigned long flags;
- bool ret = false;
+ ssize_t ret;
+ int err;
- spin_lock_irqsave(>event_lock, flags);
+ if ((filp->f_flags & O_NONBLOCK) == 0) {
+ ret = wait_event_interruptible(file_priv->event_wait,
+
!list_empty(_priv->event_list));
+ if (ret < 0)
+ return ret;
+ }
- *out = NULL;
- if (list_empty(_priv->event_list))
- goto out;
- e = list_first_entry(_priv->event_list,
-struct drm_pending_event, link);
- if (e->event->length + total > max)
- goto out;
+ ret = err = 0;
+ spin_lock_irqsave(>event_lock, flags);
+ do {
+ if (list_empty(_priv->event_list)) {
+ if (filp->f_flags & O_NONBLOCK)
+ err = -EAGAIN;
+ goto unlock;
+ }
- file_priv->event_space += e->event->length;
- list_del(>link);
- *out = e;
- ret = true;
+ e = list_first_entry(_priv->event_list,
+struct drm_pending_event, link);
+ if (e->event->length + ret > count) {
+ err = -EINVAL;
+ goto unlock;
+ }
-out:
- spin_unlock_irqrestore(>event_lock, flags);
- return ret;
-}
+ file_priv->event_space += e->event->length;
+ list_del(>link);
-ssize_t drm_read(struct file *filp, char __user *buffer,
-size_t count, loff_t *offset)
-{
- struct drm_file *file_priv = filp->private_data;
- struct drm_pending_event *e;
- size_t total;
- ssize_t ret;
+ spin_unlock_irqrestore(>event_lock, flags);
- ret = wait_event_interruptible(file_priv->event_wait,
- !list_empty(_priv->event_list));
- if (ret < 0)
- return ret;
-
- total = 0;
- while (drm_dequeue_event(file_priv, total, count, )) {
- if (copy_to_user(buffer + total,
-e->event, e->event->length)) {
- total = -EFAULT;
- break;
+ if (copy_to_user(buffer + ret, e->event, e->event->length)) {
+ err = -EFAULT;
+ goto out;
}
- total += e->event->length;
+ ret += e->event->length;
e->destroy(e);
- }
- return total;
+ spin_lock_irqsave(>event_lock, flags);
+ } while (1);
+unlock:
+ spin_unlock_irqrestore(>event_lock, flags);
+out:
+ return ret ? ret : err;
}
EXPORT_SYMBOL(drm_read);
--
1.7.5.4
Reverting rc6 by default
On Tue, Jun 21, 2011 at 08:48:55PM +0200, Francesco Allertsen wrote: > On Tue, Jun 21, 2011 at 11:29:41AM -0700, Jesse Barnes wrote: > > Use netconsole. Documentation/networking/netconsole.txt has all the > > gory details. > > I have used netconsole, with that documentation, but it doesn't show me > the drm debug messages, only the other dmesg messages, and I don't know > why. > Try to run dmesg -n 8 before loading the module. Marcin
Reverting rc6 by default
On Tue, Jun 21, 2011 at 11:29:41AM -0700, Jesse Barnes wrote: > Use netconsole. Documentation/networking/netconsole.txt has all the > gory details. I have used netconsole, with that documentation, but it doesn't show me the drm debug messages, only the other dmesg messages, and I don't know why. Bye Francesco
Reverting rc6 by default
On Tue, Jun 21, 2011 at 11:04:15AM -0700, Keith Packard wrote: > Btw, can you send along the output of dmidecode? I'm wondering what > version of the BIOS you've got. We've seen some pretty strange behaviour > on X201s with earlier BIOS versions which have been fixed with newer > versions. Here is mine: # dmidecode 2.11 SMBIOS 2.6 present. 78 structures occupying 2864 bytes. Table at 0x000E0010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: LENOVO Version: 6QET52WW (1.22 ) Release Date: 08/23/2010 Address: 0xE Runtime Size: 128 kB ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 3.5"/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.34 Firmware Revision: 1.5 Bye Francesco
[RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 11:19 AM, Jesse Barnes wrote: > On Tue, 21 Jun 2011 06:21:11 -0500 > Rob Clark wrote: > >> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes >> wrote: >> > This version adds both source and dest rect params to the set_plane >> > ioctl, and makes the source fixed point to support hardware that needs >> > it. >> > >> > I haven't changed the name of the SNB implementation yet (per Chris's >> > suggestions) but will before it gets upstream. >> > >> > I'd be interested to see whether these interfaces will work for other >> > hardware, so please take a close look at them and ideally implement them >> > on your hardware to make sure (see my userspace example code from >> > earlier posts if you want something to crib from). >> >> Cool, thanks for this >> >> I'm just thinking through how I'd implement the driver part in omap >> drm driver.. so please bear with me if I'm misunderstanding.. >> >> In particular I'm thinking about being able to use a given video pipe >> (basically like a dma channel) as either framebuffer layer or overlay >> at various points in time, depending on how many displays are >> attached. ?Is the idea to use drm_plane *only* for overlay layer, and >> still use crtc->fb for the normal framebuffer layer? > > Given the structure of the current KMS API, a CRTC implies a plane of > some sort, but I don't think the driver is restricted to using the same > plane for a given CRTC forever; it could allocate and switch them > around depending on usage, with planes beyond what's currently > associated with the CRTC exposed through this interface. The awkward thing is how do you express to userspace that if it isn't using some CRTC(s) that it has an extra plane(s) available, if each crtc even though it is not enabled, is assumed to consume a plane (video pipe).. That said if OMAP is the only hw like this, one possible solution is that you just need to have userspace know.. ie. the main one taking advantage of this feature would be the xorg driver, and it already knows what DRM driver it is talking to. Generic things like splash screen won't need to be using all the video planes. But I'm at least under the impression that some of the other SoC's have similar flexibility to use video planes as either primary or overlay layers. So I figure it is at least worth trying to handle this in a more generic way if it doesn't cause too much ugliness to KMS core. >> I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC >> pass in -1 for fb_id, followed by one or more >> DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly >> specify the drm_plane's). ?Or if _SETCRTC passes in a valid fb_id, we >> know it is the old way, and driver automatically picks a drm_plane. > > Yeah that might work; we'd probably want a new GETPARAM flag to > indicate support for this... ?The tough part is doing it in such a way > that we don't break existing userspace. fwiw, Daniel and I discussed a bit on IRC earlier today, and he had an interesting idea about having a simple drm_plane shim+helpers to keep things similar for existing drivers. I think it should be possible to support both old and new userspace semantics this way without too much if(driver_features & SUPPORTS_PLANES) sort of stuff. BR, -R
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Dear Alex, yes, the proposed fix should also fix the 'drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.' issue. The trick is, that we check within the Radeon domain directly on i2c interface level, if an EDID can be retrieved at all, before we hand over to the main drm edid functions. If you can provide some logs from Dave, I can double-check. Regards, Thomas > On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim > wrote: > > Some integrated ATI Radeon chipset implementations > > (e. g. Asus M2A-VM HDMI) indicate the availability > > of a DDC even when there's no monitor connected. > > In this case, drm_get_edid and drm_edid_block_valid > > periodically dump data and kernel errors into system > > log files and onto terminals, which lead to an unacceptable > > system behaviour. > > > > Tested since kernel 2.35 on Asus M2A-VM HDMI board > > > > Signed-off-by: Thomas Reim > > Does this patch fix the issue: > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4a9a8b71e12d41abb71c4e741bff524f016cfef4 > > Alex > > > --- > > drivers/gpu/drm/radeon/radeon_connectors.c | 10 + > > drivers/gpu/drm/radeon/radeon_display.c| 11 + > > drivers/gpu/drm/radeon/radeon_i2c.c| 60 > > > > drivers/gpu/drm/radeon/radeon_mode.h |1 + > > 4 files changed, 82 insertions(+), 0 deletions(-) > >
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often. In
order to handle the case where the event is read off the queue by
another thread before we dequeue the event, we delay the actual checking
for EAGAIN to under the spinlock and so inline drm_dequeue_event().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_fops.c | 76 +---
1 files changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2ec7d48..d248366 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -580,61 +580,57 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
-static bool
-drm_dequeue_event(struct drm_file *file_priv,
- size_t total, size_t max, struct drm_pending_event **out)
+ssize_t drm_read(struct file *filp, char __user *buffer,
+size_t count, loff_t *offset)
{
+ struct drm_file *file_priv = filp->private_data;
struct drm_device *dev = file_priv->minor->dev;
struct drm_pending_event *e;
unsigned long flags;
- bool ret = false;
-
- spin_lock_irqsave(>event_lock, flags);
+ ssize_t ret;
+ int err;
- *out = NULL;
- if (list_empty(_priv->event_list))
- goto out;
- e = list_first_entry(_priv->event_list,
-struct drm_pending_event, link);
- if (e->event->length + total > max)
- goto out;
+ if ((filp->f_flags & O_NONBLOCK) == 0) {
+ ret = wait_event_interruptible(file_priv->event_wait,
+
!list_empty(_priv->event_list));
+ if (ret < 0)
+ return ret;
+ }
- file_priv->event_space += e->event->length;
- list_del(>link);
- *out = e;
- ret = true;
+ ret = err = 0;
+ spin_lock_irqsave(>event_lock, flags);
+ do {
+ if (list_empty(_priv->event_list)) {
+ if (flip->f_flags & O_NONBLOCK)
+ err = -EAGAIN;
+ break;
+ }
-out:
- spin_unlock_irqrestore(>event_lock, flags);
- return ret;
-}
+ e = list_first_entry(_priv->event_list,
+struct drm_pending_event, link);
+ if (e->event->length + ret > max) {
+ err = -EINVAL;
+ break;
+ }
-ssize_t drm_read(struct file *filp, char __user *buffer,
-size_t count, loff_t *offset)
-{
- struct drm_file *file_priv = filp->private_data;
- struct drm_pending_event *e;
- size_t total;
- ssize_t ret;
+ file_priv->event_space += e->event->length;
+ list_del(>link);
- ret = wait_event_interruptible(file_priv->event_wait,
- !list_empty(_priv->event_list));
- if (ret < 0)
- return ret;
+ spin_unlock_irqrestore(>event_lock, flags);
- total = 0;
- while (drm_dequeue_event(file_priv, total, count, )) {
- if (copy_to_user(buffer + total,
-e->event, e->event->length)) {
- total = -EFAULT;
+ if (copy_to_user(buffer + ret, e->event, e->event->length)) {
+ err = -EFAULT;
break;
}
- total += e->event->length;
+ ret += e->event->length;
e->destroy(e);
- }
- return total;
+ spin_lock_irqsave(>event_lock, flags);
+ } while (1);
+ spin_unlock_irqrestore(>event_lock, flags);
+
+ return ret ? ret : err;
}
EXPORT_SYMBOL(drm_read);
--
1.7.5.4
Linux 3.0-rc4
* Nick Bowler -- Tuesday 21 June 2011: > We're at -rc4 now, but it seems that the following patch (drm/i915: add > missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made > it in yet? > > http://permalink.gmane.org/gmane.linux.kernel/1148279 > > The i915 driver has been broken since 3.0-rc1 without this fix, > which has been available for 3 weeks now. Keith has suggested a better fix (https://lkml.org/lkml/2011/6/6/560), but for some reason it still hasn't made it into the kernel. m.
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #17 from Anisse Astier 2011-06-21 14:43:04 --- It's the same patch as in comment 11 which I reported tested and non-working in comment 14 . I just tested 3.0-rc4, screen is still blank and/or no backlight. The only improvement (difference ?) seems to be in modelines detection. --- Comment #18 from Alex Deucher 2011-06-21 18:47:40 --- There are a number of additional fixes in 3.0-rc4. Do any of them help? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Reverting rc6 by default
On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: > I'm more interested in seeing how the dmesg output differs between the > working state (rc6=0) and the broken state (rc6=1). Or is the machine > not accessible over ssh once you've started X? I got a complete freeze when I start X. I have tried to log the output of dmesg via ethernet using netconole, but it doesn't log the drm debug. Is there another parameter to append at the kernel to send via ethernet also the debug? Bye Francesco
Reverting rc6 by default
On Tue, Jun 21, 2011 at 08:28:17AM -0700, Keith Packard wrote: > Given the number of X201s machines running this kernel (like the one I'm > using right now), I'd love to get this fixed for you instead of > disabling rc6 -- rc6 is worth a ton of power savings. I didn't know that, anyway, I'm don't know the intel driver so well to solve the problem, that's why I did only the revert, and I'll give you more information to solve the issue. > Please describe your configuration (which OS, which X and i915 driver > versions) and then send along a kernel log with drm.debug=0x04 so we can > see what's going on. If you stick these in a bugzilla entry, we'll not > lose track of them. Let's start. I'm using Slackware -current with the xorg-server version 1.9.5 and the kernel 3.0.0-rc4 (with the revert applied). Attached there is the full dmesg output with drm.debug=0x04. If you prefer that I open a bug on the kernel bugzilla to put all the informations no problem. Bye Francesco -- next part -- [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.0.0-rc1-1-g21a6271 (lupin at fujiko) (gcc version 4.5.3 (GCC) ) #327 SMP Tue Jun 21 15:49:58 CEST 2011 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009e800 (usable) [0.00] BIOS-e820: 0009e800 - 000a (reserved) [0.00] BIOS-e820: 000d2000 - 000d4000 (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - bb27c000 (usable) [0.00] BIOS-e820: bb27c000 - bb282000 (reserved) [0.00] BIOS-e820: bb282000 - bb35f000 (usable) [0.00] BIOS-e820: bb35f000 - bb371000 (reserved) [0.00] BIOS-e820: bb371000 - bb3f2000 (ACPI NVS) [0.00] BIOS-e820: bb3f2000 - bb40f000 (reserved) [0.00] BIOS-e820: bb40f000 - bb46f000 (usable) [0.00] BIOS-e820: bb46f000 - bb668000 (reserved) [0.00] BIOS-e820: bb668000 - bb6e8000 (ACPI NVS) [0.00] BIOS-e820: bb6e8000 - bb70f000 (reserved) [0.00] BIOS-e820: bb70f000 - bb717000 (usable) [0.00] BIOS-e820: bb717000 - bb71f000 (reserved) [0.00] BIOS-e820: bb71f000 - bb76c000 (usable) [0.00] BIOS-e820: bb76c000 - bb778000 (ACPI NVS) [0.00] BIOS-e820: bb778000 - bb77b000 (ACPI data) [0.00] BIOS-e820: bb77b000 - bb78b000 (ACPI NVS) [0.00] BIOS-e820: bb78b000 - bb78c000 (ACPI data) [0.00] BIOS-e820: bb78c000 - bb79f000 (ACPI NVS) [0.00] BIOS-e820: bb79f000 - bb7ff000 (ACPI data) [0.00] BIOS-e820: bb7ff000 - bb80 (usable) [0.00] BIOS-e820: bb80 - c000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: feaff000 - feb0 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fed0 - fed00400 (reserved) [0.00] BIOS-e820: fed1c000 - fed9 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff00 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 00013800 (usable) [0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! [0.00] DMI present. [0.00] DMI: LENOVO 5129CTO/5129CTO, BIOS 6QET52WW (1.22 ) 08/23/2010 [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0xbb800 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-D3FFF write-protect [0.00] D4000-DBFFF uncachable [0.00] DC000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 disabled [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC000 write-back [0.00] 3 base 1 mask FC000 write-back [0.00] 4 base 13800 mask FF800 uncachable [0.00] 5 base 0BC00 mask FFC00 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820 update
[PATCH/RFC] fbdev: Add FOURCC-based format configuration API
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart
---
Documentation/fb/api.txt | 284 ++
include/linux/fb.h | 12 ++-
2 files changed, 294 insertions(+), 2 deletions(-)
create mode 100644 Documentation/fb/api.txt
A bit late, but here's a patch that implements an fbdev format configuration
API to support YUV formats. My next step is to implement a prototype in an
fbdev driver to make sure the API works well.
Thanks to Florian Tobias Schandinat for providing feedback on the initial RFC.
Comments are as usual more than welcome. If you feel like writing a couple of
lines of documentation, feel free to extend the API doc. That's much needed.
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 000..d4cd6ec
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,284 @@
+ The Frame Buffer Device API
+ ---
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+ ...
+ __u16 capabilities; /* see FB_CAP_* */
+ ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Color components (usually RGB or YUV) are packed together into macropixels
+that are stored in a single plane. The exact color components layout is
+described in a visual-dependent way.
+
+Frame buffer visuals that don't use multiple color components per pixel
+(such as monochrome and pseudo-color visuals) are reported as packed frame
+buffer types, even though they don't stricly speaking pack color components
+into macropixels.
+
+- FB_TYPE_PLANES
+
+Color components are stored in separate planes. Planes are located
+contiguously in memory.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+black pixel and a bit set to 0 a white pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+white pixel and a bit set to 0 a black pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field. Pixels are contiguous in memory.
+
+FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
+FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the corresponding value.
+
+Each
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
Signed-off-by: Thomas Reim
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 +
drivers/gpu/drm/radeon/radeon_display.c| 11 +
drivers/gpu/drm/radeon/radeon_i2c.c| 60
drivers/gpu/drm/radeon/radeon_mode.h |1 +
4 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..7a76e45 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
if (radeon_connector->ddc_bus)
dret = radeon_ddc_probe(radeon_connector);
+
+ /* Asus M2A-VM HDMI DDC quirk:
+* Some integrated ATI Radeon chipset implementations (e. g. Asus
+* M2A-VM HDMI) indicate the availability of a DDC even when there's
+* no monitor connected.The following check prevents drm_get_edid()
+* and drm_edid_block_valid() of periodically dumping data and kernel
+* errors into the logs and onto the terminal, which would lead to an
+* unacceptable system behaviour */
+ if (dret && connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ dret = radeon_ddc_edid_probe(radeon_connector);
if (dret) {
if (radeon_connector->edid) {
kfree(radeon_connector->edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+ Seems to just force drm to dump EDID errors
+ to kernel logs */
list_for_each_entry(drm_connector,
>mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector *connector)
if (!radeon_connector->ddc_bus)
return -1;
edid = drm_get_edid(connector, _connector->ddc_bus->adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+* instead of periodically dumping data and kernel errors into the
+* logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO("Radeon display connector %s: Found valid EDID",
+ drm_get_connector_name(connector));
kfree(edid);
+ } else {
+ DRM_INFO("Radeon display connector %s: No display connected or
invalid EDID",
+ drm_get_connector_name(connector));
}
return ret;
}
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 781196d..1d6decd 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -63,6 +63,66 @@ bool radeon_ddc_probe(struct radeon_connector
*radeon_connector)
return false;
}
+/**
+ * Probe EDID information via I2C.
+ *
+ * \param adapter : i2c device adaptor
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Try to fetch EDID information by calling i2c driver function and
+ * probe for EDID header information.
+ *
+ * Remark:
+ * This function has been added, because there are integrated ATI Radeon
+ * chipset implementations (e. g. Asus M2A-VM HDMI that indicate the
+ * availability of a DDC even when there's no monitor connected.
+ * In this case, drm_get_edid and drm_edid_block_valid periodically dump
+ * data and kernel errors into the logs and onto the terminal, which lead to
+ * an unacceptable system behaviour.
+ */
+bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector)
+{
+ u8 out_buf[] = { 0x0, 0x0};
+ u8 block[20];
+ int ret;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = 0x50,
+ .flags = 0,
+ .len= 1,
+ .buf= out_buf,
+ }, {
+ .addr = 0x50,
+ .flags = I2C_M_RD,
+ .len= 20,
+
[PATCH] fix mesa build from tarball
Hi
The following patch fixes building mesa from tarball (generated from git):
- one Makefile disappeared (Makefile.template)
- two other were missing (src/mesa/drivers/dri/Makefile.{defines,targets}
Please apply
Thx
-- next part --
A non-text attachment was scrubbed...
Name: fix-build-from-tarball.diff
Type: application/octet-stream
Size: 543 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110621/ac5d3f94/attachment.obj>
Reverting rc6 by default
Hi, I wanted to try the new 3.0 Linux Kernel, and I got stucked for a freeze at the start of X. I have bisected the problem and the error was on commit a51f7a6, wich enable rc6 by default (some time ago I have sent another bug about that). I have reverted the commit (the complete patch is attached) and now everything works great. Now, I have a Lenovo X201s, and if you need more information for debugging purpose just let me know, otherwise just apply the patch attached (on top of -rc4). If you prefer I can send the patch using git-send-email. Thanks Bye Francesco
[PATCH] Revert "drm/i915: enable rc6 by default"
This reverts commit a51f7a66fb5e4af5ec4286baef940d06594b59d2. With rc6 enabled by default there is a freeze in the Lenovo X201s laptop. Signed-off-by: Francesco Allertsen --- drivers/gpu/drm/i915/i915_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0defd42..0017f7a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -52,7 +52,7 @@ module_param_named(powersave, i915_powersave, int, 0600); unsigned int i915_semaphores = 0; module_param_named(semaphores, i915_semaphores, int, 0600); -unsigned int i915_enable_rc6 = 1; +unsigned int i915_enable_rc6 = 0; module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); unsigned int i915_enable_fbc = 0; -- 1.7.5.1 --qDbXVdCdHGoSgWSk--
[Bug 38452] ETQW: Renders garbage in some places
https://bugs.freedesktop.org/show_bug.cgi?id=38452 --- Comment #1 from Vadim 2011-06-21 13:15:53 PDT --- Created an attachment (id=48255) View: https://bugs.freedesktop.org/attachment.cgi?id=48255 Review: https://bugs.freedesktop.org/review?bug=38452=48255 [PATCH] mesa: fix range check in _mesa_validate_DrawElements It's a bug in ETQW. With this patch mesa will ignore invalid calls instead of rendering garbage, but it won't fix the real bug in the game. The bug is related to index buffers and setting "r_useIndexBuffers" to 1 works for me. If it doesn't help, then it's another bug or you probably need to restart the game after changing that value. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #5 from XoD 2011-06-21 12:23:39 PDT --- Created an attachment (id=48250) --> (https://bugs.freedesktop.org/attachment.cgi?id=48250) syslog_radeon I add syslog file were only lines with radeon are keep. I have launch 2 times piglit test, each time we can see some drm errors. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Reverting rc6 by default
On Tue, 21 Jun 2011 20:47:57 +0200, Francesco Allertsen wrote: > Version: 6QET52WW (1.22 ) > Release Date: 08/23/2010 Thanks. I'll see if I can't get an X201s upgraded to this version and see if we can reproduce the problem you're having... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110621/883d2b3b/attachment.pgp>
[Bug 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #16 from Florian Mickler 2011-06-21 11:57:00 --- A patch referencing this bug report has been merged in v3.0-rc4: commit f89931f345f26c43b109191fbfcfa50678c0 Author: Alex Deucher Date: Mon Jun 13 17:13:35 2011 -0400 drm/radeon/kms: fix handling of DP to LVDS bridges -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
(Looping linux-media in)
On Thursday 09 June 2011 13:55:13 Alan Cox wrote:
> > > You also don't need a headwer with a complete list of fourcc names in
> > > it, that is the half the point of FourCC.
> >
> > #define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
> > RGB-3-3-2 */
> >
> > See that V4L2 and v4l2? I'd rather not have them used in the drm
>
> They are just helpers. The only thing that fourcc is is a 4 byte packed
> value of four symbols.
>
> > interface, either a DRM_ variant or a FOURCC_ variant that removes the
> > V4L2. Also having it in a different include file to "videodev2.h", so
> > yes we can pass FOURCC values but I'd rather we gave people a drm
> > specific way to generate them or make a generic set of macros that don't
> > include the V4L2 headers.
>
> You need a macro to assemble fourcc codes and that seems to be about it -
> so just an equivalent of the v4l2_fourcc macro.
Given that I plan to use the V4L2 FOURCCs in fbdev as well, it might indeed be
a good idea to split them from videodev2.h into their own header file.
Renaming the macros to make them V4L2-agnostic is a no-go, as that would break
the API. Manually maintaining separate sets of identical FOURCCs accross
subsystems also doesn't sound like a very good idea to me. We could create a
header that contains V4L2-agnostic FOURCC #define's, and generate a V4L2
header with the V4L2_ prefix, but I'm not sure it would be a good idea either.
--
Regards,
Laurent Pinchart
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 --- Comment #5 from Stephen Kitt 2011-06-21 11:41:50 PDT --- I'm running Debian's linux-image-2.6.39-2-686-pae 2.6.39-2, which corresponds to 2.6.39.1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim wrote:
> Some integrated ATI Radeon ?chipset implementations
> (e. g. Asus M2A-VM HDMI) indicate the availability
> of a DDC even when there's no monitor connected.
> In this case, drm_get_edid and drm_edid_block_valid
> periodically dump data and kernel errors into system
> log files and onto terminals, which lead to an unacceptable
> system behaviour.
>
> Tested since kernel 2.35 on Asus M2A-VM HDMI board
>
> Signed-off-by: Thomas Reim
Does this patch fix the issue:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4a9a8b71e12d41abb71c4e741bff524f016cfef4
Alex
> ---
> ?drivers/gpu/drm/radeon/radeon_connectors.c | ? 10 +
> ?drivers/gpu/drm/radeon/radeon_display.c ? ?| ? 11 +
> ?drivers/gpu/drm/radeon/radeon_i2c.c ? ? ? ?| ? 60
>
> ?drivers/gpu/drm/radeon/radeon_mode.h ? ? ? | ? ?1 +
> ?4 files changed, 82 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index cbfca3a..7a76e45 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
>
> ? ? ? ?if (radeon_connector->ddc_bus)
> ? ? ? ? ? ? ? ?dret = radeon_ddc_probe(radeon_connector);
> +
> + ? ? ? /* Asus M2A-VM HDMI DDC quirk:
> + ? ? ? ?* Some integrated ATI Radeon chipset implementations (e. g. Asus
> + ? ? ? ?* M2A-VM HDMI) indicate the availability of a DDC even when there's
> + ? ? ? ?* no monitor connected.The following check prevents drm_get_edid()
> + ? ? ? ?* and drm_edid_block_valid() of periodically dumping data and kernel
> + ? ? ? ?* errors into the logs and onto the terminal, which would lead to an
> + ? ? ? ?* unacceptable system behaviour */
> + ? ? ? if (dret && connector->connector_type == DRM_MODE_CONNECTOR_HDMIA)
> + ? ? ? ? ? ? ? dret = radeon_ddc_edid_probe(radeon_connector);
> ? ? ? ?if (dret) {
> ? ? ? ? ? ? ? ?if (radeon_connector->edid) {
> ? ? ? ? ? ? ? ? ? ? ? ?kfree(radeon_connector->edid);
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 292f73f..550f143 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
> ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ?radeon_setup_encoder_clones(dev);
> ? ? ? ? ? ? ? ?radeon_print_display_setup(dev);
> + ? ? ? ? ? ? ? /* Is this really required here?
> + ? ? ? ? ? ? ? ? ?Seems to just force drm to dump EDID errors
> + ? ? ? ? ? ? ? ? ?to kernel logs */
> ? ? ? ? ? ? ? ?list_for_each_entry(drm_connector,
> >mode_config.connector_list, head)
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_ddc_dump(drm_connector);
> ? ? ? ?}
> @@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
> *connector)
> ? ? ? ?if (!radeon_connector->ddc_bus)
> ? ? ? ? ? ? ? ?return -1;
> ? ? ? ?edid = drm_get_edid(connector, _connector->ddc_bus->adapter);
> + ? ? ? /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
> + ? ? ? ?* instead of periodically dumping data and kernel errors into the
> + ? ? ? ?* logs, if a monitor is not connected to HDMI */
> ? ? ? ?if (edid) {
> + ? ? ? ? ? ? ? DRM_INFO("Radeon display connector %s: Found valid EDID",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? drm_get_connector_name(connector));
> ? ? ? ? ? ? ? ?kfree(edid);
> + ? ? ? } else {
> + ? ? ? ? ? ? ? DRM_INFO("Radeon display connector %s: No display connected
> or invalid EDID",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? drm_get_connector_name(connector));
> ? ? ? ?}
> ? ? ? ?return ret;
> ?}
> diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
> b/drivers/gpu/drm/radeon/radeon_i2c.c
> index 781196d..1d6decd 100644
> --- a/drivers/gpu/drm/radeon/radeon_i2c.c
> +++ b/drivers/gpu/drm/radeon/radeon_i2c.c
> @@ -63,6 +63,66 @@ bool radeon_ddc_probe(struct radeon_connector
> *radeon_connector)
> ? ? ? ?return false;
> ?}
>
> +/**
> + * Probe EDID information via I2C.
> + *
> + * \param adapter : i2c device adaptor
> + * \param buf ? ? : EDID data buffer to be filled
> + * \param len ? ? : EDID data buffer length
> + * \return 0 on success or -1 on failure.
> + *
> + * Try to fetch EDID information by calling i2c driver function and
> + * probe for EDID header information.
> + *
> + * Remark:
> + * This function has been added, because there are integrated ATI Radeon
> + * chipset implementations (e. g. Asus M2A-VM HDMI that indicate the
> + * availability of a DDC even when there's no monitor connected.
> + * In this case, drm_get_edid and drm_edid_block_valid periodically dump
> + * data and kernel errors into the logs and onto the terminal, which lead to
> + * an unacceptable system behaviour.
> + */
> +bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector)
> +{
> + ? ? ? u8 out_buf[] = { 0x0, 0x0};
> +
Reverting rc6 by default
On Tue, 21 Jun 2011 11:04:15 -0700 Keith Packard wrote: > On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen gmail.com> wrote: > > On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: > > > I'm more interested in seeing how the dmesg output differs between the > > > working state (rc6=0) and the broken state (rc6=1). Or is the machine > > > not accessible over ssh once you've started X? > > > > I got a complete freeze when I start X. I have tried to log the output > > of dmesg via ethernet using netconole, but it doesn't log the drm debug. > > Is there another parameter to append at the kernel to send via ethernet > > also the debug? > > I don't know how to get the drm debug sent to ethernet; perhaps someone > else does? Use netconsole. Documentation/networking/netconsole.txt has all the gory details. -- Jesse Barnes, Intel Open Source Technology Center
[RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 10:55, Marcus Lorentzon wrote: > And should it be possible to only define planes with no crtc framebuffer at > all? Use case, for example letter boxed video on black background with small > UI controls/subtitles. In this case it's not power efficient to have a > fullscreen fb with mostly if not all transparent pixels. I think we could shoe-horn this use-case into the current framework by using a special crtc-property "ignore attached fb, use this default color instead". But I think this would be better done in a second step when we tackle atomic vsync flips across multiple planes and the underlying crtc - that might also require us to change certain properties in the same flip command. -Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
Reverting rc6 by default
On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen wrote: > On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: > > I'm more interested in seeing how the dmesg output differs between the > > working state (rc6=0) and the broken state (rc6=1). Or is the machine > > not accessible over ssh once you've started X? > > I got a complete freeze when I start X. I have tried to log the output > of dmesg via ethernet using netconole, but it doesn't log the drm debug. > Is there another parameter to append at the kernel to send via ethernet > also the debug? I don't know how to get the drm debug sent to ethernet; perhaps someone else does? Btw, can you send along the output of dmidecode? I'm wondering what version of the BIOS you've got. We've seen some pretty strange behaviour on X201s with earlier BIOS versions which have been fixed with newer versions. For comparison, my X201s says: # dmidecode 2.9 SMBIOS 2.6 present. 78 structures occupying 2868 bytes. Table at 0x000E0010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: LENOVO Version: 6QET46V1 (1.16 ) Release Date: 07/05/2010 Address: 0xE Runtime Size: 128 kB ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 3.5"/720 KB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.22 Firmware Revision: 1.9 -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110621/6b8061db/attachment-0001.pgp>
[RFC] Updated plane support v3
On 06/20/2011 10:11 PM, Jesse Barnes wrote: > This version adds both source and dest rect params to the set_plane > ioctl, and makes the source fixed point to support hardware that needs > it. > > I haven't changed the name of the SNB implementation yet (per Chris's > suggestions) but will before it gets upstream. > > I'd be interested to see whether these interfaces will work for other > hardware, so please take a close look at them and ideally implement them > on your hardware to make sure (see my userspace example code from > earlier posts if you want something to crib from). > > Thanks, > Jesse > > Is it possible to position a plane above and below the "normal" crtc framebuffer? Plane z-order is unsigned, and I would assume 0 is default z-order. Applications will need to position planes above and below crtc normal framebuffer. Below when using a translucent or color keyed framebuffer, and above if framebuffer is opaque. So maybe add a one liner comment about z-order meaning and make it signed unless ordering should be solved in another way. And should it be possible to only define planes with no crtc framebuffer at all? Use case, for example letter boxed video on black background with small UI controls/subtitles. In this case it's not power efficient to have a fullscreen fb with mostly if not all transparent pixels. /BR /Marcus
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 --- Comment #4 from Alex Deucher 2011-06-21 10:48:14 PDT --- What kernel are you using? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Updated plane support v3
On Tue, 21 Jun 2011 06:21:11 -0500 Rob Clark wrote: > On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes > wrote: > > This version adds both source and dest rect params to the set_plane > > ioctl, and makes the source fixed point to support hardware that needs > > it. > > > > I haven't changed the name of the SNB implementation yet (per Chris's > > suggestions) but will before it gets upstream. > > > > I'd be interested to see whether these interfaces will work for other > > hardware, so please take a close look at them and ideally implement them > > on your hardware to make sure (see my userspace example code from > > earlier posts if you want something to crib from). > > Cool, thanks for this > > I'm just thinking through how I'd implement the driver part in omap > drm driver.. so please bear with me if I'm misunderstanding.. > > In particular I'm thinking about being able to use a given video pipe > (basically like a dma channel) as either framebuffer layer or overlay > at various points in time, depending on how many displays are > attached. Is the idea to use drm_plane *only* for overlay layer, and > still use crtc->fb for the normal framebuffer layer? Given the structure of the current KMS API, a CRTC implies a plane of some sort, but I don't think the driver is restricted to using the same plane for a given CRTC forever; it could allocate and switch them around depending on usage, with planes beyond what's currently associated with the CRTC exposed through this interface. > I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC > pass in -1 for fb_id, followed by one or more > DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly > specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we > know it is the old way, and driver automatically picks a drm_plane. Yeah that might work; we'd probably want a new GETPARAM flag to indicate support for this... The tough part is doing it in such a way that we don't break existing userspace. -- Jesse Barnes, Intel Open Source Technology Center
[RFC] Updated plane support v3
On Tue, 21 Jun 2011 10:55:39 +0200 Marcus Lorentzon wrote: > On 06/20/2011 10:11 PM, Jesse Barnes wrote: > > This version adds both source and dest rect params to the set_plane > > ioctl, and makes the source fixed point to support hardware that needs > > it. > > > > I haven't changed the name of the SNB implementation yet (per Chris's > > suggestions) but will before it gets upstream. > > > > I'd be interested to see whether these interfaces will work for other > > hardware, so please take a close look at them and ideally implement them > > on your hardware to make sure (see my userspace example code from > > earlier posts if you want something to crib from). > > > > Thanks, > > Jesse > > > > > Is it possible to position a plane above and below the "normal" crtc > framebuffer? Plane z-order is unsigned, and I would assume 0 is default > z-order. > Applications will need to position planes above and below crtc normal > framebuffer. Below when using a translucent or color keyed framebuffer, > and above if framebuffer is opaque. I was thinking 0 would be the bottom layer. But either way we don't have a way of getting the primary plane z position atm, so it'll be hard to position a new plane above or below the main plane... I'm ok with a signed value here, but the real meaning will be defined by a new ioctl we use to get plane blending restrictions, z order, and such. > So maybe add a one liner comment about z-order meaning and make it > signed unless ordering should be solved in another way. > > And should it be possible to only define planes with no crtc framebuffer > at all? Use case, for example letter boxed video on black background > with small UI controls/subtitles. In this case it's not power efficient > to have a fullscreen fb with mostly if not all transparent pixels. A particular driver may be able to expose that somehow, maybe by allowing clients to define a special fb handle that can be used to indicate no plane should be bound to the CRTC as the "primary" plane. -- Jesse Barnes, Intel Open Source Technology Center
Reverting rc6 by default
On Tue, 21 Jun 2011 17:52:05 +0200, Francesco Allertsen wrote: > If you prefer that I open a bug on the kernel bugzilla to put all the > informations no problem. I'm more interested in seeing how the dmesg output differs between the working state (rc6=0) and the broken state (rc6=1). Or is the machine not accessible over ssh once you've started X? -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110621/60d25b5d/attachment.pgp>
Reverting rc6 by default
On Tue, 21 Jun 2011 16:21:33 +0200, Francesco Allertsen wrote: Non-text part: multipart/mixed > Now, I have a Lenovo X201s, and if you need more information for > debugging purpose just let me know, otherwise just apply the patch > attached (on top of -rc4). Given the number of X201s machines running this kernel (like the one I'm using right now), I'd love to get this fixed for you instead of disabling rc6 -- rc6 is worth a ton of power savings. Please describe your configuration (which OS, which X and i915 driver versions) and then send along a kernel log with drm.debug=0x04 so we can see what's going on. If you stick these in a bugzilla entry, we'll not lose track of them. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110621/9be50b38/attachment.pgp>
[RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 6:21 AM, Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
>> This version adds both source and dest rect params to the set_plane
>> ioctl, and makes the source fixed point to support hardware that needs
>> it.
>>
>> I haven't changed the name of the SNB implementation yet (per Chris's
>> suggestions) but will before it gets upstream.
>>
>> I'd be interested to see whether these interfaces will work for other
>> hardware, so please take a close look at them and ideally implement them
>> on your hardware to make sure (see my userspace example code from
>> earlier posts if you want something to crib from).
>
> Cool, thanks for this
>
> I'm just thinking through how I'd implement the driver part in omap
> drm driver.. so please bear with me if I'm misunderstanding..
>
> In particular I'm thinking about being able to use a given video pipe
> (basically like a dma channel) as either framebuffer layer or overlay
> at various points in time, depending on how many displays are
> attached. ?Is the idea to use drm_plane *only* for overlay layer, and
> still use crtc->fb for the normal framebuffer layer?
>
> Or would/could a drm_plane also be used for main layer instead of
> crtc->fb? ?In this case, either userspace would have to know (which
> doesn't seem like a good idea for things like plymouth which use drm
> interface a bit generically). ?Or the driver would have to internally
> automatically hook up a drm_plane if it sees that userspace hasn't
> done this.
>
> I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC
> pass in -1 for fb_id, followed by one or more
> DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly
> specify the drm_plane's). ?Or if _SETCRTC passes in a valid fb_id, we
> know it is the old way, and driver automatically picks a drm_plane.
just thinking through this a bit more.. the idea is that for drivers
w/ DRM_SUPPORTS_PLANES[1], there is no fb hooked directly to crtc.
And support for userspace that is not aware of planes could be, I
think, mostly in the kms core, although I'm just thinking through how
disruptive that would be..
I think if we add a crtc->funcs->get_primary_plane() to be implemented
by drivers that use planes in cases where userspace does not know
about planes. It would be used to get (and if necessary, assign) a
drm_plane to a drm_crtc, then we can do things like:
handle _SETCRTC from userspace that doesn't understand planes:
-
@@ -1580,7 +1580,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.mode = mode;
set.connectors = connector_set;
set.num_connectors = crtc_req->count_connectors;
- set.fb = fb;
+ if (fb & (dev->driver->driver_features & DRM_SUPPORTS_PLANES)) {
+ /* pass fb to the primary plane for compatibility */
+ struct drm_plane *plane =
+ crtc->funcs->get_primary_plane(crtc);
+ set.plane = plane;
+ plane->funcs->set_config();
+ } else {
+ set.fb = fb;
+ }
ret = crtc->funcs->set_config();
out:
-
or page flip ioctl from userspace that doesn't understand planes:
-
@@ -2645,7 +2652,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}
- ret = crtc->funcs->page_flip(crtc, fb, e);
+ if (dev->driver->driver_features & DRM_SUPPORTS_PLANES) {
+ struct drm_plane *plane =
+ crtc->funcs->get_primary_plane(crtc);
+ ret = plane->funcs->page_flip(plane, fb, e);
+ } else {
+ ret = crtc->funcs->page_flip(crtc, fb, e);
+ }
+
if (ret) {
spin_lock_irqsave(>event_lock, flags);
file_priv->event_space += sizeof e->event;
-
It doesn't look like there are *that* many places where crtc->fb is
reference, but I've not gone through all of them.. I'm not sure if
this sort of change would be too intrusive.
BR,
-R
--
[1] or maybe DRM_MANDATORY_PLANES if there are some drivers that would
use a hybrid model of fb either direct to drm_crtc, or indirect via a
drm_plane
BR,
-R
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #4 from Andy Furniss 2011-06-21 07:20:19 PDT --- (In reply to comment #2) > Created an attachment (id=48227) View: https://bugs.freedesktop.org/attachment.cgi?id=48227 Review: https://bugs.freedesktop.org/review?bug=38440=48227 > [PATCH] r600g: fragment/vertex color clamping > > This patch should fix model brightness. It fixes both my issues with normal lighting on rv790 - thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #3 from Sven Arvidsson 2011-06-21 06:49:32 PDT --- (In reply to comment #2) > > This patch should fix model brightness. Indeed it does. Wow, you have really been rocking with all the fixes for r600g, thanks! :) Andy, if the sky/sea issue isn't solved with this, can you post a screenshot? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC] Updated plane support v3
On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes wrote: > This version adds both source and dest rect params to the set_plane > ioctl, and makes the source fixed point to support hardware that needs > it. > > I haven't changed the name of the SNB implementation yet (per Chris's > suggestions) but will before it gets upstream. > > I'd be interested to see whether these interfaces will work for other > hardware, so please take a close look at them and ideally implement them > on your hardware to make sure (see my userspace example code from > earlier posts if you want something to crib from). Cool, thanks for this I'm just thinking through how I'd implement the driver part in omap drm driver.. so please bear with me if I'm misunderstanding.. In particular I'm thinking about being able to use a given video pipe (basically like a dma channel) as either framebuffer layer or overlay at various points in time, depending on how many displays are attached. Is the idea to use drm_plane *only* for overlay layer, and still use crtc->fb for the normal framebuffer layer? Or would/could a drm_plane also be used for main layer instead of crtc->fb? In this case, either userspace would have to know (which doesn't seem like a good idea for things like plymouth which use drm interface a bit generically). Or the driver would have to internally automatically hook up a drm_plane if it sees that userspace hasn't done this. I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC pass in -1 for fb_id, followed by one or more DRM_IOCTL_MODE_SETPLANE's, to set things up the "new" way (explicitly specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we know it is the old way, and driver automatically picks a drm_plane. BR, -R > Thanks, > Jesse > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #2 from Vadim 2011-06-21 06:08:33 PDT --- Created an attachment (id=48227) View: https://bugs.freedesktop.org/attachment.cgi?id=48227 Review: https://bugs.freedesktop.org/review?bug=38440=48227 [PATCH] r600g: fragment/vertex color clamping This patch should fix model brightness. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #1 from Andy Furniss 2011-06-21 03:26:36 PDT --- (In reply to comment #0) > Created an attachment (id=48132) --> (https://bugs.freedesktop.org/attachment.cgi?id=48132) > screenshot of bug > > As previously mentioned in bug 36917, the game ETQW have a small rendering > error in the team select menu. The model is rendered too bright when the > setting "Lightning quality" is set to normal. There's no problem when the > setting is changed to high. > > This doesn't seem to be a regression as it is present as far back as when S3TC > support was first added. In addition to this one I have found another rendering error that only appears with lighting normal on my 4890. On maps with sea - Island and Volacano, where the sky meets the sea there is a band of black/junk. It's thin from ground level, so best seen from high up. Doesn't seem to be a regression, though I only went back to April. My other settings are those you get with the high master setting + shadows on. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37662] Upgrade to version 2.6.38, disable the laptop display back light
https://bugzilla.kernel.org/show_bug.cgi?id=37662 Len Brown changed: What|Removed |Added CC||lenb at kernel.org Component|Power-Video |Video(DRI - non Intel) AssignedTo|acpi_power-video at kernel-bug |drivers_video-dri at kernel-bu |s.osdl.org |gs.osdl.org Product|ACPI|Drivers --- Comment #2 from Len Brown 2011-06-21 01:48:19 --- attachment is full of these: WARNING: at /build/buildd/linux-2.6.38/drivers/gpu/drm/radeon/radeon_gart.c:176 radeon_gart_bind+0x1ab/0x1c0 [radeon]() I don't see a linked launchpad report. moving this bug to DRM. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[git pull] drm radeon + nouveau fixes.
Hi Linus, just some nouveau and radeon fixes, nothing major, couple of fixes for rv730 since I plugged in the 30" monitor and it didn't work, one fix for the switchy GPU machines getting spammed when radeon shared an irq and some nouveau regression fixes from Ben. Dave. The following changes since commit de505e709ffb09a7382ca8e0d8c7dbb171ba5830: Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging (2011-06-18 20:33:31 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Alex Deucher (3): drm/radeon/kms/atom: fix duallink on some early DCE3.2 cards drm/radeon/kms: add missing param for dce3.2 DP transmitter setup drm/radeon/kms/r6xx+: voltage fixes Ben Skeggs (3): drm/nouveau: fix big-endian switch drm/nv50/disp: fix gamma with page flipping overlay turned on drm/nouveau: fix assumption that semaphore dmaobj is valid in x-chan sync Dave Airlie (3): drm/radeon: avoid warnings from r600/eg irq handlers on powered off card. Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drm/nouveau: drop leftover debugging Emil Velikov (1): drm/nouveau/pm: Prevent overflow in nouveau_perf_init() drivers/gpu/drm/nouveau/nouveau_acpi.c |1 - drivers/gpu/drm/nouveau/nouveau_fence.c | 59 +- drivers/gpu/drm/nouveau/nouveau_perf.c |5 +++ drivers/gpu/drm/nouveau/nouveau_state.c |4 +- drivers/gpu/drm/nouveau/nv50_display.c | 17 +++-- drivers/gpu/drm/radeon/evergreen.c | 23 +++- drivers/gpu/drm/radeon/r600.c| 18 + drivers/gpu/drm/radeon/radeon_atombios.c |4 ++ drivers/gpu/drm/radeon/radeon_encoders.c | 11 -- drivers/gpu/drm/radeon/rv770.c |3 ++ 10 files changed, 84 insertions(+), 61 deletions(-)
Re: Regression in panic
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote: Hi Dave, I think this change is causing a regression I'm seeing in panic. Before this change, I'd get a reboot on panic (we've configured as such). With this change, my machine gets wedged if the machine is running in X when the panic occurs. I traced the code flow to this: bust_spinlocks(0); -unblank_screen(); -do_unblank_screen(0); -vc-vc_sw-con_blank(vc, 0, 0); -fbcon_blank(vc, 0, 0); -update_screen(vc); -redraw_screen(vc, 0); -vc-vc_sw-con_switch(vc); -fbcon_switch(vc); -ops-update_start(info); -bit_update_start(info); -fb_pan_display(info, ops-var); -info-fbops-fb_pan_display(var, info); -drm_fb_helper_pan_display(var, info); -mutex_lock(dev-mode_config.mutex); *this blocks* With this change, there is now a lot going on in the panic path. Stuff that I'm not sure is safe when panicking. In addition to the mutex_lock, there is also a del_timer_sync() now happening in the context of panic(). I see this bug with a 2.6.38 kernel but did a quick scan of a newer kernels and did not see anything that changed in this path so I suspect its still there. Reverting this change fixes the regression. Chris Fowler reports something similar when running 2.6.38 by inducing a kernel panic via the oom killer -- see http://marc.info/?l=linux-kernelm=130805985022791. I've added him to the cc so he can participate in the thread and cherry-pick any fixes (last status update was that he was going to be trying 2.6.38.8). -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ 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: [RFC] Updated plane support v3
On 06/20/2011 10:11 PM, Jesse Barnes wrote: This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it. I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream. I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from). Thanks, Jesse Is it possible to position a plane above and below the normal crtc framebuffer? Plane z-order is unsigned, and I would assume 0 is default z-order. Applications will need to position planes above and below crtc normal framebuffer. Below when using a translucent or color keyed framebuffer, and above if framebuffer is opaque. So maybe add a one liner comment about z-order meaning and make it signed unless ordering should be solved in another way. And should it be possible to only define planes with no crtc framebuffer at all? Use case, for example letter boxed video on black background with small UI controls/subtitles. In this case it's not power efficient to have a fullscreen fb with mostly if not all transparent pixels. /BR /Marcus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 10:55, Marcus Lorentzon marcus.xm.lorent...@stericsson.com wrote: And should it be possible to only define planes with no crtc framebuffer at all? Use case, for example letter boxed video on black background with small UI controls/subtitles. In this case it's not power efficient to have a fullscreen fb with mostly if not all transparent pixels. I think we could shoe-horn this use-case into the current framework by using a special crtc-property ignore attached fb, use this default color instead. But I think this would be better done in a second step when we tackle atomic vsync flips across multiple planes and the underlying crtc - that might also require us to change certain properties in the same flip command. -Daniel -- 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 2/4] drm: add an fb creation ioctl that takes a pixel format
(Looping linux-media in)
On Thursday 09 June 2011 13:55:13 Alan Cox wrote:
You also don't need a headwer with a complete list of fourcc names in
it, that is the half the point of FourCC.
#define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8
RGB-3-3-2 */
See that V4L2 and v4l2? I'd rather not have them used in the drm
They are just helpers. The only thing that fourcc is is a 4 byte packed
value of four symbols.
interface, either a DRM_ variant or a FOURCC_ variant that removes the
V4L2. Also having it in a different include file to videodev2.h, so
yes we can pass FOURCC values but I'd rather we gave people a drm
specific way to generate them or make a generic set of macros that don't
include the V4L2 headers.
You need a macro to assemble fourcc codes and that seems to be about it -
so just an equivalent of the v4l2_fourcc macro.
Given that I plan to use the V4L2 FOURCCs in fbdev as well, it might indeed be
a good idea to split them from videodev2.h into their own header file.
Renaming the macros to make them V4L2-agnostic is a no-go, as that would break
the API. Manually maintaining separate sets of identical FOURCCs accross
subsystems also doesn't sound like a very good idea to me. We could create a
header that contains V4L2-agnostic FOURCC #define's, and generate a V4L2
header with the V4L2_ prefix, but I'm not sure it would be a good idea either.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #1 from Andy Furniss li...@andyfurniss.entadsl.com 2011-06-21 03:26:36 PDT --- (In reply to comment #0) Created an attachment (id=48132) -- (https://bugs.freedesktop.org/attachment.cgi?id=48132) screenshot of bug As previously mentioned in bug 36917, the game ETQW have a small rendering error in the team select menu. The model is rendered too bright when the setting Lightning quality is set to normal. There's no problem when the setting is changed to high. This doesn't seem to be a regression as it is present as far back as when S3TC support was first added. In addition to this one I have found another rendering error that only appears with lighting normal on my 4890. On maps with sea - Island and Volacano, where the sky meets the sea there is a band of black/junk. It's thin from ground level, so best seen from high up. Doesn't seem to be a regression, though I only went back to April. My other settings are those you get with the high master setting + shadows on. -- 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: [RFC] Updated plane support v3
On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it. I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream. I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from). Cool, thanks for this I'm just thinking through how I'd implement the driver part in omap drm driver.. so please bear with me if I'm misunderstanding.. In particular I'm thinking about being able to use a given video pipe (basically like a dma channel) as either framebuffer layer or overlay at various points in time, depending on how many displays are attached. Is the idea to use drm_plane *only* for overlay layer, and still use crtc-fb for the normal framebuffer layer? Or would/could a drm_plane also be used for main layer instead of crtc-fb? In this case, either userspace would have to know (which doesn't seem like a good idea for things like plymouth which use drm interface a bit generically). Or the driver would have to internally automatically hook up a drm_plane if it sees that userspace hasn't done this. I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC pass in -1 for fb_id, followed by one or more DRM_IOCTL_MODE_SETPLANE's, to set things up the new way (explicitly specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we know it is the old way, and driver automatically picks a drm_plane. BR, -R Thanks, Jesse ___ 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
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #2 from Vadim pt...@yandex.ru 2011-06-21 06:08:33 PDT --- Created an attachment (id=48227) View: https://bugs.freedesktop.org/attachment.cgi?id=48227 Review: https://bugs.freedesktop.org/review?bug=38440attachment=48227 [PATCH] r600g: fragment/vertex color clamping This patch should fix model brightness. -- 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: [RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 6:21 AM, Rob Clark robdcl...@gmail.com wrote:
On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This version adds both source and dest rect params to the set_plane
ioctl, and makes the source fixed point to support hardware that needs
it.
I haven't changed the name of the SNB implementation yet (per Chris's
suggestions) but will before it gets upstream.
I'd be interested to see whether these interfaces will work for other
hardware, so please take a close look at them and ideally implement them
on your hardware to make sure (see my userspace example code from
earlier posts if you want something to crib from).
Cool, thanks for this
I'm just thinking through how I'd implement the driver part in omap
drm driver.. so please bear with me if I'm misunderstanding..
In particular I'm thinking about being able to use a given video pipe
(basically like a dma channel) as either framebuffer layer or overlay
at various points in time, depending on how many displays are
attached. Is the idea to use drm_plane *only* for overlay layer, and
still use crtc-fb for the normal framebuffer layer?
Or would/could a drm_plane also be used for main layer instead of
crtc-fb? In this case, either userspace would have to know (which
doesn't seem like a good idea for things like plymouth which use drm
interface a bit generically). Or the driver would have to internally
automatically hook up a drm_plane if it sees that userspace hasn't
done this.
I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC
pass in -1 for fb_id, followed by one or more
DRM_IOCTL_MODE_SETPLANE's, to set things up the new way (explicitly
specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we
know it is the old way, and driver automatically picks a drm_plane.
just thinking through this a bit more.. the idea is that for drivers
w/ DRM_SUPPORTS_PLANES[1], there is no fb hooked directly to crtc.
And support for userspace that is not aware of planes could be, I
think, mostly in the kms core, although I'm just thinking through how
disruptive that would be..
I think if we add a crtc-funcs-get_primary_plane() to be implemented
by drivers that use planes in cases where userspace does not know
about planes. It would be used to get (and if necessary, assign) a
drm_plane to a drm_crtc, then we can do things like:
handle _SETCRTC from userspace that doesn't understand planes:
-
@@ -1580,7 +1580,14 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.mode = mode;
set.connectors = connector_set;
set.num_connectors = crtc_req-count_connectors;
- set.fb = fb;
+ if (fb (dev-driver-driver_features DRM_SUPPORTS_PLANES)) {
+ /* pass fb to the primary plane for compatibility */
+ struct drm_plane *plane =
+ crtc-funcs-get_primary_plane(crtc);
+ set.plane = plane;
+ plane-funcs-set_config(set);
+ } else {
+ set.fb = fb;
+ }
ret = crtc-funcs-set_config(set);
out:
-
or page flip ioctl from userspace that doesn't understand planes:
-
@@ -2645,7 +2652,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}
- ret = crtc-funcs-page_flip(crtc, fb, e);
+ if (dev-driver-driver_features DRM_SUPPORTS_PLANES) {
+ struct drm_plane *plane =
+ crtc-funcs-get_primary_plane(crtc);
+ ret = plane-funcs-page_flip(plane, fb, e);
+ } else {
+ ret = crtc-funcs-page_flip(crtc, fb, e);
+ }
+
if (ret) {
spin_lock_irqsave(dev-event_lock, flags);
file_priv-event_space += sizeof e-event;
-
It doesn't look like there are *that* many places where crtc-fb is
reference, but I've not gone through all of them.. I'm not sure if
this sort of change would be too intrusive.
BR,
-R
--
[1] or maybe DRM_MANDATORY_PLANES if there are some drivers that would
use a hybrid model of fb either direct to drm_crtc, or indirect via a
drm_plane
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #3 from Sven Arvidsson s...@whiz.se 2011-06-21 06:49:32 PDT --- (In reply to comment #2) This patch should fix model brightness. Indeed it does. Wow, you have really been rocking with all the fixes for r600g, thanks! :) Andy, if the sky/sea issue isn't solved with this, can you post a screenshot? -- 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 38440] ETQW: Model in team select rendering too bright
https://bugs.freedesktop.org/show_bug.cgi?id=38440 --- Comment #4 from Andy Furniss li...@andyfurniss.entadsl.com 2011-06-21 07:20:19 PDT --- (In reply to comment #2) Created an attachment (id=48227) View: https://bugs.freedesktop.org/attachment.cgi?id=48227 Review: https://bugs.freedesktop.org/review?bug=38440attachment=48227 [PATCH] r600g: fragment/vertex color clamping This patch should fix model brightness. It fixes both my issues with normal lighting on rv790 - thanks. -- 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: Regression in panic
On Mon, Jun 20, 2011 at 4:03 PM, David Rientjes rient...@google.com wrote: On Mon, 20 Jun 2011, Mandeep Singh Baines wrote: Hi Dave, I think this change is causing a regression I'm seeing in panic. Before this change, I'd get a reboot on panic (we've configured as such). With this change, my machine gets wedged if the machine is running in X when the panic occurs. I traced the code flow to this: bust_spinlocks(0); -unblank_screen(); -do_unblank_screen(0); -vc-vc_sw-con_blank(vc, 0, 0); -fbcon_blank(vc, 0, 0); -update_screen(vc); -redraw_screen(vc, 0); -vc-vc_sw-con_switch(vc); -fbcon_switch(vc); -ops-update_start(info); -bit_update_start(info); -fb_pan_display(info, ops-var); -info-fbops-fb_pan_display(var, info); -drm_fb_helper_pan_display(var, info); -mutex_lock(dev-mode_config.mutex); *this blocks* With this change, there is now a lot going on in the panic path. Stuff that I'm not sure is safe when panicking. In addition to the mutex_lock, there is also a del_timer_sync() now happening in the context of panic(). I see this bug with a 2.6.38 kernel but did a quick scan of a newer kernels and did not see anything that changed in this path so I suspect its still there. Reverting this change fixes the regression. Chris Fowler reports something similar when running 2.6.38 by inducing a kernel panic via the oom killer -- see http://marc.info/?l=linux-kernelm=130805985022791. I've added him to the cc so he can participate in the thread and cherry-pick any fixes (last status update was that he was going to be trying 2.6.38.8). One potential fix might be to convert the mutex_lock to a try if oops_in_progress but I suspect oops_in_progress checks may be needed in a bunch of other places in the screen_unblank code path. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ 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
Regression in panic
On Tue, Jun 22, 2010 at 8:12 PM, Dave Airlie airl...@gmail.com wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
Jesse's initial patch commit said:
At panic time (i.e. when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.
So make sure we try to unblank and update the display if called from a
panic context.
I've enhanced this to add a flag to the vc that console layer can set
to indicate they want this behaviour to occur. This also adds support
to fbcon for that flag and adds an fb flag for drivers to indicate
they want to use the support. It enables this for KMS drivers.
Signed-off-by: Dave Airlie airl...@redhat.com
Hi Dave,
I think this change is causing a regression I'm seeing in panic.
Before this change, I'd get a
reboot on panic (we've configured as such).
With this change, my machine gets wedged if the machine is running in
X when the panic occurs.
I traced the code flow to this:
bust_spinlocks(0);
-unblank_screen();
-do_unblank_screen(0);
-vc-vc_sw-con_blank(vc, 0, 0);
-fbcon_blank(vc, 0, 0);
-update_screen(vc);
-redraw_screen(vc, 0);
-vc-vc_sw-con_switch(vc);
-fbcon_switch(vc);
-ops-update_start(info);
-bit_update_start(info);
-fb_pan_display(info, ops-var);
-info-fbops-fb_pan_display(var, info);
-drm_fb_helper_pan_display(var, info);
-mutex_lock(dev-mode_config.mutex); *this blocks*
With this change, there is now a lot going on in the panic path. Stuff
that I'm not sure is safe when panicking. In addition to the
mutex_lock, there is also a del_timer_sync()
now happening in the context of panic().
I see this bug with a 2.6.38 kernel but did a quick scan of a newer
kernels and did not see anything that changed in this path so I
suspect its still there.
Reverting this change fixes the regression.
Regards,
Mandeep
---
drivers/char/vt.c | 13 +
drivers/gpu/drm/i915/intel_fb.c | 4 +---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 +
drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
drivers/video/console/fbcon.c | 4 +++-
include/linux/console_struct.h | 1 +
include/linux/fb.h | 4
include/linux/vt_kern.h | 7 +++
8 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index 7cdb6ee..6e04c9e 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -698,7 +698,10 @@ void redraw_screen(struct vc_data *vc, int is_switch)
update_attr(vc);
clear_buffer_attributes(vc);
}
- if (update vc-vc_mode != KD_GRAPHICS)
+
+ /* Forcibly update if we're panicing */
+ if ((update vc-vc_mode != KD_GRAPHICS) ||
+ vt_force_oops_output(vc))
do_update_region(vc, vc-vc_origin,
vc-vc_screenbuf_size / 2);
}
set_cursor(vc);
@@ -736,6 +739,7 @@ static void visual_init(struct vc_data *vc, int num, int
init)
vc-vc_hi_font_mask = 0;
vc-vc_complement_mask = 0;
vc-vc_can_do_color = 0;
+ vc-vc_panic_force_write = false;
vc-vc_sw-con_init(vc, init);
if (!vc-vc_complement_mask)
vc-vc_complement_mask = vc-vc_can_do_color ? 0x7700 : 0x0800;
@@ -2498,7 +2502,7 @@ static void vt_console_print(struct console *co, const
char *b, unsigned count)
goto quit;
}
- if (vc-vc_mode != KD_TEXT)
+ if (vc-vc_mode != KD_TEXT !vt_force_oops_output(vc))
goto quit;
/* undraw cursor first */
@@ -3703,7 +3707,8 @@ void do_unblank_screen(int leaving_gfx)
return;
}
vc = vc_cons[fg_console].d;
- if (vc-vc_mode != KD_TEXT)
+ /* Try to unblank in oops case too */
+ if (vc-vc_mode != KD_TEXT !vt_force_oops_output(vc))
return; /* but leave console_blanked != 0 */
if (blankinterval) {
@@ -3712,7 +3717,7 @@ void do_unblank_screen(int leaving_gfx)
}
console_blanked = 0;
- if (vc-vc_sw-con_blank(vc, 0, leaving_gfx))
+ if (vc-vc_sw-con_blank(vc, 0, leaving_gfx) ||
vt_force_oops_output(vc))
/* Low-level driver cannot restore - do it ourselves */
update_screen(vc);
if (console_blank_hook)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index c3c5052..bd5d87a 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -128,7 +128,7 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
strcpy(info-fix.id, inteldrmfb);
-
Reverting rc6 by default
Hi, I wanted to try the new 3.0 Linux Kernel, and I got stucked for a freeze at the start of X. I have bisected the problem and the error was on commit a51f7a6, wich enable rc6 by default (some time ago I have sent another bug about that). I have reverted the commit (the complete patch is attached) and now everything works great. Now, I have a Lenovo X201s, and if you need more information for debugging purpose just let me know, otherwise just apply the patch attached (on top of -rc4). If you prefer I can send the patch using git-send-email. Thanks Bye Francesco From 284c154625e991be963ae3080faefc8aa4f22d01 Mon Sep 17 00:00:00 2001 From: Francesco Allertsen fallert...@gmail.com Date: Tue, 21 Jun 2011 15:46:32 +0200 Subject: [PATCH] Revert drm/i915: enable rc6 by default This reverts commit a51f7a66fb5e4af5ec4286baef940d06594b59d2. With rc6 enabled by default there is a freeze in the Lenovo X201s laptop. Signed-off-by: Francesco Allertsen fallert...@gmail.com --- drivers/gpu/drm/i915/i915_drv.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0defd42..0017f7a 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -52,7 +52,7 @@ module_param_named(powersave, i915_powersave, int, 0600); unsigned int i915_semaphores = 0; module_param_named(semaphores, i915_semaphores, int, 0600); -unsigned int i915_enable_rc6 = 1; +unsigned int i915_enable_rc6 = 0; module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600); unsigned int i915_enable_fbc = 0; -- 1.7.5.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reverting rc6 by default
On Tue, 21 Jun 2011 16:21:33 +0200, Francesco Allertsen fallert...@gmail.com wrote: Non-text part: multipart/mixed Now, I have a Lenovo X201s, and if you need more information for debugging purpose just let me know, otherwise just apply the patch attached (on top of -rc4). Given the number of X201s machines running this kernel (like the one I'm using right now), I'd love to get this fixed for you instead of disabling rc6 -- rc6 is worth a ton of power savings. Please describe your configuration (which OS, which X and i915 driver versions) and then send along a kernel log with drm.debug=0x04 so we can see what's going on. If you stick these in a bugzilla entry, we'll not lose track of them. -- keith.pack...@intel.com pgpmMdPcqtnqS.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fix mesa build from tarball
Hi
The following patch fixes building mesa from tarball (generated from git):
- one Makefile disappeared (Makefile.template)
- two other were missing (src/mesa/drivers/dri/Makefile.{defines,targets}
Please apply
Thx
fix-build-from-tarball.diff
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim rei...@googlemail.com wrote:
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk
Does this patch fix the issue:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4a9a8b71e12d41abb71c4e741bff524f016cfef4
Alex
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 +
drivers/gpu/drm/radeon/radeon_display.c | 11 +
drivers/gpu/drm/radeon/radeon_i2c.c | 60
drivers/gpu/drm/radeon/radeon_mode.h | 1 +
4 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..7a76e45 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
if (radeon_connector-ddc_bus)
dret = radeon_ddc_probe(radeon_connector);
+
+ /* Asus M2A-VM HDMI DDC quirk:
+ * Some integrated ATI Radeon chipset implementations (e. g. Asus
+ * M2A-VM HDMI) indicate the availability of a DDC even when there's
+ * no monitor connected.The following check prevents drm_get_edid()
+ * and drm_edid_block_valid() of periodically dumping data and kernel
+ * errors into the logs and onto the terminal, which would lead to an
+ * unacceptable system behaviour */
+ if (dret connector-connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ dret = radeon_ddc_edid_probe(radeon_connector);
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+ Seems to just force drm to dump EDID errors
+ to kernel logs */
list_for_each_entry(drm_connector,
dev-mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
*connector)
if (!radeon_connector-ddc_bus)
return -1;
edid = drm_get_edid(connector, radeon_connector-ddc_bus-adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+ * instead of periodically dumping data and kernel errors into the
+ * logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO(Radeon display connector %s: Found valid EDID,
+ drm_get_connector_name(connector));
kfree(edid);
+ } else {
+ DRM_INFO(Radeon display connector %s: No display connected
or invalid EDID,
+ drm_get_connector_name(connector));
}
return ret;
}
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 781196d..1d6decd 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -63,6 +63,66 @@ bool radeon_ddc_probe(struct radeon_connector
*radeon_connector)
return false;
}
+/**
+ * Probe EDID information via I2C.
+ *
+ * \param adapter : i2c device adaptor
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Try to fetch EDID information by calling i2c driver function and
+ * probe for EDID header information.
+ *
+ * Remark:
+ * This function has been added, because there are integrated ATI Radeon
+ * chipset implementations (e. g. Asus M2A-VM HDMI that indicate the
+ * availability of a DDC even when there's no monitor connected.
+ * In this case, drm_get_edid and drm_edid_block_valid periodically dump
+ * data and kernel errors into the logs and onto the terminal, which lead to
+ * an unacceptable system behaviour.
+ */
+bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector)
+{
+ u8 out_buf[] = { 0x0, 0x0};
+ u8 block[20];
+ int ret;
+ struct i2c_msg msgs[] = {
Re: Reverting rc6 by default
On Tue, 21 Jun 2011 17:52:05 +0200, Francesco Allertsen fallert...@gmail.com wrote: If you prefer that I open a bug on the kernel bugzilla to put all the informations no problem. I'm more interested in seeing how the dmesg output differs between the working state (rc6=0) and the broken state (rc6=1). Or is the machine not accessible over ssh once you've started X? -- keith.pack...@intel.com pgpAElafPEIgV.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
On Tue, 21 Jun 2011 10:55:39 +0200 Marcus Lorentzon marcus.xm.lorent...@stericsson.com wrote: On 06/20/2011 10:11 PM, Jesse Barnes wrote: This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it. I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream. I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from). Thanks, Jesse Is it possible to position a plane above and below the normal crtc framebuffer? Plane z-order is unsigned, and I would assume 0 is default z-order. Applications will need to position planes above and below crtc normal framebuffer. Below when using a translucent or color keyed framebuffer, and above if framebuffer is opaque. I was thinking 0 would be the bottom layer. But either way we don't have a way of getting the primary plane z position atm, so it'll be hard to position a new plane above or below the main plane... I'm ok with a signed value here, but the real meaning will be defined by a new ioctl we use to get plane blending restrictions, z order, and such. So maybe add a one liner comment about z-order meaning and make it signed unless ordering should be solved in another way. And should it be possible to only define planes with no crtc framebuffer at all? Use case, for example letter boxed video on black background with small UI controls/subtitles. In this case it's not power efficient to have a fullscreen fb with mostly if not all transparent pixels. A particular driver may be able to expose that somehow, maybe by allowing clients to define a special fb handle that can be used to indicate no plane should be bound to the CRTC as the primary plane. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
On Tue, 21 Jun 2011 06:21:11 -0500 Rob Clark robdcl...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it. I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream. I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from). Cool, thanks for this I'm just thinking through how I'd implement the driver part in omap drm driver.. so please bear with me if I'm misunderstanding.. In particular I'm thinking about being able to use a given video pipe (basically like a dma channel) as either framebuffer layer or overlay at various points in time, depending on how many displays are attached. Is the idea to use drm_plane *only* for overlay layer, and still use crtc-fb for the normal framebuffer layer? Given the structure of the current KMS API, a CRTC implies a plane of some sort, but I don't think the driver is restricted to using the same plane for a given CRTC forever; it could allocate and switch them around depending on usage, with planes beyond what's currently associated with the CRTC exposed through this interface. I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC pass in -1 for fb_id, followed by one or more DRM_IOCTL_MODE_SETPLANE's, to set things up the new way (explicitly specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we know it is the old way, and driver automatically picks a drm_plane. Yeah that might work; we'd probably want a new GETPARAM flag to indicate support for this... The tough part is doing it in such a way that we don't break existing userspace. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 +
drivers/gpu/drm/radeon/radeon_display.c| 11 +
drivers/gpu/drm/radeon/radeon_i2c.c| 60
drivers/gpu/drm/radeon/radeon_mode.h |1 +
4 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..7a76e45 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
if (radeon_connector-ddc_bus)
dret = radeon_ddc_probe(radeon_connector);
+
+ /* Asus M2A-VM HDMI DDC quirk:
+* Some integrated ATI Radeon chipset implementations (e. g. Asus
+* M2A-VM HDMI) indicate the availability of a DDC even when there's
+* no monitor connected.The following check prevents drm_get_edid()
+* and drm_edid_block_valid() of periodically dumping data and kernel
+* errors into the logs and onto the terminal, which would lead to an
+* unacceptable system behaviour */
+ if (dret connector-connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ dret = radeon_ddc_edid_probe(radeon_connector);
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+ Seems to just force drm to dump EDID errors
+ to kernel logs */
list_for_each_entry(drm_connector,
dev-mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector *connector)
if (!radeon_connector-ddc_bus)
return -1;
edid = drm_get_edid(connector, radeon_connector-ddc_bus-adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+* instead of periodically dumping data and kernel errors into the
+* logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO(Radeon display connector %s: Found valid EDID,
+ drm_get_connector_name(connector));
kfree(edid);
+ } else {
+ DRM_INFO(Radeon display connector %s: No display connected or
invalid EDID,
+ drm_get_connector_name(connector));
}
return ret;
}
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 781196d..1d6decd 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -63,6 +63,66 @@ bool radeon_ddc_probe(struct radeon_connector
*radeon_connector)
return false;
}
+/**
+ * Probe EDID information via I2C.
+ *
+ * \param adapter : i2c device adaptor
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Try to fetch EDID information by calling i2c driver function and
+ * probe for EDID header information.
+ *
+ * Remark:
+ * This function has been added, because there are integrated ATI Radeon
+ * chipset implementations (e. g. Asus M2A-VM HDMI that indicate the
+ * availability of a DDC even when there's no monitor connected.
+ * In this case, drm_get_edid and drm_edid_block_valid periodically dump
+ * data and kernel errors into the logs and onto the terminal, which lead to
+ * an unacceptable system behaviour.
+ */
+bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector)
+{
+ u8 out_buf[] = { 0x0, 0x0};
+ u8 block[20];
+ int ret;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = 0x50,
+ .flags = 0,
+ .len= 1,
+ .buf= out_buf,
+ }, {
+ .addr = 0x50,
+ .flags = I2C_M_RD,
+ .len= 20,
+
Re: Reverting rc6 by default
On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: I'm more interested in seeing how the dmesg output differs between the working state (rc6=0) and the broken state (rc6=1). Or is the machine not accessible over ssh once you've started X? I got a complete freeze when I start X. I have tried to log the output of dmesg via ethernet using netconole, but it doesn't log the drm debug. Is there another parameter to append at the kernel to send via ethernet also the debug? Bye Francesco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 3.0-rc4
* Nick Bowler -- Tuesday 21 June 2011: We're at -rc4 now, but it seems that the following patch (drm/i915: add missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made it in yet? http://permalink.gmane.org/gmane.linux.kernel/1148279 The i915 driver has been broken since 3.0-rc1 without this fix, which has been available for 3 weeks now. Keith has suggested a better fix (https://lkml.org/lkml/2011/6/6/560), but for some reason it still hasn't made it into the kernel. m. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 --- Comment #4 from Alex Deucher ag...@yahoo.com 2011-06-21 10:48:14 PDT --- What kernel are you using? -- 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: Reverting rc6 by default
On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen fallert...@gmail.com wrote: On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: I'm more interested in seeing how the dmesg output differs between the working state (rc6=0) and the broken state (rc6=1). Or is the machine not accessible over ssh once you've started X? I got a complete freeze when I start X. I have tried to log the output of dmesg via ethernet using netconole, but it doesn't log the drm debug. Is there another parameter to append at the kernel to send via ethernet also the debug? I don't know how to get the drm debug sent to ethernet; perhaps someone else does? Btw, can you send along the output of dmidecode? I'm wondering what version of the BIOS you've got. We've seen some pretty strange behaviour on X201s with earlier BIOS versions which have been fixed with newer versions. For comparison, my X201s says: # dmidecode 2.9 SMBIOS 2.6 present. 78 structures occupying 2868 bytes. Table at 0x000E0010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: LENOVO Version: 6QET46V1 (1.16 ) Release Date: 07/05/2010 Address: 0xE Runtime Size: 128 kB ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 3.5/720 KB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.22 Firmware Revision: 1.9 -- keith.pack...@intel.com pgprRmXNKAKME.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often. In
order to handle the case where the event is read off the queue by
another thread before we dequeue the event, we delay the actual checking
for EAGAIN to under the spinlock and so inline drm_dequeue_event().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_fops.c | 76 +---
1 files changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2ec7d48..d248366 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -580,61 +580,57 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
-static bool
-drm_dequeue_event(struct drm_file *file_priv,
- size_t total, size_t max, struct drm_pending_event **out)
+ssize_t drm_read(struct file *filp, char __user *buffer,
+size_t count, loff_t *offset)
{
+ struct drm_file *file_priv = filp-private_data;
struct drm_device *dev = file_priv-minor-dev;
struct drm_pending_event *e;
unsigned long flags;
- bool ret = false;
-
- spin_lock_irqsave(dev-event_lock, flags);
+ ssize_t ret;
+ int err;
- *out = NULL;
- if (list_empty(file_priv-event_list))
- goto out;
- e = list_first_entry(file_priv-event_list,
-struct drm_pending_event, link);
- if (e-event-length + total max)
- goto out;
+ if ((filp-f_flags O_NONBLOCK) == 0) {
+ ret = wait_event_interruptible(file_priv-event_wait,
+
!list_empty(file_priv-event_list));
+ if (ret 0)
+ return ret;
+ }
- file_priv-event_space += e-event-length;
- list_del(e-link);
- *out = e;
- ret = true;
+ ret = err = 0;
+ spin_lock_irqsave(dev-event_lock, flags);
+ do {
+ if (list_empty(file_priv-event_list)) {
+ if (flip-f_flags O_NONBLOCK)
+ err = -EAGAIN;
+ break;
+ }
-out:
- spin_unlock_irqrestore(dev-event_lock, flags);
- return ret;
-}
+ e = list_first_entry(file_priv-event_list,
+struct drm_pending_event, link);
+ if (e-event-length + ret max) {
+ err = -EINVAL;
+ break;
+ }
-ssize_t drm_read(struct file *filp, char __user *buffer,
-size_t count, loff_t *offset)
-{
- struct drm_file *file_priv = filp-private_data;
- struct drm_pending_event *e;
- size_t total;
- ssize_t ret;
+ file_priv-event_space += e-event-length;
+ list_del(e-link);
- ret = wait_event_interruptible(file_priv-event_wait,
- !list_empty(file_priv-event_list));
- if (ret 0)
- return ret;
+ spin_unlock_irqrestore(dev-event_lock, flags);
- total = 0;
- while (drm_dequeue_event(file_priv, total, count, e)) {
- if (copy_to_user(buffer + total,
-e-event, e-event-length)) {
- total = -EFAULT;
+ if (copy_to_user(buffer + ret, e-event, e-event-length)) {
+ err = -EFAULT;
break;
}
- total += e-event-length;
+ ret += e-event-length;
e-destroy(e);
- }
- return total;
+ spin_lock_irqsave(dev-event_lock, flags);
+ } while (1);
+ spin_unlock_irqrestore(dev-event_lock, flags);
+
+ return ret ? ret : err;
}
EXPORT_SYMBOL(drm_read);
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reverting rc6 by default
On Tue, 21 Jun 2011 11:04:15 -0700 Keith Packard kei...@keithp.com wrote: On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen fallert...@gmail.com wrote: On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote: I'm more interested in seeing how the dmesg output differs between the working state (rc6=0) and the broken state (rc6=1). Or is the machine not accessible over ssh once you've started X? I got a complete freeze when I start X. I have tried to log the output of dmesg via ethernet using netconole, but it doesn't log the drm debug. Is there another parameter to append at the kernel to send via ethernet also the debug? I don't know how to get the drm debug sent to ethernet; perhaps someone else does? Use netconsole. Documentation/networking/netconsole.txt has all the gory details. -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Dear Alex, yes, the proposed fix should also fix the 'drm/radeon: workaround a hw bug on some radeon chipsets with all-0 EDIDs.' issue. The trick is, that we check within the Radeon domain directly on i2c interface level, if an EDID can be retrieved at all, before we hand over to the main drm edid functions. If you can provide some logs from Dave, I can double-check. Regards, Thomas On Tue, Jun 21, 2011 at 11:31 AM, Thomas Reim rei...@googlemail.com wrote: Some integrated ATI Radeon chipset implementations (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even when there's no monitor connected. In this case, drm_get_edid and drm_edid_block_valid periodically dump data and kernel errors into system log files and onto terminals, which lead to an unacceptable system behaviour. Tested since kernel 2.35 on Asus M2A-VM HDMI board Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk Does this patch fix the issue: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=4a9a8b71e12d41abb71c4e741bff524f016cfef4 Alex --- drivers/gpu/drm/radeon/radeon_connectors.c | 10 + drivers/gpu/drm/radeon/radeon_display.c| 11 + drivers/gpu/drm/radeon/radeon_i2c.c| 60 drivers/gpu/drm/radeon/radeon_mode.h |1 + 4 files changed, 82 insertions(+), 0 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38478] r600g fails to identify the screen refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=38478 --- Comment #5 from Stephen Kitt st...@sk2.org 2011-06-21 11:41:50 PDT --- I'm running Debian's linux-image-2.6.39-2-686-pae 2.6.39-2, which corresponds to 2.6.39.1. -- 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 34822] Blank display on Toshiba laptop C670D-10C using AMD E-240 Palm chip
https://bugzilla.kernel.org/show_bug.cgi?id=34822 --- Comment #17 from Anisse Astier ani...@astier.eu 2011-06-21 14:43:04 --- It's the same patch as in comment 11 which I reported tested and non-working in comment 14 . I just tested 3.0-rc4, screen is still blank and/or no backlight. The only improvement (difference ?) seems to be in modelines detection. --- Comment #18 from Alex Deucher alexdeuc...@gmail.com 2011-06-21 18:47:40 --- There are a number of additional fixes in 3.0-rc4. Do any of them help? -- 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: Reverting rc6 by default
On Tue, Jun 21, 2011 at 11:04:15AM -0700, Keith Packard wrote: Btw, can you send along the output of dmidecode? I'm wondering what version of the BIOS you've got. We've seen some pretty strange behaviour on X201s with earlier BIOS versions which have been fixed with newer versions. Here is mine: # dmidecode 2.11 SMBIOS 2.6 present. 78 structures occupying 2864 bytes. Table at 0x000E0010. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: LENOVO Version: 6QET52WW (1.22 ) Release Date: 08/23/2010 Address: 0xE Runtime Size: 128 kB ROM Size: 8192 kB Characteristics: PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 3.5/720 kB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 1.34 Firmware Revision: 1.5 Bye Francesco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reverting rc6 by default
On Tue, Jun 21, 2011 at 11:29:41AM -0700, Jesse Barnes wrote: Use netconsole. Documentation/networking/netconsole.txt has all the gory details. I have used netconsole, with that documentation, but it doesn't show me the drm debug messages, only the other dmesg messages, and I don't know why. Bye Francesco ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reverting rc6 by default
On Tue, 21 Jun 2011 20:47:57 +0200, Francesco Allertsen fallert...@gmail.com wrote: Version: 6QET52WW (1.22 ) Release Date: 08/23/2010 Thanks. I'll see if I can't get an X201s upgraded to this version and see if we can reproduce the problem you're having... -- keith.pack...@intel.com pgp0xeefBxljw.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Reverting rc6 by default
On Tue, Jun 21, 2011 at 08:48:55PM +0200, Francesco Allertsen wrote: On Tue, Jun 21, 2011 at 11:29:41AM -0700, Jesse Barnes wrote: Use netconsole. Documentation/networking/netconsole.txt has all the gory details. I have used netconsole, with that documentation, but it doesn't show me the drm debug messages, only the other dmesg messages, and I don't know why. Try to run dmesg -n 8 before loading the module. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38353] r600g : lock in desktop display durring piglit test
https://bugs.freedesktop.org/show_bug.cgi?id=38353 --- Comment #5 from XoD xodd...@gmail.com 2011-06-21 12:23:39 PDT --- Created an attachment (id=48250) -- (https://bugs.freedesktop.org/attachment.cgi?id=48250) syslog_radeon I add syslog file were only lines with radeon are keep. I have launch 2 times piglit test, each time we can see some drm errors. -- 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 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Hi Thomas,
On Tue, 21 Jun 2011 17:31:45 +0200, Thomas Reim wrote:
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid and drm_edid_block_valid
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
I don't like your implementation (see below.) Also, your comment above
suggests that your main problem here is that logging is too verbose.
Maybe that's what you should be fixing.
Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk
---
drivers/gpu/drm/radeon/radeon_connectors.c | 10 +
drivers/gpu/drm/radeon/radeon_display.c| 11 +
drivers/gpu/drm/radeon/radeon_i2c.c| 60
drivers/gpu/drm/radeon/radeon_mode.h |1 +
4 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..7a76e45 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -828,6 +828,16 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
if (radeon_connector-ddc_bus)
dret = radeon_ddc_probe(radeon_connector);
+
+ /* Asus M2A-VM HDMI DDC quirk:
+ * Some integrated ATI Radeon chipset implementations (e. g. Asus
+ * M2A-VM HDMI) indicate the availability of a DDC even when there's
+ * no monitor connected.The following check prevents drm_get_edid()
+ * and drm_edid_block_valid() of periodically dumping data and kernel
+ * errors into the logs and onto the terminal, which would lead to an
+ * unacceptable system behaviour */
+ if (dret connector-connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ dret = radeon_ddc_edid_probe(radeon_connector);
I don't like this. radeon_ddc_edid_probe() is partly redundant with
radeon_ddc_probe() and also partly redundant with drm_get_edid() and
drm_edid_is_valid(). It will add yet another round of I2C transactions,
and these transactions are slow, so the fewer we have at driver load
time, the happier we are. This is even more true these days when every
graphics card gets 8 I2C buses created.
If nothing else, you should call radeon_ddc_edid_probe() instead of,
not after, radeon_ddc_probe(), to save a transaction.
But the root cause is most certainly that the underlying I2C bus is not
working. I bet that SDA is stuck low, which causes every sent byte
(including the slave address) to look like it was acked [1], and every
read byte to be zero. So the key problem is that radeon_ddc_probe()
isn't able to detect this case. Either the bus should be tested first
(see i2c-algo-bit for a test function) or radeon_ddc_probe() should be
improved to detect this case. It doesn't have to go to the extent of
your new radeon_ddc_edid_probe() function. It would be enough to read 2
bytes from the supposed EDID EEPROM, and check that they are not both 0.
Properly checking for stuck bus would have the advantage that you don't
have to retest later (contrary to missing EDID which can show up later
when a monitor gets plugged.)
[1] Incidentally I had a similar case reported a few days ago:
http://lists.lm-sensors.org/pipermail/lm-sensors/2011-June/032959.html
Further comments below are just for completeness, as I don't think the
route your took is appropriate.
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+Seems to just force drm to dump EDID errors
+to kernel logs */
list_for_each_entry(drm_connector,
dev-mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
*connector)
if (!radeon_connector-ddc_bus)
return -1;
edid = drm_get_edid(connector, radeon_connector-ddc_bus-adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+ * instead of periodically dumping data and kernel errors into the
+ * logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO(Radeon display connector %s: Found valid EDID,
+
[Bug 38452] ETQW: Renders garbage in some places
https://bugs.freedesktop.org/show_bug.cgi?id=38452 --- Comment #1 from Vadim pt...@yandex.ru 2011-06-21 13:15:53 PDT --- Created an attachment (id=48255) View: https://bugs.freedesktop.org/attachment.cgi?id=48255 Review: https://bugs.freedesktop.org/review?bug=38452attachment=48255 [PATCH] mesa: fix range check in _mesa_validate_DrawElements It's a bug in ETQW. With this patch mesa will ignore invalid calls instead of rendering garbage, but it won't fix the real bug in the game. The bug is related to index buffers and setting r_useIndexBuffers to 1 works for me. If it doesn't help, then it's another bug or you probably need to restart the game after changing that value. -- 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
[PATCH] drm: Honour O_NONBLOCK on the device for reading events
Otherwise drmHandleEvent will block if accidentally read too often. In
order to handle the case where the event is read off the queue by
another thread before we dequeue the event, we delay the actual checking
for EAGAIN to under the spinlock and so inline drm_dequeue_event().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
v3: Compilation. Remember to at least test changes before hitting send.
-Chris
---
drivers/gpu/drm/drm_fops.c | 79 +---
1 files changed, 38 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 2ec7d48..8efc07f 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -580,61 +580,58 @@ int drm_release(struct inode *inode, struct file *filp)
}
EXPORT_SYMBOL(drm_release);
-static bool
-drm_dequeue_event(struct drm_file *file_priv,
- size_t total, size_t max, struct drm_pending_event **out)
+ssize_t drm_read(struct file *filp, char __user *buffer,
+size_t count, loff_t *offset)
{
+ struct drm_file *file_priv = filp-private_data;
struct drm_device *dev = file_priv-minor-dev;
struct drm_pending_event *e;
unsigned long flags;
- bool ret = false;
+ ssize_t ret;
+ int err;
- spin_lock_irqsave(dev-event_lock, flags);
+ if ((filp-f_flags O_NONBLOCK) == 0) {
+ ret = wait_event_interruptible(file_priv-event_wait,
+
!list_empty(file_priv-event_list));
+ if (ret 0)
+ return ret;
+ }
- *out = NULL;
- if (list_empty(file_priv-event_list))
- goto out;
- e = list_first_entry(file_priv-event_list,
-struct drm_pending_event, link);
- if (e-event-length + total max)
- goto out;
+ ret = err = 0;
+ spin_lock_irqsave(dev-event_lock, flags);
+ do {
+ if (list_empty(file_priv-event_list)) {
+ if (filp-f_flags O_NONBLOCK)
+ err = -EAGAIN;
+ goto unlock;
+ }
- file_priv-event_space += e-event-length;
- list_del(e-link);
- *out = e;
- ret = true;
+ e = list_first_entry(file_priv-event_list,
+struct drm_pending_event, link);
+ if (e-event-length + ret count) {
+ err = -EINVAL;
+ goto unlock;
+ }
-out:
- spin_unlock_irqrestore(dev-event_lock, flags);
- return ret;
-}
+ file_priv-event_space += e-event-length;
+ list_del(e-link);
-ssize_t drm_read(struct file *filp, char __user *buffer,
-size_t count, loff_t *offset)
-{
- struct drm_file *file_priv = filp-private_data;
- struct drm_pending_event *e;
- size_t total;
- ssize_t ret;
+ spin_unlock_irqrestore(dev-event_lock, flags);
- ret = wait_event_interruptible(file_priv-event_wait,
- !list_empty(file_priv-event_list));
- if (ret 0)
- return ret;
-
- total = 0;
- while (drm_dequeue_event(file_priv, total, count, e)) {
- if (copy_to_user(buffer + total,
-e-event, e-event-length)) {
- total = -EFAULT;
- break;
+ if (copy_to_user(buffer + ret, e-event, e-event-length)) {
+ err = -EFAULT;
+ goto out;
}
- total += e-event-length;
+ ret += e-event-length;
e-destroy(e);
- }
- return total;
+ spin_lock_irqsave(dev-event_lock, flags);
+ } while (1);
+unlock:
+ spin_unlock_irqrestore(dev-event_lock, flags);
+out:
+ return ret ? ret : err;
}
EXPORT_SYMBOL(drm_read);
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+- FB_TYPE_PLANES
You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and
FB_TYPE_VGA_PLANES. Ah, that's the feel free to extend the API doc :-)
+The FOURCC-based API replaces format descriptions by four character codes
+(FOURCC). FOURCCs are abstract identifiers that uniquely define a format
+without explicitly describing it. This is the only API that supports YUV
+formats. Drivers are also encouraged to implement the FOURCC-based API for
RGB
+and grayscale formats.
+
+Drivers that support the FOURCC-based API report this capability by setting
+the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field.
+
+FOURCC definitions are located in the linux/videodev2.h header. However, and
+despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to
V4L2
+and don't require usage of the V4L2 subsystem. FOURCC documentation is
+available in Documentation/DocBook/v4l/pixfmt.xml.
+
+To select a format, applications set the FB_VMODE_FOURCC bit in the
+fb_var_screeninfo vmode field, and set the fourcc field to the desired
FOURCC.
+The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to
+0 by applications and ignored by drivers. Note that the grayscale and fourcc
+fields share the same memory location. Application must thus not set the
+grayscale field to 0.
These are the only parts I don't like: (ab)using the vmode field (this
isn't really a
vmode flag), and the union of grayscale and fourcc (avoid unions where
possible).
What about storing the FOURCC value in nonstd instead?
As FOURCC values are always 4 ASCII characters (hence all 4 bytes must
be non-zero),
I don't think there are any conflicts with existing values of nonstd.
To make it even safer and easier to parse, you could set bit 31 of
nonstd as a FOURCC
indicator.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: +The following types and visuals are supported. + +- FB_TYPE_PACKED_PIXELS + +- FB_TYPE_PLANES You forgot FB_TYPE_INTERLEAVED_PLANES, FB_TYPE_TEXT, and FB_TYPE_VGA_PLANES. Ah, that's the feel free to extend the API doc :-) To be honest, I don't know how they work. That's why I haven't documented them. +The FOURCC-based API replaces format descriptions by four character codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format +without explicitly describing it. This is the only API that supports YUV +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB +and grayscale formats. + +Drivers that support the FOURCC-based API report this capability by setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. + +FOURCC definitions are located in the linux/videodev2.h header. However, and +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 +and don't require usage of the V4L2 subsystem. FOURCC documentation is +available in Documentation/DocBook/v4l/pixfmt.xml. + +To select a format, applications set the FB_VMODE_FOURCC bit in the +fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to +0 by applications and ignored by drivers. Note that the grayscale and fourcc +fields share the same memory location. Application must thus not set the +grayscale field to 0. These are the only parts I don't like: (ab)using the vmode field (this isn't really a vmode flag), and the union of grayscale and fourcc (avoid unions where possible). I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a FOURCC mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very happy with that, and proposed using the vmode field instead. Given that there's virtually no fbdev documentation, whether the vmode field and/or nonstd field are good fit for a FOURCC mode indicator is subject to interpretation. What about storing the FOURCC value in nonstd instead? Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format setting will be a standard fbdev API, I'm not very keen on storing it in the nonstd field without a union. As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Updated plane support v3
On Tue, Jun 21, 2011 at 11:19 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Tue, 21 Jun 2011 06:21:11 -0500 Rob Clark robdcl...@gmail.com wrote: On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: This version adds both source and dest rect params to the set_plane ioctl, and makes the source fixed point to support hardware that needs it. I haven't changed the name of the SNB implementation yet (per Chris's suggestions) but will before it gets upstream. I'd be interested to see whether these interfaces will work for other hardware, so please take a close look at them and ideally implement them on your hardware to make sure (see my userspace example code from earlier posts if you want something to crib from). Cool, thanks for this I'm just thinking through how I'd implement the driver part in omap drm driver.. so please bear with me if I'm misunderstanding.. In particular I'm thinking about being able to use a given video pipe (basically like a dma channel) as either framebuffer layer or overlay at various points in time, depending on how many displays are attached. Is the idea to use drm_plane *only* for overlay layer, and still use crtc-fb for the normal framebuffer layer? Given the structure of the current KMS API, a CRTC implies a plane of some sort, but I don't think the driver is restricted to using the same plane for a given CRTC forever; it could allocate and switch them around depending on usage, with planes beyond what's currently associated with the CRTC exposed through this interface. The awkward thing is how do you express to userspace that if it isn't using some CRTC(s) that it has an extra plane(s) available, if each crtc even though it is not enabled, is assumed to consume a plane (video pipe).. That said if OMAP is the only hw like this, one possible solution is that you just need to have userspace know.. ie. the main one taking advantage of this feature would be the xorg driver, and it already knows what DRM driver it is talking to. Generic things like splash screen won't need to be using all the video planes. But I'm at least under the impression that some of the other SoC's have similar flexibility to use video planes as either primary or overlay layers. So I figure it is at least worth trying to handle this in a more generic way if it doesn't cause too much ugliness to KMS core. I was thinking perhaps that if we let userspace DRM_IOCTL_MODE_SETCRTC pass in -1 for fb_id, followed by one or more DRM_IOCTL_MODE_SETPLANE's, to set things up the new way (explicitly specify the drm_plane's). Or if _SETCRTC passes in a valid fb_id, we know it is the old way, and driver automatically picks a drm_plane. Yeah that might work; we'd probably want a new GETPARAM flag to indicate support for this... The tough part is doing it in such a way that we don't break existing userspace. fwiw, Daniel and I discussed a bit on IRC earlier today, and he had an interesting idea about having a simple drm_plane shim+helpers to keep things similar for existing drivers. I think it should be possible to support both old and new userspace semantics this way without too much if(driver_features SUPPORTS_PLANES) sort of stuff. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
Salut Jean, thank you for the detailed reply. If I got you right you rose the following main points: 1. Root cause leading to flooding problem (you assume i2c bus not working correctly, i. e. stuck bus) not adequately addressed by the fix 2. Alternative proposal: Fix the verbose logging issue 3. i2c EDID probing inefficiently implemented 4. Strange coding and commenting style Point 1: The Asus M2A-VM HDMI EDID error flooding problem was already addressed in this mailing list in April this year (https://lkml.org/lkml/2011/4/15/36). But it was not further discussed, maybe due to missing bug information. I wanted to provide this information to that thread, but your mail was faster :-). In the following, you can see the i2c dump of the DVI connector of the AMD 690G chip, where the monitor is connected to: 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 00 ff ff ff ff ff ff 00 4c 2d ed 00 39 31 49 44L-?.91ID 10: 2d 0e 01 03 80 26 1e 78 2a ee 95 a3 54 4c 99 26-?x*???TL? 20: 0f 50 54 bf ef 80 81 80 71 4f 01 01 01 01 01 01?PT?qO?? 30: 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70??0*.?Q.*@0p 40: 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4c 1e?.x-?..?...?.8L? 50: 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53Q?.? ...?.S 60: 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ffyncMaster? 70: 00 48 34 4a 58 42 30 31 35 30 33 0a 20 20 00 e4.H4JXB01503? .? 80: 00 ff ff ff ff ff ff 00 4c 2d ed 00 39 31 49 44L-?.91ID 90: 2d 0e 01 03 80 26 1e 78 2a ee 95 a3 54 4c 99 26-?x*???TL? a0: 0f 50 54 bf ef 80 81 80 71 4f 01 01 01 01 01 01?PT?qO?? b0: 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70??0*.?Q.*@0p c0: 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4c 1e?.x-?..?...?.8L? d0: 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53Q?.? ...?.S e0: 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ffyncMaster? f0: 00 48 34 4a 58 42 30 31 35 30 33 0a 20 20 00 e4.H4JXB01503? .? Then we have the i2c dump of the HDMI connector with no monitor connected: 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: 00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00..?. 10: 00 00 00 00 00 XX 00 01 00 00 00 00 1f 00 00 00.X.??... 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 XX 00 00 00 00 00 7f 00 00 00 00.X.? 40: 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 00..?. 50: 00 00 00 00 00 07 00 01 00 00 00 00 00 00 00 00.?.? 60: 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00.?.. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00.?.. a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 ff 00 00 3f 00 00 00 00 00 00 00?... c0: 00 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00.?.. d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 XX 00 00 7f 00 00 00 00 00 00 00 00X..? For this connector radeon_ddc_probe() reports a working DDC, which leads to the catastrophic situation that drm_get_edid() and drm_edid_block_valid() flood the logs with EDID error messages and dumps. Finally, we have the i2c dump of the VGA connector, where also no monitor is connected to: 0 1 2 3 4 5 6 7 8 9 a b c d e f0123456789abcdef 00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX radeon_ddc_probe() reports no DDC. Do you really believe that this is caused by a stuck i2c bus? Following the i2c dumps it really
[PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
From: Thomas Reim rdrat...@yahoo.co.uk
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid() and drm_edid_block_valid()
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk
---
drivers/gpu/drm/radeon/radeon_connectors.c | 21 +--
drivers/gpu/drm/radeon/radeon_display.c| 11 ++
drivers/gpu/drm/radeon/radeon_i2c.c| 55
drivers/gpu/drm/radeon/radeon_mode.h |1 +
4 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..497e32a 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -825,9 +825,24 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
int i;
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false;
-
- if (radeon_connector-ddc_bus)
- dret = radeon_ddc_probe(radeon_connector);
+
+ if (radeon_connector-ddc_bus) {
+ /* AMD 690 chipset series HDMI DDC quirk:
+* Some integrated ATI Radeon chipset implementations (e. g.
+* Asus M2A-VM HDMI) indicate the availability of a DDC even
+* when there's no monitor connected to HDMI. For HDMI
+* connectors we check for the availability of EDID with
+* at least a correct EDID header and EDID version/revision
+* information. Only then, DDC is assumed to be available.
+* This prevents drm_get_edid() and drm_edid_block_valid() of
+* periodically dumping data and kernel errors into the logs
+* and onto the terminal, which would lead to an unacceptable
+* system behaviour */
+ if (connector-connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ dret = radeon_ddc_edid_probe(radeon_connector);
+ else
+ dret = radeon_ddc_probe(radeon_connector);
+ }
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+ Seems to just force drm to dump EDID errors
+ to kernel logs */
list_for_each_entry(drm_connector,
dev-mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector *connector)
if (!radeon_connector-ddc_bus)
return -1;
edid = drm_get_edid(connector, radeon_connector-ddc_bus-adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+* instead of periodically dumping data and kernel errors into the
+* logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO(Radeon display connector %s: Found valid EDID,
+ drm_get_connector_name(connector));
kfree(edid);
+ } else {
+ DRM_INFO(Radeon display connector %s: No display connected or
invalid EDID,
+ drm_get_connector_name(connector));
}
return ret;
}
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 781196d..80b871f 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -63,6 +63,61 @@ bool radeon_ddc_probe(struct radeon_connector
*radeon_connector)
return false;
}
+/*
+ * Probe EDID information via I2C:
+ * Try to fetch EDID information by calling i2c_transfer driver function and
+ * probe for valid EDID header and version information.
+ *
+ * AMD 690 chipset series HDMI DDC quirk:
+ * Some integrated ATI Radeon chipset implementations (e. g. Asus M2A-VM HDMI
+ * indicate the availability of a DDC even when there's no monitor connected.
+ * Invalid EDID leads to flooding of logs and terminals with error messages
+ */
+bool radeon_ddc_edid_probe(struct radeon_connector *radeon_connector)
+{
+ u8 out_buf[] = {0x0, 0x0};
+ u8 block[20];
+ int ret;
+ struct i2c_msg
Re: [PATCH 1/1] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem
On Tue, Jun 21, 2011 at 9:20 PM, rei...@googlemail.com wrote:
From: Thomas Reim rdrat...@yahoo.co.uk
Some integrated ATI Radeon chipset implementations
(e. g. Asus M2A-VM HDMI) indicate the availability
of a DDC even when there's no monitor connected.
In this case, drm_get_edid() and drm_edid_block_valid()
periodically dump data and kernel errors into system
log files and onto terminals, which lead to an unacceptable
system behaviour.
Tested since kernel 2.35 on Asus M2A-VM HDMI board
Signed-off-by: Thomas Reim rdrat...@yahoo.co.uk
---
drivers/gpu/drm/radeon/radeon_connectors.c | 21 +--
drivers/gpu/drm/radeon/radeon_display.c | 11 ++
drivers/gpu/drm/radeon/radeon_i2c.c | 55
drivers/gpu/drm/radeon/radeon_mode.h | 1 +
4 files changed, 85 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cbfca3a..497e32a 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -825,9 +825,24 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
int i;
enum drm_connector_status ret = connector_status_disconnected;
bool dret = false;
-
- if (radeon_connector-ddc_bus)
- dret = radeon_ddc_probe(radeon_connector);
+
+ if (radeon_connector-ddc_bus) {
+ /* AMD 690 chipset series HDMI DDC quirk:
+ * Some integrated ATI Radeon chipset implementations (e. g.
+ * Asus M2A-VM HDMI) indicate the availability of a DDC even
+ * when there's no monitor connected to HDMI. For HDMI
+ * connectors we check for the availability of EDID with
+ * at least a correct EDID header and EDID version/revision
+ * information. Only then, DDC is assumed to be available.
+ * This prevents drm_get_edid() and drm_edid_block_valid() of
+ * periodically dumping data and kernel errors into the logs
+ * and onto the terminal, which would lead to an unacceptable
+ * system behaviour */
+ if (connector-connector_type == DRM_MODE_CONNECTOR_HDMIA)
This is going to enable your quirk on every board with an HDMI port.
If we need to add a quirk for your board, let's make it board
specific. It might be better to just disable edid polling for certain
connectors on certain boards if they cause problems when no monitor is
detected.
Alex
+ dret = radeon_ddc_edid_probe(radeon_connector);
+ else
+ dret = radeon_ddc_probe(radeon_connector);
+ }
if (dret) {
if (radeon_connector-edid) {
kfree(radeon_connector-edid);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 292f73f..550f143 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -715,6 +715,9 @@ static bool radeon_setup_enc_conn(struct drm_device *dev)
if (ret) {
radeon_setup_encoder_clones(dev);
radeon_print_display_setup(dev);
+ /* Is this really required here?
+ Seems to just force drm to dump EDID errors
+ to kernel logs */
list_for_each_entry(drm_connector,
dev-mode_config.connector_list, head)
radeon_ddc_dump(drm_connector);
}
@@ -777,8 +780,16 @@ static int radeon_ddc_dump(struct drm_connector
*connector)
if (!radeon_connector-ddc_bus)
return -1;
edid = drm_get_edid(connector, radeon_connector-ddc_bus-adapter);
+ /* Asus M2A-VM HDMI DDC quirk: Log EDID retrieval status here once,
+ * instead of periodically dumping data and kernel errors into the
+ * logs, if a monitor is not connected to HDMI */
if (edid) {
+ DRM_INFO(Radeon display connector %s: Found valid EDID,
+ drm_get_connector_name(connector));
kfree(edid);
+ } else {
+ DRM_INFO(Radeon display connector %s: No display connected
or invalid EDID,
+ drm_get_connector_name(connector));
}
return ret;
}
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index 781196d..80b871f 100644
--- a/drivers/gpu/drm/radeon/radeon_i2c.c
+++ b/drivers/gpu/drm/radeon/radeon_i2c.c
@@ -63,6 +63,61 @@ bool radeon_ddc_probe(struct radeon_connector
*radeon_connector)
return false;
}
+/*
+ * Probe EDID information via I2C:
+ * Try to fetch EDID information by calling i2c_transfer driver function and
+ * probe for valid EDID header and version information.
+ *
+ * AMD 690 chipset
[Bug 38547] New: r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 Summary: r600g fails shader, tries to run with failed shader, freezes. Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: equinox-freedesktopb...@diac24.net when trying to create a character in EVE Online, after the first few screens I encounter multiple shaders that cannot be translated from TGSI. The error message printed is: r600_pipe_shader_create - translation from TGSI failed ! I've traced this down to: ^ check_and_set_bank_swizzle (-1) from ^ r600_bc_add_alu_type from ^ r600_shader_from_tgsi from ^ r600_pipe_shader_create (opcode: 0x09 ADD) Problematically, the application continues running after that, complains about missing shader and finally - a whole few seconds later, continuing to draw the loading animation - freezes the GFX card: [ 4996.188064] radeon :03:00.0: GPU lockup CP stall for more than 1msec [ 4996.188072] [ cut here ] [ 4996.188147] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:246 radeon_fence_wait+0x21c/0x2bb [radeon]() [ 4996.188160] GPU lockup (waiting for 0x00011BDD last fence id 0x00011BD9) after that I have to kill my X server and restart it. (So this is basically two bugs, the shader failing, and the driver trying to use a failed shader I assume - though the lockup might also be unrelated) System information: mesa 21972c85ea734dbfcf69629c6b0b940efb42d4ba on Linux 2.6.39.1 32-bit chroot on 64-bit host 03:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600 Series] R600_DUMP_SHADERS output for failed shader following in attachment. -- 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 38547] r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 --- Comment #1 from David L. equinox-freedesktopb...@diac24.net 2011-06-21 22:07:02 PDT --- Created an attachment (id=48266) -- (https://bugs.freedesktop.org/attachment.cgi?id=48266) R600_DUMP_SHADERS + errors for first failing shader (please note that I added more debug statements, so the line numbers are a few lines off in those last 3 error lines) -- 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 38547] r600g fails shader, tries to run with failed shader, freezes.
https://bugs.freedesktop.org/show_bug.cgi?id=38547 --- Comment #2 from David L. equinox-freedesktopb...@diac24.net 2011-06-21 22:19:08 PDT --- i hacked up a counter to tell me which instruction is failing, it seems to be 2517: ADD TEMP[161].x, -TEMP[158]., CONST[0]. if i'm not totally wrong. (my counter says 2518, but it is an ADD that fails so i think I'm off by one...) -- 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/RFC] fbdev: Add FOURCC-based format configuration API
Hi Geert, Laurent, On 06/21/2011 10:31 PM, Laurent Pinchart wrote: Hi Geert, On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: +The FOURCC-based API replaces format descriptions by four character codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format +without explicitly describing it. This is the only API that supports YUV +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB +and grayscale formats. + +Drivers that support the FOURCC-based API report this capability by setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. + +FOURCC definitions are located in the linux/videodev2.h header. However, and +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 +and don't require usage of the V4L2 subsystem. FOURCC documentation is +available in Documentation/DocBook/v4l/pixfmt.xml. + +To select a format, applications set the FB_VMODE_FOURCC bit in the +fb_var_screeninfo vmode field, and set the fourcc field to the desired FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields must be set to +0 by applications and ignored by drivers. Note that the grayscale and fourcc +fields share the same memory location. Application must thus not set the +grayscale field to 0. These are the only parts I don't like: (ab)using the vmode field (this isn't really a vmode flag), and the union of grayscale and fourcc (avoid unions where possible). I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a FOURCC mode indicator in my initial RFC. Florian Tobias Schandinat wasn't very happy with that, and proposed using the vmode field instead. Given that there's virtually no fbdev documentation, whether the vmode field and/or nonstd field are good fit for a FOURCC mode indicator is subject to interpretation. The reason for my suggestion is that the vmode field is accepted to contain only flags and at least to me there is no hard line what is part of the video mode and what is not. In contrast the nonstd field is already used in a lot of different (incompatible) ways. I think if we only use the nonstd field for handling FOURCC it is likely that some problems will appear. What about storing the FOURCC value in nonstd instead? Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format setting will be a standard fbdev API, I'm not very keen on storing it in the nonstd field without a union. As FOURCC values are always 4 ASCII characters (hence all 4 bytes must be non-zero), I don't think there are any conflicts with existing values of nonstd. To make it even safer and easier to parse, you could set bit 31 of nonstd as a FOURCC indicator. I would then create a union between nonstd and fourcc, and document nonstd as being used for the legacy API only. Most existing drivers use a couple of nonstd bits only. The driver that (ab)uses nonstd the most is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can tell, so nonstd 0xff00 != 0 could be used as a FOURCC mode test. This assumes that FOURCCs will never have their last character set to '\0'. Is that a safe assumption for the future ? Yes, I think. The information I found indicates that space should be used for padding, so a \0 shouldn't exist. I think using only the nonstd field and requiring applications to check the capabilities would be possible, although not fool proof ;) Great work, Laurent, do you have plans to modify fbset to allow using this format API from the command line? Regards, Florian Tobias Schandinat ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
