|--- |FIXED
--
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/20150413/de6b5c5e/attachment.html>
Plane sources are configured by the VSPS bit in the PnDDCR4 register.
Although the datasheet states that the bit is updated during vertical
blanking, it seems that updates only occur when the DU group is held in
reset through the DSYSR.DRES bit. Restart the group if the source
changes.
Signed-off-
Register live sources for VSPD0 and VSPD1 and configure the plane source
at plane setup time to source frames from memory or from the VSP1.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 +
drivers/gpu/drm/rcar-
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0
and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0
or DU0/1 plane 1.
Allocate the correct fixed plane when sourcing frames from VSPD0 or
VSPD1, and allocate planes in reverse index order otherwise to ensure
Introduce a new live source flag for framebuffers. When a framebuffer is
created with that flag set, a live source is associated with the
framebuffer instead of buffer objects. The framebuffer can then be used
with a plane to connect it with the live source.
Signed-off-by: Laurent Pinchart
---
d
Live sources represent a hardware connection between a video stream
source and a CRTC, going through a plane. The kernel API lets driver
register live sources, and the userspace API lets applications enumerate
them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 164 ++
Hello,
Here's a proposal for a different approach to live source in DRM based on an
idea by Daniel Vetter. The previous version can be found at
http://lists.freedesktop.org/archives/dri-devel/2015-March/079319.html.
The need comes from the Renesas R-Car SoCs in which a video processing engine
(na
On 13.04.2015 19:51, Jerome Glisse wrote:
> On Mon, Apr 13, 2015 at 07:23:34PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
>>> From: Christian König
>>>
>>> WIP patch which adds an user fence IOCTL.
>>>
>>> Signed-off-by: Christian König
>> I
On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
> From: Christian König
>
> WIP patch which adds an user fence IOCTL.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h | 2 ++
> drivers/gpu/drm/radeon/radeon_gem.c | 71
> ++
On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
> From: Christian König
>
> WIP patch which adds an user fence IOCTL.
>
> Signed-off-by: Christian König
I've discussed userspace fences a lot with Jerome last XDC, so here's my
comments:
My primary concern with mid-batch fenc
2015-04-13 11:53 GMT-03:00 Todd Previte :
> Displayport compliance test 4.2.2.6 requires that a source device be capable
> of
> detecting a corrupt EDID. The test specification states that the sink device
> sets up the EDID with an invalid checksum. To do this, the sink sets up an
> invalid EDID h
On 13.04.2015 18:08, Jerome Glisse wrote:
> On Mon, Apr 13, 2015 at 05:45:21PM +0200, Christian König wrote:
>> On 13.04.2015 17:31, Jerome Glisse wrote:
>>> On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
Hello everyone,
we have a requirement for a bit different k
On 13.04.2015 17:39, Jerome Glisse wrote:
> On Mon, Apr 13, 2015 at 11:25:30AM -0400, Serguei Sagalovitch wrote:
>>> the BO to be kept in the same place while it is mapped inside the kernel
>> page table
>> ...
>>> So this requires that we pin down the BO for the duration of the wait
>> IOCTL.
>>
>
On 13.04.2015 17:31, Jerome Glisse wrote:
> On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
>> Hello everyone,
>>
>> we have a requirement for a bit different kind of fence handling.
>> Currently we handle fences completely inside the kernel, but in
>> the future we would like to
tion.
>>
>> Any ideas how to avoid those problems? Or better ideas how to handle the new
>> requirements?
>>
>> Please note that the patches are only hacked together quick&dirty to
>> demonstrate the problem and not very well tested.
>>
>> Best regards,
>> Christian.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/e5f7dc45/attachment.html>
Currently, we are missing to destroy buffer of cursor when terminates
modetest.
Signed-off-by: Joonyoung Shim
---
tests/modetest/modetest.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 56d49b0..758d86c 100644
--- a/tests/mo
Currently, we are missing to destroy buffer and to remove framebuffer of
planes when terminates modetest.
Signed-off-by: Joonyoung Shim
---
tests/modetest/modetest.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
ind
This patch needs to destroy and to remove buffer and framebuffer
properly from error path of set_mode and test_page_flip.
Signed-off-by: Joonyoung Shim
---
tests/modetest/modetest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/test
It's proper to remove added framebuffer before destroy buffer.
Signed-off-by: Joonyoung Shim
---
tests/modetest/modetest.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index b59f6b5..6377459 100644
--- a/tests/modetest/modetest.c
+
If use -P option without -s option, we meet Segmentation fault error
when modetest is terminated. Check whether dev.mode.bo is NULL.
Signed-off-by: Joonyoung Shim
---
tests/modetest/modetest.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b
Hi all,
This patchset is to fix properly about buffer and framebuffer resources
when terminates modetest of libdrm.
Thanks.
Joonyoung Shim (5):
modetest: fix Segmentation fault
modetest: add to use drmModeRmFB
modetest: fix to proper error path handling
modetest: clear bu
From: Christian König
WIP patch which adds an user fence IOCTL.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_gem.c | 71 +
drivers/gpu/drm/radeon/radeon_kms.c | 1 +
include/uapi/drm/radeon_
From: Christian König
That makes it possible to call it from elsewhere as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 55 --
2 files changed, 30 insertions(+), 27 deletions(-)
d
From: Christian König
After resume buffer need to move back into VRAM. We already had this
problem with UVD, but solve it more general to be on the safe side.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 ++
drivers/gpu/drm/radeon/radeon_object.c | 11 ++
Hello everyone,
we have a requirement for a bit different kind of fence handling. Currently we
handle fences completely inside the kernel, but in the future we would like to
emit multiple fences inside the same IB as well.
This works by adding multiple fence commands into an IB which just write
On 2015ë
04ì 13ì¼ 16:28, Marek Szyprowski wrote:
> Commit adacb228d72b9529f8de0769cc33414c3012054d ("drm: Exynos: Respect
> framebuffer pitch for FIMD/Mixer") changed the way of buffer size
> calcularion: it replaced fb_width by fb_pitch entry. fb_pitch however
> already contains '(win_data->b
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/a3814fd7/attachment.sig>
iven that time_left is unsigned now, why bother with the "< 0"?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/977d0dca/attachment.sig>
ght;
> val = (unsigned long)(dma_addr + size);
> writel(val, ctx->regs + VIDWx_BUF_END(win, 0));
>
> --
> 1.9.2
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/fd27e0af/attachment-0001.html>
On Mon, Apr 13, 2015 at 08:26:05PM +0200, Christian König wrote:
> On 13.04.2015 19:51, Jerome Glisse wrote:
> >On Mon, Apr 13, 2015 at 07:23:34PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
> >>>From: Christian König
> >>>
> >>>WIP patch whi
Hi,
On 13 April 2015 at 15:06, Thierry Reding wrote:
> I'm not much of a gamer myself, but I imagine that these games would be
> useful, real-life tests and/or entertaining benchmarks. Given that I
> work mostly on ARM systems, do you know if there are any plans on making
> these games available
Hi,
On 04/11/2015 03:57 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The planes are already disabled by the drm_atomic_helper_commit() code
> so we don't need to disable the in these two places.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_drm_crtc.c|
Hi Hans,
Thank you so much for the review.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
owner at vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, March 20, 2015 7:08 PM
>
> Hi Kamil,
>
> Once again thank you for continuing this work!
>
> I do have some comments, see be
Add support for the Hannstar HSD100PXN1 to the DRM simple panel driver.
The HSD100PXN1 is an XGA (1024x768) panel with an 18-bit LVDS interface.
It supports pixel clocks in the range of 55-75 MHz.
This panel is offered for sale by Freescale as a companion part to its'
i.MX5x Quick Start board and
On Mon, Apr 13, 2015 at 01:15:49PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 13, 2015 at 10:57:14AM +0300, Jani Nikula wrote:
> > Add ELD versions according to HDA Specification v1.0a.
> >
> > 2 indicates version 2, which supports CEA_Ver 861D or below. Maximum
> > Baseline ELD size of 80 bytes
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/8d8952a7/attachment.html>
On Mon, Apr 13, 2015 at 07:23:34PM +0200, Daniel Vetter wrote:
> On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote:
> > From: Christian König
> >
> > WIP patch which adds an user fence IOCTL.
> >
> > Signed-off-by: Christian König
>
> I've discussed userspace fences a lot with
On Mon, Apr 13, 2015 at 06:55:19PM +0200, Christian König wrote:
> On 13.04.2015 18:08, Jerome Glisse wrote:
> >On Mon, Apr 13, 2015 at 05:45:21PM +0200, Christian König wrote:
> >>On 13.04.2015 17:31, Jerome Glisse wrote:
> >>>On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
> >
2015-04-13 Joonyoung Shim :
> Hi,
>
> On 04/11/2015 03:57 AM, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > The planes are already disabled by the drm_atomic_helper_commit() code
> > so we don't need to disable the in these two places.
> >
> > Signed-off-by: Gustavo Padovan
> > ---
and what libraries you use in git version.
--
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/20150413/c4508771/attachment.html>
On Mon, Apr 13, 2015 at 10:57:14AM +0300, Jani Nikula wrote:
> Add ELD versions according to HDA Specification v1.0a.
>
> 2 indicates version 2, which supports CEA_Ver 861D or below. Maximum
> Baseline ELD size of 80 bytes (15 SAD count).
>
> 31 indicates an ELD that has been partially populated
On Mon, Apr 13, 2015 at 11:52:19AM -0400, Serguei Sagalovitch wrote:
> > Given that the userspace wait fence ioctl has not way to know which
> > command buffer it is really waiting after then kernel has no knowledge
> > if this user fence will signal at all.
>
> We could pass BO handle as paramete
On Mon, Apr 13, 2015 at 05:45:21PM +0200, Christian König wrote:
> On 13.04.2015 17:31, Jerome Glisse wrote:
> >On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
> >>Hello everyone,
> >>
> >>we have a requirement for a bit different kind of fence handling.
> >>Currently we handle f
Hi Dave,
This pull request contains just cleanup for atomic pageflip/modeset
support, and some fixeups.
We wanted to merge atomic pageflip/modeset feature support, new drivers
- MIC and DECON for exynos5433 SoC - and relevant patches this time.
However, I'd found that these feature
e
> a big VRAM BO and effectively pin it in VRAM leading to a GPU
> DOS (denial of service).
>
> By the way Christian, i would add a timeout to this ioctl and
> return eagain to userspace on timeout so that userspace can
> resumit. That way a malicious userspace will just keep exhausting
> its cpu timeslot.
>
> Cheers,
> Jérôme
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/4bfb98f2/attachment-0001.html>
On Mon, Apr 13, 2015 at 05:35:04PM +0200, Christian König wrote:
> On 13.04.2015 17:25, Serguei Sagalovitch wrote:
> >> the BO to be kept in the same place while it is mapped inside the kernel
> >page table
> >...
> >> So this requires that we pin down the BO for the duration of the wait
> >IOCTL.
On Mon, Apr 13, 2015 at 11:25:30AM -0400, Serguei Sagalovitch wrote:
> > the BO to be kept in the same place while it is mapped inside the kernel
> page table
> ...
> > So this requires that we pin down the BO for the duration of the wait
> IOCTL.
>
> But my understanding is that it should be not
pin down the BO for the duration of the wait IOCTL.
>>>
>>> This practically gives userspace a way of pinning down BOs for as long as
>>> it wants, without the ability for the kernel for intervention.
>>>
>>> Any ideas how to avoid those problems? Or better ideas how to handle the
>>> new requirements?
>>>
>>> Please note that the patches are only hacked together quick&dirty to
>>> demonstrate the problem and not very well tested.
>>>
>>> Best regards,
>>> Christian.
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/4e9cdeb5/attachment.html>
On Mon, Apr 13, 2015 at 04:52:14PM +0200, Christian König wrote:
> Hello everyone,
>
> we have a requirement for a bit different kind of fence handling.
> Currently we handle fences completely inside the kernel, but in
> the future we would like to emit multiple fences inside the same
> IB as wel
Hi Dave,
Some final bits for 4.1. Some fixes for userptrs and allow a new
packet for VCE to enable some new features in mesa.
The following changes since commit 1d8ac08d498d579aae36221a80b4b724b2f52f39:
Merge tag 'v4.0-rc7' into drm-next (2015-04-09 07:48:27 +1000)
are available in the git r
On Wed, Apr 01, 2015 at 10:01:50AM +0530, Sudip Mukherjee wrote:
> On Tue, Mar 31, 2015 at 04:35:49PM +0100, Chris Wilson wrote:
> > On Tue, Mar 31, 2015 at 08:40:12PM +0530, Sudip Mukherjee wrote:
> > > This reverts commit <0f71979ab7fbd0c71c41c2798de3d33937915434>.
> > >
> > > my display was get
demonstrate the problem and not very well tested.
>
> Best regards,
> Christian.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/fffd294d/attachment.html>
On Mon, 13 Apr 2015, Jani Nikula wrote:
> They're only used to store const pointers anyway. This helps to keep
> Ville and the compiler happy.
>
> Christian König
Copy-paste fail, please s/^/Reviewed-by: / while merging.
Jani.
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_crtc.h
They're only used to store const pointers anyway. This helps to keep
Ville and the compiler happy.
Christian König
Signed-off-by: Jani Nikula
---
include/drm/drm_crtc.h | 8
include/drm/drm_crtc_helper.h | 6 +++---
include/drm/drm_plane_helper.h | 2 +-
3 files changed, 8 in
Not to be modified.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/armada/armada_output.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_output.h
b/drivers/gpu/drm/armada/armada_output.h
index 4126d43b5057..3c4023e142d0 100644
--- a/drivers/gpu
Some non-const pointers were added since the last constification, fix
them.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/radeon/radeon_connectors.c | 4 ++--
drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon
This was introduced in
commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
Author: Antonino A. Daplas
Date: Mon Jun 26 00:27:12 2006 -0700
[PATCH] VT binding: Add sysfs control to the VT layer
with the justification
"In addition, if any of the consoles are in KD_GRAPHICS mode, binding an
Our legacy SetPlane updates perform integer overflow checking on a
plane's destination rectangle in drm_mode_setplane(), and atomic updates
handled as part of a drm_atomic_state transaction do the same checking
in drm_atomic_plane_check(). However legacy cursor updates that get
routed through univ
Add ELD versions according to HDA Specification v1.0a.
2 indicates version 2, which supports CEA_Ver 861D or below. Maximum
Baseline ELD size of 80 bytes (15 SAD count).
31 indicates an ELD that has been partially populated through
implementation specific mean of default programming before an ext
On 13.04.2015 10:21, Jani Nikula wrote:
> Some non-const pointers were added since the last constification, fix
> them.
>
> Signed-off-by: Jani Nikula
For this one Reviewed-by: Christian König .
Can't say anything for patch #2, and #3 already has my rb IIRC.
Regards,
Christian.
> ---
> driv
Commit adacb228d72b9529f8de0769cc33414c3012054d ("drm: Exynos: Respect
framebuffer pitch for FIMD/Mixer") changed the way of buffer size
calcularion: it replaced fb_width by fb_pitch entry. fb_pitch however
already contains '(win_data->bpp >> 3)' factor, so it should be removed
from final buffer si
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/9829f765/attachment-0001.html>
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the ch
because there are many
different causes.
--
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/20150413/cfe36311/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/09424812/attachment.html>
10.5.2. I can't report
any dmesg or log, my system completely freezes.
--
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/
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150413/30999c41/attachment.html>
nts/20150413/e1c7dc26/attachment.html>
68 matches
Mail list logo
