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.
Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023426.html
http://lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #4 from Maarten Lankhorst ---
It looks nasty though, could you also dump mem_type for each time it calls
ttm_mem_evict_first?
--
You are receiving this mail because:
You are the assignee for the bug.
On Fri, Dec 14, 2012 at 5:57 AM, Inki Dae wrote:
> 2012/12/14 Daniel Vetter
>>
>> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae wrote:
>> > How about rebasing this patch to top of
>> > git://people.freedesktop.org/~airlied/linux.git drm-next?
>> > Exynos's many patches have already been merged to dr
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #5 from Maarten Lankhorst ---
Do any of your local patches touch radeon_evict_flags or
radeon_ttm_placement_from_domain? I don't see why it would recurse so deeply
otherwise.
A full public git tree to reproduce the problem and seeing
This patch adds iommu support for ipp.
For this, it adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().
Signed-off-by: Eunchul Kim
Signed-off-by: Jinyoung Jeon
---
drivers/gpu/drm
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.
Changelog v5:
This RFC v5 changed TODO list for arrang
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
From: Sumit Semwal
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Signed-off-by: Sumit Semwal
---
drivers/base/dma-buf.c | 149 +++
include/linux/dma-buf.h |6 +-
2 files changed, 154 insertions(+),
On Tue, 20 Nov 2012, Sean Paul wrote:
> On Tue, Nov 20, 2012 at 4:30 AM, Egbert Eich wrote:
>> drm_get_edid() returns a pointer to an EDID block. The caller
>> is responsible to free this pointer itself.
>> Here the pointer gets assigned to the local variable raw_edid.
>> Therefore it should be f
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal
Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a n
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> + list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> + seq_printf(s, "\t\t");
> +
> + seq_printf(s, "%s\n", attach_obj->dev->init_name);
> + att
unblank_screen() can be called from interrupt context during oops.
thus all ->fb_blank handlers should avoid sleeping in this situation.
callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper
From: Dave Airlie
Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
drm/radeon: use cached memory when evicting for vram on non agp
evicting from TTM would try and evict to TTM instead of system,
not so good.
This should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=58272
Signed-off-by: Dave
Op 14-12-12 12:04, Dave Airlie schreef:
> From: Dave Airlie
>
> Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
> drm/radeon: use cached memory when evicting for vram on non agp
>
> evicting from TTM would try and evict to TTM instead of system,
> not so good.
>
> This should fix:
> https://bugs.fr
Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like the idea, I don't know if it could be done in a free manner, but for
bonus points
could we also have the dma-buf fd be ob
On Fri, Dec 14, 2012 at 07:13:33AM +1000, Dave Airlie wrote:
> So this is a how to get new features pronouncement,
>
> >From what I can see people would like to have atomic interfaces for
> pageflip and modesetting merged,
>
> Now how I think developing and merging these will work (i.e. do it
> t
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
wrote:
> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a free m
Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
> wrote:
>> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>>> From: Sumit Semwal
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like the i
Added to my tree. Thanks.
On Fri, Dec 14, 2012 at 6:22 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #6 from Alex Deucher ---
Created attachment 71507
--> https://bugs.freedesktop.org/attachment.cgi?id=71507&action=edit
fix
Should be fixed with this patch.
--
You are receiving this mail because:
You are the assignee for the bug.
Nack,
I'm not against moving the TTM lock away,
when a replacement strategy for the main use case is presented.
but using wording like "unholy", "scares" just because there is a lack
of understanding or because it gets in the way of implementing
cross-device reservation is a really really bad
On 12/13/2012 11:09 PM, Terje Bergström wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have tegra-drm call into
>>> host1x with somethi
On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrj...@linux.intel.com wrote:
...
> Ever since the code started to resemble something sane, I've tried
> to avoid squashing patches, just in case someone was actually trying
> to follow what's changed. But clearly some of the patches can
> be squashe
Hi,
I have been testing Common Display Framework on OMAP, and making changes that
I've discussed in the posts I've sent in reply to the CDF series from Laurent.
While my CDF code is rather hacky and not at all ready, I wanted to post the
code for comments and also as a reference code to my posts.
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/display-core.c | 207 ++
include/video/display.h | 166 +++
2 files changed, 373 insertions(+)
create mode 100644 drivers/video/display/display-core.c
create mode 10064
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-dpi.c | 155 +
include/video/panel-dpi.h | 25 ++
2 files changed, 180 insertions(+)
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 include/video/panel-dpi.h
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/chip-tfp410.c | 164 +++
include/video/omap-panel-tfp410.h |4 +
2 files changed, 168 insertions(+)
create mode 100644 drivers/video/display/chip-tfp410.c
diff --git a/drivers/video/display/chip-tfp41
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-dvi.c | 164 +
include/video/panel-dvi.h | 18
2 files changed, 182 insertions(+)
create mode 100644 drivers/video/display/panel-dvi.c
create mode 100644 include/video/panel-dvi.h
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-taal.c | 383 ++
include/video/omap-panel-nokia-dsi.h |4 +-
2 files changed, 385 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/display/panel-taal.c
diff --git a/drivers/video/d
Signed-off-by: Tomi Valkeinen
---
drivers/video/Kconfig |1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig | 26 ++
drivers/video/display/Makefile |5 +
4 files changed, 33 insertions(+)
create mode 100644 drivers/video/di
From: Jerome Glisse
After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon
Hi Dave,
This is final git pull request for -next and includes some new features,
fixups and cleanups.
And a summary to this is as the following:
- add dmabuf attach/detach feature
. This patch would resolve performance deterioration issue
when v4l2-based driver is using the buffer imported
Dude, you're seriously overshooting here. This patch isn't required
_at_ _all_ to do cross device sharing/reservations/whatever. We've
simply discussed TTM documentation in the context of Maartens work,
and I've suggested to include all the TTM kerneldoc into a nice
DocBook. That way the kerneldoc
On 14.12.2012 18:21, Stephen Warren wrote:
> On 12/13/2012 11:09 PM, Terje Bergström wrote:
>> They want to get the global data by getting drvdata of their parent.
>
> There's no reason that /has/ to be so; they can get any information from
> wherever it is, rather than trying to require it to be
On 14.12.2012 18:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.
NAK. I changed t
On Fri, Dec 14, 2012 at 3:13 PM, Christian König
wrote:
> On 14.12.2012 18:39, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> After lockup we need to resume fence to last sync sequence and not
>> last received sequence so that all thread waiting on command stream
>> that lockedup resum
On Fri, Dec 14, 2012 at 1:04 AM, Rob Clark wrote:
> +static int lcdc_crtc_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event)
> +{
> + struct lcdc_crtc *lcdc_crtc = to_lcdc_crtc(crtc);
> + struct drm_d
From: Jerome Glisse
Modeset path seems to conflict sometimes with the memory management
leading to kernel deadlock. This move modesetting reset after GPU
acceleration reset.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 dele
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #7 from Andy Furniss ---
(In reply to comment #6)
> Created attachment 71507 [details] [review]
> fix
>
> Should be fixed with this patch.
Probably :-)
It seems that current drm-next head + fix has a different issue which makes
etq
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #8 from Maarten Lankhorst ---
Could you please run a git bisection to see where that error has been
introduced, then?
--
You are receiving this mail because:
You are the assignee for the bug.
From: Alex Deucher
Hi Dave,
This adds CS ioctl support for the async DMA rings.
The rest is bug fixes.
Alex
The following changes since commit 9add1ac3dd256ad12e266f8403daf928be19953f:
Merge branch 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux into
drm-next (2012-12-13 12:0
https://bugs.freedesktop.org/show_bug.cgi?id=57741
Matthew R. Trower changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #9 from Andy Furniss ---
Created attachment 71530
--> https://bugs.freedesktop.org/attachment.cgi?id=71530&action=edit
gpu lock + oops on use async dma for ttm buffer moves on 6xx-SI
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=58272
--- Comment #10 from Andy Furniss ---
(In reply to comment #8)
> Could you please run a git bisection to see where that error has been
> introduced, then?
It seems that drm/radeon: use async dma for ttm buffer moves on 6xx-SI is the
first non wo
So this is a how to get new features pronouncement,
>From what I can see people would like to have atomic interfaces for
pageflip and modesetting merged,
Now how I think developing and merging these will work (i.e. do it
this way or don't bother)
a) get an API you are happy with working, it does
Hi Dave,
A few leftover fixes for 3.8:
- VIC support for hdmi infoframes with the associated drm helper, fixes
some black TVs (Paulo Zanoni)
- Modeset state check (and fixup if the BIOS messed with the hw) for
lid-open. modeset-rework fallout. Somehow the original reporter went
awol, so this
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/820794f3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/1afc650c/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/e28d8cc0/attachment.html>
Hi All,
Kindly review the following patch set for Runtime PM Changes for
Mixer and Hdmi.
regards,
Rahul Sharma
On Wed, Nov 28, 2012 at 11:30 AM, Rahul Sharma
wrote:
> This patch set adds support for runtime power management for hdmi and
> mixer devices. Its also adds support for hdmiphy power
sts.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/d5740e68/attachment-0001.html>
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/b72ec3a6/attachment.html>
Thank's for your comment.
please check my answer.
BR
Eunchul Kim
On 12/13/2012 11:29 AM, Joonyoung Shim wrote:
> Hi,
>
> I can't review about logic of driver because i don't know well but i
> feel there are too many checking codes and unused or big size defines.
- I think error handling need. a
This patch fixes memory alloction(contiguous or not) and
cache mapping types(cachable or not).
For this, it converts each type from user request into dma
attribute properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 20 +
On 13.12.2012 19:58, Stephen Warren wrote:
> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>> After some more discussion with Stephen on IRC we came to the
>> conclusion that the easiest might be to have tegra-drm call into
>> host1x with something like:
>>
>> void host1x_set_drm_device(struct host
This patch fixes memory alloction(contiguous or not) and
cache mapping types(cachable or not).
For this, it converts each type from user request into dma
attribute properly.
Changelog v2:
- just code cleanup.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exyno
There is no any reason to change fb offset when CRTC is out of screen.
Also, this fixes a typing error.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_plane.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gp
This patchset is to update plane and fimd of exynos-drm. it includes
modification about coordinates calculation of plane and fimd and device
tree support of fimd.
The patchset is based exynos-drm-next branch on of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
Joonyoung Shim
The x, y coordinates of right bottom pixel cannot be negative numbers.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_
The fimd of exynos5 SoC supports extended screen coordinate.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
This adds the of_match_table to exynos-drm fimd driver to be probed from
the device tree.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exy
line?
--
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/20121214/22718628/attachment.html>
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.
Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023426.html
http://lists.freedesktop.org
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/bafdf75e/attachment.html>
On Fri, Dec 14, 2012 at 5:57 AM, Inki Dae wrote:
> 2012/12/14 Daniel Vetter
>>
>> On Thu, Dec 13, 2012 at 4:16 PM, Inki Dae wrote:
>> > How about rebasing this patch to top of
>> > git://people.freedesktop.org/~airlied/linux.git drm-next?
>> > Exynos's many patches have already been merged to dr
m and seeing what patches are
applied would also be nice.
--
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/20121214/8e7f6e86/attachment.html>
This patch adds iommu support for ipp.
For this, it adds subdrv_probe/remove callback to enable or disable ipp iommu.
we can get or put device address to a gem handle from user
through exynos_drm_gem_get/put_dma_addr().
Signed-off-by: Eunchul Kim
Signed-off-by: Jinyoung Jeon
---
drivers/gpu/drm
IPP stand for Image Post Processing and supports image scaler/rotator
/crop/flip/csc(color space conversion) and input/output DMA operations using
ipp drivers.
also supports writeback and display output operations.
ipp driver include FIMC, Rotator, GSC, SC, so on.
and ipp is integration device dri
GSC is stand for General SCaler and supports
image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
GSC supports image rotation and image effect functions, also supports writeback
and display output op
Hi All.
I am responsible for a display part from Samsung Electronics Telecommunication
Division.
and I am going to add post-processing features in exynos drm.
If you have some opinions of this patch,
please give some comments about my patch.
Changelog v5:
This RFC v5 changed TODO list for arrang
FIMC is stand for Fully Interfactive Mobile Camera and
supports image scaler/rotator/crop/flip/csc and input/output DMA operations.
input DMA reads image data from the memory.
output DMA writes image data to memory.
FIMC supports image rotation and image effect functions.
also supports writeback an
Rotator supports rotation/crop/flip and input/output DMA operations
Rotator ipp driver supports 90,180,270 degree rotaion and vertical, horizontal
flip.
and has some limitations(source and destination format have to be same, no
scaler)
Signed-off-by: Eunchul Kim
Signed-off-by: Youngjun Cho
---
From: Sumit Semwal
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Signed-off-by: Sumit Semwal
---
drivers/base/dma-buf.c | 149 +++
include/linux/dma-buf.h |6 +-
2 files changed, 154 insertions(+),
On Tue, 20 Nov 2012, Sean Paul wrote:
> On Tue, Nov 20, 2012 at 4:30 AM, Egbert Eich wrote:
>> drm_get_edid() returns a pointer to an EDID block. The caller
>> is responsible to free this pointer itself.
>> Here the pointer gets assigned to the local variable raw_edid.
>> Therefore it should be f
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal
Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a n
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> + list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> + seq_printf(s, "\t\t");
> +
> + seq_printf(s, "%s\n", attach_obj->dev->init_name);
> + att
unblank_screen() can be called from interrupt context during oops.
thus all ->fb_blank handlers should avoid sleeping in this situation.
callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper
From: Dave Airlie
Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
drm/radeon: use cached memory when evicting for vram on non agp
evicting from TTM would try and evict to TTM instead of system,
not so good.
This should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=58272
Signed-off-by: Dave
Op 14-12-12 12:04, Dave Airlie schreef:
> From: Dave Airlie
>
> Since 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d
> drm/radeon: use cached memory when evicting for vram on non agp
>
> evicting from TTM would try and evict to TTM instead of system,
> not so good.
>
> This should fix:
> https://bugs.fr
Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like the idea, I don't know if it could be done in a free manner, but for
bonus points
could we also have the dma-buf fd be
On Fri, Dec 14, 2012 at 07:13:33AM +1000, Dave Airlie wrote:
> So this is a how to get new features pronouncement,
>
> >From what I can see people would like to have atomic interfaces for
> pageflip and modesetting merged,
>
> Now how I think developing and merging these will work (i.e. do it
> t
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
wrote:
> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a fre
Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
> wrote:
>> Op 14-12-12 10:36, sumit.semwal at ti.com schreef:
>>> From: Sumit Semwal
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like th
Added to my tree. Thanks.
On Fri, Dec 14, 2012 at 6:22 AM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121214/5164ee34/attachment.html>
Nack,
I'm not against moving the TTM lock away,
when a replacement strategy for the main use case is presented.
but using wording like "unholy", "scares" just because there is a lack
of understanding or because it gets in the way of implementing
cross-device reservation is a really really bad i
On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have tegra-drm call into
>>> host1x with somethi
On Wed, Dec 12, 2012 at 06:15:27PM +0200, ville.syrjala at linux.intel.com
wrote:
...
> Ever since the code started to resemble something sane, I've tried
> to avoid squashing patches, just in case someone was actually trying
> to follow what's changed. But clearly some of the patches can
> be squ
Hi,
I have been testing Common Display Framework on OMAP, and making changes that
I've discussed in the posts I've sent in reply to the CDF series from Laurent.
While my CDF code is rather hacky and not at all ready, I wanted to post the
code for comments and also as a reference code to my posts.
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/display-core.c | 207 ++
include/video/display.h | 166 +++
2 files changed, 373 insertions(+)
create mode 100644 drivers/video/display/display-core.c
create mode 10064
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-dpi.c | 155 +
include/video/panel-dpi.h | 25 ++
2 files changed, 180 insertions(+)
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 include/video/panel-dpi.h
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/chip-tfp410.c | 164 +++
include/video/omap-panel-tfp410.h |4 +
2 files changed, 168 insertions(+)
create mode 100644 drivers/video/display/chip-tfp410.c
diff --git a/drivers/video/display/chip-tfp41
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-dvi.c | 164 +
include/video/panel-dvi.h | 18
2 files changed, 182 insertions(+)
create mode 100644 drivers/video/display/panel-dvi.c
create mode 100644 include/video/panel-dvi.h
Signed-off-by: Tomi Valkeinen
---
drivers/video/display/panel-taal.c | 383 ++
include/video/omap-panel-nokia-dsi.h |4 +-
2 files changed, 385 insertions(+), 2 deletions(-)
create mode 100644 drivers/video/display/panel-taal.c
diff --git a/drivers/video/d
Signed-off-by: Tomi Valkeinen
---
drivers/video/Kconfig |1 +
drivers/video/Makefile |1 +
drivers/video/display/Kconfig | 26 ++
drivers/video/display/Makefile |5 +
4 files changed, 33 insertions(+)
create mode 100644 drivers/video/di
From: Jerome Glisse
After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command stream
that lockedup resume. Otherwise GPU reset will be ineffective in most
cases.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon
Dude, you're seriously overshooting here. This patch isn't required
_at_ _all_ to do cross device sharing/reservations/whatever. We've
simply discussed TTM documentation in the context of Maartens work,
and I've suggested to include all the TTM kerneldoc into a nice
DocBook. That way the kerneldoc
On 14.12.2012 18:21, Stephen Warren wrote:
> On 12/13/2012 11:09 PM, Terje Bergstr?m wrote:
>> They want to get the global data by getting drvdata of their parent.
>
> There's no reason that /has/ to be so; they can get any information from
> wherever it is, rather than trying to require it to be
On 14.12.2012 18:39, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> After lockup we need to resume fence to last sync sequence and not
> last received sequence so that all thread waiting on command stream
> that lockedup resume. Otherwise GPU reset will be ineffective in most
> cases.
NAK.
On Fri, Dec 14, 2012 at 3:13 PM, Christian K?nig
wrote:
> On 14.12.2012 18:39, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> After lockup we need to resume fence to last sync sequence and not
>> last received sequence so that all thread waiting on command stream
>> that lockedup re
1 - 100 of 105 matches
Mail list logo
