||1440dbd79213a
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/873fa136/attachment.html>
bed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/d15beebc/attachment.html>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/2a5ff0b1/attachment-0001.gz>
On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> Hi,
>
> I can relatively easily reproduce this bug:
> BUG: 'list_empty(&vgdev->free_vbufs)' is true!
> [ cut here ]
> kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130!
> invalid opcode: 00
layer = sun4i_layer_init_one(drm, plane);
> if (IS_ERR(layer)) {
> dev_err(drm->dev, "Couldn't initialize %s plane\n",
> i ? "overlay" : "primary");
> return ERR_CAST(layer);
> };
> +layers[i] = layer;
>
> DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
> i ? "overlay" : "primary", plane->pipe);
> regmap_update_bits(drv->backend->regs,
> SUN4I_BACKEND_ATTCTL_REG0(i),
You're totally right. Can you send this as a formal patch?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/2ed78f33/attachment-0001.sig>
+ Arnd, Olof
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> This series adds two new drivers in order to better support the LCDC
> rev1 present on the da850 boards.
>
> The first patch adds a new memory driver which allows to write to the
> DDR2/mDDR memory controller present on
Fix tegra_bo_pin to set the parameter sgt pointer.
Host1x job pinning requires the sgt to determine
physical memory addresses of gathers.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu
From: Arto Merilainen
Host1x command buffer patching requires that the buffer object can be
mapped into kernel address space, however, the recent addition of
IOMMU did not account to this requirement. Therefore Host1x engines
cannot be used if IOMMU is enabled.
This patch implements kmap, kunmap
From: Arto Merilainen
Currently syncpoints are not locked by mutex and this causes races
if we are aggressively freeing and allocating syncpoints.
This patch adds missing mutex protection to syncpoint structures.
Signed-off-by: Arto Merilainen
Reviewed-by: Shridhar Rasal
Signed-off-by: Mikko
From: Arto Merilainen
Currently job pinning is optimized to handle only the first buffer
using a certain host1x_bo object and all subsequent buffers using
the same host1x_bo are considered done.
In most cases this is correct, however, in case the same host1x_bo
is used in multiple gathers inside
Am Dienstag, den 08.11.2016, 17:04 +0100 schrieb Lucas Stach:
> If the DC clock is disabled before the attached IDMACs are properly
> stopped the IDMACs may hang the IPU or even the whole system.
>
> Make sure the IDMACs are in safe state by disabling the planes before
> removal of the DC clock.
n-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33705 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/953192f4/attachment-0001.gz>
On 8 November 2016 at 18:36, Mauro Santos wrote:
> On 08-11-2016 18:08, Mauro Santos wrote:
>> On 08-11-2016 17:13, Emil Velikov wrote:
>>> On 8 November 2016 at 16:57, Mauro Santos
>>> wrote:
On 08-11-2016 15:57, Emil Velikov wrote:
> On 8 November 2016 at 15:27, Mauro Santos
> w
On 08-11-2016 18:08, Mauro Santos wrote:
> On 08-11-2016 17:13, Emil Velikov wrote:
>> On 8 November 2016 at 16:57, Mauro Santos
>> wrote:
>>> On 08-11-2016 15:57, Emil Velikov wrote:
On 8 November 2016 at 15:27, Mauro Santos
wrote:
> On 08-11-2016 15:00, Emil Velikov wrote:
>
On Tue, Nov 08, 2016 at 05:20:36PM +, Jon Medhurst (Tixy) wrote:
> On Tue, 2016-11-08 at 13:34 +, Russell King - ARM Linux wrote:
> > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote:
> > > Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> > >
On 11/08/2016 06:07 PM, Erik Faye-Lund wrote:
> On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot
> wrote:
>> Add FB modifiers to allow user-space to specify that a surface is in one
>> of the two tiling formats supported by Tegra chips, and add support in
>> the tegradrm driver to handle them pr
On Wed, Oct 26, 2016 at 09:15:15PM +0200, Daniel Vetter wrote:
> On Wed, Oct 26, 2016 at 8:47 PM, Stefan Lengfeld
> wrote:
> >
> > On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote:
> >> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote:
> >> > Cc: Dave Airlie
> >> > Signe
On Tue, Nov 08, 2016 at 06:04:15PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > > Now, I know you're working on getting rid of this entirely for i915, but
> > > what about that MSM driver? Will we continue to need it there, is
> > > anybody actua
On 08/11/16 15:56, Arnd Bergmann wrote:
> The newly introduced LED handling for nouveau fails to link when the
> driver is built-in but the LED subsystem is a loadable module:
>
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
> tvnv17.c:(.text.nouveau_do_suspend+0x10): undefi
On 08-11-2016 17:13, Emil Velikov wrote:
> On 8 November 2016 at 16:57, Mauro Santos
> wrote:
>> On 08-11-2016 15:57, Emil Velikov wrote:
>>> On 8 November 2016 at 15:27, Mauro Santos
>>> wrote:
On 08-11-2016 15:00, Emil Velikov wrote:
> On 8 November 2016 at 13:38, Mauro Santos
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > Now, I know you're working on getting rid of this entirely for i915, but
> > what about that MSM driver? Will we continue to need it there, is
> > anybody actually maintaining that thing?
>
> Rob Clark is, and since he's a one-man
On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote:
> > You're talking about:
> >
> > lkml.kernel.org/r/20161007154351.GL3117 at twins.programming.kicks-ass.net
> >
> > ? I got no feedback from you DRM guys on that so I kinda forgot about
> > that in the hope we'd not have to do this
On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote:
>
>
> On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta
> wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> > dev.i915.oa_max_sample_rate sysc
Hi Dave,
Yet antoher small batch of fixes. Two of the patches I had prepared
since quite some time, but they did not seem to affect operation in
a visible manner so far. Until recently, when I discovered the third
issue (disable planes before disabling CRTC), which made the two
previous fixes nece
On Tue, Nov 08, 2016 at 02:49:05PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> > The newly added assert_kernel_context_is_current introduces a warning
> > when built with W=1:
> >
> > drivers/gpu/drm/i915/i915_gem.c: In function
> > âassert_kern
From: Ravikant B Sharma
Replace direct comparisons to NULL i.e.
'x == NULL' with '!x'. As per coding standard.
Signed-off-by: Ravikant B Sharma
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c|4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_
2016-11-08 17:12 GMT+01:00 Arnd Bergmann :
> On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote:
>> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
>> > The underlying problem is that we already have a number of other
>> > symbols that either have "depends on LEDS_CLASS"
On Tue, 2016-11-08 at 13:34 +, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote:
> > Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> > these patches it's the original set of 10 patches. I've not pushed
> > thes
On Tue, Nov 08, 2016 at 01:43:25PM +, Liviu Dudau wrote:
> In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property
> we need to have a ->set_property hook defined for the planes. Set the
> plane's ->set_property hook to drm_atomic_helper_plane_set_property()
>
> Signed-off
2016-11-08 16:46 GMT+01:00 Ilia Mirkin :
> On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote:
>> The newly introduced LED handling for nouveau fails to link when the
>> driver is built-in but the LED subsystem is a loadable module:
>>
>> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do
On Tue, Nov 08, 2016 at 01:41:08PM +, Liviu Dudau wrote:
> On Tue, Nov 08, 2016 at 01:49:55PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote:
> > > Hi Dave,
> > >
> > > Here is the list of fixes that I have for drm/mali-dp. They've been on
> > > th
On 8 November 2016 at 16:57, Mauro Santos wrote:
> On 08-11-2016 15:57, Emil Velikov wrote:
>> On 8 November 2016 at 15:27, Mauro Santos
>> wrote:
>>> On 08-11-2016 15:00, Emil Velikov wrote:
On 8 November 2016 at 13:38, Mauro Santos
wrote:
> On 08-11-2016 11:06, Emil Velikov wro
On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote:
> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
> > The underlying problem is that we already have a number of other
> > symbols that either have "depends on LEDS_CLASS" or
> > "select LEDS_CLASS". To clean that up pro
On Tue, Nov 08, 2016 at 03:27:14PM +, Brian Starkey wrote:
> Hi Gustavo,
>
> On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > There is now a new property called IN_FENCE_FD attached to every plane
> > state that receives sync_file fds from us
On Tue, Nov 08, 2016 at 02:24:48PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > FIXME: Add owner of second tree to To:
> > >Add author(s)/SOB of
Am Freitag, den 28.10.2016, 10:18 +0200 schrieb Lucas Stach:
> Am Donnerstag, den 27.10.2016, 19:26 +0200 schrieb Wladimir J. van der
> Laan:
> > Hello,
> >
> > After running kmscube (or another KMS executable) on a i.MX6 QuadPlus
> > (etnaviv,
> > GC3000) a few times on I get the below crash in
On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
> The underlying problem is that we already have a number of other
> symbols that either have "depends on LEDS_CLASS" or
> "select LEDS_CLASS". To clean that up properly, we should either
> make the symbol itself hidden and only select
This has never worked properly, as the IRQ got retriggered immediately
on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
the DC channel at any point in time.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-dc.c | 61 +++--
1 f
If the DC clock is disabled before the attached IDMACs are properly
stopped the IDMACs may hang the IPU or even the whole system.
Make sure the IDMACs are in safe state by disabling the planes before
removal of the DC clock.
Fixes: 33f14235302f (drm/imx: atomic phase 1: Use transitional atomic
Adapting the videomode to the hardware constraints is something that
can and must happen during normal operation and isn't something that
the user can avoid. So printing a warning each time it happens isn't
helpful.
Demote this message to the debug level.
Signed-off-by: Lucas Stach
---
drivers/
On 08-11-2016 15:57, Emil Velikov wrote:
> On 8 November 2016 at 15:27, Mauro Santos
> wrote:
>> On 08-11-2016 15:00, Emil Velikov wrote:
>>> On 8 November 2016 at 13:38, Mauro Santos
>>> wrote:
On 08-11-2016 11:06, Emil Velikov wrote:
> On 1 November 2016 at 18:47, Mauro Santos
Hi Dave,
On 2016-09-19 00:16, Philipp Zabel wrote:
> Hi Dave,
>
> this tag contains support for the I2C master controller contained in the
> HDMI TX IP core, for those boards that don't allow to mux their DDC pins
> to SoC I2C controllers. This will make the dw-hdmi driver register its
> internal
On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote:
> > diff --git a/drivers/gpu/drm/nouveau/Kconfig
> > b/drivers/gpu/drm/nouveau/Kconfig
> > index 78631fb61adf..715cd6f4dc31 100644
> > --- a/drivers/gpu/drm/nouveau/Kconfig
> > +++ b/drivers/gpu/drm/nouveau/Kconfig
> > @@ -46,6 +46,14
Add FB modifiers to allow user-space to specify that a surface is in one
of the two tiling formats supported by Tegra chips, and add support in
the tegradrm driver to handle them properly. This is necessary for the
display controller to directly display buffers generated by the GPU.
This feature i
On 8 November 2016 at 16:40, Dave Airlie wrote:
>> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
>> udl 1-2:1.0: fb1: udldrmfb frame buffer device
>> [drm] Initialized udl on minor 1
>> usbcore: registered new interface driver udl
>>
>>
>> Is this expected WARN?
>
> I've just posted
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
and it looks like the answer is no, so here's
v2 which kmemdups.
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 16 +++-
1 fil
On Tue, Nov 08, 2016 at 05:16:41PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 01:43:25PM +, Liviu Dudau wrote:
> > In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property
> > we need to have a ->set_property hook defined for the planes. Set the
> > plane's ->set_
> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
> udl 1-2:1.0: fb1: udldrmfb frame buffer device
> [drm] Initialized udl on minor 1
> usbcore: registered new interface driver udl
>
>
> Is this expected WARN?
I've just posted a patch in theory to fix it, please test if oyu have time.
On Sat, Nov 5, 2016 at 11:08 AM, Rob Clark wrote:
> I realized that I had not re-sent this after updating from review
> comments, and adding kerneldoc.
>
> The drm/msm bits I can include in my msm-next pull-req for 4.10. Just
> including them here to show example usage.
>
> There will be a minor
From: Dave Airlie
Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?
Reported-by: poma
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ud
On 8 November 2016 at 16:21, Karol Herbst wrote:
> 2016-11-08 17:12 GMT+01:00 Arnd Bergmann :
>> On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote:
>>> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote:
>>> > The underlying problem is that we already have a number of other
On 07/11/16 11:25 PM, Bridgman, John wrote:
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>> Of Michel Dänzer
>> Sent: Monday, November 07, 2016 2:24 AM
>> On 07/11/16 03:56 AM, Sandeep wrote:
>>>
>>> I was wondering when DRM_AMDGPU_CIK would be turned on by defa
On 8 November 2016 at 15:27, Mauro Santos wrote:
> On 08-11-2016 15:00, Emil Velikov wrote:
>> On 8 November 2016 at 13:38, Mauro Santos
>> wrote:
>>> On 08-11-2016 11:06, Emil Velikov wrote:
On 1 November 2016 at 18:47, Mauro Santos
wrote:
> On 01-11-2016 18:13, Emil Velikov wro
From: Gustavo Padovan
Support DRM out-fences by creating a sync_file with a fence for each CRTC
that sets the OUT_FENCE_PTR property.
We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
the sync_file fd back to userspace.
The sync_file and fd are allocated/created before com
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init()
From: Gustavo Padovan
There is now a new property called IN_FENCE_FD attached to every plane
state that receives sync_file fds from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_array
subclass or just a normal fence) and then used by DRM to fenc
From: Gustavo Padovan
Hi,
This is yet another version of the DRM fences patches. Please refer
to the cover letter[1] in a previous version to check for more details.
In v7 we now have split most of the out_fences code into
prepare_crtc_signaling() and unprepare_crtc_signaling() with improved er
On Tue, Nov 08, 2016 at 03:25:45PM +, Robin Murphy wrote:
> On 08/11/16 13:34, Russell King - ARM Linux wrote:
> > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote:
> >> Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> >> these patches it's the o
On Mon, 7 Nov 2016 23:37:41 +0100
Maxime Ripard wrote:
> Hi,
>
> On Fri, Oct 28, 2016 at 07:34:20PM +0200, Jean-Francois Moine wrote:
> > On Fri, 28 Oct 2016 00:03:16 +0200
> > Maxime Ripard wrote:
[snip]
> > > > > We've been calling them bus and mod.
> > > >
> > > > I can understand "
On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>+static struct dma_fence *get_crtc_fence(struct drm_crtc *crtc,
>+ struct drm_crtc_state *crtc_state)
>+{
>+ struct dma_fence *fence;
>+
>+ fence = kzalloc(size
On 08-11-2016 15:00, Emil Velikov wrote:
> On 8 November 2016 at 13:38, Mauro Santos
> wrote:
>> On 08-11-2016 11:06, Emil Velikov wrote:
>>> On 1 November 2016 at 18:47, Mauro Santos
>>> wrote:
On 01-11-2016 18:13, Emil Velikov wrote:
> From: Emil Velikov
>
> Parsing config s
Hi Gustavo,
On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>There is now a new property called IN_FENCE_FD attached to every plane
>state that receives sync_file fds from userspace via the atomic commit
>IOCTL.
>
>The fd is then translated to a fence (th
On 08/11/16 13:34, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote:
>> Unfortunately, my drm-tda998x-devel branch is slightly out of date with
>> these patches it's the original set of 10 patches. I've not pushed
>> these ones out to that
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_shrinker.c
between commits:
1233e2db199d ("drm/i915: Move object backing storage manipulation to its own
On Tue, Nov 08, 2016 at 12:43:55PM +0100, Andrzej Hajda wrote:
> On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > CEA-861 specifies that the vertical front porch may vary by one or two
> > lines for specific VICs. Up to now we've only considered a mode
On 8 November 2016 at 13:38, Mauro Santos wrote:
> On 08-11-2016 11:06, Emil Velikov wrote:
>> On 1 November 2016 at 18:47, Mauro Santos
>> wrote:
>>> On 01-11-2016 18:13, Emil Velikov wrote:
From: Emil Velikov
Parsing config sysfs file wakes up the device. The latter of which ma
The newly added assert_kernel_context_is_current introduces a warning
when built with W=1:
drivers/gpu/drm/i915/i915_gem.c: In function
âassert_kernel_context_is_currentâ:
drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty
body in an âelseâ statement [-Werror=emp
The newly introduced LED handling for nouveau fails to link when the
driver is built-in but the LED subsystem is a loadable module:
drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to
`nouveau_led_suspend'
drivers/g
A recent bugfix replaced an out-of-bounds access with direct
use of unintialized data:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function
'smu7_patch_limits_vddc':
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be
used uninitialized in this function [-Werro
On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote:
> The newly added assert_kernel_context_is_current introduces a warning
> when built with W=1:
>
> drivers/gpu/drm/i915/i915_gem.c: In function
> âassert_kernel_context_is_currentâ:
> drivers/gpu/drm/i915/i915_gem.c:4417:63: error
On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > FIXME: Add owner of second tree to To:
> >Add author(s)/SOB of conflicting commits.
> >
> > Today's linux-next merge of the tip tree got a
On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> This is yet another version of the DRM fences patches. Please refer
> to the cover letter[1] in a previous version to check for more details.
>
> In v7 we now have split most of the out_fences c
On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Support DRM out-fences by creating a sync_file with a fence for each CRTC
> that sets the OUT_FENCE_PTR property.
>
> We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
> the sync_fi
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/650e3675/attachment.html>
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
Acked-by: Dave Airlie #irc
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 dele
On Tue, Nov 08, 2016 at 01:44:34PM +0100, Christian König wrote:
> Am 08.11.2016 um 12:45 schrieb Chris Wilson:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, G
On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote:
> Hi Dave,
>
> Here is the list of fixes that I have for drm/mali-dp. They've been on the
> mailing
> lists for a while and merged into linux-next for a few weeks, but due to
> holiday and
> travel to Linux Plumbers I did not send the
On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote:
> 0day found that stackdepot.h doesn't get automatically included on all
> architectures, so remember to add our #include.
>
> Reported-by: kbuild test robot
> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on
> shu
Am 08.11.2016 um 12:56 schrieb Chris Wilson:
> 0day found that stackdepot.h doesn't get automatically included on all
> architectures, so remember to add our #include.
>
> Reported-by: kbuild test robot
> Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on
> shutdown")
> Signed-o
It's possible for CVAL to get set whilst we are in config mode. If this
happens, afer we leave config mode the HW will latch whatever
configuration is in the registers at the next vsync. Most likely this
will be a partial configuration, as we'll be racing against the ongoing
atomic_commit.
To avoi
Am 08.11.2016 um 12:45 schrieb Chris Wilson:
> On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
>>> On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
From: Gustavo Padovan
Hi,
Thi
On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > > > From: Gustavo Padovan
> >
In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property
we need to have a ->set_property hook defined for the planes. Set the
plane's ->set_property hook to drm_atomic_helper_plane_set_property()
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_planes.c | 1 +
1 fil
On Tue, Nov 08, 2016 at 01:49:55PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote:
> > Hi Dave,
> >
> > Here is the list of fixes that I have for drm/mali-dp. They've been on the
> > mailing
> > lists for a while and merged into linux-next for a few week
On 08-11-2016 11:06, Emil Velikov wrote:
> On 1 November 2016 at 18:47, Mauro Santos
> wrote:
>> On 01-11-2016 18:13, Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Parsing config sysfs file wakes up the device. The latter of which may
>>> be slow and isn't required to begin with.
>>>
>>> Re
r
>> hours without blanking.
>>
>> --
>> You are receiving this mail because:
>>
>>- You are on the CC list for the bug.
>>
>>
--
You are receiving this mail because:
You are the assignee for the bug.
------ n
bug.
>
>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/337c2123/attachment.html>
On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote:
> Unfortunately, my drm-tda998x-devel branch is slightly out of date with
> these patches it's the original set of 10 patches. I've not pushed
> these ones out to that branch yet, as I've three additional patches on
> top of
On Tue, Nov 08, 2016 at 01:19:51PM +, Robin Murphy wrote:
> Hi Russell,
>
> On 08/11/16 12:24, Russell King - ARM Linux wrote:
> > As no one responded to the previous round, I'm not spending soo much
> > time writing up a description of these changes again. It's also been
> > quite a long tim
Hi Russell,
On 08/11/16 12:24, Russell King - ARM Linux wrote:
> As no one responded to the previous round, I'm not spending soo much
> time writing up a description of these changes again. It's also been
> quite a long time, so I've forgotten all the details of the changes,
> so I'll do my best.
I misread the kbuild result thinking that we had missed the include
(which we had for completeness anyway), what kbuild was actually warning
me about was that depot_save_stack was not exported.
Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin
Reported-by: kbuild test robot
DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently
depot_save_stack is not exported.
Fixes: 5c7fcf2db027 ("drm/i915: Enable drm_mm debug when enabling
DRM_I915_DEBUG")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 dele
On Tue, Nov 08, 2016 at 01:46:15PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote:
> > 0day found that stackdepot.h doesn't get automatically included on all
> > architectures, so remember to add our #include.
> >
> > Reported-by: kbuild test robot
> >
On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Høgsberg wrote:
> We used to call drm_of_encoder_active_endpoint_id() from
> rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the
> active encoder. However, the encoder isn't necessarily active at this
> point or it may be co
On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote:
> > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> > > > On Tue, Nov 08, 2016 at 03:54
This v2 patch bumps the command parser version so it can be referenced in
corresponding i-g-t gem_exec_parse changes.
--- >8 ---
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mes
On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> CEA-861 specifies that the vertical front porch may vary by one or two
> lines for specific VICs. Up to now we've only considered a mode to match
> the VIC if it matched the shortest possible vertical front po
On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This is yet another version of the DRM fences patches. Please refer
> > to the cover letter[1] in a previous version to c
t value.
That could still break existing use-cases, but it would at least allow
basic hand-over.
Also, if leaving the GPIO configured as-is causes glitches or other
issues, then these are observable with the current code as well, until
the panel driver takes over and disables everything.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/e0f3dae7/attachment.sig>
On Tue, Nov 08, 2016 at 10:59:43AM +, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote:
> > Hm, I entirely missed that part of the troubles. Anyway, if you all agree
> > on a patch I certainly won't block it, feel free to merge through suitable
> >
1 - 100 of 182 matches
Mail list logo
