https://bugzilla.kernel.org/show_bug.cgi?id=39832
Santiago Garcia Mantinan changed:
What|Removed |Added
CC||ma...@manty.net
--- Commen
From: Ville Syrj?l?
Just a quick prototype to test the atomic modeset API. Implemented
via already existing non-atomic mechanisms internally.
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_atomic.c | 788 ++
drivers/gpu/drm/i915/in
From: Ville Syrj?l?
First draft.
The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.
Detailed error reporting is missing
From: Ville Syrj?l?
Refactor the code to check whether an object has a specific property
to a new function.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/driv
From: Ville Syrj?l?
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crt
From: Ville Syrj?l?
Treat a range property as signed when the unsigned minimum value is
larger than the unsigned maximum value.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |8 +---
include/drm/drm_crtc.h |4
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6dafb99..ce0f446 100644
--- a/dri
This is some very early demo code for the atomic modesetting feature.
According to my current plan there would be just one ioctl. You simply feed
it an arbitrary list of object properties and the implementation will decice
how it can apply those (for example, whether it can complete the operation
From: Alex Deucher
Using the wrong union.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ni.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index b01c2dd..ce4e7cc 100644
On Thu, May 24, 2012 at 08:49:53PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote:
> > On Thu, 24 May 2012 21:29:46 +0300
> > ville.syrjala at linux.intel.com wrote:
> >
> > > Currently the video sprites appear to get disabled on modeset more by
> > > ac
https://bugs.freedesktop.org/show_bug.cgi?id=50325
--- Comment #2 from T?r?k Edwin 2012-05-24 14:57:24
PDT ---
Created attachment 62080
--> https://bugs.freedesktop.org/attachment.cgi?id=62080
sw-good.png
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=50325
--- Comment #1 from T?r?k Edwin 2012-05-24 14:57:08
PDT ---
Created attachment 62079
--> https://bugs.freedesktop.org/attachment.cgi?id=62079
r600g-bad.png
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=50325
Bug #: 50325
Summary: Glyphy bad render on r600g (software render is fine)
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote:
> On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
> > UINT_MAX.
> >
> > Signed-off-by: Ville Syrj
On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:08:58 +0300
> ville.syrjala at linux.intel.com wrote:
>
> > From: Ville Syrj?l?
> >
> > Take fb->offset[0] into account when calculating the linear and tile x/y
> > offsets.
> >
> > For non-tiled surfaces fb-
From: Ville Syrj?l?
Convert intel_fb_restore_mode to be useable as the
drm_fb_helper.restore_fbdev_mode hook. This will cause all planes to be
disabled when swithing back to fbcon.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |
From: Ville Syrj?l?
When setting a display mode, disable all planes on the CRTC beforehand,
and re-enable them after the new mode has been set.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 48 ++
1 files changed, 48 insertions(+), 0
From: Ville Syrj?l?
Add an optional driver specific restore_fbdev_mode() hook to
drm_fb_helper. If the driver doesn't provide the hook,
drm_fb_helper_restore_fbdev_mode() is called directly as before.
In this hook the driver can disable additional planes, cursors etc.
that shouldn't be visible w
From: Ville Syrj?l?
If the update_plane() operation succeeds, make a copy of the requested
src and crtc coordinates, so that the the plane may be reclipped if the
display mode changed later.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |8
include/drm/drm_crtc.h
Currently the video sprites appear to get disabled on modeset more by
accient than by design.
With the current API that behaviour makes very little sense to me.
You first enable some plane, and then it can get disabled due to some
unrelated operation.
So these patches change the behaviour so that
A 30 ms delay is simply way too big to waste cpu cycles on.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 6056603..efa0d17 1
We should return the number of added modes. Luckily no one really
cares, but it kinda sticked out compared to the other ->get_modes
functions I've looked at recently.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 41 ++--
1 files changed,
Like the previous patches.
While at it also kill a stale comment - we've moved hdmi audio
detection from ->get_modes to ->detect and the audio property handling
functions.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_hdmi.c | 48 +
Again, let's be slightly more clever here.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 47 ++
1 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3bbd
Let's put all this new&neat output detection infrastructure and rework
to some good use and cache the crt edid. Given that the drm helpers
now only call ->detect when actually required, we only need to reset
the edid there and can keep it otherwise.
Slashes xrandr time on systems that are hotplug
Otherwise if the detect callback reports a different state than what
the user forced (rather likely), we continously annoy userspace about
a hotplug uevent.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --gi
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |6 ++
1 files
Actually there's a reason this stuff is there, and it's called
commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
Author: Chris Wilson
Date: Fri Aug 20 09:13:36 2010 +0100
drm/kms: Add a module parameter to disable polling
The idea has been that users can enable/disable polling at runtime. S
Only call that function if something has actually changed (i.e. in the
output polling or hdp handling functions) or when userspace asks for
the information and DRM_CONNECTOR_POLL_FORCE is set.
Let's see how many bugs this uncovers.
v2: Run ->detect if the current connector status is 'unknown' -
o
We need this because otherwise the improved connector code has no idea
when it needs to run the ->detect callback after boot/resume on all
connectors.
Because drm/i915 is the only driver that properly calls
mode_config_reset at resume time, this will horribly blow up
everywhere else.
Signed-Off-b
The detection function is simply too unreliable - it doesn't
properly pick up changes right away.
For now, just set the compat flag and ignore this, because on a
quick look fixing this properly is a very big fish to fry.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |2
Useful for ->detect functions that have different behaviour if force
is set. This way probe_single_connector can avoid to do the expensive
edid dance on connectors where this is not needed.
I've checked through all drivers and set this flag everywhere where
the connector->detect function has diffe
Instead of reusing the polling code for hdp handling, split them up.
This has a few consequences:
- Don't touch HDP capable connectors in the poll loop.
- Only touch HDP capable connectors in drm_helper_hpd_irq_event.
- Run the HDP handling directly instead of going through a work item -
all call
Useful if drivers want to be slightly more clever about hotplug
handling.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
include/drm/drm_crtc_helper.h |1 +
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_c
Hi all,
I've got fed up with our sorry state of connector detection and rampant edid re
and rere-reading.
This patch series lays the groundwork in the drm helpers so that drivers can
avoid all this madness (at least on working hw) and properly cache the edid.
With the additional changes for drm/
From: Ville Syrj?l?
The framebuffer pixel format is already checked by the common code.
So there's no way an invalid format could reach the driver. So instead
of falling back to a default format, call BUG().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_sprite.c |8 ++--
From: Ville Syrj?l?
Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_sprite.c | 19 +++
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers
From: Ville Syrj?l?
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to a best effort approach, where the
source coordinates are rounded to the nearest (macro)
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 102
include/drm/drm_crtc.h |4 ++
2 files changed, 106 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
ind
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.c | 155
include/drm/drm_crtc.h | 24 +++
2 files
First add a bit of helper functions to aid in the clipping duties
(those patches were already posted a long time ago) and then utilize
them to properly clip the video sprites to the pipe dimensions.
I also threw in a few small cleanup patches dealing with the sprite code.
From: Ville Syrj?l?
MI display flips can't handle some changes in the framebuffer
format or layout. Return an error in such cases.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers
From: Ville Syrj?l?
Take fb->offset[0] into account when calculating the linear and tile x/y
offsets.
For non-tiled surfaces fb->offset[0] is simply added to the linear
byte offset.
For tiled surfaces treat fb->offsets[0] as a byte offset into the
linearized view of the surface. So we end up co
From: Ville Syrj?l?
The framebuffer offset must be aligned to (macro)pixel size.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel
From: Ville Syrj?l?
Zero initialize the mode_cmd structure when creating the kernel
framebuffer. Avoids having uninitialized data in offsets[0] for
instance.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_fb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
From: Ville Syrj?l?
Make sure the the framebuffer stride is smaller than the maximum
accepted by any plane.
Also when using a tiled memory make sure the object stride matches
the framebuffer stride.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 18 +
From: Ville Syrj?l?
Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
format).
Fix intel_init_framebuffer() to match hardware and driver limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 & co. are supported on Gen3 and earlier
* XRGB210101010 & co.
Add all kinds of framebuffer layout sanity checks to the code.
Also the framebuffer offset wasn't properly handled, and code dealing
with the primary plane pixel format was quite broken.
On Thu, May 24, 2012 at 09:54:37PM +0300, Ville Syrj?l? wrote:
> On Thu, May 24, 2012 at 08:30:23PM +0200, Daniel Vetter wrote:
> > On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrj?l?
> > >
> > > Make sure 'width * cpp' and 'height * pi
On Thu, May 24, 2012 at 09:49:15PM +0300, Ville Syrj?l? wrote:
> On Thu, May 24, 2012 at 11:31:32AM -0700, Jesse Barnes wrote:
> > On Thu, 24 May 2012 21:08:58 +0300
> > ville.syrjala at linux.intel.com wrote:
> >
> > > From: Ville Syrj?l?
> > >
> > > Take fb->offset[0] into account when calcula
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e1b53fb..5fc198d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/dr
From: Ville Syrj?l?
Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
UINT_MAX.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
From: Ville Syrj?l?
The rest of the code uses stdint types, so use them in
drm_property_change_is_valid() as well.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
Just a few small items caught in my net while trawling the code.
On Thu, May 24, 2012 at 11:35:35AM -0700, Jesse Barnes wrote:
> On Thu, 24 May 2012 21:29:46 +0300
> ville.syrjala at linux.intel.com wrote:
>
> > Currently the video sprites appear to get disabled on modeset more by
> > accient than by design.
> >
> > With the current API that behaviour makes ve
On Thu, May 24, 2012 at 08:53:59PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Make sure 'width * cpp' and 'height * pitch + offset' don't exceed
> UINT_MAX.
>
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_crtc.c | 10 +-
> 1 files changed,
https://bugs.freedesktop.org/show_bug.cgi?id=50232
--- Comment #2 from almos 2012-05-24 13:25:38 PDT ---
(In reply to comment #1)
> Please test with the first patch from bug 50230.
The revert patch fixes the ghost image problem. The warning is still printed,
but the visuals seem to be good now.
https://bugs.freedesktop.org/show_bug.cgi?id=50230
--- Comment #10 from almos 2012-05-24 13:25:32 PDT ---
(In reply to comment #9)
> Created attachment 62057 [details] [review]
> [PATCH] radeon/llvm: fix sampler index in llvm_emit_tex
>
> Does this patch help?
Yes, the patch fixes it. I also tri
I can easily trigger a crash in nouveau interrupt handler by unbinding
and rebinding the GPU.
The command used:
echo $pci_device > nouveau/unbind && \
sleep 5 && \
echo $pci_device > nouveau/bind
Kernel is 3.4.0 with modular drm/nouveau.
GPU is NVidia nForce IGP (NV11)
Unbind
Hi Linus,
this is the main merge window request for the drm,
Its big, but jam packed will lots of features and of course 0 regressions.
(okay maybe there'll be one).
Highlights:
new KMS drivers for server GPU chipsets: ast, mgag200 and cirrus (qemu
only). These drivers use the generic modeset
From: Alex Deucher
Using the wrong union.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/ni.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index b01c2dd..ce4e7cc 100644
---
These guys seem to be recently introduced:
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700
This is on my
These guys seem to be recently introduced:
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1700, was 1206
[drm:gen6_sanitize_pm] *ERROR* Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected 1707, was 1700
This is on my
On Fri, May 25, 2012 at 09:50:44AM +0800, Lee, Chun-Yi wrote:
> In v3.3, the gma500 drm driver moved from staging to drm group by
> Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
> brightness well and don't need gma500 stub driver anymore.
Looks good to me.
--
Matthew Garrett |
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #8 from J?r?me Glisse 2012-05-24
19:13:23 ---
Created an attachment (id=73382)
--> (https://bugzilla.kernel.org/attachment.cgi?id=73382)
Fix backend map
This patch should fix your issue
--
Configure bugmail: https://bugzilla.
On Thu, 2012-05-24 at 10:18 +0400, Dmitry Eremin-Solenikov wrote:
> Hello, colleagues,
>
> I'm trying to enable an AGP slot (again) on my Maple board (dual
> PPC970FX board, with CPC925 (U3H) north bridge).
>
> For now I'm stuck with a problem: I use radeon card, drm-radeon driver
> with KMS.
ot familiar with the related
problems, so I take your word that it's not simple =).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/e3c5d6b2/attachment.pgp>
Hi Dave,
A set of fixes for 3.5:
- Fixes for regressions in 3.5: fix spurious gmbus NAK, fix module unload,
fix pch pll asserts.
- Fix up eDP panel power sequencing - turns out we need to keep vdd on
while switching everything off.
- Reject doubleclocked modes on dp.
- Fixup sdvo interlaced ha
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: 21 May 2012 10:04
> To: Dave Airlie
> Cc: Tom Cooksey; linaro-mm-sig at lists.linaro.org; xorg-
> devel at lists.x.org; dri-devel at lists.freedesktop.org
> Subject: Re: [Lin
https://bugzilla.kernel.org/show_bug.cgi?id=43207
--- Comment #7 from Vladislav Tcendrovskii 2012-05-24
16:30:46 ---
I have tested kernel 3.4.
Results look a bit strange:
When i use modprobe radeon, I have the same pixel noise, which I had before.
If I start X, I have screen with windows
> Does the linux API mandates atomic_t to be a 32bits word?
AFAIK it is, at least for the platforms we care about.
...
>>>
>>> Then, the proper course of action would be to add to the linux API, sized
>>> atomic operation first, wouldn't it?
>>
>> No, atomic is fine for this, I t
https://bugs.freedesktop.org/show_bug.cgi?id=50232
--- Comment #1 from Vadim Girlin 2012-05-24 08:50:00 PDT
---
Please test with the first patch from bug 50230.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You a
was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/2af85523/attachment.pgp>
he
> > kernel by another driver?
>
> Hmm, I'm not quite sure what you have in mind, but it sounds a bit
> hacky.. I'd guess if you need 100% backwards compatibility even down
> to kernel cmdline / module params, then you probably want to use
> omapfb. But there isn't really need to add new features to omapfb in
> that case.
I was thinking of making omapfb use omapdrm, instead of omapdss. I mean,
not planning to do that, just wondering if that would be possible.
> Off the top of my head, I guess that 80-90% compatibility would
> probably be reasonable to add to omapdrm's fbdev.. and that the last
> 10-20% would be too hacky/invasive to justify adding to omapdrm.
I think it should be 99.9% - 100% or nothing. If it's only 80-90%
compatible, then it's not compatible =).
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120524/c8ad9dc8/attachment-0001.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=50325
--- Comment #2 from Török Edwin 2012-05-24 14:57:24 PDT
---
Created attachment 62080
--> https://bugs.freedesktop.org/attachment.cgi?id=62080
sw-good.png
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
https://bugs.freedesktop.org/show_bug.cgi?id=50325
--- Comment #1 from Török Edwin 2012-05-24 14:57:08 PDT
---
Created attachment 62079
--> https://bugs.freedesktop.org/attachment.cgi?id=62079
r600g-bad.png
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- Yo
https://bugs.freedesktop.org/show_bug.cgi?id=50325
Bug #: 50325
Summary: Glyphy bad render on r600g (software render is fine)
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
>> Does the linux API mandates atomic_t to be a 32bits word?
>
> AFAIK it is, at least for the platforms we care about.
> ...
Then, the proper course of action would be to add to the linux API, sized
atomic operation first, wouldn't it?
--
Sylvain
https://bugs.freedesktop.org/show_bug.cgi?id=50230
--- Comment #9 from Vadim Girlin 2012-05-24 07:38:10 PDT
---
Created attachment 62057
--> https://bugs.freedesktop.org/attachment.cgi?id=62057
[PATCH] radeon/llvm: fix sampler index in llvm_emit_tex
Does this patch help?
--
Configure bugmai
On Thu, May 24, 2012 at 1:53 PM, wrote:
> Just a few small items caught in my net while trawling the code.
for the series:
Reviewed-by: Alex Deucher
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/m
https://bugzilla.kernel.org/show_bug.cgi?id=12434
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=12434
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=12342
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=12342
Alan changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
CC|
On Thu, May 24, 2012 at 10:50 AM, Frank Binns wrote:
> Hi,
> I don't know if this patch got missed in the list traffic or if I did
> something wrong but it doesn't appear to have been picked up. This is my
> first time contributing so if I did anything wrong some pointers would be
> appreciated
On Thu, Mar 22, 2012 at 09:30:56AM +0300, Dan Carpenter wrote:
> If we hit an error here, then we should unlock and unreference obj
> before returning.
>
This is still present in linux-next.
regards,
dan carpenter
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b
> + atomic_tring_int[RADEON_NUM_RINGS];
> boolcrtc_vblank_int[RADEON_MAX_CRTCS];
> - boolpflip[RADEON_MAX_CRTCS];
> - int pflip_refcount[RADEON_MAX_CRTCS];
> + atomic_t
On Thu, May 24, 2012 at 1:53 PM, Dave Airlie wrote:
> On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND
> wrote:
Does the linux API mandates atomic_t to be a 32bits word?
>>>
>>> AFAIK it is, at least for the platforms we care about.
>>> ...
>>
>> Then, the proper course of action would be
On Thu, May 24, 2012 at 1:46 PM, Sylvain BERTRAND wrote:
>>> Does the linux API mandates atomic_t to be a 32bits word?
>>
>> AFAIK it is, at least for the platforms we care about.
>> ...
>
> Then, the proper course of action would be to add to the linux API, sized
> atomic operation first, wouldn'
A 30 ms delay is simply way too big to waste cpu cycles on.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 6056603..efa0d17 1
We should return the number of added modes. Luckily no one really
cares, but it kinda sticked out compared to the other ->get_modes
functions I've looked at recently.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 41 ++--
1 files changed,
https://bugzilla.kernel.org/show_bug.cgi?id=12333
Alan changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure bugmail: https://bugzilla
Like the previous patches.
While at it also kill a stale comment - we've moved hdmi audio
detection from ->get_modes to ->detect and the audio property handling
functions.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_hdmi.c | 48 +
https://bugzilla.kernel.org/show_bug.cgi?id=12333
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Again, let's be slightly more clever here.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 47 ++
1 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3bbd
Let's put all this new&neat output detection infrastructure and rework
to some good use and cache the crt edid. Given that the drm helpers
now only call ->detect when actually required, we only need to reset
the edid there and can keep it otherwise.
Slashes xrandr time on systems that are hotplug
Otherwise if the detect callback reports a different state than what
the user forced (rather likely), we continously annoy userspace about
a hotplug uevent.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --gi
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c |6 ++
1 files
Actually there's a reason this stuff is there, and it's called
commit e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
Author: Chris Wilson
Date: Fri Aug 20 09:13:36 2010 +0100
drm/kms: Add a module parameter to disable polling
The idea has been that users can enable/disable polling at runtime. S
Only call that function if something has actually changed (i.e. in the
output polling or hdp handling functions) or when userspace asks for
the information and DRM_CONNECTOR_POLL_FORCE is set.
Let's see how many bugs this uncovers.
v2: Run ->detect if the current connector status is 'unknown' -
o
1 - 100 of 240 matches
Mail list logo
