https://bugzilla.kernel.org/show_bug.cgi?id=65911
--- Comment #11 from tomka ---
In another bug report (https://bugzilla.redhat.com/show_bug.cgi?id=990986) it
was suggested to disable glx-tls during build configuration. So I replaced the
line "--enable-glx-tls" with "--disable-glx-tls". However,
On Fri, Nov 29, 2013 at 06:18:58PM +, Thomas Wood wrote:
> Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
> HDMI Vendor Specific Data Block.
>
> v2: Use an offset value depending on 3D_Multi_present and add
> detail_present. (Ville Syrj?l?)
> v3: Make sure the
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/958b4bb6/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/302e400f/attachment.html>
. Anything usefull?
--
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/20131129/fba691fd/attachment.html>
On Fri, Nov 29, 2013 at 03:33:28PM +, Thomas Wood wrote:
> Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
> HDMI Vendor Specific Data Block.
>
> v2: Use an offset value depending on 3D_Multi_present and add
> detail_present. (Ville Syrj?l?)
>
> Signed-off-by:
Hi Shirish,
Please see my comments inline.
On Monday 25 of November 2013 14:24:39 Shirish S wrote:
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
>
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrj?l?)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
present. (Ville
On Friday 29 of November 2013 09:13:19 Rob Clark wrote:
> On Fri, Nov 29, 2013 at 4:10 AM, Tomasz Figa wrote:
> > I would mostly agree with you if we were discussing SoC-internal
> > components here. Mostly, because the ARM world is more complex and you
> > can see the same IP across completely
On 11/28/13 18:45, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20131128:
>
on x86_64:
CONFIG_ACPI is not enabled.
CC drivers/gpu/drm/i915/intel_opregion.o
In file included from drivers/gpu/drm/i915/intel_opregion.c:31:0:
include/linux/acpi_io.h:7:45: error: unknown type name
Hi Sean,
On Tuesday 29 of October 2013 12:13:17 Sean Paul wrote:
> This patch moves the lvds bridge discovery and connector pre-emption
> code from exynos common code into the dp driver (since the bridge is
> only applicable for dp).
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v3:
>
Hi Sean,
On Tuesday 29 of October 2013 12:13:18 Sean Paul wrote:
> This path removes the exynos_drm_connector code since it was just
> passing hooks through display_ops. The individual device drivers are now
> responsible for implementing drm_connector directly.
>
> Signed-off-by: Sean Paul
>
Hi Sean,
On Tuesday 29 of October 2013 12:13:16 Sean Paul wrote:
> This patch implements drm_connector directly in the vidi
> driver, this will allow us to move away from the exynos_drm_connector
> layer.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v3:
> - Added to the patchset
>
Hi Sean,
On Tuesday 29 of October 2013 12:13:15 Sean Paul wrote:
> This patch implements drm_connector directly in the dp driver, this will
> allow us to move away from the exynos_drm_connector layer.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v3:
> - Added to the patchset
>
>
On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote:
> > Additionally the current code is broken in that the upper layer in
> > vm/base.c doesn't increment "pte" by the right amount.
> >
> > Now, if those two assertions can be made always true:
> >
> > - Those two functions (map_sg and
Hi Sean,
On Tuesday 29 of October 2013 12:13:14 Sean Paul wrote:
> This patch implements drm_connector in the hdmi driver directly, instead
> of using exynos_drm_connector.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v3:
> - Added to the patchset
>
>
On 11/27/2013 11:54 AM, Thierry Reding wrote:
> On Mon, Nov 25, 2013 at 04:05:41PM +0100, Andrzej Hajda wrote:
> [...]
+/**
+ * mipi_dsi_device_register - register a DSI device
+ * @dev: DSI device we're registering
+ */
+int mipi_dsi_device_register(struct mipi_dsi_device
Hi Sean,
On Tuesday 29 of October 2013 12:13:12 Sean Paul wrote:
> This patch removes all of the suspend/resume logic from the individual
> drivers and consolidates it in drm_drv. This consolidation reduces the
> number of functions which enable/disable the hardware to just one -- the
> dpms
use:
You are the assignee for the bug.
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/7cab042b/attachment.html>
both runs once I'll have set back
mclk to its default value.
--
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/20131129/23b18831/attachment.html>
On Wed, Nov 06, 2013 at 01:46:41PM +1000, Dave Airlie wrote:
> On Wed, Oct 30, 2013 at 4:06 AM, wrote:
> > So I took another look at the vblank timestamping code, and got a bit
> > excited. The result is this patchset.
>
> I'd like to merge this, I was hoping Mario could ack it at least as it
>
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrj?l?)
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_edid.c | 64
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_edid.c | 67 +++---
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0a1e4a5..f1d6e1e 100644
--- a/drivers/gpu/drm/drm_edid.c
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52e060e..0a1e4a5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2674,7 +2674,7
Here's an updated series of patches taking into account Ville's review.
Regards,
Thomas
pplication/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/7a886112/attachment.pgp>
be removed.
Ah, there it is!
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/2d85e249/attachment.pgp>
t here the linux/clk/tegra.h include can again be dropped.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/f826b445/attachment.pgp>
On Wed, Nov 27, 2013 at 06:24:08PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Sometimes we want to disable all the screens on a system, because that
> will allow the graphics card to be put into low-power states. The
> problem is that, for example, while all screens are disabled, if we
On Fri, Nov 29, 2013 at 12:05 PM, Tomasz Figa wrote:
> On Friday 29 of November 2013 09:13:19 Rob Clark wrote:
>> On Fri, Nov 29, 2013 at 4:10 AM, Tomasz Figa
>> wrote:
>> > I would mostly agree with you if we were discussing SoC-internal
>> > components here. Mostly, because the ARM world is
On Fri, Nov 29, 2013 at 10:10 AM, Tomasz Figa wrote:
> I would mostly agree with you if we were discussing SoC-internal
> components here. Mostly, because the ARM world is more complex and you
> can see the same IP across completely different SoCs from different
> vendors.
Yeah, hence the
ook it likely doesn't ship with a completely
mainline kernel. That frees it from the stability requirements, doesn't
it?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/42198eb9/attachment.pgp>
p with a much better
solution than at this point in time.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/f97dfc52/attachment.pgp>
On Thu, Nov 28, 2013 at 09:08:45PM +0100, Jan Engelhardt wrote:
> On Wednesday 2013-11-27 12:08, Chris Wilson wrote:
> >On Wed, Nov 27, 2013 at 11:59:56AM +0100, Jan Engelhardt wrote:
> >>
> >> Despite the i915/drm fixes added in v3.11.8, the X server still
> >> terminates due to some pipe state
On Friday 29 of November 2013 08:52:22 Daniel Vetter wrote:
> On Fri, Nov 29, 2013 at 12:04:04AM +0100, Tomasz Figa wrote:
> > On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote:
> > > More like code written in the same style as x86 DRM stuff, where
> > > they're not used to
On Fri, Nov 29, 2013 at 4:10 AM, Tomasz Figa wrote:
> I would mostly agree with you if we were discussing SoC-internal
> components here. Mostly, because the ARM world is more complex and you
> can see the same IP across completely different SoCs from different
> vendors.
>
> However, the topic
On Thu, Nov 28, 2013 at 09:08:45PM +0100, Jan Engelhardt wrote:
> On Wednesday 2013-11-27 12:08, Chris Wilson wrote:
> >On Wed, Nov 27, 2013 at 11:59:56AM +0100, Jan Engelhardt wrote:
> >>
> >> Despite the i915/drm fixes added in v3.11.8, the X server still
> >> terminates due to some pipe state
On Fri, Nov 29, 2013 at 12:04:04AM +0100, Tomasz Figa wrote:
> On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote:
> > More like code written in the same style as x86 DRM stuff, where
> > they're not used to overabstracting things from day one to make things
> > generic instead of
u 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/20131129/d75c4009/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/3e4f1b74/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=65911
--- Comment #10 from tomka ---
Oops, I figured the last dmesg log lines were truncated. Here they are again:
[ 170.607701] radeon :00:01.0: GPU lockup CP stall for more than 1msec
[ 170.607711] radeon :00:01.0: GPU lockup (waiting
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/3cd6bffe/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=65121
--- Comment #7 from Matthew Stapleton ---
It looks like that fixes it. Thanks. Also, I'm only running on console, X
isn't running.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Does this patch help?
>
> --
> 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.
-- next part --
An HTML attachment was scr
sktop.org/archives/dri-devel/attachments/20131129/a6b252d9/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131129/693ee7be/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131129/b2c1331f/attachment.html>
On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote:
> On Tue, Nov 12, 2013 at 10:35 AM, Tomasz Figa
> wrote:
> > On Tuesday 12 of November 2013 12:51:11 Sean Paul wrote:
> >> On Sun, Nov 10, 2013 at 4:09 PM, Tomasz Figa
> >> wrote:
> >> > Hi Sean,
> >> >
> >> > On Tuesday 29 of
48 matches
Mail list logo
