On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote:
> Add Cc. to platform-driver-x86 and linux-acpi
>
> Hi Baptiste
>
> 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到：
> > Hi,
> >
> > I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't
> > have a keyboard, but two displays
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 restarting game doesn't help, only computer restart have the effect
Hi Baptiste,
On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez wrote:
> On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote:
>> Add Cc. to platform-driver-x86 and linux-acpi
>>
>> Hi Baptiste
>>
>> 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到：
>> > Hi,
>> >
>> > I've got a lot of troubles wit
On Tue, Dec 06, 2011 at 11:12:26PM +0100, Benjamin Tissoires wrote:
> Hi Baptiste,
Hi,
> On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez wrote:
> > The second screen works fine with the attached patch. It actually is
> > 6 months old but seems to have been lost in the wild...
>
> You don't have
> 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.
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 initiators (DSS, IVAHD, etc) which do not otherwise support
> no
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-
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 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
https://bugs.freedesktop.org/show_bug.cgi?id=43395
--- Comment #12 from Michel Dänzer 2011-12-07 03:17:11 UTC
---
Does setting the environment variable vblank_mode=0 for the Wine process using
OpenGL work around the problem? There should be a message
ATTENTION: default value of option vblank_m
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
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 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
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
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
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
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
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 Hadzi
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
> > >> 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
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)
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 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
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.
>>>
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
> 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 ++
>
> 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
> 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
> 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
> ++
> 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
> 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
> 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 +
> 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
> 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
> 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
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
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
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/
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_
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 -
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
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
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
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 +--
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
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
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
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
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
---
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/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/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
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
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
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
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
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 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/
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
> 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
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
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
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
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
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
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
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
> 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.
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>
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-
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 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
https://bugs.freedesktop.org/show_bug.cgi?id=43395
--- Comment #12 from Michel D?nzer 2011-12-07 03:17:11
UTC ---
Does setting the environment variable vblank_mode=0 for the Wine process using
OpenGL work around the problem? There should be a message
ATTENTION: default value of option vblank_m
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
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 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
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
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
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
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
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
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
> > >> 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
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)
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 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
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.
>>>
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
> 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 ++
>
> 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
> 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
> 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
> ++
> 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
> 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
> 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 +
> 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
> 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
> 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
1 - 100 of 125 matches
Mail list logo
