n/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2011/28490dc7/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=38488
Harald Judt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=38022
Harald Judt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis
wrote:
> On Fri, Nov 11, 2011 at 7:17 PM, James Simmons
> wrote:
>>
>>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>>> > I'm not sure whether / how you handle the case of hardware render to
>>> > cursor surfaces on i915, b
On Fri, Nov 11, 2011 at 7:17 PM, James Simmons
wrote:
>
>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>> > I'm not sure whether / how you handle the case of hardware render to
>> > cursor surfaces on i915, but it seems to me like if a lot of drivers
>> > need to implement d
On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
> On Fri, 11 Nov 2011 18:04:04 +0200
> ville.syrjala at linux.intel.com wrote:
>
> > From: Ville Syrj?l?
> >
> > Make sure the source coordinates stay within the buffer.
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/
On Fri, Nov 11, 2011 at 09:01:46AM -0800, Jesse Barnes wrote:
> On Fri, 11 Nov 2011 18:04:05 +0200
> ville.syrjala at linux.intel.com wrote:
>
> > From: Ville Syrj?l?
> >
> > Help drivers a little by guaranteeing that crtc_x+crtc_w and
> > crtc_y+crtc_h don't overflow.
> >
> > Signed-off-by: Vi
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 48
include/drm/drm_crtc.h| 55 +
include/drm/drm_crtc_helper.h |5 +++
3 files changed, 108 insertions(+), 0 del
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 102 +
include/drm/drm_crtc_helper.h |4 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm
From: Ville Syrj?l?
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 156 +
include/drm/drm_crtc_helper.h | 24 ++
2
From: Ville Syrj?l?
This function performs a battery of sanity checks on the requested
framebuffer layout. Drivers can call it from their fb_create hook.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 70 +
include/drm/drm_crtc_helper
From: Ville Syrj?l?
These functions return the chroma subsampling factors for the specified
pixel format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 67 +
include/drm/drm_crtc_helper.h |2 +
2 files changed, 69 insertions(
From: Ville Syrj?l?
This function returns the bytes per pixel value based on the pixel
format and plane index.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 43 +
include/drm/drm_crtc_helper.h |1 +
2 files changed, 44 insert
From: Ville Syrj?l?
This function returns the number of planes used by a specific pixel
format.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c | 33 +
include/drm/drm_crtc.h|1 +
include/drm/drm_crtc_helper.h |3 +++
This set intoduces a bunch of helper functions for help drm plane
driver writers deal with scaling and other details. Still work in progress,
escpecially the last patch.
Some open questions:
- In which file should this kind of stuff be placed?
- How should the functions be named?
- Should the sc
> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
> > I'm not sure whether / how you handle the case of hardware render to
> > cursor surfaces on i915, but it seems to me like if a lot of drivers
> > need to implement driver specific "tricks" to meet the semantics of
> > a generi
On Fri, Nov 11, 2011 at 03:33:07PM +, James Simmons wrote:
>
> > Review, flames highly welcome.
> >
> > Cheers, Daniel
> >
> > Daniel Vetter (23):
> > drm/sis: track obj->drm_fd relations in the driver
> > drm/via: track obj->drm_fd relations in the driver
> > drm/sman: kill owner trac
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 27d46b1..04680bc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/driver
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |2 +-
include/drm/drm_crtc.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2410a9a..27d46b1 100644
--- a/drivers/gpu
From: Ville Syrj?l?
Help drivers a little by guaranteeing that crtc_x+crtc_w and
crtc_y+crtc_h don't overflow.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/g
From: Ville Syrj?l?
Make sure the source coordinates stay within the buffer.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index
From: Ville Syrj?l?
These are the only indication to user space that the plane was disabled.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d3b88
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7058ed3..d3b884e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/
From: Ville Syrj?l?
Avoids having junk in offsets[] and pitches[] arrays.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 39cccb4..7058ed3 100644
This set has a bunch of fixes and additional checks on top of Jesse's
drm plane series.
Jesse, feel free to squash some or all of these with your patches.
From: Jerome Glisse
Provide helper function to compute the kernel memory size needed
for each buffer object. Move all the accounting inside ttm, simplifying
driver and avoiding code duplication accross them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++-
From: Jerome Glisse
Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.
V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V3 Make sure page l
From: Konrad Rzeszutek Wilk
If the card is capable of more than 32-bit, then use the default
TTM page pool code which allocates from anywhere in the memory.
Note: If the 'ttm.no_dma' parameter is set, the override is ignored
and the default TTM pool is used.
V2 use pci_set_consistent_dma_mask
V
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.
V2 force dma32 if we fail to set bigger dma mask
V3 Rebase on top of no memory account changes (where
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.
V2 Rebase on top of memory a
From: Jerome Glisse
ttm_backend will only exist with a ttm_tt, and ttm_tt
will only be of interest when bound to a backend. Merge them
to avoid code and data duplication.
V2 Rebase on top of memory accounting overhaul
V3 Rebase on top of more memory accounting changes
V4 Rebase on top of no memo
From: Jerome Glisse
Use the ttm_tt pages array for pages allocations, move the list
unwinding into the page allocation functions.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 85 +-
drivers/gpu/drm/ttm/ttm_tt.c | 36 +++
From: Jerome Glisse
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Thomas Hellstrom
---
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 90527a
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
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 fi
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
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 inser
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
Reviewed-by: Thoma
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
So attached is updated serie of patch with fixes for swaping issue
that also impacted memory accounting. Last patch fix memory accounting
for radeon & nouveau. I think it's ready to go into drm-next, patchset
is against linus tree as there is thing there not in next that conflict.
(in radeon iirc)
On 11/11/2011 04:47 PM, Jerome Glisse wrote:
> On Fri, Nov 11, 2011 at 08:49:39AM +0100, Thomas Hellstrom wrote:
>
>> On 11/11/2011 12:33 AM, Jerome Glisse wrote:
>>
>>> On Thu, Nov 10, 2011 at 09:05:22PM +0100, Thomas Hellstrom wrote:
>>>
On 11/10/2011 07:05 PM, Jerome Gliss
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #14 from Jerome Glisse 2011-11-11 16:13:51
PST ---
Created attachment 53428
--> https://bugs.freedesktop.org/attachment.cgi?id=53428
Verbose debug to help pin point issue
Can you build a kernel with attached patch and boot with io
> Review, flames highly welcome.
>
> Cheers, Daniel
>
> Daniel Vetter (23):
> drm/sis: track obj->drm_fd relations in the driver
> drm/via: track obj->drm_fd relations in the driver
> drm/sman: kill owner tracking interface functions
> drm/sman: rip out owner tracking
> drm/via: track
Hi Linus,
Pretty much fixes for everything, nouveau and radeon are the main ones,
some vmwgfx also, and one exynos. A few core drm fixes and cleanups.
I've included 3 i915 fixes, one serious hang, one build and one leak, I
know Keith has these queued but he seems to have been a bit busy and I'
From: Jerome Glisse
Provide helper function to compute the kernel memory size needed
for each buffer object. Move all the accounting inside ttm, simplifying
driver and avoiding code duplication accross them.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++-
From: Jerome Glisse
Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.
V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V3 Make sure page l
From: Konrad Rzeszutek Wilk
If the card is capable of more than 32-bit, then use the default
TTM page pool code which allocates from anywhere in the memory.
Note: If the 'ttm.no_dma' parameter is set, the override is ignored
and the default TTM pool is used.
V2 use pci_set_consistent_dma_mask
V
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.
V2 force dma32 if we fail to set bigger dma mask
V3 Rebase on top of no memory account changes (where
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.
V2 Rebase on top of memory a
From: Jerome Glisse
ttm_backend will only exist with a ttm_tt, and ttm_tt
will only be of interest when bound to a backend. Merge them
to avoid code and data duplication.
V2 Rebase on top of memory accounting overhaul
V3 Rebase on top of more memory accounting changes
V4 Rebase on top of no memo
From: Jerome Glisse
Use the ttm_tt pages array for pages allocations, move the list
unwinding into the page allocation functions.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 85 +-
drivers/gpu/drm/ttm/ttm_tt.c | 36 +++
From: Jerome Glisse
Signed-off-by: Jerome Glisse
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Thomas Hellstrom
---
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 90527a
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
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_tt.c |5 -
1 fi
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
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/radeon/radeon_ttm.c |1 -
include/drm/ttm/ttm_bo_driver.h |2 --
2 files changed, 0 inser
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
Reviewed-by: Thoma
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
So attached is updated serie of patch with fixes for swaping issue
that also impacted memory accounting. Last patch fix memory accounting
for radeon & nouveau. I think it's ready to go into drm-next, patchset
is against linus tree as there is thing there not in next that conflict.
(in radeon iirc)
https://bugs.freedesktop.org/show_bug.cgi?id=38488
Harald Judt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=38022
Harald Judt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=42808
--- Comment #5 from Michel D?nzer 2011-11-11 04:42:28
PST ---
Then it sounds like your laptop is muxless, i.e. the Radeon GPU physically
isn't connected to any display outputs. I'm afraid this won't be supported for
a long time, as it requires a
On Fri, Nov 11, 2011 at 05:22:26PM +0100, Thomas Hellstrom wrote:
> On 11/11/2011 04:47 PM, Jerome Glisse wrote:
> >On Fri, Nov 11, 2011 at 08:49:39AM +0100, Thomas Hellstrom wrote:
> >>On 11/11/2011 12:33 AM, Jerome Glisse wrote:
> >>>On Thu, Nov 10, 2011 at 09:05:22PM +0100, Thomas Hellstrom wrot
https://bugs.freedesktop.org/show_bug.cgi?id=42808
--- Comment #4 from samit vats 2011-11-11 04:12:54 PST
---
(In reply to comment #3)
> This may be because the primary device is the integrated Intel GPU, not the
> Radeon one. Possible solutions might be removing the Section "Device" for the
> r
On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis wrote:
> On Fri, Nov 11, 2011 at 7:17 PM, James Simmons wrote:
>>
>>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>>> > I'm not sure whether / how you handle the case of hardware render to
>>> > cursor surfaces on i915, but i
On Fri, Nov 11, 2011 at 7:17 PM, James Simmons wrote:
>
>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>> > I'm not sure whether / how you handle the case of hardware render to
>> > cursor surfaces on i915, but it seems to me like if a lot of drivers
>> > need to implement dr
https://bugs.freedesktop.org/show_bug.cgi?id=42808
--- Comment #3 from Michel D?nzer 2011-11-11 02:56:29
PST ---
This may be because the primary device is the integrated Intel GPU, not the
Radeon one. Possible solutions might be removing the Section "Device" for the
radeon driver (letting it be
Another comment below, I'd rather you respin them, with a version
number on them so I know which ones to pick up, really this is my 3rd
try at merging these and I keep finding sillyness.
>> index 07711b0..3cfa160 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -27,6 +27,8
On Fri, Nov 11, 2011 at 10:47 AM, Dave Airlie wrote:
> On Tue, Nov 8, 2011 at 9:18 PM, Jesse Barnes
> wrote:
>> To properly support the various plane formats supported by different
>> hardware, the kernel must know the pixel format of a framebuffer object.
>> So add a new ioctl taking a format a
On Fri, Nov 11, 2011 at 08:49:39AM +0100, Thomas Hellstrom wrote:
> On 11/11/2011 12:33 AM, Jerome Glisse wrote:
> >On Thu, Nov 10, 2011 at 09:05:22PM +0100, Thomas Hellstrom wrote:
> >>On 11/10/2011 07:05 PM, Jerome Glisse wrote:
> >>>On Thu, Nov 10, 2011 at 11:27:33AM +0100, Thomas Hellstrom wrot
On Tue, Nov 8, 2011 at 9:18 PM, Jesse Barnes
wrote:
> To properly support the various plane formats supported by different
> hardware, the kernel must know the pixel format of a framebuffer object.
> So add a new ioctl taking a format argument corresponding to a fourcc
> name from videodev2.h. ?I
https://bugs.freedesktop.org/show_bug.cgi?id=42808
samit vats changed:
What|Removed |Added
Priority|medium |high
--
Configure bugmail: https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=42808
--- Comment #2 from samit vats 2011-11-11 02:37:23 PST
---
Created attachment 53394
--> https://bugs.freedesktop.org/attachment.cgi?id=53394
xorg.conf
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=42808
--- Comment #1 from samit vats 2011-11-11 02:36:59 PST
---
Created attachment 53393
--> https://bugs.freedesktop.org/attachment.cgi?id=53393
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=42808
Bug #: 42808
Summary: Xserver fails to start with NI Seymour XT
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
OS/Version: All
St
> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
> > I'm not sure whether / how you handle the case of hardware render to
> > cursor surfaces on i915, but it seems to me like if a lot of drivers
> > need to implement driver specific "tricks" to meet the semantics of
> > a generi
On 11/11/2011 09:47 AM, Dave Airlie wrote:
>> What are the symptoms of the failure you're seeing with Radeon? Any
>> suggestions on why it happens?
>>
> I suspect radeon swapping might have some issues, I really think we
> should put the effort into a test suite like the intel-gpu-tools,
> in
On Fri, 11 Nov 2011 19:11:39 +0200
Ville Syrjälä wrote:
> On Fri, Nov 11, 2011 at 09:01:46AM -0800, Jesse Barnes wrote:
> > On Fri, 11 Nov 2011 18:04:05 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Help drivers a little by guaranteeing that crtc_x+cr
On Fri, 11 Nov 2011 19:18:52 +0200
Ville Syrjälä wrote:
> On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
> > On Fri, 11 Nov 2011 18:04:04 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Make sure the source coordinates stay within the buf
ractice, since the drivers will have to
> > validate the target CRTC rect against the actual pipe dimensions anyway.
>
> My master plan is that drivers would just stick these into a drm_region
> (introduced in my other patchset) and clip that to the pipe dimensions.
Ok that makes
->crtc_y,
> > >plane_req->crtc_w, plane_req->crtc_h,
> >
> > Good sanity check (saves the drivers from having to do it), but I
> > wonder if we can use a better return value like ENOSPC or something to
> > make it easier for userspace to figure out.
>
> Yeah, getting EINVAL for every kind of failure is rather annoying. The
> only issue I have with ENOSPC is the strerror() output. It doesn't
> exactly fit this use case. But if there's nothing better I'm OK with
> ENOSPC.
Yeah, dunno what's best. Check out include/asm-generic/errno-base.h
and errno.h; maybe you'll find a better fit.
--
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/2011/d6065f8b/attachment.pgp>
On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
> On Fri, 11 Nov 2011 18:04:04 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Make sure the source coordinates stay within the buffer.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm
On Fri, Nov 11, 2011 at 05:22:26PM +0100, Thomas Hellstrom wrote:
> On 11/11/2011 04:47 PM, Jerome Glisse wrote:
> >On Fri, Nov 11, 2011 at 08:49:39AM +0100, Thomas Hellstrom wrote:
> >>On 11/11/2011 12:33 AM, Jerome Glisse wrote:
> >>>On Thu, Nov 10, 2011 at 09:05:22PM +0100, Thomas Hellstrom wrot
On Fri, Nov 11, 2011 at 09:01:46AM -0800, Jesse Barnes wrote:
> On Fri, 11 Nov 2011 18:04:05 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Help drivers a little by guaranteeing that crtc_x+crtc_w and
> > crtc_y+crtc_h don't overflow.
> >
> > Signed-off-by: Ville
On Fri, Nov 11, 2011 at 03:33:07PM +, James Simmons wrote:
>
> > Review, flames highly welcome.
> >
> > Cheers, Daniel
> >
> > Daniel Vetter (23):
> > drm/sis: track obj->drm_fd relations in the driver
> > drm/via: track obj->drm_fd relations in the driver
> > drm/sman: kill owner trac
From: Ville Syrjälä
This function performs a battery of sanity checks on the requested
framebuffer layout. Drivers can call it from their fb_create hook.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 70 +
include/drm/drm_crtc_helper
From: Ville Syrjälä
These functions return the chroma subsampling factors for the specified
pixel format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 67 +
include/drm/drm_crtc_helper.h |2 +
2 files changed, 69 insertions(
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 48
include/drm/drm_crtc.h| 55 +
include/drm/drm_crtc_helper.h |5 +++
3 files changed, 108 insertions(+), 0 del
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 102 +
include/drm/drm_crtc_helper.h |4 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm
From: Ville Syrjälä
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 156 +
include/drm/drm_crtc_helper.h | 24 ++
2
From: Ville Syrjälä
This function returns the bytes per pixel value based on the pixel
format and plane index.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 43 +
include/drm/drm_crtc_helper.h |1 +
2 files changed, 44 insert
This set intoduces a bunch of helper functions for help drm plane
driver writers deal with scaling and other details. Still work in progress,
escpecially the last patch.
Some open questions:
- In which file should this kind of stuff be placed?
- How should the functions be named?
- Should the sc
From: Ville Syrjälä
This function returns the number of planes used by a specific pixel
format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_helper.c | 33 +
include/drm/drm_crtc.h|1 +
include/drm/drm_crtc_helper.h |3 +++
d comments/and some logic based on review, Added Jerome tag]
> [v4: rebase on top of ttm_tt& ttm_backend merge]
> [v5: rebase on top of ttm memory accounting overhaul]
> [v6: New rebase on top of more memory accouting changes]
> [v7: well rebase on top of no memory accounting changes]
> Reviewed-by: Jerome Glisse
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
>
Acked-by: Thomas Hellstrom
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2011/37e8c38d/attachment.htm>
On 11/11/2011 02:36 AM, j.glisse at gmail.com wrote:
> 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.
>
> V2 Rebase on top of memory acco
Reviewed-by: Thomas Hellstrom
On 11/11/2011 02:36 AM, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Use the ttm_tt pages array for pages allocations, move the list
> unwinding into the page allocation functions.
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/ttm_page_allo
On Fri, 11 Nov 2011 18:04:05 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Help drivers a little by guaranteeing that crtc_x+crtc_w and
> crtc_y+crtc_h don't overflow.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 12
> 1 files cha
Acked-by: Jesse Barnes
--
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/2011/a289dd50/attachment.pgp>
On Fri, 11 Nov 2011 18:04:03 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> These are the only indication to user space that the plane was disabled.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c |2 ++
> 1 files changed, 2 insertions(+), 0 delet
ize: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2011/b67d507d/attachment.pgp>
1 - 100 of 141 matches
Mail list logo
