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
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
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
The ELD may or may not change when switching the video mode.
If unchanged, don't trigger hot plug events to HDMI audio driver.
This avoids disturbing the user with repeated printks.
Reported-by: Nick Bowler
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/i915/intel_display.c | 51 +++
SandyBridge should be using the same register addresses as IvyBridge.
Signed-off-by: Wu Fengguang
---
drivers/gpu/drm/i915/i915_reg.h |6 +++---
drivers/gpu/drm/i915/intel_display.c | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
--- linux.orig/drivers/gpu/drm/i915/
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
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
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
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 number of wakeups that are entirely unnecessary but which
consume meas
drm_vblank_offdelay is currently a system global, despite the optimal
value being hardware-specific. Move it to the drm_device structure.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/drm_irq.c |6 +++---
drivers/gpu/drm/drm_stub.c |8 +---
include/drm/drmP.h |2 +-
Right now if vblank_offdelay is 0, vblanks won't be disabled after the
last user. Fix that case up.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/drm_irq.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index
Sandybridge, at least, seems to manage without any vblank offdelay.
Dropping this reduces the number of wakeups on an otherwise idle system
dramatically.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/
On Wed, 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 numb
> 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
On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote:
> On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
> > On 11/14/2011 05:02 PM, Jerome Glisse wrote:
> > >On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hellstrom
> > >wrote:
> > >>On 11/11/2011 11:47 PM, j.gli...@gmail.com w
On Wed, Nov 16, 2011 at 10:15 AM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Nov 14, 2011 at 01:54:27PM -0500, Jerome Glisse wrote:
>> On Mon, Nov 14, 2011 at 05:06:42PM +0100, Thomas Hellstrom wrote:
>> > On 11/14/2011 05:02 PM, Jerome Glisse wrote:
>> > >On Mon, Nov 14, 2011 at 9:49 AM, Thomas Hells
> +#ifdef CONFIG_SWIOTLB
> + if (swiotlb_nr_tbl()) {
> + return ttm_dma_populate(ttm, rdev->dev);
> + }
> +#endif
..
> +#ifdef CONFIG_SWIOTLB
> + if (swiotlb_nr_tbl()) {
> + ttm_dma_unpopulate(ttm, rdev->dev);
> + return;
> + }
> +#endif
> +#ifde
> +int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev)
> +{
.. snip..
> + for (i = 0; i < ttm->num_pages; ++i) {
> + ret = ttm_dma_pool_get_pages(pool, ttm, i);
> + if (ret != 0) {
> + ttm_dma_unpopulate(ttm, dev);
> + re
> > which I think was your V4 posting (or earlier) (the last patch is something
> > I added
> > to toggle it off/on to test).
>
> You have to allocate like a million of gem object to trigger it.
>
Which I certainly did not, but I did find an accounting error in the
rebased v5 version of the TTM
On Wed, Nov 16, 2011 at 10:50:01AM -0500, Konrad Rzeszutek Wilk wrote:
> > +int ttm_dma_populate(struct ttm_tt *ttm, struct device *dev)
> > +{
> .. snip..
>
> > + for (i = 0; i < ttm->num_pages; ++i) {
> > + ret = ttm_dma_pool_get_pages(pool, ttm, i);
> > + if (ret != 0) {
>
On Wed, Nov 16, 2011 at 10:46:57AM -0500, Konrad Rzeszutek Wilk wrote:
> > +#ifdef CONFIG_SWIOTLB
> > + if (swiotlb_nr_tbl()) {
> > + return ttm_dma_populate(ttm, rdev->dev);
> > + }
> > +#endif
> ..
> > +#ifdef CONFIG_SWIOTLB
> > + if (swiotlb_nr_tbl()) {
> > + ttm_dma_un
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
Respin some of the patch with syntax/typo fix + patch 10 with proper
memory accounting of page being free.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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: 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: 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 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
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
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
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
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
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: 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: 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
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: 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: 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 +++-
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
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
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=e
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=e
https://bugs.freedesktop.org/show_bug.cgi?id=42997
Alex Deucher changed:
What|Removed |Added
Attachment #53605|text/x-log |text/plain
mime type|
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 f
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
--- You
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
> >> -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 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
2011/11/16 Matthew Garrett :
> 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
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 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 vblank c
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
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
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
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
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
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
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=43000
Bug #: 43000
Summary: huge performance regression in ut2004 since 7.11
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status:
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
--- 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
--- 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 #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
> 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
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
> 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
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 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 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
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 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
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 -
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
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
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
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
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
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
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
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
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
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 #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
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
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 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
A call to i915_add_request() has been made in function i915_gem_busy_ioctl().
i915_add_request can fail,
so in it's exit path previously allocated memory needs to be freed.
Signed-off-by: Rakib Mullick
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d18
On Tuesday 15 of November 2011 23:21:10 Alex Deucher wrote:
> On Tue, Nov 15, 2011 at 2:05 PM, Sergey V. wrote:
> > Kernel from Linus tree, HEAD at 7f80850d3f9fd8fda23a317044aef3a6bafab06b
> >
> > Loading radeon module with modeset=1 causes black screen.
> >
> > Usually it happens at boot time, bu
On 15.11.2011 20:32, Jerome Glisse wrote:
> On Sat, Oct 29, 2011 at 03:00:28PM +0200, Christian K?nig wrote:
>> Hello everybody,
>>
>> to support multiple compute rings, async DMA engines and UVD we need
>> to teach the radeon kernel module how to sync buffers between
>> different rings and make so
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
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
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
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>
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>
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
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
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 number of wakeups that are entirely unnecessary but which
consume meas
drm_vblank_offdelay is currently a system global, despite the optimal
value being hardware-specific. Move it to the drm_device structure.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/drm_irq.c |6 +++---
drivers/gpu/drm/drm_stub.c |8 +---
include/drm/drmP.h |2 +-
1 - 100 of 170 matches
Mail list logo
