ong register when setting up the ACR packet control.
--
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/20150601/c88ee6f8/attachment.html>
All users of async updates seem to clear clear crtc_state->event
correctly, so move destroying vblank event to crtc_destroy_state.
This is better than manually free'ing it in the atomic ioctl, since
this code seems to do it wrong.
While we're at it handle -EDEADLK from atomic_commit correctly,
be
Hi Darren,
On 01-06-15 19:41, Darren Hart wrote:
> On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> I'm working on cleaning up the currently somewhat convoluted logic to
>> select which backlight interfaces to register on x86 systems, see:
>> http://lists.freedesktop
HD 4000 series]
--
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/20150601/8383bc4f/attachment.html>
On Mon, Jun 01, 2015 at 11:25:05AM +0200, Hans de Goede wrote:
> Hi All,
>
> I'm working on cleaning up the currently somewhat convoluted logic to
> select which backlight interfaces to register on x86 systems, see:
> http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html
>
> F
Hi,
On 1 June 2015 at 19:12, Maarten Lankhorst
wrote:
> drm_framebuffer_reference(new_fb);
> plane->fb = new_fb;
> plane->crtc = plane->state->crtc;
> + drm_framebuffer_unreference(plane->old_fb)
Hello,
as pointed out in [1] before, this gives me an kernel oops during boot.
With best wishes,
Tobias
[1] http://www.spinics.net/lists/linux-samsung-soc/msg44736.html
On 2015-06-01 17:04, Gustavo Padovan wrote:
> From: Joonyoung Shim
>
> Handle changes by removing copy from adjusted_mode t
Some targets (eg: msm8994) use the pinctrl framework to configure
interface pins. This change adds support for initialization and
pinctrl active/sleep state control for the HDMI driver.
Signed-off-by: Stephane Viau
---
v2:
- Add devicetree binding documentation for pinctrl property [Ivan]
- Use
--
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/20150601/67f1f193/attachment.html>
On 06/01/2015 02:40 PM, Jan Kara wrote:
> On Thu 28-05-15 16:24:02, Andrew Morton wrote:
>> On Wed, 13 May 2015 15:08:08 +0200 Jan Kara wrote:
>>
>>> Provide new function get_vaddr_frames(). This function maps virtual
>>> addresses from given start and fills given array with page frame numbers of
you be able to post an API trace of one of the games that is locking up?
--
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/20150601/ca7bb63a/attachment-0001.html>
On Thu 28-05-15 16:24:02, Andrew Morton wrote:
> On Wed, 13 May 2015 15:08:08 +0200 Jan Kara wrote:
>
> > Provide new function get_vaddr_frames(). This function maps virtual
> > addresses from given start and fills given array with page frame numbers of
> > the corresponding pages. If given star
ad you know the regression happened in the 3.15 kernel
cycle.
--
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/20150601/419de660/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150601/09580d40/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150601/e8610aaa/attachment.html>
eiving 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/20150601/62741ebf/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150601/b25734cd/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150601/edb807ca/attachment.html>
testing problem enormously.
--
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/20150601/934df4e2/attachment-0001.html>
org/archives/dri-devel/attachments/20150601/294345bb/attachment.html>
On 27.05.15 14:05, Laurent Pinchart wrote:
> Even though 'compatability' has a dedicated entry in the Wiktionary,
> it's listed as 'Mispelling of compatibility'. Fix it.
>
> Signed-off-by: Laurent Pinchart
> ---
> arch/metag/include/asm/elf.h | 2 +-
> arch/powerpc/kvm/book3s.c
On Tue, May 19, 2015 at 08:33:59PM +0900, Alexandre Courbot wrote:
> On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote:
> >On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote:
> >>dma_alloc_coherent() can return memory in the vmalloc range.
> >>virt_to_page() cannot handle such addr
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Additional to that "linux/types.h" is not part of the uapi as far as
> I know, so including it in a header which is part of the uapi should
> be forbidden.
linux/types.h is part of uapi. See usr/include after 'make headers_install
From: Gustavo Padovan
To follow more closely the new atomic API we split the dpms()
helper into the enable() and disable() helper to get exactly the
same semantics.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 87 ++
drivers/gpu/dr
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
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 -
From: Gustavo Padovan
Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms
From: Gustavo Padovan
exynos needs to update planes with the crtc enabled (mainly for the FIMD
case) so this specific atomic commit changes the order of
drm_atomic_helper_commit_modeset_enables() and
drm_atomic_helper_commit_planes() to commit planes after we enable crtc
and encoders.
Signed-off
From: Gustavo Padovan
This is a preparation commit to move exynos_drm_crtc_disable() together
with the future exynos_drm_crtc_enable() that will come from the split of
exynos_drm_crtc_dpms() callback.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 36
From: Gustavo Padovan
Everything starts disabled so we don't really need to disable anything.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/dr
From: Gustavo Padovan
Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.
v2: remove unused exynos_drm_crtc
v3: fix checkpatch error (reported by Joonyoung)
Signed-off-by: Gustavo Padovan
Rev
From: Gustavo Padovan
PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.
v2: Add .atomic_begin() step to handle the vblank part we removed from
exynos page_flip code.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
From: Gustavo Padovan
Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.
v2: also remove .prepare() callback
v3: remove .mode_set() and .mode_set_base() and encoder's
.prepare() callbacks
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by:
From: Gustavo Padovan
Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
drivers/gpu/drm/exyno
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file change
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/b
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
v2: remove WARN_ON(!crtc->state) from mode_set_nofb
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/dr
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
Tested-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_plane.c
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
From: Joonyoung Shim
Handle changes by removing copy from adjusted_mode to mode as using
adjusted_mode of crtc_state.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_pl
From: Joonyoung Shim
The exynos_update_plane function needs 16.16 fixed point source data.
Signed-off-by: Joonyoung Shim
Reviewed-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
Hi Joonyoung,
2015-06-01 Joonyoung Shim :
> On 05/30/2015 12:57 AM, Gustavo Padovan wrote:
> > Hi Joonyoung,
> >
> > 2015-05-29 Joonyoung Shim :
> >
> >> Handle changes by removing copy from adjusted_mode to mode as using
> >> adjusted_mode of crtc_state.
> >>
> >> Signed-off-by: Joonyoung Shim
On 05/30/2015 10:20 PM, Emil Velikov wrote:
> On 29 May 2015 at 07:50, Joonyoung Shim wrote:
>> On 05/29/2015 12:51 AM, Emil Velikov wrote:
>>> Seems like I'm either too subtle and/or too stingy earlier.
>>>
>>> If drmAvailable() returns false, we have two options:
>>> - opt for the old-schoold (
On 05/30/2015 10:02 PM, Emil Velikov wrote:
> On 29 May 2015 at 07:34, Joonyoung Shim wrote:
>> On 05/28/2015 10:02 PM, Emil Velikov wrote:
>>> On 28 May 2015 at 00:56, Joonyoung Shim wrote:
The build error is introduced by commit fde496917682 ("Add device
enumeration interface (v4)") i
On 05/30/2015 06:33 AM, Gustavo Padovan wrote:
> 2015-05-29 Joonyoung Shim :
>
>> On 05/29/2015 06:36 AM, Gustavo Padovan wrote:
>>> 2015-05-28 Joonyoung Shim :
>>>
On 05/28/2015 05:24 PM, Joonyoung Shim wrote:
> On 05/28/2015 02:39 PM, Inki Dae wrote:
>> Hi Gustavo,
>>
>> On
On 05/30/2015 12:57 AM, Gustavo Padovan wrote:
> Hi Joonyoung,
>
> 2015-05-29 Joonyoung Shim :
>
>> Handle changes by removing copy from adjusted_mode to mode as using
>> adjusted_mode of crtc_state.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> This is based on a patch "[PATCH v9 04/18] drm/exy
On 01.06.2015 11:38, Russell King - ARM Linux wrote:
> On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:
>> Yeah, completely agree with Linus on the visibility problem and that's
>> exactly the reason why we don't include in the kernel header and
>> expect userspace to define the I
||
--
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/20150601/28bcfe14/attachment.html>
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which
acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.
The unregistering of the acpi video bus event listener usually is
undesirable, which
Hi All,
I'm working on cleaning up the currently somewhat convoluted logic to
select which backlight interfaces to register on x86 systems, see:
http://lists.freedesktop.org/archives/dri-devel/2014-December/074687.html
For a rought outline (details will change in the actual patch-set).
These 3 p
-
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/20150601/c9a08b93/attachment.html>
On Mon, Jun 1, 2015 at 11:08 AM, Christian König
wrote:
> Yeah, completely agree with Linus on the visibility problem and that's
> exactly the reason why we don't include in the kernel header and
> expect userspace to define the ISO types somewhere.
>
> But using the types from "include/linux/ty
Yeah, completely agree with Linus on the visibility problem and that's
exactly the reason why we don't include in the kernel header
and expect userspace to define the ISO types somewhere.
But using the types from "include/linux/types.h" and especially
including it into the uapi headers doesn't
On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:
> Yeah, completely agree with Linus on the visibility problem and that's
> exactly the reason why we don't include in the kernel header and
> expect userspace to define the ISO types somewhere.
>
> But using the types from "include
On 30.05.2015 18:46, Russell King - ARM Linux wrote:
> On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote:
>> Fixes userspace compilation error:
>>
>> drm/exynos_drm.h:30:2: error: unknown type name âuint64_tâ
>>
>> Signed-off-by: Mikko Rapeli
> This is another thing which we need to
Using the latest kernel 4.1.0-rc6, I try to get MST running with
an Asus 4k Display. The Display only show's NoSignal.
Did anyone get a MST display running?
This is the output of dmesg with drm.debug=4 when setting mode to
1920x2160 on both parts of the DP MST output.
[ 104.758484] [drm:radeon
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Using types that differs on 32-bit and 64-bit machines for a kernel
> interface is indeed a rather bad idea. This not only includes longs, but
> pointers as well.
[cut standard stdint.h types argument which we've heard before]
Yo
Hi,
> This looks reasonable to me.
> Would you be willing to be listed in
> MAINTAINERS and review patches for this driver?
Yes, that is fine.
cheers,
Gerd
This fixes some regressions in i915 when converting to atomic.
set_config failed with -EINVAL, and I received the following warning
in dmesg:
[drm:drm_atomic_crtc_check] [CRTC:20] active without enabled
Solve this by clearing active when a crtc is disabled.
Because crtc_state->enable implies tha
Hi Dave,
Another pull request of amdkfd for 4.2
drm-amdkfd-next-2015-06-01:
- Add the H/W debugger support module, including new IOCTLs to:
- register/unregister a process as a debugged process
- Set address watch-point in the debugged process's GPU kernel
- Do a wave control operation in
't already fixed there.
Regards,
Christian.
--
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/20150601/10cba3c2/attachment.html>
Hello,
I have the pleasure to announce that the X.org Developer Conference 2015
will be held in Toronto, Canada from September 16 to September 18. The
venue is located at Seneca College's campus at York University.
The official page for the event is http://www.x.org/wiki/Events/XDC2015
while the
ATM.
--
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/20150601/7185d349/attachment-0001.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150601/d0e4aa66/attachment.html>
Hi Emil,
Here is the pseudo code:
int drmGetPciDevices(drmPciDevicePtr devSet, uint16_t vendorId)
{
If(devSet == NULL && vendorId == 0)
Probe all the graphic device and return the number of it
Else If(devSet != NULL && vendorId != 0)
Probe the specif
> Jammy or Frank might be able to provide some pseudo code in the interim.
I think the requirement here is quite simple. We would like to have some
interface to enumerate the GPU devices on the system, and select some specific
device for different purposes (i.e, rendering, computing, displaying,
68 matches
Mail list logo
