On Thu, Nov 03, 2011 at 03:48:52PM -0700, Jesse Barnes wrote:
> On Thu, 3 Nov 2011 11:21:18 -0700
> Jesse Barnes wrote:
>
> > On Wed, 2 Nov 2011 15:33:04 -0700
> > Jesse Barnes wrote:
> >
> > > On Wed, 2 Nov 2011 13:03:19 -0700
> > > Jesse Barnes wrote:
> > >
> > > > Planes are a bit like ha
On Thu, Nov 03, 2011 at 10:25:18PM +, Alan Cox wrote:
> The ioremap for stolen RAM is about 8MB - we do actually need that mapped
> for the console framebuffer. The GTT tables are pretty small (64K or so)
> and the rest of the GTT space if ever used doesn't get an ioremap.
>
> It's a bit diffe
> The first poulsbos used to crash badly when attempting to map the GTT
> write-combined, and IIRC it didn't even advertise write-combining
> capabilities on the PCI BAR. Has this been improved on lately or how is
> this handled currently?
It seems to be reliable in the current driver. Whether
The ioremap for stolen RAM is about 8MB - we do actually need that mapped
for the console framebuffer. The GTT tables are pretty small (64K or so)
and the rest of the GTT space if ever used doesn't get an ioremap.
It's a bit different to the i915 world because the CPU cannot indirect
via the GTT b
> We're talking about gpus, there's no way an application will talk to them
> than through some nice cozy abstraction layer like OpenGl, X, ... Even
> Wayland has gbm to do the low-level kms scanout allocation.
You are talking about scanouts. Nothing more. Nothing in KMS/DRM even
requires GPU acce
On 11/03/2011 07:20 PM, Alan Cox wrote:
> From: Alan Cox
>
> This driver supports unaccelerated KMS display, and accelerated console
> handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.
>
> For the initial merge Medfield will be left out as it needs considerable
> further wor
On Thu, Nov 03, 2011 at 06:21:09PM +, Alan Cox wrote:
> From: Alan Cox
>
> This fits alongside the GEM support to manage our resources on the card
> itself. It's not actually clear we need to configure the MMU at all.
> Further research is needed before removing it entirely. For now we suck i
From: Jakob Bornecrantz
Enough to get cursors working under Wayland.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 66e92ac.
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 667437b..66e9
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 5ccce1c..4
A number of fixes for bugs discovered by Jakob while doing Wayland/EGL testing.
On Thu, Nov 03, 2011 at 06:20:58PM +, Alan Cox wrote:
> From: Alan Cox
>
> The driver uses GEM along with a couple of small bits of wrapping of its
> own. The only real oddity here is the support for using the 'stolen' memory
> rather than wasting several MB.
>
> We use a simple resource man
On Thu, Nov 03, 2011 at 05:47:43PM +, Alan Cox wrote:
> > In short decoding these fourcc values with all their implicit assumptions
> > about offset, strides and whatnotelse will be one giant switch mess. Not
> > my idea of a nice kernel interface. Also practically guaranteed to result
> > in s
From: Konrad Rzeszutek Wilk
With the exception that we do not handle the AGP case. We only
deal with PCIe cards such as ATI ES1000 or HD3200 that have been
detected to only do DMA up to 32-bits.
CC: Dave Airlie
CC: Alex Deucher
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Jerome Glisse
From: Konrad Rzeszutek Wilk
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/linu
From: Konrad Rzeszutek Wilk
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
From: Jerome Glisse
Move the page allocation and freeing to driver callback and
provide ttm code helper function for those.
Most intrusive change, is the fact that we now only fully
populate an object this simplify some of code designed around
the page fault design.
Signed-off-by: Jerome Glisse
From: Jerome Glisse
ttm_backend will exist only and only with a ttm_tt, and ttm_tt
will be of interesting use only when bind to a backend. Thus to
avoid code & data duplication btw the two merge them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 14 ++-
drivers/
From: Jerome Glisse
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2dd45ca..58ea7dc 100644
--- a/drivers
From: Jerome Glisse
Use the ttm_tt page ptr array for page allocation, move the list to
array unwinding into the page allocation functions.
V2 split the fix to use ttm put page as a separate fix
properly fill pages array when TTM_PAGE_FLAG_ZERO_ALLOC is not
set
V3 Added back page_count()==1 chec
From: Jerome Glisse
On failure we need to make sure the page we free has wb cache
attribute. Do this pas call the proper ttm page helper function.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 files changed, 4 insertions(+), 1
From: Jerome Glisse
This field is not use by any of the driver just drop it.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff
From: Jerome Glisse
Split btw highmem and lowmem page was rendered useless by the
pool code. Remove it. Note further cleanup would change the
ttm page allocation helper to actualy take an array instead
of relying on list this could drasticly reduce the number of
function call in the common case o
From: Jerome Glisse
This was never use in none of the driver, properly using userspace
page for bo would need more code (vma interaction mostly). Removing
this dead code in preparation of ttm_tt & backend merge.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/d
Hi,
So updated patchset, only patch 5 seen change since last set.
Last 3 patch are from your patchset, modified on top of mine.
Konrad so i added you dma pool allocator on top of that
and added support for it to radeon. All in all it's slightly
smaller than your patchset.
Biggest change is use o
Hi Jesse,
It sees that there might be an overflow when crtc_w or crtc_h =0.
Following is my patch.
Thanks and best regards.
Hai Lan
>From 778327daa3451f3c5f41c5db8bdccdcbf484267b Mon Sep 17 00:00:00 2001
From: Hai Lan
Date: Fri, 4 Nov 2011 18:08:11 +0800
Subject: [PATCH] drm/i915:fix the overf
11/03/2011 05:03 AM, Jesse Barnes 쓴 글:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 ++
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #9 from Mandeep Singh Baines 2011-11-03
19:15:58 PDT ---
Tested with drm-fixes-staging. Same behavior.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Hi all,
I've discussed this a bit on irc and consensus seems to be "some ugliness
due to interface impendance mistmatches in the kernel? who cares ...". I
agree that there's not a fundamental problem with fourcc and planar yuv
that can't be fixed with a bunch of boilerplate code with the assorted
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/Kconfig |3 +++
drivers/gpu/drm/Makefile |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b493663..7c1cb0d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b
From: Alan Cox
Again this is similar but has some differences so we have a set of plug in
support. This does make the driver bigger than is needed in some respects
but the tradeoff for maintainability is huge.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c| 351 +
From: Alan Cox
Oaktrail (GMA600) is found on some tablet/slate PC type systems. It's a bit
different to the GMA500 but similar enough it makes sense to plug it into
the same driver.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail.h | 252
drivers/gpu/drm/gma500/
From: Alan Cox
This provides the specific code for Poulsbo, some of which is also used for
the later chipsets. We support the GTT, the 2D engine (for console), and
the display setup/management. We do not support 3D or the video overlays.
In theory enough public info is available to do the video
From: Alan Cox
Not really a nice way to split this up further for submission. This
provides all the DRM interfacing logic, the headers and relevant glue.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drm.h | 207 +++
drivers/gpu/drm/gma500/psb_drv.c | 1210 ++
From: Alan Cox
Again this might be a candidate for sharing later.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_i2c.c | 169
1 files changed, 169 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/gma500/intel_i2c.c
diff --git
From: Alan Cox
Some of this should one day become a library shared by i915 and gma500 I
suspct. Best however to deal with that later once it is all nice and
stably merged.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_bios.c | 303 ++
drivers/gpu/drm/gma500
From: Alan Cox
The devices have various internal differences so we have some abstractions
to hide the ugly differences and we then wrap them up in standard
interfaces. Add these bits
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/backlight.c | 49 ++
drivers/gpu/drm/gma500/power.c
Hi,
Quick question: How does this compare to Dave Airlies' PRIME buffer
sharing work for drm respectively the more generic dma_buf buffer sharing
work pushed by Linaro? You seem to aim for a solution for similar problems
(judging by your description) using a rather different approach.
Cheers, Dan
From: Alan Cox
We support 2D acceleration on some devices but we try and do tricks with
the GTT as a starting point as this is far faster. The GTT logic could be
improved further but for most display sizes it already makes a pretty good
decision.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gm
From: Alan Cox
This fits alongside the GEM support to manage our resources on the card
itself. It's not actually clear we need to configure the MMU at all.
Further research is needed before removing it entirely. For now we suck it
in (slightly abused) from the old semi-free driver.
Signed-off-by
From: Alan Cox
The driver uses GEM along with a couple of small bits of wrapping of its
own. The only real oddity here is the support for using the 'stolen' memory
rather than wasting several MB.
We use a simple resource manager as we don't need to manage our space
intensively at all as we only
From: Alan Cox
This driver supports unaccelerated KMS display, and accelerated console
handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.
For the initial merge Medfield will be left out as it needs considerable
further work to reach a decent standard
Begin by adding the M
> Well the current plan I had for this was to do it in userspace, I don't think
> the kernel
> has any business doing it and I think for the simple USB case its fine but
> will fallover
> when you get to the non-trivial cases where some sort of acceleration is
> required to move
> pixels around.
> In short decoding these fourcc values with all their implicit assumptions
> about offset, strides and whatnotelse will be one giant switch mess. Not
> my idea of a nice kernel interface. Also practically guaranteed to result
> in slightly different behaviour in each driver.
So you'd rather make
Am 03.11.2011 16:59, schrieb Ilija Hadzic:
> Hi everyone,
>
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will prov
From: Konrad Rzeszutek Wilk
With the exception that we do not handle the AGP case. We only
deal with PCIe cards such as ATI ES1000 or HD3200 that have been
detected to only do DMA up to 32-bits.
CC: Dave Airlie
CC: Alex Deucher
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Jerome Glisse
From: Konrad Rzeszutek Wilk
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/linu
From: Konrad Rzeszutek Wilk
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
From: Jerome Glisse
Move the page allocation and freeing to driver callback and
provide ttm code helper function for those.
Most intrusive change, is the fact that we now only fully
populate an object this simplify some of code designed around
the page fault design.
Signed-off-by: Jerome Glisse
From: Jerome Glisse
ttm_backend will exist only and only with a ttm_tt, and ttm_tt
will be of interesting use only when bind to a backend. Thus to
avoid code & data duplication btw the two merge them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 14 ++-
drivers/
From: Jerome Glisse
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 2dd45ca..58ea7dc 100644
--- a/drivers
From: Jerome Glisse
Use the ttm_tt page ptr array for page allocation, move the list to
array unwinding into the page allocation functions.
V2 split the fix to use ttm put page as a separate fix
properly fill pages array when TTM_PAGE_FLAG_ZERO_ALLOC is not
set
V3 Added back page_count()==1 chec
From: Jerome Glisse
On failure we need to make sure the page we free has wb cache
attribute. Do this pas call the proper ttm page helper function.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 files changed, 4 insertions(+), 1
From: Jerome Glisse
This field is not use by any of the driver just drop it.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff
From: Jerome Glisse
Split btw highmem and lowmem page was rendered useless by the
pool code. Remove it. Note further cleanup would change the
ttm page allocation helper to actualy take an array instead
of relying on list this could drasticly reduce the number of
function call in the common case o
From: Jerome Glisse
This was never use in none of the driver, properly using userspace
page for bo would need more code (vma interaction mostly). Removing
this dead code in preparation of ttm_tt & backend merge.
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
---
drivers/gpu/d
Hi,
So updated patchset, only patch 5 seen change since last set.
Last 3 patch are from your patchset, modified on top of mine.
Konrad so i added you dma pool allocator on top of that
and added support for it to radeon. All in all it's slightly
smaller than your patchset.
Biggest change is use o
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #8 from Anisse Astier 2011-11-03 09:17:28 PDT
---
As I said to Alex on IRC, these patches also solves the issue on Toshiba
laptops: C670D-10C (AMD E-240) and C670D-11K (AMD E-450).
(Old reference: https://bugzilla.kernel.org/show_bug
On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes
wrote:
> Except for VDD?? That does come on... and shouldn't be any different
> than a full power sequence as far as link training etc go...
Oh, that's a good point. Doing things in this order essentially forces
yet another full panel power seque
...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/2d627f57/attachment.pgp>
On Thu, Nov 03, 2011 at 03:48:52PM -0700, Jesse Barnes wrote:
> On Thu, 3 Nov 2011 11:21:18 -0700
> Jesse Barnes wrote:
>
> > On Wed, 2 Nov 2011 15:33:04 -0700
> > Jesse Barnes wrote:
> >
> > > On Wed, 2 Nov 2011 13:03:19 -0700
> > > Jesse Barnes wrote:
> > >
> > > > Planes are a bit like ha
On Thu, 3 Nov 2011 11:21:18 -0700
Jesse Barnes wrote:
> On Wed, 2 Nov 2011 15:33:04 -0700
> Jesse Barnes wrote:
>
> > On Wed, 2 Nov 2011 13:03:19 -0700
> > Jesse Barnes wrote:
> >
> > > Planes are a bit like half-CRTCs. They have a location and fb, but
> > > don't drive outputs directly. A
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes
wrote:
> Reviewed-by: Jesse Barnes
I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.
That leaves only the panel power sequencing changes, which could
probably use more testing to make sur
On Thu, 3 Nov 2011 11:21:18 -0700
Jesse Barnes wrote:
> On Wed, 2 Nov 2011 15:33:04 -0700
> Jesse Barnes wrote:
>
> > On Wed, 2 Nov 2011 13:03:19 -0700
> > Jesse Barnes wrote:
> >
> > > Planes are a bit like half-CRTCs. They have a location and fb, but
> > > don't drive outputs directly. A
hment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/84f30dfb/attachment.pgp>
On Thu, 03 Nov 2011 15:30:57 -0700
Keith Packard wrote:
> On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes
> wrote:
>
> > A few comments on this one (also, is it strictly required to fix your
> > bug)?
>
> I think so; the panel definitely was not happy when I turned the link
> off while the pa
on sequence, but at least they're
consistent.
--
Jesse Barnes, Intel Open Source Technology Center
-- 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/2003/5358e1d7/attachment.pgp>
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes
wrote:
> Reviewed-by: Jesse Barnes
Thanks for your careful patch review here.
--
keith.pack...@intel.com
pgpPNrs802K0I.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freed
ize: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/ba7ed7d4/attachment.pgp>
On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes
wrote:
> Sneaky putting this bug fix into this patch. :)
Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.
> Don't you love the training state machine? I th
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/5b3f82a9/attachment.pgp>
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes
wrote:
> A few comments on this one (also, is it strictly required to fix your
> bug)?
I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS paths
doing things in d
On Thu, Nov 03, 2011 at 10:25:18PM +, Alan Cox wrote:
> The ioremap for stolen RAM is about 8MB - we do actually need that mapped
> for the console framebuffer. The GTT tables are pretty small (64K or so)
> and the rest of the GTT space if ever used doesn't get an ioremap.
>
> It's a bit diffe
vailable
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/77cf237e/attachment-0001.pgp>
> The first poulsbos used to crash badly when attempting to map the GTT
> write-combined, and IIRC it didn't even advertise write-combining
> capabilities on the PCI BAR. Has this been improved on lately or how is
> this handled currently?
It seems to be reliable in the current driver. Whether
On Thu, 3 Nov 2011 22:20:00 +
Alan Cox wrote:
> > We're talking about gpus, there's no way an application will talk to them
> > than through some nice cozy abstraction layer like OpenGl, X, ... Even
> > Wayland has gbm to do the low-level kms scanout allocation.
>
> You are talking about sca
The ioremap for stolen RAM is about 8MB - we do actually need that mapped
for the console framebuffer. The GTT tables are pretty small (64K or so)
and the rest of the GTT space if ever used doesn't get an ioremap.
It's a bit different to the i915 world because the CPU cannot indirect
via the GTT b
re
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/c8544473/attachment.pgp>
On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes wrote:
> On Thu, 3 Nov 2011 18:29:14 +0100
> Daniel Vetter wrote:
>
>> Hi all,
>>
>> I've discussed this a bit on irc and consensus seems to be "some ugliness
>> due to interface impendance mistmatches in the kernel? who cares ...". I
>> agree that th
> We're talking about gpus, there's no way an application will talk to them
> than through some nice cozy abstraction layer like OpenGl, X, ... Even
> Wayland has gbm to do the low-level kms scanout allocation.
You are talking about scanouts. Nothing more. Nothing in KMS/DRM even
requires GPU acce
On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote:
> In response to feedback, I've adjusted the new addfb2 ioctl to take per
> component pitch and offset args. Generally, the offset[0] field will be
> 0, but it's conceivable that some metadata could be stored at the start
> of a given b
On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes
wrote:
> Modulo what we already discussed on irc about the PP_READY bit, and the
Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
not actually useful.
>
on-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2003/6e023fe9/attachment.pgp>
On Wed, Nov 02, 2011 at 07:37:53PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
Reviewed-by-me.
> ---
> drivers/gpu/drm/ttm/ttm_tt.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/driv
On Wed, Nov 02, 2011 at 07:37:52PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Use the ttm_tt page ptr array for page allocation, move the list to
> array unwinding into the page allocation functions.
>
> V2 split the fix to use ttm put page as a separate fix
> properly fill pa
On Wed, Nov 02, 2011 at 07:37:51PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> On failure we need to make sure the page we free has wb cache
> attribute. Do this pas call the proper ttm page helper function.
>
> Signed-off-by: Jerome Glisse
Reviewed-by...
> ---
> drivers/gpu
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #8 from Alex Deucher 2011-11-03 07:17:19 PDT
---
(In reply to comment #7)
> I've tried 3.0.6, 3.1 and the drm-core-next branch from:
> git://people.freedesktop.org/~airlied/linux
>
> Is there a radeon linux kernel tree I could test?
On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes
wrote:
> On Thu, 3 Nov 2011 18:29:14 +0100
> Daniel Vetter wrote:
>
>> Hi all,
>>
>> I've discussed this a bit on irc and consensus seems to be "some ugliness
>> due to interface impendance mistmatches in the kernel? who cares ...". I
>> agree that t
>
> Hi everyone,
>
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will provide a short abstract, so that you can
>
On 11/03/2011 07:20 PM, Alan Cox wrote:
From: Alan Cox
This driver supports unaccelerated KMS display, and accelerated console
handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware.
For the initial merge Medfield will be left out as it needs considerable
further work to reach
On Thu, Nov 03, 2011 at 06:21:09PM +, Alan Cox wrote:
> From: Alan Cox
>
> This fits alongside the GEM support to manage our resources on the card
> itself. It's not actually clear we need to configure the MMU at all.
> Further research is needed before removing it entirely. For now we suck i
From: Jakob Bornecrantz
Enough to get cursors working under Wayland.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/
On Tue, 1 Nov 2011 23:20:30 -0700
Keith Packard wrote:
> Found a couple of bare tabs in intel_dp.c
>
> 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.c b/drive
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 66e92ac.
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 667437b..66e9
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
On Tue, 1 Nov 2011 23:20:29 -0700
Keith Packard wrote:
> Instead of going through the sequence just once, run through the whole
> set up to 5 times to see if something can work. This isn't part of the
> DP spec, but the BIOS seems to do it, and given that link training
> failure is so bad, it se
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 5ccce1c..4
1 - 100 of 170 matches
Mail list logo
