On 29/09/11 22:36, Alex Deucher wrote:
> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
> wrote:
>> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
>> the displayport AUX channel stopped re-trying commands that elicited a DEFER
>> response.
>>
>
> It should still be ret
On 29/09/11 22:36, Alex Deucher wrote:
> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
> wrote:
>> This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
>> the displayport AUX channel stopped re-trying commands that elicited a DEFER
>> response.
>>
> It should still be retry
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #3 from Alex Deucher 2011-09-29 22:50:19 PDT ---
I don't have access to source code at the moment, but the following change
should fix the issue. I'll make a proper patch in the next few days. The
existing code has a logic error; we
https://bugs.freedesktop.org/show_bug.cgi?id=41248
--- Comment #3 from Alex Deucher 2011-09-29 22:50:19 PDT
---
I don't have access to source code at the moment, but the following change
should fix the issue. I'll make a proper patch in the next few days. The
existing code has a logic error; w
On Fri, Sep 30, 2011 at 1:14 AM, Brad Campbell
wrote:
> On 30/09/11 12:59, Alex Deucher wrote:
>>
>> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
>
>>> Looking at it with a nights sleep, it's obvious the code path in
>>> aux_native_write is ok. Is this a bit cleaner than the last patch?
>>
>> Lo
This patch fixes a regression introduced between 2.6.39 & 3.1-rc1
whereby the displayport AUX channel stopped re-trying commands that
elicited a DEFER response.
Signed-off-by: Brad Campbell
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 7ad43c6.
On 30/09/11 12:59, Alex Deucher wrote:
On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
Looking at it with a nights sleep, it's obvious the code path in
aux_native_write is ok. Is this a bit cleaner than the last patch?
Looks pretty good. I was thinking of something more like this (sorry
for
On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell
wrote:
> On 29/09/11 23:21, Brad Campbell wrote:
>>
>> On 29/09/11 22:36, Alex Deucher wrote:
>>>
>>> On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
>>> wrote:
This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
th
On Thu, Sep 29, 2011 at 06:09:32PM -0700, Keith Packard wrote:
> Ok, so I've split all of the changes into bite-sized pieces so that
> they should make sense individually now. I've also added the same
> asynchronous power control to the panel power, this reduces the
> module load time down to about
On Thu, Sep 29, 2011 at 06:09:32PM -0700, Keith Packard wrote:
> Ok, so I've split all of the changes into bite-sized pieces so that
> they should make sense individually now. I've also added the same
> asynchronous power control to the panel power, this reduces the
> module load time down to about
On Thu, Sep 29, 2011 at 7:41 PM, Alan Cox wrote:
> On Thu, 29 Sep 2011 16:26:32 +0100
> Dave Airlie wrote:
>
>> From: Dave Airlie
>>
>> For the simple KMS driver case we need some more info about argb cursor
>> limits and a preferred depth and if shadowed framebuffer access is preferred.
>>
>> I
On Thu, 29 Sep 2011 09:43:12 -0700
Eric Anholt wrote:
> On Thu, 29 Sep 2011 16:26:32 +0100, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > For the simple KMS driver case we need some more info about argb cursor
> > limits and a preferred depth and if shadowed framebuffer access is
> > prefe
On Thu, 29 Sep 2011 16:26:32 +0100
Dave Airlie wrote:
> From: Dave Airlie
>
> For the simple KMS driver case we need some more info about argb cursor
> limits and a preferred depth and if shadowed framebuffer access is preferred.
>
> I've only added this for intel/radeon which support the dumb
The mouse cursor hotspot calculation when the cursor is partially off the
top or left side of the screen was off by one.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158
Signed-off-by: Nicholas Miell
---
drivers/gpu/drm/radeon/radeon_cursor.c |4 ++--
1 files changed, 2 insertions(+
The mouse cursor hotspot calculation when the cursor is partially off the
top or left side of the screen was off by one.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41158
Signed-off-by: Nicholas Miell
---
drivers/gpu/drm/radeon/radeon_cursor.c |4 ++--
1 files changed, 2 insertions(+
Here are three tiny patches, two new bug fixes and one regression fix
that disables FBC on Ironlake and older chips.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://people.fr
Talking to the eDP DDC channel requires that the panel be powered
up. Wrap both the EDID and modes fetch code with calls to turn the vdd
power on and back off.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 31 ---
1 files changed, 28 insertions(
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
This eliminates a fairly long delay when power sequencing newer
hardware
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 51 +++
1 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu
The DP i2c initialization code does a couple of i2c transactions,
which means that an eDP panel must be powered up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b
The return value was unused, so just stop doing that.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b5162..56146a2 100644
---
Any call to intel_dp_sink_dpms must ensure that the panel has power so
that the DP_SET_POWER operation will be correctly received. The only
one missing this was in intel_dp_prepare.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 de
On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp
The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
This ensures that the panel power sequencing is complete before
attempting to communicate over the aux channel.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/
Cleans up code dealing with eDP VDD a bit. Remove redundant checks in
callers
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/int
If the panel is powered up, there's no need to delay for the 'off'
interval when turning the panel on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d
Using the same basic plan as the VDD force delayed power off, make
turning the panel power off asynchronous.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 71 +--
1 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/g
We need to check eDP VDD force and panel on in several places, so
create some simple helper functions to avoid duplicating code.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
di
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
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/20110929/de0a2546/attachment.pgp>
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gp
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0c
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_reg.h |5 -
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.
Given the length of th
If the panel is powered up, there's no need to delay for the 'off'
interval when turning the panel on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d
This eliminates a fairly long delay when power sequencing newer
hardware
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 51 +++
1 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu
Using the same basic plan as the VDD force delayed power off, make
turning the panel power off asynchronous.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 71 +--
1 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/g
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
We need to check eDP VDD force and panel on in several places, so
create some simple helper functions to avoid duplicating code.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
di
The return value was unused, so just stop doing that.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b5162..56146a2 100644
---
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
This ensures that the panel power sequencing is complete before
attempting to communicate over the aux channel.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/
Any call to intel_dp_sink_dpms must ensure that the panel has power so
that the DP_SET_POWER operation will be correctly received. The only
one missing this was in intel_dp_prepare.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 de
The DP i2c initialization code does a couple of i2c transactions,
which means that an eDP panel must be powered up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b
Talking to the eDP DDC channel requires that the panel be powered
up. Wrap both the EDID and modes fetch code with calls to turn the vdd
power on and back off.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 31 ---
1 files changed, 28 insertions(
On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp
The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
Cleans up code dealing with eDP VDD a bit. Remove redundant checks in
callers
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/int
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..f0c
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gp
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_reg.h |5 -
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.
Given the length of th
On Wed, Sep 28, 2011 at 04:10:08PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/Makefile |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 34 ++-
> drivers/gpu/drm/vmwgfx
On 29/09/11 23:21, Brad Campbell wrote:
On 29/09/11 22:36, Alex Deucher wrote:
On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell
wrote:
This patch fixes a regression introduced between 2.6.39& 3.1-rc1 whereby
the displayport AUX channel stopped re-trying commands that elicited
a DEFER
response.
On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> More preparation for Screen Object support.
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 238 +++
> Would prefer_shadow ever be 0?
>
Yes thats for the USB and vmware type users, where the buffer is just
a main RAM buffer not in VRAM or uncached memory.
> Isn't preferred_depth just a static (non-driver-specific) preference
> list like "24, 30, 16, 15, 8" or something? ?Do we not expose the li
On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/driver
On Wed, Sep 28, 2011 at 04:10:02PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/dr
; Best regards,
> Huacai Chen
>
>
Regards,
- Chen Jie
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110929/718d8ecf/attachment.htm>
. which is pretty much like the other TTM pool except it
also handles moving the page to another pool list.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 96 ++
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/dri
. and provide in the function callback a method to register
with the backend a new (*set_caching).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 46 ++
drivers/gpu/drm/ttm/ttm_tt.c | 46 +---
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/g
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
in
In TTM world the pages for the graphic drivers are kept in three different
pools: write combined, uncached, and cached (write-back). When the pages
are used by the graphic driver the graphic adapter via its built in MMU
(or AGP) programs these pages in. The programming requires the virtual address
As a mechanism to detect whether SWIOTLB is enabled or not.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
[v1: Ripped out swiotlb_enabled]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/swiotlb-xen.c |2 +-
include/linux/swiotlb.h |2 +-
lib/s
We want to pass in the 'struct device' to the TTM layer so that
the TTM DMA pool code (if enabled) can use it. The DMA API code
needs the 'struct device' to do the DMA API operations.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/nouveau/nouveau_mem.c |3 ++-
drivers/gpu/drm/radeo
Which has the function members for all of the current page pool
operations defined. The old calls (ttm_put_pages, ttm_get_pages, etc)
are plumbed through little functions which lookup in the ttm_page_alloc_func
the appropiate implementation and call it.
There is currently only one page pool code s
. instead of checking against the DMA_ERROR_CODE value which is
per-platform specific. The zero value is a known invalid value
that the TTM layer sets on the dma_address array if it is not
used (ttm_tt_alloc_page_directory calls drm_calloc_large which
creates a page with GFP_ZERO).
We can't use pc
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
From: Dave Airlie
For the simple KMS driver case we need some more info about argb cursor
limits and a preferred depth and if shadowed framebuffer access is preferred.
I've only added this for intel/radeon which support the dumb ioctls so far.
I really don't want to expose a truck load of info,
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #10 from Martin Stolpe 2011-09-29 15:21:53
PDT ---
Created an attachment (id=51780)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51780)
Build script used to create mesa package
--
Configure bugmail: https://bugs.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #9 from Martin Stolpe 2011-09-29 15:21:25
PDT ---
Created an attachment (id=51779)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51779)
log file for xorg server
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cg
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #10 from Martin Stolpe 2011-09-29
15:21:53 PDT ---
Created an attachment (id=51780)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51780)
Build script used to create mesa package
--
Configure bugmail: https://bugs.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=30402
--- Comment #9 from Martin Stolpe 2011-09-29
15:21:25 PDT ---
Created an attachment (id=51779)
--> (https://bugs.freedesktop.org/attachment.cgi?id=51779)
log file for xorg server
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cg
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Martin Stolpe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=30402
Martin Stolpe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On Wed, Sep 28, 2011 at 04:10:08PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/Makefile |2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 34 ++-
> drivers/gpu/drm/vmwgfx
Hi guys,
I've pushed a 'restart' branch to the xf86-video-modesetting driver,
Its a basic attempt to write a simple generic unaccelerated, fallback
driver for KMS. I need this to do some hotplug testing and work.
Features:
argb cursor support
randr 1.2
dirty tracking ioctl support.
Differences
On Wed, Sep 28, 2011 at 04:10:06PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> More preparation for Screen Object support.
>
> Signed-off-by: Jakob Bornecrantz
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 238 +++
On Wed, Sep 28, 2011 at 04:10:01PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/driver
On Wed, Sep 28, 2011 at 04:10:02PM +0200, Thomas Hellstrom wrote:
> From: Jakob Bornecrantz
>
> Signed-off-by: Jakob Bornecrantz
> Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/dr
https://bugs.freedesktop.org/show_bug.cgi?id=1236
--- Comment #5 from Marcin Baczyński 2011-09-29 14:34:13
PDT ---
Probably the MGA bugs can be closed now that the driver is removed from git?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=1236
--- Comment #5 from Marcin Baczy?ski 2011-09-29 14:34:13
PDT ---
Probably the MGA bugs can be closed now that the driver is removed from git?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=41340
--- Comment #9 from mlam...@gmail.com 2011-09-29 13:41:47 PDT ---
According to
http://linux-hybrid-graphics.blogspot.com/2011/08/bios-update-has-been-released-for-amd.html
vgaswitcheroo should work when using the "Fixed Mode" BIOS setting, but I s
https://bugs.freedesktop.org/show_bug.cgi?id=41340
--- Comment #9 from mlambda at gmail.com 2011-09-29 13:41:47 PDT ---
According to
http://linux-hybrid-graphics.blogspot.com/2011/08/bios-update-has-been-released-for-amd.html
vgaswitcheroo should work when using the "Fixed Mode" BIOS setting, but
As a mechanism to detect whether SWIOTLB is enabled or not.
We also fix the spelling - it was swioltb instead of
swiotlb.
CC: FUJITA Tomonori
[v1: Ripped out swiotlb_enabled]
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/swiotlb-xen.c |2 +-
include/linux/swiotlb.h |2 +-
lib/s
The TTM DMA only gets turned on when the SWIOTLB is enabled - but
we might also want to turn it off when SWIOTLB is on to
use the non-DMA TTM pool code.
In the future this parameter can be removed.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |4
in
[.. and this is what I said in v1 post]:
Way back in January this patchset:
http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html
was merged in, but pieces of it had to be reverted b/c they did not
work properly under PowerPC, ARM, and when swapping out pages to disk.
After a b
. and provide in the function callback a method to register
with the backend a new (*set_caching).
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 46 ++
drivers/gpu/drm/ttm/ttm_tt.c | 46 +---
. which is pretty much like the other TTM pool except it
also handles moving the page to another pool list.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 96 ++
1 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/dri
All the storage devices that use the dmapool set the coherent DMA
mask so they can properly use the dmapool. Since the TTM DMA pool
code is based on that and dma_alloc_coherent checks the
'coherent_dma_mask' and not 'dma_mask' we want to set it.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/g
1 - 100 of 191 matches
Mail list logo
