On Mit, 2011-11-16 at 20:42 +0200, ville.syrj...@linux.intel.com wrote:
>
> Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
> names, especially for the RGB formats. Component order and byte order are
> now strictly specified for each format.
>
> The RGB format naming fol
On Wed, Nov 16, 2011 at 07:54:12PM +, Alan Cox wrote:
> > If anyone has problems with the way the formats are defined, please
> > speak up now! Since only Jesse has bothered to comment on my rantings
> > I can only assume people are happy with my approach to things.
>
> Umm .. no. I don't see
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #3 from interweiss at yahoo.ca 2011-11-16 15:03:59 PST ---
Created attachment 53613
--> https://bugs.freedesktop.org/attachment.cgi?id=53613
xorg log
Here is my xorg log.
--
Configure bugmail: https://bugs.freedesktop.org/userpref
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #2 from interweiss at yahoo.ca 2011-11-16 15:00:15 PST ---
Created attachment 53612
--> https://bugs.freedesktop.org/attachment.cgi?id=53612
dmesg output
Here is my dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/
From: Alan Cox
Finally move the API where it can be seen
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c |2 -
drivers/gpu/drm/gma500/gem.c |2 -
drivers/gpu/drm/gma500/intel_bios.c |2 -
drivers/gpu/drm/gma500/mid_bios.c|2 -
driv
From: Alan Cox
We don't want this external in case someone adds more to the hardware. We
want it out of the ABI.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drm.h |3 ---
drivers/gpu/drm/gma500/psb_drv.h |2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gem.c |4 ++--
drivers/gpu/drm/gma500/psb_drm.h | 20 ++--
drivers/gpu/drm/gma500/psb_drv.c | 16
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/gma
From: Alan Cox
At this point we won't add an external set of definitions. We want to get
everything out before we admit to a public API beyond the standardised
ones.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drm.h | 159 ++--
drivers/gpu/drm/gma500/psb_drv.c | 507 -
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #3 from Ian Romanick 2011-11-16 14:25:23
PST ---
If this was a recent change, I'll guess that it will bisect to my changes to
the way uniforms are handled. I pushed a patch today that may restore previous
performance:
commit 010dc2
There are two possible races when disabling vblanks. If the IRQ
fired but the hardware didn't update its counter yet, then we store
too low a hardware counter. (Sensible hardware never does this.
Apparently not all hardware is sensible.) If, on the other hand,
the counter updated but the IRQ did
There are two possible races when disabling vblanks. If the IRQ
fired but the hardware didn't update its counter yet, then we store
too low a hardware counter. (Sensible hardware never does this.
Apparently not all hardware is sensible.) If, on the other hand,
the counter updated but the IRQ did
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett wrote:
> On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote:
>> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote:
>> >For Radeon, I'd have thought you could handle this by scheduling
>> >an irq
>> >for the beginning of scanout (avivo ha
On monitor hot removal:
1) clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE
2) clear ELD Valid bit
So that the audio driver will receive hot plug events and take action to
refresh its device state and ELD contents.
cc: Wang Zhenyu
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/drm_crtc_help
On Wed, Nov 16, 2011 at 6:19 PM, Matthew Garrett wrote:
> On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote:
>> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote:
>> >For Radeon, I'd have thought you could handle this by scheduling
>> >an irq
>> >for the beginning of scanout (avivo ha
Sorry forgot to remove this left over chunk...
Note that I've not yet got the hardware to test the DisplayPort part
of this patch, but should be able to do so this week.
> --- linux.orig/drivers/gpu/drm/i915/intel_drv.h 2011-11-16
> 20:54:27.0 +0800
> +++ linux/drivers/gpu/drm/i915
> I think the only format in my list where I didn't use an existing fourcc
> is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that
Right but you redefine all sorts of stuff in the driver in your patch to
non FourCC names which is just confusing (and painful given the format
picked
An embedded and charset-unspecified text was scrubbed...
Name: eld-hot-removal
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/abe8b563/attachment.asc>
An embedded and charset-unspecified text was scrubbed...
Name: no-extra-eld-passing
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/01c9d33c/attachment.asc>
An embedded and charset-unspecified text was scrubbed...
Name: sandybridge-eld-fix
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111116/914003d5/attachment.asc>
Keith,
Here are 3 fixes on HDMI/ELD audio.
The third one adds a ->hot_remove hook to drm_connector_funcs. Please review.
[PATCH 1/3] drm/i915: fix ELD writing for SandyBridge
[PATCH 2/3] drm/i915: dont trigger hotplug events on unchanged ELD
[PATCH 3/3] drm/i915: hot removal notification to HDMI
From: Ville Syrj?l?
Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
names, especially for the RGB formats. Component order and byte order are
now strictly specified for each format.
The RGB format naming follows a convention where the components names
and sizes are liste
From: Ville Syrj?l?
The code happened to compile because the flag wasn't actually used yet.
Signed-off-by: Ville Syrj?l?
---
include/drm/drm_mode.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 094da8a..27d7faf 1
I decided to go all out with the pixel format definitions. Added pretty
much all of the possible RGB/BGR variations. Just left out ones with
16bit components and floats. Also added a whole bunch of YUV formats,
and 8 bit pseudocolor for good measure.
I'm sure some of the fourccs now clash with the
Hi Ville,
Regarding 3 plane YCbCr, DRM_FORMAT_yuv444 (non sub-sampled YCbCr)
would also be useful.
-Ilyes
On Wed, Nov 16, 2011 at 7:42 PM, wrote:
> From: Ville Syrj?l?
>
> Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
> names, especially for the RGB formats. Compone
https://bugs.freedesktop.org/show_bug.cgi?id=42960
--- Comment #2 from Sandeep 2011-11-16 20:02:02 PST ---
Created attachment 53616
--> https://bugs.freedesktop.org/attachment.cgi?id=53616
dmesg output before suspending and after resuming
--
Configure bugmail: https://bugs.freedesktop.org/use
https://bugs.freedesktop.org/show_bug.cgi?id=42960
--- Comment #1 from Sandeep 2011-11-16 20:01:12 UTC ---
Created attachment 53615
--> https://bugs.freedesktop.org/attachment.cgi?id=53615
glxinfo output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You ar
https://bugs.freedesktop.org/show_bug.cgi?id=42960
--- Comment #1 from Sandeep 2011-11-16 20:01:12 UTC
---
Created attachment 53615
--> https://bugs.freedesktop.org/attachment.cgi?id=53615
glxinfo output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You a
> If anyone has problems with the way the formats are defined, please
> speak up now! Since only Jesse has bothered to comment on my rantings
> I can only assume people are happy with my approach to things.
Umm .. no. I don't see why they are needed. Its just an extra layer of
gratuitious confusin
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #2 from almos 2011-11-16 11:52:30 PST ---
The hw is barts pro (hd6850). The only part changed is mesa: 7.11 is installed
(debian unstable), and I compiled one from git. In the latter case I start
programs as
LD_LIBRARY_PATH=/home/almo
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #1 from Alex Deucher 2011-11-16 11:45:32 PST
---
I doubt you are using radeonhd. Please attach your xorg log and dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #1 from Alex Deucher 2011-11-16 11:42:52 PST
---
What hardware are you using? Is mesa the only part that changed or did you
also update your kernel and/or ddx? If it's just mesa, can you bisect? If
it's multiple parts that you upg
https://bugs.freedesktop.org/show_bug.cgi?id=42999
Alex Deucher changed:
What|Removed |Added
AssignedTo|eich at pdx.freedesktop.org|dri-devel at
lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=43000
Bug #: 43000
Summary: huge performance regression in ut2004 since 7.11
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
On Nov 16, 2011, at 6:11 PM, Matthew Garrett wrote:
> On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote:
>
>> I thought the main reason for the delay wasn't broken hardware but to
>> avoid constantly ping-ponging the vblank IRQ between on and off with
>> apps which regularly neeed the
> I decided to go all out with the pixel format definitions. Added pretty
> much all of the possible RGB/BGR variations. Just left out ones with
> 16bit components and floats. Also added a whole bunch of YUV formats,
> and 8 bit pseudocolor for good measure.
Thank you for including the pseudocolo
On Wed, Nov 16, 2011 at 07:27:51PM +0100, Mario Kleiner wrote:
> It's not broken hardware, but fast ping-ponging it on and off can
> make the vblank counter and vblank timestamps unreliable for apps
> that need high timing precision, especially for the ones that use
> the OML_sync_control extensio
https://bugs.freedesktop.org/show_bug.cgi?id=42998
Bug #: 42998
Summary: [r600g] Regression: EVE Online graphics borked again
(bisected)
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
On Thu, Nov 17, 2011 at 01:26:37AM +0100, Mario Kleiner wrote:
> On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote:
> >I'll admit that I'm struggling to understand the issue here. If the
> >vblank counter is incremented at the time of vblank (which isn't the
> >case for radeon, it seems, but as fa
At Wed, 16 Nov 2011 13:58:57 +0100,
Daniel Mack wrote:
>
> On 11/14/2011 11:39 AM, Takashi Iwai wrote:
> > OK, then perhaps a better fix is to change the check to be equivalent
> > with pineview, as you mentioned in the original post. The handling of
> > bit 0 for old chips was lost during the re
On Mit, 2011-11-16 at 09:20 -0500, Matthew Garrett wrote:
> The drm core currently waits 5 seconds from userspace dropping a request
> for vblanks to vblanks actually being disabled. This appears to be a
> workaround for broken hardware, but results in a mostly idle desktop
> generating a huge num
On Mon, Nov 14, 2011 at 17:10, James Simmons wrote:
>> > Should I test this set of patches for the VIA driver or wait until you
>> > have a second version of this patch?
>>
>> Testing this on via would be awesome! Iirc I haven't changed anything in
>> the via specific patches, but if it's more con
https://bugs.freedesktop.org/show_bug.cgi?id=42997
--- Comment #4 from Thomas Wendt 2011-11-16 09:15:13 PST
---
Created attachment 53608
--> https://bugs.freedesktop.org/attachment.cgi?id=53608
dmesg output
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=42997
--- Comment #3 from Alex Deucher 2011-11-16 09:13:24 PST
---
Please attach your dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=42997
Alex Deucher changed:
What|Removed |Added
Attachment #53605|text/x-log |text/plain
mime type|
On Wed, Nov 16, 2011 at 06:03:15PM +0100, Michel D?nzer wrote:
> I thought the main reason for the delay wasn't broken hardware but to
> avoid constantly ping-ponging the vblank IRQ between on and off with
> apps which regularly neeed the vblank counter value, as that could make
> the counter unre
https://bugs.freedesktop.org/show_bug.cgi?id=42997
--- Comment #2 from Thomas Wendt 2011-11-16 09:05:23 PST
---
Created attachment 53607
--> https://bugs.freedesktop.org/attachment.cgi?id=53607
Screenshot of the corruption
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42997
--- Comment #1 from Thomas Wendt 2011-11-16 09:04:56 PST
---
Created attachment 53606
--> https://bugs.freedesktop.org/attachment.cgi?id=53606
Screenshot of the corruption
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=
https://bugs.freedesktop.org/show_bug.cgi?id=42997
Bug #: 42997
Summary: [R600] Corruption after resume from suspend to ram
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (Al
https://bugs.freedesktop.org/show_bug.cgi?id=42998
--- Comment #1 from Vadim 2011-11-16 16:47:41 UTC ---
This patch should help:
http://lists.freedesktop.org/archives/mesa-dev/2011-November/014688.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
https://bugs.freedesktop.org/show_bug.cgi?id=42998
--- Comment #1 from Vadim 2011-11-16 16:47:41 UTC ---
This patch should help:
http://lists.freedesktop.org/archives/mesa-dev/2011-November/014688.html
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
The Ivybridge eDP control register looks like a cross between a
Cougarpoint PCH DP control register and a Sandybridge eDP control
register.
Where things trivially match, share the code. Where there are any
tricky bits, just split things out into two obviously separate code paths.
Signed-off-by: K
The Ivybridge eDP control register looks like a cross between a
Cougarpoint PCH DP control register and a Sandybridge eDP control
register.
Where things trivially match, share the code. Where there are any
tricky bits, just split things out into two obviously separate code paths.
Signed-off-by: K
On Nov 16, 2011, at 7:48 PM, Matthew Garrett wrote:
On Wed, Nov 16, 2011 at 07:27:51PM +0100, Mario Kleiner wrote:
It's not broken hardware, but fast ping-ponging it on and off can
make the vblank counter and vblank timestamps unreliable for apps
that need high timing precision, especially for
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #3 from interwe...@yahoo.ca 2011-11-16 15:03:59 PST ---
Created attachment 53613
--> https://bugs.freedesktop.org/attachment.cgi?id=53613
xorg log
Here is my xorg log.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.c
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #2 from interwe...@yahoo.ca 2011-11-16 15:00:15 PST ---
Created attachment 53612
--> https://bugs.freedesktop.org/attachment.cgi?id=53612
dmesg output
Here is my dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/use
> So generally we need to provide a userspace interface via ioctls, we
> do this with a shared header file that goes in include/drm/ with the
> Kbuild bits
At the moment the only public API is the generic bits.
> Now I'm assuming psb_drm.h is meant to be this file? but as-is its not
> really what
From: Alan Cox
Finally move the API where it can be seen
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c |2 -
drivers/gpu/drm/gma500/gem.c |2 -
drivers/gpu/drm/gma500/intel_bios.c |2 -
drivers/gpu/drm/gma500/mid_bios.c|2 -
driv
From: Alan Cox
We don't want this external in case someone adds more to the hardware. We
want it out of the ABI.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drm.h |3 ---
drivers/gpu/drm/gma500/psb_drv.h |2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gem.c |4 ++--
drivers/gpu/drm/gma500/psb_drm.h | 20 ++--
drivers/gpu/drm/gma500/psb_drv.c | 16
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/gma
From: Alan Cox
At this point we won't add an external set of definitions. We want to get
everything out before we admit to a public API beyond the standardised
ones.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drm.h | 159 ++--
drivers/gpu/drm/gma500/psb_drv.c | 507 -
On Wed, Nov 16, 2011 at 08:16:31PM +0100, Ilyes Gouta wrote:
> Hi Ville,
>
> Regarding 3 plane YCbCr, DRM_FORMAT_yuv444 (non sub-sampled YCbCr)
> would also be useful.
Yeah I was wondering whether to add that. So far I've not run into
hardware which can eat that, so I left it out for now.
Packed
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #3 from Ian Romanick 2011-11-16 14:25:23 PST
---
If this was a recent change, I'll guess that it will bisect to my changes to
the way uniforms are handled. I pushed a patch today that may restore previous
performance:
commit 010dc2
On Wed, Nov 16, 2011 at 01:23:01PM -0800, Jesse Barnes wrote:
> On Wed, 16 Nov 2011 23:19:38 +0200
> Ville Syrjälä wrote:
> > Oh and one extra detail just occured to me regarding the three plane
> > formats. Should we even define formats for both the YUV vs. YVU
> > variant. Seeing as we now have
From: Jerome Glisse
Somewhat specializaed sub-allocator designed to perform sub-allocation
for command buffer not only for current cs ioctl but for future command
submission ioctl as well. Patch also convert current ib pool to use
the sub allocator. Idea is that ib poll buffer can be share with o
On Wed, Nov 16, 2011 at 09:26:20PM +, Alan Cox wrote:
> > I think the only format in my list where I didn't use an existing fourcc
> > is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that
>
> Right but you redefine all sorts of stuff in the driver in your patch to
> non FourC
On Wed, Nov 16, 2011 at 2:18 PM, wrote:
> From: Jerome Glisse
>
> Somewhat specializaed sub-allocator designed to perform sub-allocation
> for command buffer not only for current cs ioctl but for future command
> submission ioctl as well. Patch also convert current ib pool to use
> the sub alloc
From: Jerome Glisse
Somewhat specializaed sub-allocator designed to perform sub-allocation
for command buffer not only for current cs ioctl but for future command
submission ioctl as well. Patch also convert current ib pool to use
the sub allocator. Idea is that ib poll buffer can be share with o
On Wed, 16 Nov 2011 23:19:38 +0200
Ville Syrjälä wrote:
> Oh and one extra detail just occured to me regarding the three plane
> formats. Should we even define formats for both the YUV vs. YVU
> variant. Seeing as we now have independent handles and offsets for
> each plane, we can make do with ju
On 11/14/2011 11:39 AM, Takashi Iwai wrote:
> OK, then perhaps a better fix is to change the check to be equivalent
> with pineview, as you mentioned in the original post. The handling of
> bit 0 for old chips was lost during the refactoring of backlight code
> since 2.6.37.
>
> Does the patch be
> I think the only format in my list where I didn't use an existing fourcc
> is I420/IYUV. And BTW, for that one I used the same "fake" fourcc that
Right but you redefine all sorts of stuff in the driver in your patch to
non FourCC names which is just confusing (and painful given the format
picked
gp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2016/1724ce93/attachment.pgp>
On Wed, Nov 16, 2011 at 07:54:12PM +, Alan Cox wrote:
> > If anyone has problems with the way the formats are defined, please
> > speak up now! Since only Jesse has bothered to comment on my rantings
> > I can only assume people are happy with my approach to things.
>
> Umm .. no. I don't see
> >> -int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev);
> >> -extern void ttm_dma_unpopulate(struct ttm_tt *ttm, struct device *dev);
> >> +int ttm_dma_populate(struct ttm_dma_tt *ttm_dma, struct device *dev);
> >> +extern void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct devic
On Thu, Nov 3, 2011 at 6:22 PM, Alan Cox wrote:
> 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.
I've started merging it, and my main review focus is as always the
userspace interface
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
Respin some of the patch with syntax/typo fix + patch 10 with proper
memory accounting of page being free.
Cheers,
Jerome
> If anyone has problems with the way the formats are defined, please
> speak up now! Since only Jesse has bothered to comment on my rantings
> I can only assume people are happy with my approach to things.
Umm .. no. I don't see why they are needed. Its just an extra layer of
gratuitious confusin
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #2 from almos 2011-11-16 11:52:30 PST ---
The hw is barts pro (hd6850). The only part changed is mesa: 7.11 is installed
(debian unstable), and I compiled one from git. In the latter case I start
programs as
LD_LIBRARY_PATH=/home/almo
https://bugs.freedesktop.org/show_bug.cgi?id=42999
--- Comment #1 from Alex Deucher 2011-11-16 11:45:32 PST ---
I doubt you are using radeonhd. Please attach your xorg log and dmesg output.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=43000
--- Comment #1 from Alex Deucher 2011-11-16 11:42:52 PST ---
What hardware are you using? Is mesa the only part that changed or did you
also update your kernel and/or ddx? If it's just mesa, can you bisect? If
it's multiple parts that you upgr
https://bugs.freedesktop.org/show_bug.cgi?id=42999
Alex Deucher changed:
What|Removed |Added
AssignedTo|e...@pdx.freedesktop.org|dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=43000
Bug #: 43000
Summary: huge performance regression in ut2004 since 7.11
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
Hi Ville,
Regarding 3 plane YCbCr, DRM_FORMAT_yuv444 (non sub-sampled YCbCr)
would also be useful.
-Ilyes
On Wed, Nov 16, 2011 at 7:42 PM, wrote:
> From: Ville Syrjälä
>
> Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
> names, especially for the RGB formats. Compone
On Wed, Nov 16, 2011 at 2:18 PM, wrote:
> From: Jerome Glisse
>
> Somewhat specializaed sub-allocator designed to perform sub-allocation
> for command buffer not only for current cs ioctl but for future command
> submission ioctl as well. Patch also convert current ib pool to use
> the sub alloc
From: Jerome Glisse
Somewhat specializaed sub-allocator designed to perform sub-allocation
for command buffer not only for current cs ioctl but for future command
submission ioctl as well. Patch also convert current ib pool to use
the sub allocator. Idea is that ib poll buffer can be share with o
> I decided to go all out with the pixel format definitions. Added pretty
> much all of the possible RGB/BGR variations. Just left out ones with
> 16bit components and floats. Also added a whole bunch of YUV formats,
> and 8 bit pseudocolor for good measure.
Thank you for including the pseudocolo
From: Jerome Glisse
Somewhat specializaed sub-allocator designed to perform sub-allocation
for command buffer not only for current cs ioctl but for future command
submission ioctl as well. Patch also convert current ib pool to use
the sub allocator. Idea is that ib poll buffer can be share with o
1 - 100 of 170 matches
Mail list logo
