Hi Laurent,
Thanks for the reply.
On 17 December 2012 20:55, Laurent Pinchart <
laurent.pinch...@ideasonboard.com> wrote:
> Hi Vikas,
>
> Sorry for the late reply. I now have more time to work on CDF, so delays
> should be much shorter.
>
> On Thursday 06 December 2012 10:51:15 Vikas Sajjan wro
Hi All,
On 17 December 2012 20:55, Laurent Pinchart
wrote:
>
> Hi Vikas,
>
> Sorry for the late reply. I now have more time to work on CDF, so delays
> should be much shorter.
>
> On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
> > Hi Laurent,
> >
> > I was thinking of porting CDF to sa
Hello,
I am working on imx53 board developed in house. I have one problem. We have one
linux logo. We want to display that logo on display till our GUI application
gets loaded and shown on the screen. But in between screen is getting blank. I
could find the IOCTL for framebuffer which actual cle
Hi Dave!
On Tue, Dec 18, 2012 at 5:38 AM, Dave Airlie wrote:
> 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.
On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
>> The other thing I'd like you guys to do is kill the idea of fbdev and
>> v4l drivers that are "shared" with the drm codebase, really just
>> implement fbdev and v4l on top of the drm layer, some people might
>> think this is some sort of maintai
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:
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@lists.freedesktop.org
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
On Tue, 18 Dec 2012 01:28:22 +0100, Daniel Vetter wrote:
> The last parameter of search_free_generic is best_match, which isn't used
> by any current caller. The only reason it's still there is that I haven't
> converted yet all drm_mm.c users to preallocate drm_mm_node's, but as soon
> as that's
2012/12/18 Daniel Vetter
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
> >> The other thing I'd like you guys to do is kill the idea of fbdev and
> >> v4l drivers that are "shared" with the drm codebase, really just
> >> implement fbdev and v4l on top of the drm layer, some people might
>
On 17.12.2012 22:31, Paul Bolle wrote:
On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV
This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow, befo
On Sun, 16 Dec 2012 17:51:41 +, Chris Wilson
wrote:
> Avoid clobbering adjacent blocks if they happen to expire earlier and
> amalgamate together to form the requested hole.
>
> In passing this fixes a regression from
> commit ea7b1dd44867e9cd6bac67e7c9fc3f128b5b255c
> Author: Daniel Vetter
On 12/18/2012 06:04 AM, Dave Airlie wrote:
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 usefu
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
> > > wrote:
> > > > On 2012.12.17 at 16:32 -0500, Alex Deucher
On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote:
> Hi,
>
> Following to my shared talk with krh, danvet and Timothée Ravier @
> XDC2012, I have
> actually taken the time to start fixing some security holes found in
> the graphics stack.
>
> Today, I would like to request your comment
Le 18/12/2012 13:03, Daniel Vetter a écrit :
On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote:
Hi,
Following to my shared talk with krh, danvet and Timothée Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in
the graphics stack.
Today, I wo
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
> > >
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:
>
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 12/18/2012 07:21 AM, Rob Clark wrote:
On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
So this might be a bit off topic but this whole CDF triggered me
looking at stuff I generally avoid:
The biggest problem I'm having currently with the whole ARM graphics
and output world is the prolif
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
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
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(
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
On Tue, Dec 18, 2012 at 5:36 AM, Christian König
wrote:
> On 17.12.2012 22:31, Paul Bolle wrote:
>>
>> On an (outdated) laptop the radeon driver (almost always) prints, during
>> the first resume of each session:
>> [drm] crtc 1 is connected to a TV
>>
>> This message is a bit puzzling as, as
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 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 standard resolutions like 640x480, 720x576
> and 1680x1050. Additi
On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma wrote:
> Extend the mixer configuration to include more resolutions that can be
> generated by the mixer. This adds 640x480, 720x576 and 1680x1050.
>
I'd like to know why you changed this from
https://gerrit.chromium.org/gerrit/#/c/32245, which pulled
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
https://bugs.freedesktop.org/show_bug.cgi?id=44126
Fabio Pedretti changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=44126
Fabio Pedretti changed:
What|Removed |Added
Status|REOPENED|NEW
--
You are receiving this mail bec
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 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
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
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
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
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
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
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 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
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 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
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
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 ++
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
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
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
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:28 PM, Paul Bolle wrote:
> 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
>> >>
https://bugs.freedesktop.org/show_bug.cgi?id=22576
Alan Swanson changed:
What|Removed |Added
CC||ranki...@googlemail.com
--- Comment #22 f
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
https://bugs.freedesktop.org/show_bug.cgi?id=57350
--- Comment #5 from Marcin Slusarz ---
Rui Salvaterra: your bug is completely different from the others
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=57350
Marcin Slusarz changed:
What|Removed |Added
Summary|[nouveau, linux-3.7-rc] |[nouveau, linux-3.7-rc]
https://bugs.freedesktop.org/show_bug.cgi?id=57350
Marcin Slusarz changed:
What|Removed |Added
Attachment #71608|0 |1
is obsolete|
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
https://bugs.freedesktop.org/show_bug.cgi?id=58378
Marcin Slusarz changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
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...
https://bugs.freedesktop.org/show_bug.cgi?id=57350
Marcin Slusarz changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://
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.
https://bugs.freedesktop.org/show_bug.cgi?id=39285
smoki changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=22576
smoki changed:
What|Removed |Added
CC||b7.10110...@gmail.com
--- Comment #23 from smoki
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
- 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
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
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
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
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
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
... 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
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
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
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 +++---
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
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://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
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.
__
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 #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.
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 #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 #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.
_
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 #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
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
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
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
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
---
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
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
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
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/
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 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
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
On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
wrote:
> Sorry, not sure what information is most appropriate here. GPU hangs from
> time to time on this laptop, typically when running firefox on
> graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6
> (squeeze), lspci
ider the display to represent and deal
> >> with the whole pipeline, while video source deals with the bus between
> >> two display entities.
> >
> > What is missing in your proposal is an explanation of how the panel is
> > controlled. What does your register_display() function register the
> > display with, and what then calls the display operations ?
>
> In my particular case, the omapfb calls the display operations, which is
> the higher level "manager" for the whole display. So omapfb does calls
> both to the DSS side and to the panel side of the pipeline.
>
> I agree that making calls to both ends is a bit silly, but then again, I
> think it also happens in your model, it's just hidden there.
That's probably the biggest difference between our models. Let's discuss it
face to face tomorrow and hopefully come up with an agreement.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121218/ad978873/attachment.pgp>
On Tue, Dec 18, 2012 at 12:15 AM, Heinz Diehl wrote:
>> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
>> [drm] capturing error event; look for more information in
>> /debug/dri/0/i915_error_state
>> [drm:i915_reset] *ERROR* Failed to reset chip.
>
> I have the same problem
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters wit
On 17.12.2012, Guennadi Liakhovetski wrote:
> [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> [drm] capturing error event; look for more information in
> /debug/dri/0/i915_error_state
> [drm:i915_reset] *ERROR* Failed to reset chip.
I have the same problem, are able to r
All drivers which implement this need to have some sort of refcount to
allow concurrent vmap usage. Hence implement this in the dma-buf core.
To protect against concurrent calls we need a lock, which potentially
causes new funny locking inversions. But this shouldn't be a problem
for exporters wit
1 - 100 of 200 matches
Mail list logo
