- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/b914c108/attachment.html>
resize them (from any resolution).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/0612daec/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/0acb230f/attachment.html>
pp/edid-decode/
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/ff63d296/attachment.pgp>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/5da82fb0/attachment-0001.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/2bbb710c/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/70be5362/attachment.html>
org/archives/dri-devel/attachments/20121218/121ed4ca/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/30d595b1/attachment.html>
b18
91abd9cb2eeab3d3324e4859776cf66e1934fa72 M src
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/7c353a7e/attachment.html>
With refcounting we need to adjust framebuffer refcounts at each
callsite - much easier to do if they all call the same little helper
function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 19 +--
drivers/gpu/drm/drm_fb_helper.c|6 +++---
Some drivers don't have real ->create_handle callbacks.
- cirrus/ast/mga200: Returns either 0 or -EINVAL.
- udl: Didn't even bother with a callback, leading to a nice
userspace-triggerable OOPS.
- vmwgfx: This driver bothered with an implementation to return 0 as
the handle (which is the can
Noticed while reviewing the fence locking in the radeon pageflip
handler.
v2: Instead of grabbing the bdev->fence_lock in object_transfer just
move the single callsite of that function a few lines, so that it is
protected by the fence_lock. Suggested by Jerome Glisse.
v3: Fix typo in commit messa
... by moving the bo_pin/bo_unpin manipulation of the pin_refcount
under the protection of the ttm reservation lock. pin/unpin seems
to get called from all over the place, so atm this is completely racy.
After this patch there are only a few places in cleanup functions
left which access ->pin_refc
With per-crtc locks modeset operations can run in parallel, and the
cursor code uses the device-global evo master channel for hw frobbing.
But the pageflip code can also sync with the master under some
circumstances. Hence just wrap things up in a mutex to ensure that
pushbuf access doesn't intermi
Doing this within the fb->destroy callback leads to a locking
nightmare. And all other drm drivers that restore the fbcon do
it in lastclose, too.
With this adjustments all fb->destroy callbacks optionally drop
references to any gem objects used as backing storage, call
drm_framebuffer_cleanup and
vmwgfx has an oddity, when failing to reference the surface it'll
return 0, since that's what the successfull drm_framebuffer_init will
leave behind in ret. Fix this up by returning -EINVAL.
Split out from all the other driver updates due to the above tiny
semantic change. Shouldn't matter though
With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by
And do a quick pass to adjust them to the last few (years?) of changes
...
This time actually compile-tested ;-)
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl |4 ++
drivers/gpu/drm/drm_crtc.c | 92 +++-
2 files changed, 48 inserti
- config_cleanup was confused: It claimed that callers need to hold
the modeset lock, but the connector|encoder_cleanup helpers grabbed
that themselves (note that crtc_cleanup did _not_ grab the modeset
lock). Which resulted in all drivers _not_ hodling the lock. Since
this is for single-th
Hi all,
So I've beaten on the series a bit more, written some evil testcases and things
seem to hold up. I'm rather happy with it now. I've also reordered patches a bit
to move all the prep stuff which doesn't introduce the new concepts, but just
adds shims/docs/reworks driver locking where requir
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #17 from Andre 2012-12-18 22:23:33 ---
Okay, after more than 30 hours uptime, i think this patch fixed it. :-)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because
I don't care either way, but being different from the documentation
is less bad than crashing which is what your patch does. Please
be more careful in the future.
regards,
dan carpenter
On Wed, Dec 19, 2012 at 06:34:04AM +1300, Tony Prisk wrote:
> Resend to include mailing lists.
These kind of comments should go under the Signed of by line under
a "---" line. They will be removed by git-am instead of being
preserved in the git log.
Signed-off-by bla bla blah
---
Commments...
On Wed, Dec 19, 2012 at 06:34:05AM +1300, Tony Prisk wrote:
> Resend to include mailing lists.
>
> Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
>
The original code is correct. clk_get() can return NULL depending
on the .config.
regards,
dan carpenter
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
In the fail: path of mixer_resources_init() and vp_resources_init()
the first clk tested cannot be NULL either, so IS_ERR_OR_NULL is
removed from these as well. Other clocks may still be NULL as they
haven't been clk_get'd yet.
Signed-off-by:
On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote:
> On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma
> wrote:
>> Program the core and timing generator registers using the timing data
>> provided in drm_display_mode instead of using hardcoded configurations.
>> This allows us to support more standar
Hi all!
On Wed, 15 Aug 2012 17:40:40 +0200
Paul Menzel wrote:
> Date: Wed, 8 Aug 2012 23:12:19 +0200
>
> Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
> vertical stripes in the top half.
>
This patch, which was merged in v3.6-rc4, makes the image on my ASUS
VW222U ca.
From: Dave Airlie
This adds the support for drivers that use the gem mmap call, they need
to specify DRIVER_GEM_MMAP in their feature set, so they get this behaviour.
This saves me adding 10 open/close handlers for now, if someone would like
to do that instead of midlayer, then I'd be happy to w
From: Dave Airlie
So instead of creating a whole set of per-file address spaces, and having
some sort of melt down in my understanding of the inode/address_space code,
I realised we could just keep a lot of filps that the object has been attached
to, or has had a handle created on.
At the moment
From: Dave Airlie
This is just a cleanup, can probably do better, but at least it makes
the calls to the unmap_mapping_range consistent.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_vma_offset_man.c | 11 +++
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
drivers/gpu/drm/ttm/
The 2+3 patches are actually the code, the first was just a cleanup.
Anyways the second patch describes it best, but I've taken the approach
that we just need to keep track of what filp this object has had a handle
created on, and block mmaps on it. We could also probably block a bit
more explicit
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121218/3cb8dab0/attachment.html>
smoki ---
*** Bug 39285 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121
Extend the mixer configuration to include more resolutions that can be
generated by the mixer. This adds 640x480, 720x576 and 1680x1050.
Signed-off-by: Sean Paul
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c |8
1 files changed, 4 insertions(+), 4 deletions(
Program the core and timing generator registers using the timing data
provided in drm_display_mode instead of using hardcoded configurations.
This allows us to support more standard resolutions like 640x480, 720x576
and 1680x1050. Additional PHY configs has been added to support extra
refresh rates
This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).
Given resoltuion will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer can generat
Op 18-12-12 17:12, Markus Trippelsdorf schreef:
> On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote:
>> Op 18-12-12 14:38, Markus Trippelsdorf schreef:
>>> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
> On 2012.12.17
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/14e66213/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/907f299d/attachment-0001.html>
79 365 57 48 - http://blog.ffwll.ch
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/eb4e567c/attachment-0001.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/939e7d8c/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/15d68aff/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/e8d085c2/attachment.html>
On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
> On Tue, Dec 18, 2012 at 5:36 AM, Christian K?nig
> wrote:
> > On 17.12.2012 22:31, Paul Bolle wrote:
> >> 1) Sent as an RFC because I do not understand why this laptop (almost
> >> always) prints the "crtc 1" message on first resume. Note th
On Tue, Dec 18, 2012 at 12:02 AM, Andy Gross wrote:
> Added resume hooks that will be called on resuming from DEVICE_OFF.
> The dmm portion of the patch reprograms the LUT to point to the dummy
> pages. The omapdrm portion of the patch repins the buffers into the
> DMM.
>
> Signed-off-by: Andy Gr
On Tue, Dec 18, 2012 at 12:02 AM, Andy Gross wrote:
> Add support for OMAP5 processor. The main differences are that the OMAP5
> has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
> size.
>
> Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
> ---
> drivers/staging/om
From: Dave Airlie
This uses the drm vm accessor to access the address space offset
rather than storing it separately.
When I boot tested this, it threw up a problem in the virtual unmapping code
where we unmap a mapping range from 0 unnecessairly, so this patch also
checks we have a mapping befo
From: Dave Airlie
So we have to offset manager implementations for dealing with VMA offsets.
GEM had one using the hash table, TTM had one using an rbtree,
I'd rather we just had one to rule them all, since ttm is using the rbtree
variant to allow sub mappings, to keep ABI we need to use that on
From: Dave Airlie
We currently don't need map_lists to store this information, with the new
encapsulation, just move the vma_offset object into the gem object.
In the future I'd guess we need per-filp vma offsets so this might make
it a bit cleaner to start from.
Signed-off-by: Dave Airlie
---
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 33 ++
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 37
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/video/fbmon.c | 42
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/video/fbmon.c
This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.
If no native mode is specified, the first subnode will be used.
For cases where the graph
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: St
Hi!
Finally, right in time before the end of the world on friday, v16 of the
display helpers.
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: ad
So a passing comment on irc from Daniel made me look at this, and cleaning
up some surrounding things. This unifies the GEM/TTM vma offset managers
around a single one based on the TTM one.
There is also a patch to cleanup the GEM code after this, and one to clean
up some bits of TTM also.
I've t
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 33 ++
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/gpu/drm/drm_modes.c | 37
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/video/fbmon.c | 42
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar
Reviewed-by: Thierry Reding
Acked-by: Thierry Reding
Tested-by: Thierry Reding
Tested-by: Philipp Zabel
Reviewed-by: Laurent Pinchart
Acked-by: Laurent Pinchart
---
drivers/video/fbmon.c
This adds support for reading display timings from DT into a struct
display_timings. The of_display_timing implementation supports multiple
subnodes. All children are read into an array, that can be queried.
If no native mode is specified, the first subnode will be used.
For cases where the graph
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: St
Hi!
Finally, right in time before the end of the world on friday, v16 of the
display helpers.
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: ad
vel/attachments/20121218/00153c88/attachment.html>
On 2012.12.18 at 16:24 +0100, Maarten Lankhorst wrote:
> Op 18-12-12 14:38, Markus Trippelsdorf schreef:
> > On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
> >> On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
> >>> On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote:
> O
On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim
wrote:
> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
> gem
> makes memory leak. release function of dma-buf cannot be called because
> f_count
> of dma-buf increased by importing gem and gem ref count cannot be decr
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/95e3f7b0/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/b5713e56/attachment.html>
Op 18-12-12 14:38, Markus Trippelsdorf schreef:
> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
>> On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
>>> On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote:
On 2012.12.17 at 17:00 -0500, Alex Deucher wrote:
> On Mon, De
On Tue, Dec 18, 2012 at 12:02 AM, Andy Gross wrote:
> Added resume hooks that will be called on resuming from DEVICE_OFF.
> The dmm portion of the patch reprograms the LUT to point to the dummy
> pages. The omapdrm portion of the patch repins the buffers into the
> DMM.
>
> Signed-off-by: Andy Gr
On Tue, Dec 18, 2012 at 12:02 AM, Andy Gross wrote:
> Add support for OMAP5 processor. The main differences are that the OMAP5
> has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
> size.
>
> Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
> ---
> drivers/staging/om
Hi Dave,
On 2012? 12? 18? 15:30, Dave Airlie wrote:
> On Thu, Sep 27, 2012 at 4:30 PM, Seung-Woo Kim
> wrote:
>> Increasing ref counts of both dma-buf and gem for imported dma-buf come from
>> gem
>> makes memory leak. release function of dma-buf cannot be called because
>> f_count
>> of dma-b
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #8 from maxi...@free.fr ---
(In reply to comment #7)
> Indeed, the resolution is the problem,
>
> running any application in my system resolution (1680x1050) breaks
> rendering, something like 640x480 has no problems. It also corrupts
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #7 from maxi...@free.fr ---
Indeed, the resolution is the problem,
running any application in my system resolution (1680x1050) breaks rendering,
something like 640x480 has no problems. It also corrupts things like glxgears
while I res
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #6 from Jerome Glisse ---
Can you try some other resolution than 1680x1040 and see if it has issue too.
Specially something like 640x480
--
You are receiving this mail because:
You are the assignee for the bug.
_
>
> b) don't keep track of dma_buf, keep track of gem objects, when we get
> a lookup, check inside the gem object, since currently we NULL out the
> export_dma_buf when we hit the release path, apart from the fact I'm
> sure the locking is foobar,
Okay I've sent and implementation of this option,
From: Dave Airlie
So when we export an dma buf we store it on the import list for that file
priv, so we can trap later imports of a buffer we exported from ourselves.
However there is nothing to clean that pointer up if the dma-buf gets
released internally, since we don't hold a reference to it.
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #5 from maxi...@free.fr ---
Yes, I'm sure, I did another test to check, nothing gets added to my dmesg even
after it shows up.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #4 from Jerome Glisse ---
YOu sure this is the kernel log after the issue show up ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #3 from maxi...@free.fr ---
Created attachment 71772
--> https://bugs.freedesktop.org/attachment.cgi?id=71772&action=edit
Kernel log
--
You are receiving this mail because:
You are the assignee for the bug.
>
> Many developers showed interest in the first RFC, and I've had the opportunity
> to discuss it with most of them. I would like to thank (in no particular
> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
> Lorentzon for his useful input during Linaro Connect Q4 20
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #2 from Jerome Glisse ---
Kernel log please
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://list
https://bugs.freedesktop.org/show_bug.cgi?id=58491
--- Comment #1 from maxi...@free.fr ---
Created attachment 71768
--> https://bugs.freedesktop.org/attachment.cgi?id=71768&action=edit
Heroes of newerth corruption
--
You are receiving this mail because:
You are the assignee for the bug.
__
Doesn't really add anything which can't be figured out through
proc files. And more clearly separates the new gem mmap handling
code from the old drm maps mmap handling code, which is surely a
good thing.
Cc: Martin Peres
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 11 +-
On Tue, 18 Dec 2012 14:57:45 +0100, Daniel Vetter
wrote:
> Doesn't really add anything which can't be figured out through
> proc files.
(grep /dev/dri /proc/$pid/maps)
> And more clearly separates the new gem mmap handling
> code from the old drm maps mmap handling code, which is surely a
> goo
https://bugs.freedesktop.org/show_bug.cgi?id=58491
Priority: medium
Bug ID: 58491
Assignee: dri-devel@lists.freedesktop.org
Summary: regression : r600g: work around ddx over alignment
Severity: normal
Classification: Unclassified
On 2012.12.18 at 14:38 +0100, Markus Trippelsdorf wrote:
> On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
> > On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
> > > On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote:
> > > > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote:
>
On 2012.12.18 at 12:20 +0100, Michel D?nzer wrote:
> On Mon, 2012-12-17 at 23:55 +0100, Markus Trippelsdorf wrote:
> > On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote:
> > > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote:
> > > > On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf
> > >
So I've gotten back to playing with prime for a day, and found some
old intel/radeon tests I had failing,
Tracked it down to a lifetime issue with the current code and can
think of two fixes,
The problem scenario is
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import
Dear Florian,
Am Dienstag, den 18.12.2012, 21:03 +0100 schrieb Florian Mickler:
> On Wed, 15 Aug 2012 17:40:40 +0200 Paul Menzel wrote:
>
> > Date: Wed, 8 Aug 2012 23:12:19 +0200
> >
> > Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
> > vertical stripes in the top half.
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #17 from Andre 2012-12-18 22:23:33 ---
Okay, after more than 30 hours uptime, i think this patch fixed it. :-)
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because
With refcounting we need to adjust framebuffer refcounts at each
callsite - much easier to do if they all call the same little helper
function.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 19 +--
drivers/gpu/drm/drm_fb_helper.c|6 +++---
Some drivers don't have real ->create_handle callbacks.
- cirrus/ast/mga200: Returns either 0 or -EINVAL.
- udl: Didn't even bother with a callback, leading to a nice
userspace-triggerable OOPS.
- vmwgfx: This driver bothered with an implementation to return 0 as
the handle (which is the can
Noticed while reviewing the fence locking in the radeon pageflip
handler.
v2: Instead of grabbing the bdev->fence_lock in object_transfer just
move the single callsite of that function a few lines, so that it is
protected by the fence_lock. Suggested by Jerome Glisse.
v3: Fix typo in commit messa
... by moving the bo_pin/bo_unpin manipulation of the pin_refcount
under the protection of the ttm reservation lock. pin/unpin seems
to get called from all over the place, so atm this is completely racy.
After this patch there are only a few places in cleanup functions
left which access ->pin_refc
1 - 100 of 200 matches
Mail list logo
