You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/6669c774/attachment.html>
e been busy with other
things lately, but I could give it a go in the next week.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attach
On 23/01/15 16:17, Frank Binns wrote:
> Ping
>
Thanks for the patches and reminder Frank.
I've pushed these to master with Rob's r-b.
Cheers,
Emil
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #20 from Gustaw Smolarczyk ---
I will try that on Sunday since I have no access to the radeonsi hardware at
the moment.
--
You are receiving this mail because:
You are watching the assignee of the bug.
all,
On Tue, Jan 20, 2015 at 06:48:42AM +0100, Daniel Vetter wrote:
> On Mon, Jan 19, 2015 at 08:40:24AM -0800, Matt Roper wrote:
> > On Mon, Jan 19, 2015 at 11:04:04AM +, Chris Wilson wrote:
> > > On Mon, Jan 19, 2015 at 11:51:43AM +0100, Daniel Vetter wrote:
> > > > There's also an issue in
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/237a5e12/attachment.html>
a trace using the LLVM backend, please let me know.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/d1b60f1b/attachment.html>
ll hardware may support transferring 16 bytes at a time. How
does that work with these adapters? Does it mean they can't work on DP
hardware that can't do 16 byte block transfers?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/3761dd96/attachment.sig>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/911b306f/attachment.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/0d1add39/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150123/2abd89fa/attachment.html>
On Fri, Jan 23, 2015 at 06:40:38PM +, Simon Farnsworth wrote:
> DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> their I2C over AUX implementation. They work fine with Windows, but fail
> with Linux.
>
> It turns out that they cannot keep an I2C transaction open unles
formats and num_formats arguments were previously called fmts and nfmts.
Fix the kernel doc comment so that it matches the new argument names.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm
https://bugzilla.kernel.org/show_bug.cgi?id=71051
Thomas J. Moore changed:
What|Removed |Added
CC||darktjm at gmail.com
--- Comment #16 fr
The atmel-hlcdc driver selects DRM_GEM_CMA_HELPER which makes use of
symbols only available when HAVE_DMA_ATTRS is selected.
Add a dependency on the ARM architecture which select this option.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/atmel-hlcdc/Kconfig | 2 +-
1 file changed, 1 inserti
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #19 from Maarten Lankhorst ---
Created attachment 164511
--> https://bugzilla.kernel.org/attachment.cgi?id=164511&action=edit
Clear irqs before processing.. Patch on top of 'another approach'
Can you try with the irq_put/get lines c
https://bugzilla.kernel.org/show_bug.cgi?id=91861
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
their I2C over AUX implementation. They work fine with Windows, but fail
with Linux.
It turns out that they cannot keep an I2C transaction open unless the
previous read was 16 bytes; shorter reads can only be followed by a ze
From: Lucas Stach
On systems without a mux between the IPU display interfaces
and the LVDS channels it isn't possible to infer the DI
number from the LDB port numbers, but have a static 1:1
mapping.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/imx-ldb.c | 17
On i.MX53, the DI0 clock can only be sourced from ldb_di0, and
the DI1 clock can only be sourced from ldb_di1. i.MX6q does not
have this limitation.
Luckily, in split mode both ldb_di0 and ldb_di1 have to be
synchronous, so we can choose either one of them as source for
the display interface. imx_l
Commit eb10d6355532 ("imx-drm: encoder prepare/mode_set must use adjusted mode")
broke the first LVDS modeset by using crtc->hwmode before crtc mode_set is
called. In fact, encoder prepare is not supposed to prepare the display clock
at all. Rather encoder mode_set should be used to set the DI cloc
On Mon, Jan 19, 2015 at 05:53:20PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> If the image size would ever read as 0, pci_get_rom_size could keep
> processing the same image over and over again.
>
> Reported-by: Federico
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänz
Am Freitag, den 23.01.2015, 14:27 -0200 schrieb Fabio Estevam:
> Hi Philipp,
>
> On Fri, Jan 23, 2015 at 2:18 PM, Philipp Zabel
> wrote:
> > @@ -281,6 +267,9 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder
> > *encoder,
> > struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/dc0c643e/attachment.html>
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/da6ab9de/attachment.html>
The amazing 2015 linux.conf.au video team has already posted all the videos
from the talks at this years conference - you can find them on their YouTube
channel at https://www.youtube.com/user/linuxconfau2015 or via the links on
http://lca2015.linux.org.au/
Talks of particular relevance to Xorg, D
Am Freitag, den 23.01.2015, 13:06 -0200 schrieb Fabio Estevam:
> On Fri, Jan 23, 2015 at 12:56 AM, Liu Ying wrote:
> > Hi,
> >
> > It looks that the below commit makes my Hannstar XGA LVDS panel stop working
> > on the i.MX6DL SabreSD board. Any idea?
>
> Yes, with eb10d6355532def3a ("mx-drm: en
From: Thierry Reding
This small program allows universal planes to be tested. Currently this
isn't very flexible because it allows only the first plane of a given
type to be tested on the first CRTC. However it should be simple to
extend this with some additional command-line arguments.
Signed-o
From: Thierry Reding
This test program sets a mode and framebuffer on a connector and cycles
through all CRTCs, moving the connector to each of them in turn. This is
useful to verify that CRTC stealing is properly handled in the DRM core
and drivers.
Signed-off-by: Thierry Reding
---
tests/kms
From: Thierry Reding
This library contains abstractions for KMS that help remove the need for
a lot of boilerplate in KMS test programs.
Signed-off-by: Thierry Reding
---
configure.ac| 1 +
tests/Makefile.am | 2 +-
tests/kms/Makefile.am
From: Thierry Reding
Allow connector names to be used in the specification of the -s option.
This requires storing the string passed on the command-line so that it
can later be resolved to a connector ID (after the DRM device has been
opened).
Signed-off-by: Thierry Reding
---
tests/modetest/m
From: Thierry Reding
This brings xf86drmMode.h in sync with include/drm/drm_mode.h.
Eventually we really should only have a single set of definitions rather
than duplicating this in two files.
Signed-off-by: Thierry Reding
---
xf86drmMode.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/x
From: Thierry Reding
Signed-off-by: Thierry Reding
---
xf86drmMode.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 856a6bb0f569..e70c16d437f4 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -123,13 +123,13 @@ extern "C
From: Thierry Reding
These tables are duplicated in several places, so move them into libutil
so that they can be shared.
Signed-off-by: Thierry Reding
---
tests/modetest/modetest.c | 50 ++-
tests/proptest/Makefile.am | 4 +-
tests/proptest/proptest.c | 40 +-
From: Thierry Reding
Some of the helpers, such as the pattern drawing helpers or the format
lookup helpers, have potential to be reused. Move them into a separate
library to make it easier to share them.
Signed-off-by: Thierry Reding
---
configure.ac| 1 +
tests/Makefile.am
From: Thierry Reding
Signed-off-by: Thierry Reding
---
xf86drmMode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 7e228b3e7aa3..3d6b9cc307d1 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -250,7 +250,7 @@ err_allocs:
}
int drm
From: Thierry Reding
Usage of blank lines can be a matter of taste, of course, but for these
we can surely all agree that they're not needed and inconsistent.
Signed-off-by: Thierry Reding
---
xf86drmMode.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/xf86drmMode.c b/xf86drm
From: Thierry Reding
Fixes a few complaints raised by valgrind when running the Tegra tests.
Signed-off-by: Thierry Reding
---
xf86drmMode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 60ce3699f3e3..f6e4416b88b5 100644
--- a/xf86drmMode.c
+++ b/xf8
From: Thierry Reding
This is a stash of commits that I've been carrying for a couple months.
Laurent really wanted to have the connector name patch for modetest so
I thought I'd send them all out for review.
Thierry
Thierry Reding (11):
libdrm: valgrind-clear a few more IOCTL arguments
libd
From: Donghwa Lee
This patch adds MIPI-DSI based S6E3HA2 panel driver. This panel has
1440x2560 resolution in 5.7-inch physical panel. This panel was
selected for Galaxy Note 4.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Cc: Inki Dae
Cc: Sangbae Lee
---
.../devicetree/bindings
Hi Dave,
Just flushing out my drm-misc branch, nothing major. Well too old patches
I've dug out from years since a patch from Rob look eerily familiar ;-)
I'm cooking some more atomic patches that I'd like to sneak into 3.20, but
still need a bit more testing. I'll send the pull for that next wee
Hi Dave,
drm-intel-next-2015-01-17:
- refactor i915/snd-hda interaction to use the component framework (Imre)
- psr cleanups and small fixes (Rodrigo)
- a few perf w/a from Ken Graunke
- switch to atomic plane helpers (Matt Roper)
- wc mmap support (Chris Wilson & Akash Goel)
- smaller things all
Ping
On 14/01/15 14:07, Frank Binns wrote:
> Now that there are render nodes it doesn't seem appropriate for the type of
> the card nodes to be DRM_NODE_RENDER. For this reason, rename this type to
> DRM_NODE_PRIMARY as this name better represents the purpose of these nodes.
>
> Signed-off-by: Fra
Ajay Kumar wrote:
>
> Define videoports and use endpoints to describe the connection between
> the encoder, bridge and the panel, instead of using phandles.
>
> Signed-off-by: Ajay Kumar
> Acked-by: Inki Dae
> Tested-by: Rahul Sharma
> Tested-by: Javier Martinez Canillas
> Tested-by: Gustavo
Hi Dave,
The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:
Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22
10:44:41 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-3.20-rc1
for yo
Hi Dave,
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-3.20-rc1
for you to fetch changes up to c618c446adffebd4a059
n't actually boot though, it got
> stuck shortly after or during DRM probing:
>
> http://arm-soc.lixom.net/bootlogs/next/next-20150123/minnowmax-x86-minnowmax_defconfig.html
>
> I bisected it down to the below patch that I failed to find posted
> (with that subject) anywhere on a
On Fri, Jan 23, 2015 at 2:39 PM, Philipp Zabel
wrote:
> Am Freitag, den 23.01.2015, 14:27 -0200 schrieb Fabio Estevam:
>> Hi Philipp,
>>
>> On Fri, Jan 23, 2015 at 2:18 PM, Philipp Zabel
>> wrote:
>> > @@ -281,6 +267,9 @@ static void imx_ldb_encoder_mode_set(struct
>> > drm_encoder *encoder,
>
Kees Cook writes:
> On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell
> wrote:
>> Oded Gabbay writes:
>>> On 12/24/2014 01:01 AM, Rusty Russell wrote:
Oded Gabbay writes:
> I didn't say it doesn't always work.
> The actual thing that doesn't work is the define symbol_get and only in a
Hi Philipp,
On Fri, Jan 23, 2015 at 2:18 PM, Philipp Zabel
wrote:
> @@ -281,6 +267,9 @@ static void imx_ldb_encoder_mode_set(struct drm_encoder
> *encoder,
> struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
> struct imx_ldb *ldb = imx_ldb_ch->ldb;
> int d
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/282f1230/attachment.html>
Hi Daniel, Mika,
For the first time in a few days, -next was bootable last night. I
noticed that my Minnowboard Max didn't actually boot though, it got
stuck shortly after or during DRM probing:
http://arm-soc.lixom.net/bootlogs/next/next-20150123/minnowmax-x86-minnowmax_defconfig.ht
On Fri, Jan 23, 2015 at 12:56 AM, Liu Ying wrote:
> Hi,
>
> It looks that the below commit makes my Hannstar XGA LVDS panel stop working
> on the i.MX6DL SabreSD board. Any idea?
Yes, with eb10d6355532def3a ("mx-drm: encoder prepare/mode_set must
use adjusted mode") applied
the DI clock is 0:
-
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named()
Hi Philipp,
On Fri, Jan 23, 2015 at 8:50 AM, Philipp Zabel
wrote:
> What are this panel timings? The adjustment should increase the vertical
> back porch by up to two lines (so it is at least two lines), reducing
> the front porch or vsync length by the same amount. Does this panel use
> the HS
On 01/23/2015 12:03 PM, Boris Brezillon wrote:
> The atmel-hlcdc driver selects DRM_GEM_CMA_HELPER which makes use of
> symbols only available when HAVE_DMA_ATTRS is selected.
> Add a dependency on the ARM architecture which select this option.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/92a5d515/attachment-0001.html>
Hi Liu,
Am Freitag, den 23.01.2015, 10:56 +0800 schrieb Liu Ying:
> Hi,
>
> It looks that the below commit makes my Hannstar XGA LVDS panel stop working
> on the i.MX6DL SabreSD board. Any idea?
>
> commit eb10d6355532def3a74aaabd115e2373cca70b9d
> Author: Steve Longerbeam
> Date: Thu Dec 18
On Wed, Jan 14, 2015 at 9:07 AM, Frank Binns wrote:
> Now that there are render nodes it doesn't seem appropriate for the type of
> the card nodes to be DRM_NODE_RENDER. For this reason, rename this type to
> DRM_NODE_PRIMARY as this name better represents the purpose of these nodes.
>
> Signed-of
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/37ab5fa9/attachment.html>
VT switch back/forth from console to xserver (for example) has potential
to go horribly wrong if a dynamic DP MST connector ends up in the saved
modeset that is restored when switching back to fbcon.
When removing a dynamic connector, don't forget to clean up the saved
state.
Bugzilla: https://bu
On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kamil Debski wrote:
> Add the CEC framework.
-snip-
> +Remote control handling
> +---
> +
> +The CEC framework provides two ways of handling the key messages of remote
> +control. In the first case, the CEC framework will handle these me
Hi,
It looks that the below commit makes my Hannstar XGA LVDS panel stop working
on the i.MX6DL SabreSD board. Any idea?
commit eb10d6355532def3a74aaabd115e2373cca70b9d
Author: Steve Longerbeam
Date: Thu Dec 18 18:00:24 2014 -0800
imx-drm: encoder prepare/mode_set must use adjusted mode
The
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/436f8f68/attachment.html>
From: Daniel Kurtz
The 'mode' is the modeline information which specifies the ideal mode
requested by the mode set initiator (usually userspace).
The 'adjusted_mode' is the actual hardware mode after all the crtcs
and encoders have had a chance to "fix it up".
The adjusted_mode starts as a dupli
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off
From: Gustavo Padovan
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b
From: Gustavo Padovan
exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
from the underlying layer. However neither one of these layers implement
win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
is pointless.
Signed-off-by: Gustavo Padovan
---
driver
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
From: Gustavo Padovan
The drm_file event_list hasn't been used anymore by exynos, so we don't
need any code to clean it.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b
rm tree. At least that's the typical
> workflow that usually works for everyone.
I will be sending out a pull request today, so I'm not going to include
this patch or the dependent patch. I'll pick it up again after the merge
window and see if I need to rebase it on top of Tomeu's work.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/f4499650/attachment.sig>
->crtc
> might be NULL, and hiding that isn't a good idea.
>
> If you have a atomic_plane_disable hook then ->crtc is guaranteed to be
> non-NULL in atomic_plane_update, but being explicit here is imo a feature.
> So nacked from my side.
I've dropped this pat
From: Thierry Reding
Wrap struct drm_crtc_state in a driver-specific structure and add the
planes field which keeps track of which planes are updated or disabled
during a modeset. This allows atomic updates of the the display engine
at ->atomic_flush() time.
v2: open-code getting the state of th
From: Thierry Reding
In order to prevent drivers from having to perform the same checks over
and over again, add an optional ->atomic_disable callback which the core
calls under the right circumstances.
v2: pass old state and detect edges to avoid calling ->atomic_disable on
already disabled pla
From: Thierry Reding
There is no use-case where it would be useful for drivers not to
implement this function and the transitional plane helpers already
require drivers to provide an implementation.
v2: add new requirement to kerneldoc
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
to kerneldoc that it's mandatory is probably the best
we can do here.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/515b004c/attachment.sig>
On Thu, Jan 22, 2015 at 6:29 PM, Mark Yao wrote:
> drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
> but vop only have enable/disable mode, maybe case such bug:
> --> DRM_DPMS_ON: power on vop
> --> DRM_DPMS_SUSPEND: power off vop
> --> DRM_DPMS_OFF: already power off at SUSPEND, c
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/f7afbf17/attachment.html>
The atomic helpers rely on drm_atomic_state_clear() to reset an atomic
state if a retry is needed due to the w/w mutexes. The subsequent calls
to drm_atomic_get_{crtc,plane,...}_state() would then return the stale
pointers in state->{crtc,plane,...}_states.
Signed-off-by: Ander Conselvan de Olivei
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/da620cc0/attachment.html>
From: Thierry Reding
The current implementation is limited by the number of addresses that
fit into an unsigned long. This causes problems on 32-bit Tegra where
unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB
On Fri, Jan 23, 2015 at 09:27:59AM +0200, Ander Conselvan de Oliveira wrote:
> The atomic helpers rely on drm_atomic_state_clear() to reset an atomic
> state if a retry is needed due to the w/w mutexes. The subsequent calls
> to drm_atomic_get_{crtc,plane,...}_state() would then return the stale
>
Hello,
On 2015-01-23 00:19, Tobias Jakobi wrote:
> Marek Szyprowski wrote:
>> If system provides IOMMU feature, Exynos DRM should use it by default,
>> because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
>> driver has been enabled and no IOMMU support has been compiled into Ex
https://bugzilla.kernel.org/show_bug.cgi?id=91861
--- Comment #1 from Mike S. ---
Sorry, the Ubuntu versions should be 14.04 & 14.10 of course.
Mike
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=91861
Bug ID: 91861
Summary: [Radeon RS780] Blank screen (no signal) on HDMI after
boot in 3.15 & later
Product: Drivers
Version: 2.5
Kernel Version: 3.15 + later
Hardware: In
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/f7f5cd31/attachment-0001.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/aaea63d7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90861
Michel Dänzer changed:
What|Removed |Added
CC||bugs at mblankhorst.nl
--- Comment #11 f
The series are Reviewed-by: Jammy Zhou
Regards,
Jammy
-Original Message-
From: Gabbay, Oded
Sent: Thursday, January 22, 2015 6:59 PM
To: dri-devel at lists.freedesktop.org; Zhou, Jammy
Cc: alexdeucher at gmail.com
Subject: [PATCH v2 0/3] Fix bugs related to init pipelines
Following com
/WINE
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150123/6040e05b/attachment.html>
Hello!
Marek Szyprowski wrote:
> If system provides IOMMU feature, Exynos DRM should use it by default,
> because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
> driver has been enabled and no IOMMU support has been compiled into Exynos
> DRM driver.
>
> Signed-off-by: Marek Sz
91 matches
Mail list logo
