The "if (!p && !p->dev)" condition isn't right because || was intended
instead of &&. But actually, "p" is the list cursor and so it's always
non-NULL and we can just remove that bit. We can remove the another
similar check as well.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/ttm
On Wed, 07 Dec 2011 19:42:22 +0100, Eric Anholt wrote:
On Tue, 06 Dec 2011 22:59:58 +0100, semiRocket
wrote:
Hi,
I'm running on Intel i3 2100 integrated graphics, I'm getting some
strange
noise particles in games like Minecraft and Speed Dreams (mostly
noticeable in Minecraft) after play
On 02.12.11 21:48:20, Markus Trippelsdorf wrote:
> BTW I always see (mostly only on screen, sometimes in the logs):
>
> [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400,
> but the register is already in use for vector 0xf9 on another cpu
> [Firmware Bug]: cpu 2, IBS int
When 2 or more EDID extension blocks are present, segment must be
selected prior to reading the extended EDID block over the DDC
channel. Add support for this.
Signed-off-by: Jean Delvare
Cc: Adam Jackson
---
This needs testing by someone with access to such a display.
drivers/gpu/drm/drm_edid
2011/12/7 Alex Deucher :
> 2011/12/7 Rafa? Mi?ecki :
>>
>> Signed-off-by: Rafa? Mi?ecki
>> ---
>> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?6 +++---
>> ?1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeo
https://bugs.freedesktop.org/show_bug.cgi?id=43617
Bug #: 43617
Summary: [bisected i965]oglc api-error(negative.glGetPixelMap)
segfaults
Classification: Unclassified
Product: DRI
Version: unspecified
Platform: All
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/atombios_encoders.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 39c04c1..63e5426 100644
--- a/drivers/gpu/drm/r
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen_reg.h | 10 +++
drivers/gpu/drm/radeon/r600_hdmi.c | 44 ++--
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h
b/drivers/gpu/drm/radeon
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c | 14 ++
drivers/gpu/drm/radeon/evergreen_reg.h |8
drivers/gpu/drm/radeon/r600_audio.c| 22 +++---
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/r600_hdmi.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5021372..06f923e 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
++
https://bugs.freedesktop.org/show_bug.cgi?id=43395
--- Comment #13 from Tomas Schlosser 2011-12-07
13:33:53 PST ---
(In reply to comment #12)
> Does setting the environment variable vblank_mode=0 for the Wine process using
> OpenGL work around the problem? There should be a message
>
> ATTENTI
When "MC timeout" happens at GPU reset, we found the 12th and 13th
bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
two bits are like this:
#define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1)
#define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1)
Co
We currently don't have support for parsing SDVO mappings from BIOS so we're
guessing the bus switch parameter. This isn't working so hardcode it to a
configuration known to work on most poulsbo hardware.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c |8
Replace psb_intel_output with psb_intel_encoder and psb_intel_connector
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 18
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 29 +++
drivers/gpu/drm/gma500/oaktrail_lvds.c | 79 +--
Replace psb_intel_output with psb_intel_encoder and psb_intel_connector.
Things will need to be cleaned up and tested so consider this an initial
patch for Cedarview.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 47 +++-
drivers/gpu/drm/gma500/cdv_in
Our current SDVO implementation is not working properly, so replace it with
a modified version of the i915. Further testing and debugging is needed to make
sure we can handle the different SDVO setups and wiring.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_drv.h |
Before we integrate the new SDVO code we need GMBUS support
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Makefile|1 +
drivers/gpu/drm/gma500/intel_gmbus.c | 493
drivers/gpu/drm/gma500/psb_device.c|7 +
drivers/gpu/drm/gma500
LVDS for PSB now uses psb_intel_encoder and psb_intel_connectors instead of
psb_intel_output. i2c_bus and ddc_bus are moved to lvds_priv. There was also a
pointer to mode_dev (for no obvious reason) that we now get directly from
dev_priv.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma50
Fix cases where we need to know what encoder type is behind a given connector.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c |8
drivers/gpu/drm/gma500/psb_drv.c |6 +++---
drivers/gpu/drm/gma500/psb_intel_display.c | 24 -
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_drv.h |5 +++--
drivers/gpu/drm/gma500/psb_intel_modes.c | 16 +++-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_
First step towards adding i915 alike encoder and connector abstractions. This
will make life easier when adding i915 output code into our driver. It also
removes the old psb_intel_output struct.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c |7 +
drivers/
This set of patches removes psb_intel_output and replaces it with
psb_intel_encoder and psb_intel_connector. It also replaces the SDVO code with a
slightly modified version from i915. i915 SDVO needs Intel gmbus so this is
added along with a SDVO DDC bus guessing fix for Poulsbo.
Patrik Jakobsson
Hi Daniel, Rob,
On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark wrote:
> On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote:
>> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
>>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
>>> > In the patch 2, you have a section about migrati
There's no reason to force the first byte to be correct if we're already
scoring how correct the header is.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=722909
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 18 --
1 files changed, 8 insertions(+), 10 del
2011/12/7 Rafa? Mi?ecki :
>
> Signed-off-by: Rafa? Mi?ecki
> ---
> ?drivers/gpu/drm/radeon/evergreen_reg.h | ? 10 +++
> ?drivers/gpu/drm/radeon/r600_hdmi.c ? ? | ? 44
> ++--
> ?2 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeo
2011/12/7 Rafa? Mi?ecki :
>
> Signed-off-by: Rafa? Mi?ecki
> ---
> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?6 +++---
> ?1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 39c04
On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann wrote:
> On Wednesday 07 December 2011, Semwal, Sumit wrote:
>> >
>> > Do you have a use case for making the interface compile-time disabled?
>> > I had assumed that any code using it would make no sense if it's not
>> > available so you don't actually
> Chris Wilson rightly complained that this doesn't explain the list_del
> magic going on. New commit msg reads:
>
> To make the transition in a piece-wise and bisectable way possible,
> I've hijacked the ->owner_list from drm_sman. While transitioning, the
> list_add was done by the
> A few things
> - kill reclaim_buffers, it's never ever called because via does not set
> DRIVER_HAVE_DMA
> - inline the idlelock dance into the buffer reclaim logic and make it
> a simple preclose cleanup function
> - directly call the the dma_quiescent function and kill the needless
> if
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/Makefile |2 +-
> drivers/gpu/drm/drm_sman.c | 210
>
> include/drm/drm_sman.h | 151 ---
> 3 files changed
> Signed-off-by: Daniel Vetter
Can't test on SiS but does nothing to my VIA hardware.
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 -
> drivers/gpu/drm/sis/sis_drv.h |5 +-
> drivers/gpu/drm/sis/sis_mm.c | 137 +++-
> 3 files
> Now that we are again in proper control of owner_list, we need to
> properly list_del it on free.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/via/via_drv.h |5 ++-
> drivers/gpu/drm/via/via_map.c |7
> drivers/gpu/drm/via/via_mm.c | 72 +
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 36 ++--
> include/drm/drm_sman.h |5 -
> 2 files changed, 2 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sman
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 +++
> drivers/gpu/drm/sis/sis_drv.h |2 +
> drivers/gpu/drm/sis/sis_mm.c | 60 ++--
> drivers/gpu/drm/via/via_map.c |2 +
> 4 files changed, 53 i
> Massive indirection through a hashtable for a simple key->pointer
> look-up actually just adds bloat.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/via/via_drv.h |2 +
> drivers/gpu/drm/via/via_map.c |1 +
> drivers/gpu/drm/via/via_mm.c | 61
> ++
> In contrast to kms drivers, sis/via _always_ associated a buffer with
> a drm fd. So by the time we reach lastclose, all open drm fds are gone
> and with them their associated objects.
>
> So when sis/via call drm_sman_cleanup in their lastclose funcs, that
> will free 0 objects.
>
> The owner
> These are now unused.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 38 --
> include/drm/drm_sman.h | 19 ---
> 2 files changed, 0 insertions(+), 57 deletions(-)
>
> diff --git a/dr
> Exactly like the previous patch for sis.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
Same goes for PATCH 01 which I'm missing in my inbox.
> ---
> drivers/gpu/drm/via/via_drv.c | 25 +
> drivers/gpu/drm/via/via_mm.c | 22 ++
>
W dniu 7 grudnia 2011 15:53 u?ytkownik Alex Deucher
napisa?:
> 2011/12/7 Rafa? Mi?ecki :
>> W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher
>> napisa?:
>>> 2011/12/7 Rafa? Mi?ecki :
In theory function atombios_get_encoder_mode should report
ATOM_ENCODER_MODE_HDMI when TV supports au
On 2011.12.07 at 15:32 +0100, Robert Richter wrote:
> On 02.12.11 21:48:20, Markus Trippelsdorf wrote:
> > BTW I always see (mostly only on screen, sometimes in the logs):
> >
> > [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector
> > 0x10400, but the register is already in use f
W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher
napisa?:
> 2011/12/7 Rafa? Mi?ecki :
>> In theory function atombios_get_encoder_mode should report
>> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
>> ATOM_ENCODER_MODE_DVI if card is DCE4.
>>
>> Is there any reason for it? Can
On 02.12.11 21:48:20, Markus Trippelsdorf wrote:
> BTW I always see (mostly only on screen, sometimes in the logs):
>
> [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400,
> but the register is already in use for vector 0xf9 on another cpu
> [Firmware Bug]: cpu 2, IBS int
There's no reason to force the first byte to be correct if we're already
scoring how correct the header is.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=722909
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 18 --
1 files changed, 8 insertions(+), 10 del
Signed-off-by: Rafał Miłecki
---
V2: Don't touch DIG_CNTL manually, AtomBIOS does that for us.
My early testing was done with hacked code to enable HDMI on DVI. After
fixing atombios_get_encoder_mode the behaviour has changed a little,
that hack is not needed anymore.
---
drivers/gpu/drm/radeon/
When 2 or more EDID extension blocks are present, segment must be
selected prior to reading the extended EDID block over the DDC
channel. Add support for this.
Signed-off-by: Jean Delvare
Cc: Adam Jackson
---
This needs testing by someone with access to such a display.
drivers/gpu/drm/drm_edid
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/r600_hdmi.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5021372..06f923e 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
++
Signed-off-by: Rafał Miłecki
---
V2: don't duplicate check for radeon_audio
---
drivers/gpu/drm/radeon/atombios_encoders.c | 35 +--
1 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/ato
2011/12/7 Rafał Miłecki :
>
> Signed-off-by: Rafał Miłecki
> ---
> drivers/gpu/drm/radeon/evergreen_reg.h | 10 +++
> drivers/gpu/drm/radeon/r600_hdmi.c | 44
> ++--
> 2 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeo
2011/12/7 Alex Deucher :
> 2011/12/7 Rafał Miłecki :
>>
>> Signed-off-by: Rafał Miłecki
>> ---
>> drivers/gpu/drm/radeon/atombios_encoders.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
>> b/drivers/gpu/drm/radeo
he connected
HDMI monitor. Currently only the 3D format support fields are read.
Later this could be extended. This information is expected to be sent to
the user space which then sets the format on the monitor.
This patch also handles DIP register signaling to the HDMI connected 3D
monitor th
2011/12/7 Rafał Miłecki :
>
> Signed-off-by: Rafał Miłecki
> ---
> drivers/gpu/drm/radeon/atombios_encoders.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
> b/drivers/gpu/drm/radeon/atombios_encoders.c
> index 39c04
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/atombios_encoders.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 39c04c1..63e5426 100644
--- a/drivers/gpu/drm/r
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen_reg.h | 10 +++
drivers/gpu/drm/radeon/r600_hdmi.c | 44 ++--
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h
b/drivers/gpu/drm/radeon
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/evergreen.c | 14 ++
drivers/gpu/drm/radeon/evergreen_reg.h |8
drivers/gpu/drm/radeon/r600_audio.c| 22 +++---
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
Signed-off-by: Rafał Miłecki
---
drivers/gpu/drm/radeon/r600_hdmi.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5021372..06f923e 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
++
> > >> Testing this on via would be awesome! Iirc I haven't changed anything in
> > >> the via specific patches, but if it's more convenient you can also
> > >> directly test my branch:
> > >>
> > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire
> > >
> > > Okay I tried the patches
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> Thanks for the excellent discussion - it indeed is very good learning
> for the relatively-inexperienced me :)
>
> So, for the purpose of dma-buf framework, could I summarize the
> following and rework accordingly?:
> 1. remove mmap() dma_buf_o
https://bugs.freedesktop.org/show_bug.cgi?id=43395
--- Comment #13 from Tomas Schlosser 2011-12-07
13:33:53 PST ---
(In reply to comment #12)
> Does setting the environment variable vblank_mode=0 for the Wine process using
> OpenGL work around the problem? There should be a message
>
> ATTENTI
In theory function atombios_get_encoder_mode should report
ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
ATOM_ENCODER_MODE_DVI if card is DCE4.
Is there any reason for it? Can we just drop that DCE4 condition? This
fixme seems to be here since ever.
--
Rafa?
In theory function atombios_get_encoder_mode should report
ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
ATOM_ENCODER_MODE_DVI if card is DCE4.
Is there any reason for it? Can we just drop that DCE4 condition? This
fixme seems to be here since ever.
--
Rafa?
-
Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>
> This looks very nice, but there are a few things I don't understand yet
> and a bunch
change v4
Hello Jerome Glisse,
This is a semi-automatic email about new static checker warnings.
The patch dc97b3409a79: "drm/ttm: callback move_notify any time bo
placement change v4" from Nov 18, 2011, leads to the following Smatch
complaint:
drivers/gpu/drm/nouveau/nouveau_bo.c +818 nouvea
2011/12/7 Rafa? Mi?ecki :
> W dniu 7 grudnia 2011 15:53 u?ytkownik Alex Deucher
> napisa?:
>> 2011/12/7 Rafa? Mi?ecki :
>>> W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher
>>> napisa?:
2011/12/7 Rafa? Mi?ecki :
> In theory function atombios_get_encoder_mode should report
> ATOM_E
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> Right; that would be ideal, but we may not be able to ask each user to
> do so - especially when the sharing part might be interspersed in
> existing buffer handling code. So for now, I would like to keep it as
> it-is.
Ok, fair enough. It cert
ext attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/b21a02a6/attachment.pgp>
Import the current kernel bits into libdrm for client code.
Signed-off-by: Jesse Barnes
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir}/lib
,25 @@ typedef struct _drmModeConnector {
uint32_t *encoders; /**< List of encoder ids */
} drmModeConnector, *drmModeConnectorPtr;
+typedef struct _drmModePlane {
+ uint32_t count_formats;
+ uint32_t *formats;
+ uint32_t plane_id;
+ uint32_t crtc_id;
+ uint32_t fb_id;
+
+ uint32_t crtc_x, crtc_y;
+ uint32_t x, y;
+
+ uint32_t possible_crtcs;
+ uint32_t gamma_size;
+} drmModePlane, *drmModePlanePtr;
+
+typedef struct _drmModePlaneRes {
+ uint32_t count_planes;
+ uint32_t *planes;
+} drmModePlaneRes, *drmModePlaneResPtr;
extern void drmModeFreeModeInfo( drmModeModeInfoPtr ptr );
extern void drmModeFreeResources( drmModeResPtr ptr );
@@ -286,6 +304,7 @@ extern void drmModeFreeFB( drmModeFBPtr ptr );
extern void drmModeFreeCrtc( drmModeCrtcPtr ptr );
extern void drmModeFreeConnector( drmModeConnectorPtr ptr );
extern void drmModeFreeEncoder( drmModeEncoderPtr ptr );
+extern void drmModeFreePlane( drmModePlanePtr ptr );
/**
* Retrives all of the resources associated with a card.
@@ -307,6 +326,11 @@ extern drmModeFBPtr drmModeGetFB(int fd, uint32_t
bufferId);
extern int drmModeAddFB(int fd, uint32_t width, uint32_t height, uint8_t depth,
uint8_t bpp, uint32_t pitch, uint32_t bo_handle,
uint32_t *buf_id);
+/* ...with a specific pixel format */
+extern int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
+uint32_t pixel_format, uint32_t bo_handles[4],
+uint32_t pitches[4], uint32_t offsets[4],
+uint32_t *buf_id, uint32_t flags);
/**
* Destroies the given framebuffer.
*/
@@ -391,6 +415,15 @@ extern int drmModeCrtcGetGamma(int fd, uint32_t crtc_id,
uint32_t size,
extern int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t fb_id,
uint32_t flags, void *user_data);
+extern drmModePlaneResPtr drmModeGetPlaneResources(int fd);
+extern drmModePlanePtr drmModeGetPlane(int fd, uint32_t plane_id);
+extern int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id,
+ uint32_t fb_id, uint32_t flags,
+ uint32_t crtc_x, uint32_t crtc_y,
+ uint32_t crtc_w, uint32_t crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h);
+
#if defined(__cplusplus) || defined(c_plusplus)
}
#endif
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/773a9eb1/attachment-0001.pgp>
Hi Linus,
Okay the 2 non-kexec fixes + one of the calloc changes as by looking at
it, there was nothing stopping userspace for abusing the integer overflow
on these ioctls. The other calloc changes either were kernel internal or
had other things stopping userspace from exploiting them.
Dave.
On Tue, 06 Dec 2011 22:59:58 +0100, semiRocket wrote:
> Hi,
>
> I'm running on Intel i3 2100 integrated graphics, I'm getting some strange
> noise particles in games like Minecraft and Speed Dreams (mostly
> noticeable in Minecraft) after playing a while, like half an hour. After
> that res
- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/151f7820/attachment.pgp>
We currently don't have support for parsing SDVO mappings from BIOS so we're
guessing the bus switch parameter. This isn't working so hardcode it to a
configuration known to work on most poulsbo hardware.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c |8
Replace psb_intel_output with psb_intel_encoder and psb_intel_connector
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/oaktrail_crtc.c | 18
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 29 +++
drivers/gpu/drm/gma500/oaktrail_lvds.c | 79 +--
Replace psb_intel_output with psb_intel_encoder and psb_intel_connector.
Things will need to be cleaned up and tested so consider this an initial
patch for Cedarview.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 47 +++-
drivers/gpu/drm/gma500/cdv_in
Before we integrate the new SDVO code we need GMBUS support
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/Makefile|1 +
drivers/gpu/drm/gma500/intel_gmbus.c | 493
drivers/gpu/drm/gma500/psb_device.c|7 +
drivers/gpu/drm/gma500
LVDS for PSB now uses psb_intel_encoder and psb_intel_connectors instead of
psb_intel_output. i2c_bus and ddc_bus are moved to lvds_priv. There was also a
pointer to mode_dev (for no obvious reason) that we now get directly from
dev_priv.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma50
Fix cases where we need to know what encoder type is behind a given connector.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/framebuffer.c |8
drivers/gpu/drm/gma500/psb_drv.c |6 +++---
drivers/gpu/drm/gma500/psb_intel_display.c | 24 -
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_drv.h |5 +++--
drivers/gpu/drm/gma500/psb_intel_modes.c | 16 +++-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h
b/drivers/gpu/drm/gma500/psb_intel_
First step towards adding i915 alike encoder and connector abstractions. This
will make life easier when adding i915 output code into our driver. It also
removes the old psb_intel_output struct.
Signed-off-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/psb_intel_display.c |7 +
drivers/
This set of patches removes psb_intel_output and replaces it with
psb_intel_encoder and psb_intel_connector. It also replaces the SDVO code with a
slightly modified version from i915. i915 SDVO needs Intel gmbus so this is
added along with a SDVO DDC bus guessing fix for Poulsbo.
Patrik Jakobsson
From: Chen Jie
Sweep common_modes array should start with index 0.
Signed-off-by: Chen Jie
---
drivers/gpu/drm/radeon/radeon_benchmark.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benc
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >
> > Do you have a use case for making the interface compile-time disabled?
> > I had assumed that any code using it would make no sense if it's not
> > available so you don't actually need this.
>
> Ok. Though if we keep the interface compile-
2011/12/7 Rafa? Mi?ecki :
> W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher
> napisa?:
>> 2011/12/7 Rafa? Mi?ecki :
>>> In theory function atombios_get_encoder_mode should report
>>> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
>>> ATOM_ENCODER_MODE_DVI if card is DCE4.
>>>
2011/12/7 :
> When "MC timeout" happens at GPU reset, we found the 12th and 13th
> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
> two bits are like this:
> #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1)
> #define G_000E50_MCDW_BUSY(x)
2011/12/7 Rafał Miłecki :
> W dniu 7 grudnia 2011 15:53 użytkownik Alex Deucher
> napisał:
>> 2011/12/7 Rafał Miłecki :
>>> W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher
>>> napisał:
2011/12/7 Rafał Miłecki :
> In theory function atombios_get_encoder_mode should report
> ATOM_E
2011/12/7 Rafa? Mi?ecki :
> In theory function atombios_get_encoder_mode should report
> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
> ATOM_ENCODER_MODE_DVI if card is DCE4.
>
> Is there any reason for it? Can we just drop that DCE4 condition? This
> fixme seems to be here sinc
> Chris Wilson rightly complained that this doesn't explain the list_del
> magic going on. New commit msg reads:
>
> To make the transition in a piece-wise and bisectable way possible,
> I've hijacked the ->owner_list from drm_sman. While transitioning, the
> list_add was done by the
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/Makefile |2 +-
> drivers/gpu/drm/drm_sman.c | 210
>
> include/drm/drm_sman.h | 151 ---
> 3 files changed
> Signed-off-by: Daniel Vetter
Can't test on SiS but does nothing to my VIA hardware.
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 -
> drivers/gpu/drm/sis/sis_drv.h |5 +-
> drivers/gpu/drm/sis/sis_mm.c | 137 +++-
> 3 files
> Now that we are again in proper control of owner_list, we need to
> properly list_del it on free.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/via/via_drv.h |5 ++-
> drivers/gpu/drm/via/via_map.c |7
> drivers/gpu/drm/via/via_mm.c | 72 +
> No longer used.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 36 ++--
> include/drm/drm_sman.h |5 -
> 2 files changed, 2 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sman
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/sis/sis_drv.c |4 +++
> drivers/gpu/drm/sis/sis_drv.h |2 +
> drivers/gpu/drm/sis/sis_mm.c | 60 ++--
> drivers/gpu/drm/via/via_map.c |2 +
> 4 files changed, 53 i
> Massive indirection through a hashtable for a simple key->pointer
> look-up actually just adds bloat.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/via/via_drv.h |2 +
> drivers/gpu/drm/via/via_map.c |1 +
> drivers/gpu/drm/via/via_mm.c | 61
> ++
> In contrast to kms drivers, sis/via _always_ associated a buffer with
> a drm fd. So by the time we reach lastclose, all open drm fds are gone
> and with them their associated objects.
>
> So when sis/via call drm_sman_cleanup in their lastclose funcs, that
> will free 0 objects.
>
> The owner
> These are now unused.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
> ---
> drivers/gpu/drm/drm_sman.c | 38 --
> include/drm/drm_sman.h | 19 ---
> 2 files changed, 0 insertions(+), 57 deletions(-)
>
> diff --git a/dr
> Exactly like the previous patch for sis.
>
> Signed-off-by: Daniel Vetter
Acked-by: James Simmons
Same goes for PATCH 01 which I'm missing in my inbox.
> ---
> drivers/gpu/drm/via/via_drv.c | 25 +
> drivers/gpu/drm/via/via_mm.c | 22 ++
>
> So having looked at the patch itself, I don't dislike the notion of
> making sure certain fields are nicely initialized. So I don't hate the
> patch itself, but quite frankly, to me it doesn't smell even
> *remotely* like "regression fix". I don't think this is something that
> has ever worked.
Right. The goof is a consequence of me doing copy-and-paste style edits. I
first added powers-of-two benchmark which intentionally start from index 1
but and then copied and edited that into comon-modes benchmark, and missed
to correct the starting index of the loop.
Reviewed-by: Ilija Hadzic
On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote:
>> From: Rob Clark
>>
>> Support for DMM and tiled buffers. ?The DMM/TILER block in omap4+ SoC
>> provides support for remapping physically discontiguous buffers for
>> various DMA
W dniu 7 grudnia 2011 15:53 użytkownik Alex Deucher
napisał:
> 2011/12/7 Rafał Miłecki :
>> W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher
>> napisał:
>>> 2011/12/7 Rafał Miłecki :
In theory function atombios_get_encoder_mode should report
ATOM_ENCODER_MODE_HDMI when TV supports au
2011/12/7 Rafał Miłecki :
> W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher
> napisał:
>> 2011/12/7 Rafał Miłecki :
>>> In theory function atombios_get_encoder_mode should report
>>> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report
>>> ATOM_ENCODER_MODE_DVI if card is DCE4.
>>>
1 - 100 of 125 matches
Mail list logo
