On Thu, Mar 31, 2016 at 07:26:25PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-02-25 Ã s 14:51 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > To save a bit of power, let's try to turn off the TMDS output buffers
> > in DP++ adaptors when we're not driving t
On Thu, Mar 31, 2016 at 07:25:36PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > Add a helper which aids in he identification of DP dual mode (aka.
> > DP++)
> > adaptors. There are several types
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/bfa3523a/attachment.html>
Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have n
be from the old
version though.
--
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/20160331/7d3edb98/attachment.html>
On Thu, 31 Mar 2016 10:48:01 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > pwm_config/enable/disable() have been deprecated and should be replaced
> > by pwm_apply_state().
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > d
Hi Dmitry,
On Thu, 31 Mar 2016 10:38:58 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > Prefix those function as deprecated to encourage all existing users to
> > switch to pwm_apply_state().
>
> Why not keep at least some of th
2016-03-31 19:04 GMT+09:00 Daniel Vetter :
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
Hi Daniel,
2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae wrote:
>> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> On 31 March 2016 at 08:45, Inki Dae wrote:
As of now, it seems that this wouldn't be optional but mandatory if
>
Hi Liu,
Am Montag, den 14.03.2016, 16:10 +0800 schrieb Liu Ying:
> To avoid race condition issue, we should protect the function
> ipu_dmfc_init_channel() with the mutex dmfc->priv->mutex, since it
> configures the register DMFC_GENERAL1 at runtime which contains
> several control bits for various
Em Qui, 2016-02-25 Ã s 14:51 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
>
> v2: Let's not forget DDI, toss in a debug message while at it
>
Em Ter, 2016-02-23 Ã s 18:46 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Add a helper which aids in he identification of DP dual mode (aka.
> DP++)
> adaptors. There are several types of adaptors specified:
> type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
>
>
On to, 2016-03-31 at 09:35 +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: linux-media at vger.kernel.org
> Cc: dri-devel at lists.fr
Hi Daniel,
2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 31 March 2016 at 08:45, Inki Dae wrote:
>> 2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
In addition, I wonder how explicit and implicit
https://bugzilla.kernel.org/show_bug.cgi?id=107001
--- Comment #2 from Timo Valtoaho ---
git bisected this to d57c0edfe00d3274b50f91ce3076ed0e82d28782.
Reverting this solves the problem, at least with 4.5.0 in which I'm testing the
revert.
--
You are receiving this mail because:
You are watchi
freedesktop.org/archives/dri-devel/attachments/20160331/c5b5fcc5/attachment.html>
are/linux-firmware.git/commit/?id=6e767c2b85c62fb7325fdc00f51b90f6747c13ab
--
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/20160331/7092a6bf/attachment-0001.html>
in
your initrd.
--
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/20160331/177b38a7/attachment.html>
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/2bcee43d/attachment.html>
Currently, our implementation of drm_connector_funcs.detect is
based on getting a valid EDID.
This requirement makes the driver fail to detect connected
connectors in case of EDID corruption, which prevents from falling
back to modes provided by builtin or user-provided EDIDs.
Let's fix this by i
Hi Tomi,
On 03/30/2016 03:37 AM, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 24/03/16 23:20, Hans Verkuil wrote:
>> Hi Tomi,
>>
>> I hope you (or someone else on this list) can help me find the problem in
>> this code.
>>
>> I am working on a kernel framework for HDMI CEC (see
>> https://lwn.net/Art
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/64d1dfdd/attachment.html>
2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to
>> explicit
Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-boneblack.dts | 71 --
1 file changed, 67 insertions(+), 4 d
Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.
With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI code
Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/i2c/tda998x_drv.c | 77 +
Add audio abort() callback, that is provided at audio stream start,
for video side. This is for video side to use in case there is a
pressing need to tear down the audio playback for some reason.
Signed-off-by: Jyri Sarha
---
include/sound/hdmi-codec.h| 8 ++--
sound/soc/codecs/hdmi-cod
The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the HDMI encoder's audio
functionality.
The structures and definitions in the API header are mostly redundant
copies of
Treat 32 bit sample width as if it was 24 bits when generating IEC958
channel status bits. On some platforms 24 sample width is problematic
and to get full 24 bit precision a 32 bit format, using only the 24
most significant bits, may have to be used.
Signed-off-by: Jyri Sarha
---
sound/core/pcm
Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.
Signed-off-by: Jyri Sarha
---
include/sound/pcm_iec958.h | 2 ++
sound/core/pcm_iec95
Couple of minor changes since v8 to ALSA/ASoC side patches. The series
is based on top of drm-next. However, it does not look like there is
enough attention to the DRM side so that the tda998x patches would get
in any time soon. So I am happy to rebase the first ALSA-side patches
on top of Mark Bro
Split out dma-buf related parts into their own section, add missing
files, and write a bit of overview about how it all fits together.
Signed-off-by: Rob Clark
---
Documentation/DocBook/device-drivers.tmpl | 36 +++
1 file changed, 32 insertions(+), 4 deletions(-)
di
Signed-off-by: Rob Clark
---
drivers/dma-buf/reservation.c | 72 ---
include/linux/reservation.h | 53 +++
2 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reserva
Apparently nobody noticed that dma-buf.h wasn't actually pulled into
docbook build. And as a result the headerdoc comments bitrot a bit.
Add missing params/fields.
Signed-off-by: Rob Clark
---
include/linux/dma-buf.h | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --g
A bit overkill since, for example, the rcu_dereference_protected() in
reservation_object_get_list() will WARN. But this is much less subtle
for folks reading the code.
Signed-off-by: Rob Clark
---
drivers/dma-buf/reservation.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dm
Some dma-buf headerdoc fixes (turns out dma-buf.h wasn't getting pulled
into doc build), add reservation headerdoc, and fixup a bit the section
in device-drivers.tmpl.
Rob Clark (4):
reservation: sprinkle some WARN_ON()s
dma-buf: headerdoc fixes
reservation: add headerdoc comments
doc: upd
In the atomic modesetting path, each driver simply wants to grab a ref
to the exclusive fence from a reservation object to store in the incoming
drm_plane_state, without doing the whole RCU dance. Since each driver
will need to do this, lets make a helper.
v2: rename to _rcu instead of _unlocked
On Thu, Mar 31, 2016 at 12:41:10PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Update the UAPI header to the latest version in the Linux kernel. This
> changes the struct drm_tegra_gem_mmap to properly handle offsets on 64-
> bit architectures.
>
> See commit bdf765071a8b ("drm/tegra
Welcome Rob!
On Thu, Mar 31, 2016 at 3:35 PM, Robert Foss wrote:
> Hey,
>
> I'm new to DRM development, but was thinking about getting into the shallow
> side of pool, and doing some DRMJanitors development.
>
> Do you have a preference for a task for me to look at? Is there one that
> would be p
the attached patch fix the problem?
> I would be interested in a fix for the acceleration problem if possible .
Beware that while the kernel side of this might be relatively easy to
fix, making the userspace radeonsi driver work on big endian hosts would
likely require substantial effort.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: radeon-guard-vblank-on-off.diff
Type: text/x-patch
Size: 1914 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/8afc3297/attachment.bin>
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/a846b2b5/attachment.html>
From: Michel Dänzer
Without this, since the conversion from drm_vblank_pre/post_modeset to
drm_vblank_on/off, the vblank interrupt could never be disabled after
userspace triggered enabling it.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 ++
1 file changed, 2
From: Michel Dänzer
Without this, since the conversion from drm_vblank_pre/post_modeset to
drm_vblank_on/off, the vblank interrupt could never be disabled after
userspace triggered enabling it.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
1 file changed, 2
On Thu, 31 Mar 2016 15:35:59 +0200,
Jyri Sarha wrote:
>
> Treat 32 bit sample width as if it was 24 bits when generating IEC958
> channel status bits. On some platforms 24 sample width is problematic
> and to get full 24 bit precision a 32 bit format, using only the 24
> most significant bits, may
On Thu, 31 Mar 2016 15:35:58 +0200,
Jyri Sarha wrote:
>
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.
>
> Signed-off-by: Jyri
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/89d14f4f/attachment.html>
264876
91177308-0d34-0410-b5e6-96231b3b80d8
--
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/20160331/d8a1c3fc/attachment.html>
vm-project/llvm/trunk at 264876
91177308-0d34-0410-b5e6-96231b3b80d8
--
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/20160331/6a8ddfd7/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/fafa5f99/attachment.html>
Hi Archit,
On 29-03-2016 18:03, Archit Taneja wrote:
>
>
> On 3/29/2016 4:22 PM, Jose Abreu wrote:
>> Hi Archit,
>>
>> On 29-03-2016 09:05, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/28/2016 08:06 PM, Jose Abreu wrote:
This patch adds audio support for the ADV7511 HDMI transmitter
using
ceiving 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/20160331/58fe8fcd/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/467d5254/attachment-0001.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/2e594acb/attachment.html>
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impo
eiving 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/20160331/78d4b3f4/attachment.html>
5 = NULL
if ((eax & 0x3ff) != 0) {
// ...
// r15 is set in this block to valid value
// ...
}
// 0x74846845:
rcx = r15->variable_at_offset_0x10 // crash here because r15 can be NULL
}
// function end
--
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/20160331/a340b2f3/attachment.html>
On Fri, Mar 25, 2016 at 02:10:03PM +0100, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add HDMI CEC specific keycodes to the keycodes definition.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
> ---
> include/uapi/linux/input-event-codes.h | 30
From: Thierry Reding
Update the UAPI header to the latest version in the Linux kernel. This
changes the struct drm_tegra_gem_mmap to properly handle offsets on 64-
bit architectures.
See commit bdf765071a8b ("drm/tegra: gem: Return 64-bit offset for
mmap(2)") in the Linux kernel (as of v4.1).
S
Hi Inki,
On 31 March 2016 at 12:26, Inki Dae wrote:
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> On 31 March 2016 at 11:05, Inki Dae wrote:
>>> Then, existing drivers would need additional works for explicit fencing
>>> support. This wouldn't be really what the drivers have to but should be
edesktop.org/archives/dri-devel/attachments/20160331/322db032/attachment.sig>
his might even fix a bug or two.
Thierry
-- next part --
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/20160331/6a5cf18a/attachment.sig>
start 1010, end 1022
error in dmesg.
Using patched kernel.
--
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/20160331/75647
On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
>
> Hi all,
>
> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> som
On Thu, Mar 31, 2016 at 2:46 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Without this, since the conversion from drm_vblank_pre/post_modeset to
> drm_vblank_on/off, the vblank interrupt could never be disabled after
> userspace triggered enabling it.
>
> Signed-off-by: Michel Dänzer
A
On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
You can mix it, if you're careful. CrOS wants
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/09c7c0bb/attachment-0001.html>
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae wrote:
> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>> On 31 March 2016 at 08:45, Inki Dae wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if
>>> explicit fence support is added to the atomic helper framew
nctions shouldn't be there in the first place. We
have helpers in the core that already do this. Most of the functionality
is duplicated in this driver.
I realize that this is a problem that existed in the Exynos DP driver,
but somebody really ought to rewrite those parts to make use of the DRM
DP helpers.
Thierry
-- next part --
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/20160331/5f26b101/attachment-0001.sig>
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
between commit:
257bf15a4b97 ("drm/amdgpu: add slap cache for sync objects as well")
from Linus' tree and commit:
44debe7a123c ("vgacon: dummy implementation for vgacon_text_
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> pwm_config/enable/disable() have been deprecated and should be replaced
> by pwm_apply_state().
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/input/misc/max77693-haptic.c | 23 +--
> 1 file cha
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> Prefix those function as deprecated to encourage all existing users to
> switch to pwm_apply_state().
Why not keep at least some of them as wrappers where we do not need to
chnage several parameters at once? It is much e
Hi Mark,
On 29-03-2016 19:22, Mark Brown wrote:
> On Tue, Mar 29, 2016 at 07:03:01PM +0100, Jose Abreu wrote:
>
>> The major part of this patch is the adding of an ALSA platform driver so that
>> audio comes out of the box in AXS boards but we also added functionalities to
>> the i2s driver and pe
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/354cbb70/attachment.html>
Hi Inki,
On 31 March 2016 at 08:45, Inki Dae wrote:
> 2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>>> In addition, I wonder how explicit and implicit fences could coexist
>>> together.
>>> Rob said,
>>> "Implicit sync ofc remains
On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
> Hi Daniel,
>
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> Hi Inki,
>>
>> On 31 March 2016 at 11:05, Inki Dae wrote:
>>> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
On 31 March 2016 at 08:45, Inki Dae wrote:
> As of now
As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".
v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/ro
On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This is used when reading Display Control capability Registers on the sink
> device.
>
> cc: Jani Nikula
> cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Yetunde Adebisi
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_dp_helper.h | 1 +
On 31 March 2016 at 03:25, Mark yao wrote:
> On 2016å¹´03æ30æ¥ 21:48, Tomeu Vizoso wrote:
>>
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> Also wait for the pending event to complete when a sync
e
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/22fcdcbc/attachment.sig>
On Mon, Mar 28, 2016 at 06:59:58PM -0700, Stefan Agner wrote:
> The Vybrid DCU variant has two independent clock inputs, one
> for the registers (IPG bus clock) and one for the pixel clock.
> Support this distinction in the DCU DRM driver while staying
> backward compatible with devices providing o
If we fail to create the anon file, we need to remember to release the
module reference on the owner.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
drivers/dma-b
On Mon, Mar 28, 2016 at 07:00:00PM -0700, Stefan Agner wrote:
> Add driver for the TCON (timing controller) module. The TCON module
> is a separate module attached after the DCU (display controller
> unit). Each DCU instance has its own, directly connected TCON
> instance. The DCU's RGB and timing
On 2016å¹´03æ30æ¥ 21:48, Tomeu Vizoso wrote:
> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
> updated is requested and there is an earlier updated pending".
>
> Also wait for the pending event to complete when a sync update is
> requested.
>
> Signed-off-by: Tomeu Vizo
Hi,
On Thu, Mar 31, 2016 at 2:56 AM, Thierry Reding wrote:
> Ugh... most of these functions shouldn't be there in the first place. We
> have helpers in the core that already do this. Most of the functionality
> is duplicated in this driver.
>
> I realize that this is a problem that existed in the
Hi,
On Wed, Mar 30, 2016 at 1:32 PM, Guenter Roeck wrote:
> This results in the following build errors if DRM_ANALOGIX_DP
> is configured as module.
>
> ERROR: "analogix_dp_start_video"
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane0_link_traini
On Thu, Mar 31, 2016 at 07:54:18AM +0200, Andrzej Hajda wrote:
> On 03/30/2016 04:03 PM, Jani Nikula wrote:
> > From: Deepak M
> >
> > Adding new DCS commands which are specified in the
> > DCS 1.3 spec related to CABC.
> >
> > v2: Sorted the Macro`s by value (Andrzej)
> >
> > v3 by Jani: sort all
On Wed, Mar 30, 2016 at 09:06:33PM +0100, Emil Velikov wrote:
> On 30 March 2016 at 15:42, Daniel Vetter wrote:
> > This ports the below libdrm commit to the kernel
> >
> > commit 0f4452bb51306024fbf4cbf77d8baab20cefba67
> > Author: Daniel Kurtz
> > Date: Mon Aug 26 23:39:16 2013 +0800
> >
> >
On Wed, Mar 30, 2016 at 05:51:45PM -0300, Gustavo Padovan wrote:
> 2016-03-18 Rob Clark :
>
> Hi Rob,
>
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 15 +--
> > include/drm/drm_atomic_helper.h | 2 ++
> > 2 files changed, 15 insertions(+), 2 de
On 03/30/2016 04:03 PM, Jani Nikula wrote:
> From: Deepak M
>
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> v2: Sorted the Macro`s by value (Andrzej)
>
> v3 by Jani: sort all of enum, refer to MIPI DCS 1.3
>
> Cc: Andrzej Hajda
> Cc: Thierry Reding
> Cc
On 3/31/2016 2:50 AM, Michel Dänzer wrote:
> On 30.03.2016 19:36, Julian Margetson wrote:
>> On 3/29/2016 11:49 PM, Michel Dänzer wrote:
>>> On 29.03.2016 18:55, Julian Margetson wrote:
On 3/28/2016 11:15 PM, Michel Dänzer wrote:
> On 29.03.2016 08:47, Julian Margetson wrote:
>> See
do you need?
--
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/20160331/7963d8ae/attachment.html>
Hi,
> We've fixed piles of those in recent kernels, but didn't backport all the
> fixes (since usually it's a silent failure, but it can correlate with
> black screens).
Not quite completely, it seems ...
I have built drm-intel-nightly (f261f82359), and I'm getting this:
| [ 15.855007] [drm:i
92 matches
Mail list logo