Hi Laurent,
On Mon, Sep 19, 2016 at 8:27 PM, Laurent Pinchart
wrote:
> The vblank interrupt is disabled after one occurrence, preventing the
> atomic update event from being processed twice. However, this also
> prevents the software frame counter from being updated correctly that
> would require
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/a9de4d3d/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=141741
--- Comment #17 from Alex Deucher ---
(In reply to Lukas P from comment #16)
> It may be the same problem as Bug 120321.
>
> At my PC the latest Antergos live-image does work normal although it has
> kernel 4.7.4. The installed version and every
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/0ad6f2d8/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/98d019bc/attachment.html>
ent was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/dc215424/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=141741
--- Comment #16 from Lukas P ---
It may be the same problem as Bug 120321.
At my PC the latest Antergos live-image does work normal although it has kernel
4.7.4. The installed version and every other distros i tried with the distro or
vanilla ke
isched. With
R600_DEBUG=vs,tcs,tes,gs,ps,cs,sisched I get the following.
--
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/20
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/841f6189/attachment.html>
vel/attachments/20160927/d3df8617/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160927/1fdc2270/attachment.html>
I think that create conflicts with what is already in Vincent pull
request where we have fix the problem reported by coccicheck and
sparse.
https://lists.freedesktop.org/archives/dri-devel/2016-September/118892.html
Benjamin
2016-09-27 18:35 GMT+02:00 Sean Paul :
> On Sun, Sep 25, 2016 at 3:57 A
Hi Meng,
This starts to look good, some comments below.
For the next revision, can you also add the device tree maintainers? I
would like to get an ack from somebody there that such a split up is ok.
On 2016-09-27 20:17, Meng Yi wrote:
> Gamma correction is optional and can be used to adjust the
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/fcc1d31b/attachment.html>
Hello Andrzej,
Andrzej Hajda wrote:
> On 27.09.2016 13:22, Tobias Jakobi wrote:
>> Hello Inki,
>>
>>
>> Inki Dae wrote:
>>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
in mixer_cfg_layer().
Trigger this v
s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/be8ce18d/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/c4c171e2/attachment-0001.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/af746147/attachment.html>
2016-09-27 Emilio López :
> As part of the sync framework destaging, the sync_file.h header
> was moved, but an entry was not added on Kbuild to install it.
> This patch resolves this omission so that "make headers_install"
> installs this header.
>
> Fixes: 460bfc41fd52 ("dma-buf/sync_file: de-
The function is never called with zero 'runqueue_node'.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 1a000c1..fa25c7f 100644
The runqueue worker currently issues a get() when a new
node is processed, and a put() once a node is completed.
The corresponding suspend and resume calls currently only
do clock gating, but with the upcoming introduction of
IOMMU runpm also the corresponding IOMMU domain gets
enabled (for get())
On 27 September 2016 at 17:43, Joe Perches wrote:
> On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
>> On 27 September 2016 at 17:04, Joe Perches wrote:
>> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>> > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
>> > > > Use a bit
While the engine works on a runqueue node it does memory access to
the buffers associated with that node.
Make sure that the engine is idle when g2d_close() and/or
g2d_remove() are called, i.e. buffer associated with the process (for
g2d_close()), or all buffers (for g2d_remove()) can be safely be
The driver might be closed (and/or removed) while there are still
nodes queued for processing.
Make sure to remove these nodes, which means all of them in
the case of g2d_remove() and only those belonging to the
corresponding process in g2d_close().
Signed-off-by: Tobias Jakobi
---
drivers/gpu/d
Do all pm_runtime_{get,put}() calls in the runqueue worker.
Also keep track of the engine's idle/busy state.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 78 +++--
1 file changed, 56 insertions(+), 22 deletions(-)
diff --git a/drivers/gp
This reverts commit b05984e21a7e000bf5074ace00d7a574944b2c16.
The change, i.e. merging the sleep and runpm operations, produces
a deadlock situation:
(1) exynos_g2d_exec_ioctl() prepares a runqueue node and
calls g2d_exec_runqueue()
(2) g2d_exec_runqueue() calls g2d_dma_start() which gets
Hello everyone,
as discussed with Marek I have broken down my initial patch into smaller piecer.
Anyway, this series fixes a regression introduced by commit
b05984e21a7e000bf5074ace00d7a574944b2c16.
With best wishes,
Tobias
Tobias Jakobi (6):
Revert "drm/exynos: g2d: fix system and runtime pm
On 27 September 2016 at 17:04, Joe Perches wrote:
> On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>> > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
>> > Use a bit more consistent style with kernel loglevels
>> > I'm not convinced this is worth doing if we're going to keep the
>> WAR
i-devel/attachments/20160927/8944198f/attachment.html>
Some architectures don't use the common clock framework and don't
implement all the clk interfaces for every clock. This is the case
for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
Trying to set the clock rate for the LCDC clock results in -EINVAL
being returned.
As a workaround
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/0edd5b6a/attachment.html>
2016ë
09ì 27ì¼ 14:40ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Inki Dae wrote:
>>
>>
>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>> in mixer_cfg_layer().
>>> Trigger this via atomic flush.
>>>
>>> Changes in v2:
TML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/b236d201/attachment.html>
Replace custom code with core helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 4a19221..238c08c 100644
--- a/
Replace custom code with core helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade
Replace custom code with core helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 33716
Replace custom code with core helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/arm/malidp_drv.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 82171d2..e8bd8b0 100644
--- a/driver
Replace custom code with core helper.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 48019ae..a17ddb5 100644
--- a/driver
A lot of drivers need to fire pageflip completion event at very next vblank
interrupt. The patch adds helper to perform this operation.
drm_crtc_arm_completion_event checks if there is an event to handle,
if vblank reference get succeeds it arms the event, otherwise it sends the
event immediately.
Hi,
During playing with vblanks on Exynos I have encountered
common pattern of arming completion event. I have put it
into core helper.
Since I am not sure if it will be accepted I have not added
subsystem maintainers to CC.
I have tested it on Exynos with some pending patches.
Other drivers were
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/f3dedcb5/attachment.sig>
eedesktop.org/archives/dri-devel/attachments/20160927/b488ffcd/attachment.html>
unsigned long flags;
> +
> + if (event) {
> + WARN_ON(drm_crtc_vblank_get(crtc) != 0);
Where's the matching put?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/8c4ac296/attachment.sig>
because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/065ce798/attachment.html>
2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
>
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - add
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/262623a5/attachment.html>
Emilio López writes:
> El 22/09/16 a las 06:43, Michael Ellerman escribió:
>> Emilio López writes:
>>
>> Please don't include the *kernel* headers, they're really not meant to
>> be used in userspace programs :)
>>
>>> +CFLAGS += -I../../../../usr/include/
>>
>> That is the correct place to ge
drm_crtc_arm_vblank_event(crtc, event);
>>>>>>> + else
>>>>>>> + drm_crtc_send_vblank_event(crtc, event);
>>>>>>> + spin_unlock_irq(&crtc->dev->event_lock);
>>
lock);
>>>>>> + if (drm_crtc_vblank_get(crtc) == 0)
>>>>>> + drm_crtc_arm_vblank_event(crtc, event);
>>>>>> + else
>>>>>> + drm_crtc_send_vblank_event(crtc, event);
>>>>&
Hi Daniel,
On Wed, Sep 21, 2016 at 10:59:25AM +0200, Daniel Vetter wrote:
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 1407715736a5..256219bfd07b 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -319,10 +319,48 @@ struct drm_plane_funcs {
>
On 27.09.2016 13:22, Tobias Jakobi wrote:
> Hello Inki,
>
>
> Inki Dae wrote:
>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>>> in mixer_cfg_layer().
>>> Trigger this via atomic flush.
>>>
>>> Changes in v2:
>>> - is
Hello Marek,
Marek Szyprowski wrote:
> Hi Tobias,
>
> On 2016-09-26 16:15, Tobias Jakobi wrote:
>> Marek Szyprowski wrote:
>>> On 2016-09-24 20:58, Tobias Jakobi wrote:
The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
operation of the G2D. After this commit the following
On Tue, Sep 27, 2016 at 12:54:46PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >
> > index 85172a977bf3..e52aece30900 100644
> > --- a/drivers/gpu/drm/drm_blen
Hello Inki,
Inki Dae wrote:
> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Changes in v2:
>> - issue mixer_cfg_layer() in mixer_disable()
>> - rename fi
Hey Inki,
Inki Dae wrote:
> 2016ë
09ì 27ì¼ 14:40ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Inki Dae wrote:
>>>
>>>
>>> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
in mixer_cfg_layer().
Trigger this via a
On Tue, Sep 27, 2016 at 12:54 PM, Emil Velikov
wrote:
> On 27 September 2016 at 17:43, Joe Perches wrote:
>> On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
>>> On 27 September 2016 at 17:04, Joe Perches wrote:
>>> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>>> > > On Sun, Sep
On ma, 2016-09-26 at 19:31 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> The primary and sprite planes on CHV pipe B support horizontal
> mirroring. Expose it to the world.
>
> Sadly the hardware ignores the mirror bit when the rotate bit is
> set, so we'll have to r
On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that all drivers have been converted over to the per-plane rotation
> property, we can just nuke the global rotation property.
>
> v2: Rebase due to BIT(),__builtin_ffs() & co.
> Â Â Â Â Dea
On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
>
> On certain platforms not all planes support the same set of
> rotations/reflections, so let's use the per-plane property
> for this.
>
> This is already a problem on SKL when we use the legay
Hi Dave,
Just a couple of small fixes for 4.8:
- dpm stability fix for some SI parts
- fix a regression in 4.8 on display tear down
The following changes since commit 47a66e45d7a7613322549c2475ea9d809baaf514:
drm: Only use compat ioctl for addfb2 on X86/IA64 (2016-09-19 17:28:20 +1000)
are av
On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
>
> index 85172a977bf3..e52aece30900 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
Now that I'm thinking, *_zpos_* fi
2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
> in mixer_cfg_layer().
> Trigger this via atomic flush.
>
> Changes in v2:
> - issue mixer_cfg_layer() in mixer_disable()
> - rename fields as suggested by Andrzej
> - add
On Sun, Sep 25, 2016 at 3:57 AM, Baoyou Xie wrote:
> We get 6 warnings when building kernel with W=1:
> drivers/gpu/drm/sti/sti_mixer.c:361:6: warning: no previous prototype for
> 'sti_mixer_set_matrix' [-Wmissing-prototypes]
> drivers/gpu/drm/sti/sti_dvo.c:109:5: warning: no previous prototype f
On Sun, Sep 25, 2016 at 3:43 AM, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:309:6: warning: no previous
> prototype for 'rockchip_drm_fb_suspend' [-Wmissing-prototypes]
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:318:6: war
On Sun, Sep 25, 2016 at 3:41 AM, Baoyou Xie wrote:
> We get 4 warnings when building kernel with W=1:
> drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype
> for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
> drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previou
On Sun, Sep 25, 2016 at 3:38 AM, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:130:5: warning: no previous
> prototype for 'rockchip_drm_fbdev_init' [-Wmissing-prototypes]
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:173:6:
On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
>
> We have intel_rotation_90_or_270() in i915 to check if the rotation is
> 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move
> the helper into a central place and use it everw
e
>>>>> + drm_crtc_send_vblank_event(crtc, event);
>>>>> + spin_unlock_irq(&crtc->dev->event_lock);
>>>>> + }
>>>>> +}
>>>>
>>>> This should be done by drivers, in the ->update
On Tue, Sep 27, 2016 at 2:36 AM, David Herrmann
wrote:
> Hi Chris
>
> On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson
> wrote:
>> Currently we use a linear walk to lookup a handle and return a dma-buf,
>> and vice versa. A long overdue TODO task is to convert that to a
>> hashtable. Since the in
Am Donnerstag, den 22.09.2016, 11:50 +0200 schrieb Arnd Bergmann:
> The imx_drm_bind function causes a warning in linux-next when
> CONFIG_DRM_FBDEV_EMULATION is not set:
>
> drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> drivers/gpu/drm/imx/imx-drm-core.c:441:1: error: label 'e
Am Mittwoch, den 21.09.2016, 15:12 + schrieb Wei Yongjun:
> From: Wei Yongjun
>
> Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
>
> Generated by: scripts/coccinelle/api/err_cast.cocci
>
> Signed-off-by: Wei Yongjun
Applied, thank you.
regards
Philipp
On Mon, Sep 26, 2016 at 6:21 AM, Jonathan Liu wrote:
> The panel should be enabled after the controller so that we do not have
> visual glitches on the panel while the controller is setup. Similarly,
> the panel should be disabled before the controller.
>
> Signed-off-by: Jonathan Liu
Cool, this
On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
> Use a bit more consistent style with kernel loglevels
I'm not convinced this is worth doing if we're going to keep the
WARN/WARNING discrepancy, and I don't think we should switch DRM_WARN
to DRM_WARNING since it's so widely used.
Sean
> wi
On Mon, Sep 26, 2016 at 4:36 AM, Chris Wilson
wrote:
> On Sun, Sep 25, 2016 at 07:18:34PM -0700, Joe Perches wrote:
>> Remove function name and special " *ERROR*" from argument list
>>
>> $ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected)
>>text data bss
Hi,
El 27/09/16 a las 01:23, Michael Ellerman escribió:
> Emilio López writes:
>> El 22/09/16 a las 06:43, Michael Ellerman escribió:
>>> Emilio López writes:
>>>
>>> Please don't include the *kernel* headers, they're really not meant to
>>> be used in userspace programs :)
>>>
+CFLAGS
On Sat, Sep 24, 2016 at 10:26 AM, Shawn Guo wrote:
> It adds the initial ZTE VOU display controller DRM driver. There are
> still some features to be added, like overlay plane, scaling, and more
> output devices support. But it's already useful with dual CRTCs and
> HDMI monitor working.
>
> It'
As part of the sync framework destaging, the sync_file.h header
was moved, but an entry was not added on Kbuild to install it.
This patch resolves this omission so that "make headers_install"
installs this header.
Fixes: 460bfc41fd52 ("dma-buf/sync_file: de-stage sync_file headers")
Reported-by: M
On Tue, Sep 27, 2016 at 9:36 AM, Andrzej Hajda wrote:
> Replace custom code with core helper.
>
> Signed-off-by: Andrzej Hajda
Nice cleanup. Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
Remove Jean-Christophe from the maintainers, and remove links to
old unmaintained web pages and git trees.
Signed-off-by: Tomi Valkeinen
---
Jean-Christophe hasn't done any fbdev work for years, hasn't responded to any
emails, and now emails to him bounce back.
MAINTAINERS | 3 ---
1 file chan
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/6ea8f092/attachment-0001.html>
On Sat, Sep 24, 2016 at 4:18 PM, Maxime Ripard
wrote:
> On Fri, Sep 23, 2016 at 11:43:55PM +1000, Jonathan Liu wrote:
>> Hi Maxime,
>>
>> On 23 September 2016 at 23:16, Maxime Ripard
>> wrote:
>> > On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
>> >> Hi Maxime,
>> >>
>> >> On Thurs
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/fa3d0da1/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160927/28bd146e/attachment.html>
On Wed 21 Sep 05:09 PDT 2016, Emil Velikov wrote:
> On 20 September 2016 at 09:32, Peter Griffin
> wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin
> >> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which expos
On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
> On 27 September 2016 at 17:04, Joe Perches wrote:
> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
> > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
> > > > Use a bit more consistent style with kernel loglevels
> > > I'm not
Hi Dave,
Just wanted to make sure this pull request hasn't got lost in the mail.
Thanks,
Oded
On Mon, Sep 19, 2016 at 10:49 PM, Oded Gabbay wrote:
> Hi Dave,
>
> This is amdkfd's pull request for kernel 4.9. It contains a fix to a possible
> infinite loop bug and a couple of other minor "c
s://lists.freedesktop.org/archives/dri-devel/attachments/20160927/9ca206d9/attachment-0001.html>
On Mon, Sep 26, 2016 at 11:41 AM, Marek Vasut wrote:
> But then, I see a few drivers (arm hdlcd, fsl-dcu,...) doing the same
> thing at random callbacks of CRTC . Shouldn't this event handling be
> consolidated into some generic function and those drivers fixed to
> call it from atomic update ?
t
On Mon, Sep 26, 2016 at 2:59 PM, Marek Vasut wrote:
> On 09/26/2016 11:41 AM, Marek Vasut wrote:
>> On 09/25/2016 11:00 PM, Daniel Vetter wrote:
>>> On Sun, Sep 25, 2016 at 09:41:58PM +0200, Marek Vasut wrote:
Handle the vblank events in the simple_kms_helper driver, otherwise
the drm_at
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/09468f1b/attachment.html>
On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
> On 27 September 2016 at 17:04, Joe Perches wrote:
> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
> > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
> > > > Use a bit more consistent style with kernel loglevels
> > > I'm not
On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
wrote:
> There's no point in enabling PSR when the panel doesn't support it.
>
> This also avoids a problem when PSR gets enabled when a CRTC is being
> disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
> interrupt on which we wait
On Fri, Sep 23, 2016 at 10:06 AM, Tomeu Vizoso
wrote:
> So users know whether PSR should be enabled or not.
>
> Signed-off-by: Tomeu Vizoso
> Cc: Sean Paul
> Cc: Yakir Yang
> Cc: Archit Taneja
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
>
today.
--
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/5e316de1/attachment.html>
On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
> > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
> > Use a bit more consistent style with kernel loglevels
> > I'm not convinced this is worth doing if we're going to keep the
> WARN/WARNING discrepancy, and I don't think we should switch
receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160927/6d3e1758/attachment.html>
Hi Chris
On Mon, Sep 26, 2016 at 10:44 PM, Chris Wilson
wrote:
> Currently we use a linear walk to lookup a handle and return a dma-buf,
> and vice versa. A long overdue TODO task is to convert that to a
> hashtable. Since the initial implementation of dma-buf/prime, we now
> have resizeable has
Hi Tobias,
On 2016-09-26 16:15, Tobias Jakobi wrote:
> Marek Szyprowski wrote:
>> On 2016-09-24 20:58, Tobias Jakobi wrote:
>>> The commit b05984e21a7e000bf5074ace00d7a574944b2c16 broke
>>> operation of the G2D. After this commit the following
>>> happens.
>>> - exynos_g2d_exec_ioctl() prepares a
Inki Dae wrote:
>
>
> 2016ë
09ì 26ì¼ 20:36ì Tobias Jakobi ì´(ê°) ì´ ê¸:
>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once
>> in mixer_cfg_layer().
>> Trigger this via atomic flush.
>>
>> Changes in v2:
>> - issue mixer_cfg_layer() in mixer_disable()
>> - rename fields as
On Mon, Sep 26, 2016 at 8:29 PM, Lukas Wunner wrote:
> On Sun, Sep 25, 2016 at 11:34:48PM +0300, Grazvydas Ignotas wrote:
>> Some code called by drm_crtc_force_disable_all() wants to wait for all
>> fences, so only do fence teardown after CRTCs are disabled.
>
> Ugh, how embarrassing, that was add
1 - 100 of 103 matches
Mail list logo
