On Wed, Jul 29, 2015 at 11:15:23PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wednesday 29 July 2015 08:32:43 Daniel Vetter wrote:
> > With
> >
> > commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> > Author: Daniel Vetter
> > Date: Thu Jul 9 23:44:28 2015
2015-07-29 ì¤í 9:46ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote:
>> On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
>>> On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
On Mon, Jul 13, 2015 at 05:35:15PM +0900,
IM DM ZM OM UM PM ]
--
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/20150730/39defecf/attachment-0001.html>
> I've discussed drm props and ABI requirements a bit with Dave on irc.
> In the past we've been pretty lax with properties since connector
> properties are mostly meant for end-users to set manually, so not
> really much point in standardizing and treating them like ABI. But now
> we have props fo
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150730/f0196543/attachment.html>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
5677d67ae394 ("drm: Stop resetting connector state to unknown")
from Linus' tree and commit:
1c473be11958 ("drm: Fixup locking WARNINGs in drm_mode_config_reset")
from th
Hi Gustavo,
On 2015ë
07ì 30ì¼ 05:11, Gustavo Padovan wrote:
> Hi Inki,
>
> Any comments about this series?
Will review all of them. Now we are reviewing fix-up and clean-up patches.
Thanks,
Inki Dae
>
> Thanks,
>
> Gustavo
>
> 2015-07-16 Gustavo Padovan :
>
>> From: Gusta
On Thu, Jul 30, 2015 at 4:43 AM, Dave Airlie wrote:
> (are there any closed source compositors?)
Afaik everyone's hwc driver for surface flinger is a blob and only
code-dropped for nexus devices since google requires that. So can't
really use those one-offs to develop new stuff since it's a fork
This will cause drm_atomic_helper_page_flip and drm_mode_atomic_ioctl to
fail with -EINVAL if a event is requested on a inactive crtc.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d719ce0b10a0..679577e8e02d 100644
--- a/driver
This may cause a failure when atomic_free is called asynchronously.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3efd91c0c6cb..d719ce0b10a0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -153,8
From: Zhao Junwang
Set CRTC, planes and connectors to use the default implementations
from the atomic helper library.
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b
From: Zhao Junwang
Now that phase 1 and 2 are complete we can switch the
update/disable_plane callbacks to their atomic version
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_main.c |3 +++
drivers/gpu/drm/cirrus/cirrus_mode.c |4 ++--
2 files changed, 5 insertions(+), 2
From: Zhao Junwang
Run dpms operations through the atomic interfaces. This basically
removes the .dpms() callback from encoders and crtcs and use .disable
and .enable to turn the crtc on and off.
use drm_atomic_helper_connector_dpms for connector
Signed-off-by: Zhao Junwang
---
drivers/gpu/dr
From: Zhao Junwang
This patch series aim to convert DRM_CIRRUS to atomic mode-setting.
This mostly reference my previous patch series on DRM_BOCHS and
Gustavo Padovan;s patch series on drm/exynos.
Zhao Junwang (7):
drm/cirrus: phase 1 - use the transitional helpers
drm/cirrus: phase 2: wire
From: Zhao Junwang
Since driver is now fully atomic, we should add DRIVER_ATOMIC to
.driver_features
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/dr
From: Zhao Junwang
Now that phase 1 and phase 2 are completed, switch .set_config
helper to use the atomic one.
-stop looking legacy crtc->primary->fb, instead we should use
crtc->primary->state->fb
.prepare() calls are no more needed, remove them
.mode_set() and .mode_set_base are no longer ne
From: Zhao Junwang
-register driver's own primary plane
-use drm_crtc_init_with_planes instead drm_crtc_init
-the new atomic_infrastructure needs ->mode_set_nofb callback
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/cirrus/cirrus_drv.c |1 -
drivers/gpu/drm/cirrus/cirrus_drv.h |3
From: Zhao Junwang
when the first modeset calls prepare_fb, bo->pin_count change from
0 to 1, then the second modeset with the same fb, that should set
bo->pin_count to 2, and then when cleanup_fb was called, bo->pin_count
should be 2 to 1.
But in the cirrus_bo_pin, it will set bo->pin_count = 1
On 30 July 2015 at 15:18, Linus Torvalds
wrote:
> On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>>
>> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
>
> You didn't catch enough of the code line to decode the code, but it's
> early enough in drm_crtc_index() (just five bytes in) that
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/fdb7b92e/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/eb0c57aa/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/950ac901/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/edd7fc3f/attachment.html>
dri-devel/attachments/20150730/ef8c4818/attachment-0001.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/d0e5484d/attachment.html>
ts.freedesktop.org/archives/dri-devel/attachments/20150730/a3450bf1/attachment.html>
nts/20150730/7fa5fb0c/attachment.html>
Hi,
On 27-07-15 17:52, Hans de Goede wrote:
> Slightly offtopic:
>
> I decided to be bold and try gnome-shell on the nv46 with msi disabled,
> which sofar was a guaranteed way to freeze the system, and it now works
> somewhat (latest kernel, ddx and mesa). I see something which shows
> horizontal
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/80b64b8a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/b700d7c9/attachment-0001.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/20150730/4ae50a58/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150730/56152a34/attachment.html>
vel/attachments/20150730/1ed4ce64/attachment.html>
Is this happening with libdrm 2.4.60? If so, that's a known
(user-side) issue and should be fixed by using any version but that
one.
On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue
wrote:
> Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
> of the browser and current
On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5b59d5ad7d1c..aac212297b49 10
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
What's the freedesktop bugzilla # for reference?
Regards,
Peter Hurley
> On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
What's the freedesktop bugzilla # for reference?
Regards,
Peter Hurley
> On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'
On Thu, Jul 30, 2015 at 10:46 AM, Peter Hurley
wrote:
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
> What's the freedesktop bugzilla # for reference?
I
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
wrote:
> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>
>> On 30/07/15 15:49, Peter Hurley wrote:
>>>
>>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known
(user-side) issue and sh
On 30 July 2015 at 16:02, Ilia Mirkin wrote:
> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
> wrote:
>> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>>
>>> On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>
> Is this happening with libdrm 2.
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> but I couldn't test them yet since no dp mst here and I didn't find
> anything that would ship faster than 1-2 weeks yet. I'll try to get some
> other people h
On Thu, Jul 30, 2015 at 5:32 PM, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
>> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
>> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
>> > 1 file changed, 5 insertions(+), 3 deletions(-)
>>
On Thu, 30 Jul 2015 17:32:28 +0200,
Theodore Ts'o wrote:
>
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > > 1 file changed, 5 insertions(+), 3 deletion
- Ted
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/gzip
Size: 25784 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/5b475051/attachment-0002.bin&g
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> > I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> > but I couldn't test them yet since no dp mst here and I didn't find
> > anything that woul
Op 29-07-15 om 14:01 schreef Daniel Vetter:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers already add all planes on a crtc when a modeset
> happen
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/01355738/attachment.html>
ang.
I've attached a small code which reproduce the hang.
--
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/20150730/f3c1e8
On Thu, Jul 30, 2015 at 8:57 AM, Takashi Iwai wrote:
> On Thu, 30 Jul 2015 17:32:28 +0200,
> Theodore Ts'o wrote:
>>
>> BTW, is there any chance that I can suspend my laptop, and then move
>> it from my docking station at home (where I have a Dell 30" display)
>> to my docking station at work (whe
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
> On 30 July 2015 at 16:02, Ilia Mirkin wrote:
>> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
>> wrote:
>>> On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
>
> On 07/3
On 30/07/15 15:12, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
>
Yes that's my version 2.4.60.
On 30/07/15 15:52, Bryan O'Donoghue wrote:
> On 30/07/15 15:49, Peter Hurley wrote:
>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>>> Is this happening with libdrm 2.4.60? If so, that's a known
>>> (user-side) issue and should be fixed by using any version but that
>>> one.
>>
>> What's the freedes
Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version
of the browser and current tip-of-tree 86ea07ca846a I get the following
error message followed by a lock-up of X.
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list
nouveau E[chrome[2737]] validate_
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150730/08a76dbb/attachment-0001.html>
On 30/07/15 15:49, Peter Hurley wrote:
> On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>> Is this happening with libdrm 2.4.60? If so, that's a known
>> (user-side) issue and should be fixed by using any version but that
>> one.
>
> What's the freedesktop bugzilla # for reference?
>
> Regards,
> Peter
gma500 expects the OpRegion to be cached (i.e. not __iomem), so
explicitly map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams
---
drivers/gpu/drm/gma500/opregion.c |8
On 30/07/15 16:02, Ilia Mirkin wrote:
>
> That's unfortunate. I know next to nothing about debian/ubuntu or how
> they do versions or how to even build packages for them. But they're
> big distros, presumably they have support teams of some sort, perhaps
> they can help you.
>
> Assuming that switc
Changes since v2 [1]:
1/ Move arch_memremap() and arch_memunmap() out of line (Christoph)
2/ Convert region_is_ram() to region_intersects() and define an enum for
its 3 return values. (Luis)
3/ Fix gma500 and i915 to explicitly use cached mappings and clean up
the __iomem usage. (Daniel)
i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx at lists.freedesktop.org
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Signed-off-b
The retina MacBook Pro uses an eDP panel and a gmux controller to switch
the panel between its two GPUs. Unfortunately it seems that it cannot
switch the AUX channel separately from the main link.
But we can emulate switching of DDC/AUX in software by using the active
client as a proxy to talk to
61 matches
Mail list logo
