On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2015 at 8:04 PM, Dave Jones
> wrote:
> > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> >
> > > > I tried tweaking the delays in
> > drm_dp_link_train_clock_recovery_delay, without any noticab
e panel returns all 0s for
the dpcd unless the panel is in D0 state.
--
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/2015051
I don't really know much about the current status of using DRM_CAS macro,
but the reality is that there is a company Vivante which provides OpenGL driver
for their 3D core which uses DRM_CAS for locking.
There is a chip with mips processor and Vivante core (I'm part of that chip) =>
no support fo
On 14/05/15 12:38, Guo, Yejun wrote:
> Thanks Daniel Kurtz and Emil Velikov for the reply.
>
> In general, drm APIs are invoked by user mode drivers, but, I want to mimic
> the behavior of driver in my unit test to create buffer objects. After do
> some searching, I wrote the following code in
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/2e935ada/attachment-0001.html>
ng 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/20150514/6dcbc578/attachment.html>
Hi,
On 2015ë
05ì 13ì¼ 22:08, Jan Kara wrote:
> Convert g2d_userptr_get_dma_addr() to pin pages using get_vaddr_frames().
> This removes the knowledge about vmas and mmap_sem locking from exynos
> driver. Also it fixes a problem that the function has been mapping user
> provided address withou
0 00
--
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/20150514/81d1660e/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/af8b2cc5/attachment.html>
NAK. The original code is correct.
On Thu, May 14, 2015 at 2:17 PM, Guo Yejun wrote:
> Signed-off-by: Guo Yejun
> ---
> xf86drm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..5e7306e 100644
> --- a/xf86drm.c
> +++ b/xf86dr
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/8aa6855c/attachment.html>
ted.
--
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/20150514/8ec35659/attachment.html>
this function was not used anywhere and was giving a build warning.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f06..6e60f71 100644
--- a/dr
I2C drivers that support OF, have both an I2C and OF device ID tables
that are used to fill the supported module aliases. But currently the
I2C core only uses the OF table to match a device with a driver and
the aliases information are always reported in the form i2c:.
The client->name is used as
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/219c45da/attachment.html>
dn't get a working display otherwise, should I try without it?
--
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/20150514/2571/attachment-0001.html>
, 0
> [7.843206] [drm] DPCD: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
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/20150514/3a540c4f/attachment.html>
Hi Inki and Tobias,
2015-05-12 Gustavo Padovan :
> 2015-05-10 Inki Dae :
>
> > 2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> > > Hello Inki,
> > >
> > >
> > > Inki Dae wrote:
> > >> Hi,
> > >>
> > >> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
> > >>> Hello,
> > >>>
> > >>> I've tested this on my H
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/6331a4b0/attachment.html>
The DSnPR plane configuration registers are updated on vblank, and no
vblank will occur once the CRTC is stopped. We thus can't only disable
planes right before starting the CRTC as it would start scanning out
immediately from old frame buffers until the next vblank.
Fix the problem by disabling a
This helps debugging probe failures.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index da1216a73969..780ca11512ba 10064
The ADV7511 is probed before its slave encoder init function associates
it with an encoder. This creates a time window during which hot plug
detection interrupts can occur with an encoder, resulting in a crash in
the IRQ handler.
Fix this by ignoring hot plug detection IRQs when no encoder is
asso
Em Wed, 1 Apr 2015 15:15:27 +0200
Gerd Hoffmann escreveu:
> After adding virtio-gpu I get this funky kconfig dependency loop.
>
> scripts/kconfig/conf --oldconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5: symbol FB is selecte
Signed-off-by: Aleksey Kuleshov
---
xf86drm.h | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/xf86drm.h b/xf86drm.h
index 40c55c9..2ba75d9 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -462,6 +462,27 @@ do { register unsigned int __old __asm("o0");
Hi Sudip,
On 14 May 2015 at 12:14, Sudip Mukherjee wrote:
> this function was not used anywhere and was giving a build warning.
Thanks for the patch, but this function is used in following patches
that are in the process of being merged. This shouldn't have snuck in
in the earlier patch; apologi
On 05/14/2015 02:29 PM, Laurent Pinchart wrote:
> The ADV7511 is probed before its slave encoder init function associates
> it with an encoder. This creates a time window during which hot plug
> detection interrupts can occur with an encoder, resulting in a crash in
> the IRQ handler.
>
> Fix this
Signed-off-by: Guo Yejun
---
xf86drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index f7c45f8..5e7306e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -635,9 +635,8 @@ static int drmOpenByName(const char *name, int type)
drmFreeV
t.
>
> > - if (!pages) {
> > - DRM_ERROR("failed to allocate pages.\n");
> > - ret = -ENOMEM;
> > + vec = g2d_userptr->vec = frame_vector_create(npages);
>
> I think you can use g2d_userptr->vec so it seems that vec isn't needed.
>
> > + if (!vec)
> > goto err_free;
> > - }
> >
> > - down_read(¤t->mm->mmap_sem);
> > - vma = find_vma(current->mm, userptr);
>
> For vma, ditto.
Thanks for review! Attached is a new version of the patch.
Honza
--
Jan Kara
SUSE Labs, CR
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-exynos-Convert-g2d_userptr_get_dma_addr-to-use-g.patch
Type: text/x-patch
Size: 7676 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/cf217dc2/attachment.bin>
narrow down where the dpcd info is getting corrupted.
--
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/20150514/228ede95/attachment.html>
longer and more often (very choppy).
--
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/20150514/146dee11/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/f6f7ef5b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/16fe5d03/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/ef36754e/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/53280407/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/15098226/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/4d326926/attachment-0001.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/39c26d73/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/b7115389/attachment.html>
Thanks Daniel Kurtz and Emil Velikov for the reply.
In general, drm APIs are invoked by user mode drivers, but, I want to mimic the
behavior of driver in my unit test to create buffer objects. After do some
searching, I wrote the following code in my unit test (user mode simple
application ba
On Thu, May 14, 2015 at 5:12 AM, Aleksey Kuleshov wrote:
> Signed-off-by: Aleksey Kuleshov
> ---
At least a few years ago, DRM_CAS was only used by DRI1 which is
pretty dead at this point. Has something changed?
What problem are you trying to solve?
Hi Dave,
A just a few small fixes for radeon.
The following changes since commit 332545b3016cbff066c17037d32ec8aae8e4cfb5:
Merge tag 'drm-intel-fixes-2015-05-08' of
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-05-11 06:06:22
+1000)
are available in the git repository at:
On 14 May 2015 at 07:17, Guo Yejun wrote:
> Signed-off-by: Guo Yejun
> ---
> xf86drm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index f7c45f8..5e7306e 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -635,9 +635,8 @@ static int drmOpenB
A naive question and a nit follow. That's probably not what you'd like
to see for an RFC, but the patch got tangled up in my mail filter
anyhow.
On Wed, 2015-05-13 at 23:23 +0800, CK Hu wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> +config DRM_MEDIATEK_FBDEV
> + bool "Enab
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2015 at 8:04 PM, Dave Jones
> wrote:
> > On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
> >
> > > > I tried tweaking the delays in
> > drm_dp_link_train_clock_recovery_delay, without any noticab
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/c4a96672/attachment.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/20150514/e9ee9fe6/attachment.html>
This patch adds a helper to get bits per pixel value of MIPI DSI pixel format.
The helper takes a parameter in the type 'enum mipi_dsi_pixel_format' and
returns it's bits per pixel value if the parameter is valid, otherwise, it
returns -EINVAL. The helper makes users' life easier to do the convers
2015-05-12 21:36 GMT+08:00 Thierry Reding :
> On Fri, Feb 13, 2015 at 01:25:19PM +0800, Liu Ying wrote:
>> Signed-off-by: Liu Ying
>
> This could use a commit message. Describe for example why this is useful
> or when to use it.
Ok, I'll add it in the next version.
>
>> ---
>> v9->v9.5:
>> * Ad
On Tue, May 12, 2015 at 8:04 PM, Dave Jones wrote:
> On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
>
> > > I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay,
> without any noticable
> > > difference. Is there something else I can try to make it try harder
>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/55371973/attachment.html>
r237139
--
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/20150514/686f61a6/attachment.html>
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen
Don't pollute the dmesg with EDID read success message as an error.
Printing as debug should be fine.
Signed-off-by: Krzysztof Kozlowski
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/driv
Javier,
On Thu, May 14, 2015 at 7:31 AM, Javier Martinez Canillas
wrote:
> I2C drivers that support OF, have both an I2C and OF device ID tables
> that are used to fill the supported module aliases. But currently the
> I2C core only uses the OF table to match a device with a driver and
> the alia
On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote:
> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
> always on for wm calculation (v4)") fixes a null pointer dereference.
> Setting the primary and cursor panes to false in
> ilk_compute_wm_parameters to false does h
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150514/9b3e55e2/attachment.html>
|(bisected) |(bisected)
--
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/20150514/d276279c/attachment.html>
57 matches
Mail list logo
