On (03/14/16 17:40), Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160311:
>
> The vfs tree gained a conflict against Linus' tree. I also applied a
> patch for a known runtime bug.
>
> The tip tree gained a conflict against the mips tree.
>
> The aio tree still had a build failure so I
ri-devel/attachments/20160315/e4358c4f/attachment.html>
On 11.03.2016 23:38, Christian König wrote:
> From: Christian König
>
> We somehow forgot the flags paramter in amdgpu_create_bo_from_user_mem(). Fix
> that with a new function.
>
> Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer |
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/47c0ce82/attachment.sig>
On 08.03.2016 11:54, Nicolai Hähnle wrote:
> On 05.03.2016 16:24, Christian König wrote:
>> just an educated guess, but I think the problem is simply that kernel
>> 3.14 doesn't yet contain the code so that radeon_fence_get() can safely
>> called with a NULL pointer.
>>
>> So the backport of Nico
dri-devel/attachments/20160315/a8347a44/attachment.html>
On Mon, Mar 14, 2016 at 02:37:44PM +0100, Bastien Nocera wrote:
> Do you have references for the i915 runtime PM support, a bugzilla or
> mailing-list thread?
i915.ko has runtime PM support, it's just not yet enabled by default due
to some funky corner cases. If you enable it you might hit a bunch
Make sure drm clients (mostly the X server) are communicated the current
layout when switched in.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/
Enables using multiple framebuffers. For legacy display units,
explicit crtc placement is not supported due to hardware limitations.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
2 files ch
Base the cursor position on the coordinate of the crtc origin in the
gui coordinate system rather than in the framebuffer coordinate system.
With explicit placement, these may differ (for example when two crtcs
scan out of the same framebuffer location).
Signed-off-by: Thomas Hellstrom
Reviewed-
X re-export these values as 32-bit, so they end up as -1.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8451400..a27b2e0 100644
--- a/drivers/gpu
Just like for screen objects, make sure we use only a single framebuffer
for implicit placement.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
Introduced by qxl, add these properties as a generic way to tell a
display manager about the GUI layout.
Also add the hotplug_mode_update_property which advises display managers to
reread the mode list on a hotplug event.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drive
Preparation for supporting explicit fbs for screen objects and screen
targets.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 92 ++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
From: Charmaine Lee
Add support for DXGenMips command.
Signed-off-by: Charmaine Lee
Reviewed-by: Sinclair Yeh
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 ++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 7 +++
drivers/gpu/drm/v
If there are no cliprects for a particular crtc, an invalid command would
have been generated. If that's the case, instead ditch the generated
command sequence.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 15 +++
1 file change
Gnome-Shell / Wayland assumes that page-flips can be done on a crtc
regardless of framebuffer size and the crtc position within the
framebuffer.
Therefore rework the screen target code to correctly handle changes in
framebuffer size and content_fb_type. Also make sure that we update
the screen tar
On vmware there is a daemon telling the KMS system about the GUI layout.
Typically it talks to the X server but in the absence of an X server or if
there are multiple, it wants to talk directly to the vmwgfx kernel module.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |
For page flips the framebuffer may be much larger than the crtc
scanout area and may be attached to multiple crtcs.
When flipping a crtc, make sure we dirty only that crtc's area of the
framebuffer.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.
signals availability of resolutionKMS support
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Reviewed-by: Sinclar Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/
On Mon, Mar 14, 2016 at 04:18:43PM +0100, Lucas Stach wrote:
> Am Montag, den 14.03.2016, 15:09 + schrieb Russell King - ARM Linux:
> > On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote:
> > > I guess not using the offset on MC10 will also allow you to enable TS on
> > > those parts?
On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > > + Â Â Â Â struct
On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> X re-export these values as 32-bit, so they end up as -1.
>
> Signed-off-by: Thomas Hellstrom
Imo that's a bug in X, and X should clamp the range itself. Not the
kernel. Prop abi is pretty consistent that its all 64bit values.
-
On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
>> X re-export these values as 32-bit, so they end up as -1.
>>
>> Signed-off-by: Thomas Hellstrom
> Imo that's a bug in X, and X should clamp the range itself. Not the
> kernel. Prop a
On Mon, Mar 14, 2016 at 05:21:10PM -0300, Tiago Vignatti wrote:
> On 03/05/2016 06:34 AM, Daniel Vetter wrote:
> >On Mon, Feb 29, 2016 at 03:02:09PM +, Chris Wilson wrote:
> >>On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> >>>On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wil
On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
> On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> > On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> >> X re-export these values as 32-bit, so they end up as -1.
> >>
> >> Signed-off-by: Thomas Hellstrom
> > Imo th
On Tue, Mar 15, 2016 at 10:23:04AM +0100, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
> > On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> > > On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> > >> X re-export these values as 32-bit, so t
On 03/15/2016 10:23 AM, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
>> On 03/15/2016 09:14 AM, Daniel Vetter wrote:
>>> On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
X re-export these values as 32-bit, so they end up as -1.
Hi Gustavo,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20160315]
[cannot apply to v4.5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Gustavo
>
> I guess that's only useful until we get runtime PM support.
For the discrete GPUs on regular laptops we have runtime PM support for
powerdown already. Some newer laptops need a bit of work in the PCIE layer
but for most things we have it covered. The known broken ones are Apple
laptops. If the
Hi Marek,
On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
wrote:
> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
> side-effect of this change is a switch from bitmap-based IO address space
> mana
exynos_plane_mode_set should use adjusted_mode from the same atomic state as
plane state. Otherwise it will result in incorrect behavior in case
crtc mode changes.
The patch fixes bug with black console framebuffer in case of command mode
panels.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm
Fbdev code should be compiled only if CONFIG_DRM_FBDEV_EMULATION option
is enabled. The patch fixes exynos-drm code trying to manipulate
fbdev data which is not initialized in case CONFIG_DRM_FBDEV_EMULATION
is disabled.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/Makefile
Hi Daniel,
Am Mittwoch, den 09.03.2016, 22:23 +0800 schrieb Daniel Kurtz:
> Hi Philipp, Jie,
>
> Some small comments.
> Nothing that can't be fixed after merging if you prefer.
>
> On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel
> wrote:
[...]
> > +static int mtk_dpi_power_on(struct mtk_dpi *dpi,
Hi Daniel,
Am Mittwoch, den 09.03.2016, 22:07 +0800 schrieb Daniel Kurtz:
> Hi Philipp, CK,
>
> Some small comments.
> Nothing that couldn't be addressed after merging, if you prefer.
>
> On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel
> wrote:
[...]
> > +static int mtk_dsi_poweron(struct mtk_ds
Hi Magnus,
On 15/03/16 11:18, Magnus Damm wrote:
> Hi Marek,
>
> On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
> wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this
Hello,
On 2016-03-15 12:18, Magnus Damm wrote:
> Hi Marek,
>
> On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
> wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this ch
On Tue, Mar 15, 2016 at 7:49 PM, Philipp Zabel
wrote:
>
> Hi Daniel,
>
> Am Mittwoch, den 09.03.2016, 22:07 +0800 schrieb Daniel Kurtz:
> > Hi Philipp, CK,
> >
> > Some small comments.
> > Nothing that couldn't be addressed after merging, if you prefer.
> >
> > On Tue, Mar 8, 2016 at 9:27 PM, Phi
Hi Dave,
Just a small fix for uninitialized variable. Hoping you could squeeze it into
the merge window's pull request, but -rc2 is perfectly fine as well.
Thanks,
Oded
The following changes since commit 211afd577a186e18d3eece543c6767420d6f6737:
Merge tag 'drm-vc4-next-2016-03-14' of github
Hi Marek, Arnd,
On 19/02/16 10:30, Arnd Bergmann wrote:
> On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this change
DRM core provide helper to access crtc state.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/drm_atomic_helper.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2b430b0..e1cbba6
DRM core provide helper to access crtc state.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
in
On Tue, 15 Mar 2016 13:46:28 +0100
Andrzej Hajda wrote:
> DRM core provide helper to access crtc state.
>
> Signed-off-by: Andrzej Hajda
Acked-by: Boris Brezillon
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
The recent changes which removed platform data support from panels &
encoders had a few mistakes, causing probes of DVI connector and DSI
command mode panels to fail every time due to missing '!'. Fix the
if()s.
Signed-off-by: Tomi Valkeinen
Reported-by: Laurent Pinchart
---
Hi Dave,
Can you a
On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> On Tue, 15 Mar 2016 13:46:28 +0100
> Andrzej Hajda wrote:
>
> > DRM core provide helper to access crtc state.
> >
> > Signed-off-by: Andrzej Hajda
>
> Acked-by: Boris Brezillon
Want me to pull this in through drm-misc?
-Danie
On Tue, 15 Mar 2016 14:07:46 +0100
Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> > On Tue, 15 Mar 2016 13:46:28 +0100
> > Andrzej Hajda wrote:
> >
> > > DRM core provide helper to access crtc state.
> > >
> > > Signed-off-by: Andrzej Hajda
> >
> >
On Tue, Mar 15, 2016 at 02:08:05PM +0100, Boris Brezillon wrote:
> On Tue, 15 Mar 2016 14:07:46 +0100
> Daniel Vetter wrote:
>
> > On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> > > On Tue, 15 Mar 2016 13:46:28 +0100
> > > Andrzej Hajda wrote:
> > >
> > > > DRM core provide
Hi Mika,
On Mon, Mar 14, 2016 at 11:43:35AM +0200, Mika Westerberg wrote:
> On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> > On 11 March 2016 at 23:45, Rafael J. Wysocki wrote:
> > > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> > >> On Thu, Mar 10, 2016 at 09:57:
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/b3c78ad1/attachment-0001.html>
Hello all,
I wanted to ask if there has been any progress since last time. Also I
was wondering if it would be feasible to just fixup the IPP API and then
go from there (instead of trying to do automagic behind the scenes).
Marek has pointed out that currently the API has some major flaws and
the
On Tue, Mar 15, 2016 at 01:46:00PM +0100, Andrzej Hajda wrote:
> DRM core provide helper to access crtc state.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
>
On Tue, Mar 15, 2016 at 03:24:46PM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> > >
> > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > > >
> > > > On Fri,
Hi Alex,
On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> Is there any reason to make use of the mux?
Performance (lower latency => no need for framebuffer writes over PCIe),
improved battery life (no need to use 2 GPUs simultaneously).
Technically you can't just ignore that the m
From: Nicolai Hähnle
[Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
an additional NULL pointer guard that is required for kernels 3.17 and older.
To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
use common fence implementation for fenc
...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/fb7e9263/attachment.html>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/a3236ac0/attachment.html>
On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner wrote:
> Hi Alex,
>
> On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
>> Is there any reason to make use of the mux?
>
> Performance (lower latency => no need for framebuffer writes over PCIe),
> improved battery life (no need to use 2 GP
https://bugzilla.kernel.org/show_bug.cgi?id=114711
Bug ID: 114711
Summary: ubsan: "shift exponent 32 is too large" in
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c:167:16
Product: Drivers
Version: 2.5
Kernel Version: 4.5.0
Hi Alex,
On Tue, Mar 15, 2016 at 02:33:56PM -0400, Alex Deucher wrote:
> On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner wrote:
> > On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> >> Is there any reason to make use of the mux?
> >
> > Performance (lower latency => no need for frameb
Hi Dave,
On Thu, Mar 10, 2016 at 08:04:26AM +1000, Dave Airlie wrote:
> On 10 March 2016 at 00:40, Lukas Wunner wrote:
> > On Wed, Mar 09, 2016 at 04:14:05PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This fixes GPU auto powerdown on the Lenovo W541,
> >> since we advertise Windo
)
from this type of email.
Meetup Inc. (http://www.meetup.com/), POB 4668 #37895 New York NY USA 10163
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/87b68988/attachment.html>
On Tue, 2016-03-15 at 21:10 +1000, Dave Airlie wrote:
> >
> >
> > I guess that's only useful until we get runtime PM support.
> For the discrete GPUs on regular laptops we have runtime PM support
> for
> powerdown already. Some newer laptops need a bit of work in the PCIE
> layer
> but for most t
On Tue, Mar 15, 2016 at 02:39:58PM +0100, Lukas Wunner wrote:
> Hi Mika,
>
> On Mon, Mar 14, 2016 at 11:43:35AM +0200, Mika Westerberg wrote:
> > On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> > > On 11 March 2016 at 23:45, Rafael J. Wysocki wrote:
> > > > On Friday, March 11, 201
Hi Daniel,
On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> >
> > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > >
> > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > >
> > > > +stati
On 2016å¹´03æ14æ¥ 21:35, Tomeu Vizoso wrote:
> On 2 December 2014 at 10:15, Mark Yao wrote:
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> new file mode 100644
>> index 000..e7ca25b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/r
On (03/15/16 07:43), Wolfram Sang wrote:
> > Hello,
> >
> > I'm seeing a bunch of warnings and errors
>
> I pushed the fix to my for-next branch yesterday. Sorry for the fuzz!
no prob, thanks!
-ss
67 matches
Mail list logo
