So the problem with async commit (especially async modeset commit) is
that the legacy pointers only get updated after the point of no
return, in the async part of the modeset sequence. At least as
implemented by the current helper functions. This is done in the
set_routing_links function in drm_ato
On 2014ë
11ì 25ì¼ 22:08, Ajay kumar wrote:
> Hi Inki,
>
> On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote:
>> On 2014ë
11ì 25ì¼ 21:17, Ajay kumar wrote:
>>> ping.
>>>
>>
>> You'd need to clean up clocks and fix up binding file. And then let's
>> have review in more details. I wish that
On Wed, Nov 26, 2014 at 01:17:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
>
On 2014ë
11ì 25ì¼ 21:17, Ajay kumar wrote:
> ping.
>
You'd need to clean up clocks and fix up binding file. And then let's
have review in more details. I wish that other people also give you
their reviews.
Anyway, below is my answer.
Thanks,
Inki Dae
> On Tue, Nov 11, 2014 at 10:08 PM, A
Hi Dave,
Add Exynos4415 SoC support, some fixups and cleanups.
Summary:
- Resolve kernel lockup issue incurred by probe request in probe context.
. For this, it moves all register codes of sub drivers into init function
and adds component binding support for vidi driver.
-
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/da09d31b/attachment.html>
At Fri, 14 Nov 2014 20:39:15 +0100,
Takashi Iwai wrote:
>
> At Fri, 14 Nov 2014 12:29:17 -0500,
> Alex Deucher wrote:
> >
> > On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai wrote:
> > > At Fri, 14 Nov 2014 10:40:08 -0500,
> > > Alex Deucher wrote:
> > >>
> > >> On Fri, Nov 14, 2014 at 5:09 AM, T
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 589a921..9972cc8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -239
Signed-off-by: Rob Clark
---
include/drm/drmP.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index be776fb..8ba35c6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -809,7 +809,7 @@ struct drm_device {
struct drm_lo
A couple small OCD cleanups I noticed, which my other work-in-progress
propertification/atomic-ioctl patches are on top of. No dependency on
any atomic stuff, so might as well hit 'send'.
Rob Clark (2):
drm: fix indentation
drm: use mode_object_find helpers
drivers/gpu/drm/drm_crtc.c | 13 +
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 9 +
drivers/gpu/drm/msm/msm_kms.h| 23 ---
3 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/md
Add helper macros to iterate the current, or incoming set of planes
attached to a crtc. These helpers are only available for drivers
converted to use atomic-helpers.
Signed-off-by: Rob Clark
---
Documentation/DocBook/drm.tmpl | 1 +
include/drm/drm_atomic_helper.h | 28 +++
Chasing plane->state->crtc of planes that are *not* part of the same
atomic update is racy, making it incredibly awkward (or impossible) to
do something simple like iterate over all planes and figure out which
ones are attached to a crtc.
Solve this by adding a bitmask of currently attached planes
Resend the series.. I think danvet has first one queued up on
topic/core-stuff, second one updated from bikeshedding, adding
the third which converts over msm to use the new iterator macros
(now that mdp5 atomic stuff is on drm-next)
Rob Clark (3):
drm/atomic: track bitmask of planes attached to
This is dead code. We don't need to unbind here, we can just return
directly.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a17e2dd..b4f49ac 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers
On Tue, Nov 25, 2014 at 6:47 PM, Laurent Pinchart
wrote:
> From: Lars-Peter Clausen
>
> The drm_get_edid() function performs direct I2C accesses to read EDID
> blocks, assuming that the monitor DDC interface is directly connected to
> the I2C bus. It can't thus be used with HDMI encoders that con
On Tue, Nov 25, 2014 at 6:59 PM, Inki Dae wrote:
> On 2014ë
11ì 25ì¼ 22:08, Ajay kumar wrote:
>> Hi Inki,
>>
>> On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote:
>>> On 2014ë
11ì 25ì¼ 21:17, Ajay kumar wrote:
ping.
>>>
>>> You'd need to clean up clocks and fix up binding file.
https://bugzilla.kernel.org/show_bug.cgi?id=88911
Bug ID: 88911
Summary: Radeon: Patch "drm/radeon: fix speaker allocation
setup" causes kernel lockup
Product: Drivers
Version: 2.5
Kernel Version: 3.17.3
Hardware: All
Hi Inki,
On Tue, Nov 25, 2014 at 6:30 PM, Inki Dae wrote:
> On 2014ë
11ì 25ì¼ 21:17, Ajay kumar wrote:
>> ping.
>>
>
> You'd need to clean up clocks and fix up binding file. And then let's
> have review in more details. I wish that other people also give you
> their reviews.
Nice to hear. Ea
ping.
On Tue, Nov 11, 2014 at 10:08 PM, Ajay kumar wrote:
> Hi Inki,
>
> On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote:
>>
>> Hi,
>>
>> Fortunately, I could get the user manual for Exynos7420. Below are my
>> comments.
>>
>> Thanks,
>> Inki Dae
>>
>> On 2014ë
10ì 23ì¼ 01:34, Ajay kumar wro
Mark,
Am Donnerstag, 20. November 2014, 09:46:34 schrieb Mark Yao:
> This a series of patches is a DRM Driver for Rockchip Socs, add support
> for vop devices. Future patches will add additional encoders/connectors,
> such as eDP, HDMI.
>
> The basic "crtc" for rockchip is a "VOP" - Video Output
On Tue, Nov 25, 2014 at 12:14:21PM -0500, Alex Deucher wrote:
> The vbios image is available via ACPI prior to the OS taking over.
> IIRC, Matthew Garret fixed up the bootloader to fetch the vbios image
> prior to loading Linux so that it could be accessed after the OS
> loaded.
EFI rather than AC
From: Daniel Kurtz
A framebuffer gets committed to FIMD's default window like this:
exynos_drm_crtc_update()
exynos_plane_commit()
fimd_win_commit()
fimd_win_commit() programs BUF_START[0]. At each vblank, FIMD hardware
copies the value from BUF_START to BUF_START_S (BUF_START's shadow
re
The mqds array members are not freed when dqm is uninitialized.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_dev
On 11/25/2014 12:24 PM, Dan Carpenter wrote:
> The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
> error code is incorrect.
>
> Fixes: 45102048f77e ('amdkfd: Add process queue manager module')
> Signed-off-by: Dan Carpenter
>
Patch is:
Reviewed-by: Oded Gabbay
And applie
On Fri, Nov 21, 2014 at 03:28:31PM -0500, Rob Clark wrote:
> Chasing plane->state->crtc of planes that are *not* part of the same
> atomic update is racy, making it incredibly awkward (or impossible) to
> do something simple like iterate over all planes and figure out which
> ones are attached to a
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141125/46301a02/attachment.html>
From: Markus Elfring
Date: Tue, 25 Nov 2014 14:30:28 +0100
The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers
On 11/25/2014 12:21 PM, Dan Carpenter wrote:
> There is a typo here so the errors from kfd_bind_process_to_device()
> are not detected.
>
> Signed-off-by: Dan Carpenter
>
Patch is:
Reviewed-by: Oded Gabbay
And applied to my 3.19-next-wip tree
Oded
> diff --git a/drivers/gpu/drm/amd/amd
Reviewed-by: Ben Goz
-Original Message-
From: Gabbay, Oded
Sent: Tuesday, November 25, 2014 3:22 PM
To: dri-devel at lists.freedesktop.org
Cc: Goz, Ben
Subject: [PATCH] amdkfd: Fix memory leak of mqds on dqm fini
The mqds array members are not freed when dqm is uninitialized.
Signed-of
From: Markus Elfring
Date: Tue, 25 Nov 2014 13:44:20 +0100
The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On Fri, Nov 21, 2014 at 09:42:25PM +0100, Thierry Reding wrote:
> On Fri, Nov 21, 2014 at 09:38:40PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 21, 2014 at 03:28:32PM -0500, Rob Clark wrote:
> > > +#define drm_crtc_for_each_plane(plane, crtc) \
> > > + list_for_each_entry((plane), &(crtc)->dev->mo
On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > In order to prevent drivers from having to perform the same c
On Tue, Nov 25, 2014 at 12:57:04PM +0100, Thierry Reding wrote:
> On Tue, Nov 25, 2014 at 12:45:46PM +0100, Thierry Reding wrote:
> > On Tue, Nov 25, 2014 at 12:22:34PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> [...]
> > > > +/*
> > > > + *
The call to kernel_queue_uninit(NULL) will trigger a BUG(), and also the
error code is incorrect.
Fixes: 45102048f77e ('amdkfd: Add process queue manager module')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_pr
There is a typo here so the errors from kfd_bind_process_to_device()
are not detected.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 64c73ba..c5dd0ae 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b
at sound accurate and sufficient to you?
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/20141125/bbd487ee/attachment.sig>
/
>
> right above?
Sounds good.
>
> > +}
>
> Hm, given that this is used by helpers maybe place it into
> drm_atomic_helper.h?
It technically operates only on the drm_plane and drm_plane_state so
could be useful outside of helpers, but I have no objections to moving
it to the helpers.
> I'm also not too happy about the name, disabled
> doesn't clearly only mean the enable->disable transition. What about
> drm_atomic_plane_disabling instead, to make it clear we only care about
> the transition? After all your kerneldoc also uses continuous ("being
> disabled").
Okay, I can't think of anything better, so drm_atomic_plane_disabling()
it is.
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/20141125/9fad09a8/attachment.sig>
On Tue, Nov 25, 2014 at 12:09:46PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
>
> v2: pass old st
On Sat, Nov 22, 2014 at 2:30 PM, Wilfried Klaebe
wrote:
> At least Apple's MacBook Pro 8,2 booting EFI -> GRUB2 -> Linux (without
> BIOS emulation) seems to have no Radeon BIOS accessible via conventional
> means. Loading one via firmware system previously dumped (with
> "dd if=/dev/mem of=/lib/fi
From: Thierry Reding
The current state of CRTCs, planes and connectors currently leaks during
DRM driver ->unload() unless drivers explicitly clean it up. Since there
is nothing driver-specific about it, that cleanup can be done within the
DRM core.
Reviewed-by: Daniel Vetter
Signed-off-by: Thi
From: Thierry Reding
This header file makes use of a bunch of structures declared in the
drm_crtc.h header file. Include that to make sure the drm_atomic.h
header can be included standalone.
Signed-off-by: Thierry Reding
---
include/drm/drm_atomic.h | 2 ++
1 file changed, 2 insertions(+)
dif
From: Thierry Reding
This header uses a bunch of declarations from the drm/drm_crtc.h header,
so make sure to include that as well so that drm_atomic_helper.h can be
included standalone.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
include/drm/drm_atomic_helper.h | 2 ++
1 fil
From: Thierry Reding
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.
v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled pla
From: Thierry Reding
The plane helpers aren't pulled into the DocBook yet, so these weren't
noticed.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
include/drm/drm_plane_helper.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_plane_helper.h b/include/drm
From: Thierry Reding
In most situations it will be useful to have the old state passed to the
->atomic_update() callback. For example if a plane is being disabled the
new state's .crtc field will be NULL, but some drivers may rely on this
field to program the CRTCs registers.
v2: rename variable
The drm_prime_pages_to_sg() function never returns NULL pointers, only
error pointers and valid pointers.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/udl/udl_dmabuf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/udl
Fixes dmabuf export failure with -E_NOMEM when the page is not mapped.
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/udl/udl_dmabuf.c | 7 +--
drivers/gpu/drm/udl/udl_drv.h| 2 ++
drivers/gpu/drm/udl/udl_gem.c| 4 ++--
3 files changed, 9 insertions(+
Hi Andreas,
On Mon, Nov 24, 2014 at 8:35 PM, Andreas Färber wrote:
> Hi,
>
> Am 24.11.2014 um 11:05 schrieb Javier Martinez Canillas:
>> On 11/21/2014 09:57 PM, Javier Martinez Canillas wrote:
>>> On 11/21/2014 06:32 PM, Ajay kumar wrote:
I have rebased my bridge series on top of linux-next
https://bugzilla.kernel.org/show_bug.cgi?id=85491
--- Comment #15 from Marek ---
Hi, I tried also Kubuntu with new kernel (newer than 3.15) and it was not
working (previous versions of kernel were working also with Kubuntu) so it is
not Fedora specific problem. The result of bisection is that the
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/a407dd83/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/73f47082/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/a727496b/attachment.html>
Hi Laurent,
On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the review.
>
> On Friday 07 November 2014 10:19:14 Daniel Vetter wrote:
> > On Fri, Nov 07, 2014 at 08:25:32AM +0200, Laurent Pinchart wrote:
> > > Hi Dave,
> > >
> > > Here's a pull re
Hey,
Op 22-11-14 om 21:16 schreef Michael Marineau:
> On Nov 22, 2014 11:45 AM, "Michael Marineau" wrote:
>>
>> On Nov 22, 2014 8:56 AM, "Maarten Lankhorst" <
> maarten.lankhorst at canonical.com> wrote:
>>> Hey,
>>>
>>> Op 22-11-14 om 01:19 schreef Michael Marineau:
On Thu, Nov 20, 2014 at
The function vmw_master_check() might return -ERESTARTSYS if there is a
signal pending, indicating that the IOCTL should be rerun, potentially from
user-space. At that point we shouldn't print out an error message since that
is not an error condition. In short, avoid bloating the kernel log when a
ug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/8672c8a3/attachment-0001.html>
s bug has been marked as a duplicate of bug 86432 ***
--
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/20141125/c4a0f062/attachment.html>
vel/attachments/20141125/33ea60f7/attachment.html>
On 25 November 2014 at 00:18, Lars-Peter Clausen wrote:
> On 11/24/2014 03:00 PM, Laurent Pinchart wrote:
>>
>> Hi Daniel,
>>
>> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm:
>> Decouple EDID parsing from I2C adapter" patch available at
>> git://linuxtv.org/pinchartl/f
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/d87736e9/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88781
--- Comment #2 from Michel Dänzer ---
Duplicate of bug 88481.
--
You are receiving this mail because:
You are watching the assignee of the bug.
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/7b3aa2ff/attachment.html>
nsumer of this anywhere?
>>
>> - ajax
>>
>>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141125/b72310a0/attachment.html>
64 matches
Mail list logo
