the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/45962288/attachment-0001.html>
On Sun, Feb 2, 2014 at 10:43 PM, Alexandre Courbot wrote:
> On Sun, Feb 2, 2014 at 8:58 AM, Lucas Stach wrote:
>> Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin:
>>> On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach wrote:
>>> > Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Co
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #36 from Hohahiu ---
(In reply to Alex Deucher from comment #35)
> (In reply to Christoph Haag from comment #33)
> > But I have an awful lot of this block in dmesg, I guess from every time
> > starting X:
>
> Those are the messages fr
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #35 from Alex Deucher ---
(In reply to Christoph Haag from comment #33)
> But I have an awful lot of this block in dmesg, I guess from every time
> starting X:
Those are the messages from the driver each time the card is powered off o
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #34 from Hohahiu ---
(In reply to Christoph Haag from comment #33)
> Created attachment 125111 [details]
> possibly call chain that calls radeon stuff
>
> @ Hohahiu
>
> Do you mean those?
> [ 8077.648324] [drm:si_dpm_set_power_state]
Address of the ENG_RUNLIST register should be 0x002284 + (engine * 8),
not 0x002284 + (engine * 4).
Signed-off-by: Alexandre Courbot
---
Stumbled upon this one and I'm quite certain the offset was not correct.
This is inconsequential for GK20A which only features one runlist, but
other GPUs might
If the number of connectors changes, then it is possible for the fbdev
helper to overrun/underrun some arrays which it allocates. It allocates
these arrays based on mode_config.num_connector but then walks lists
using fb_helper->connector_count to limit the array index. This can
lead to writes of
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/cfd940f6/attachment.html>
RL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/0c6f3b81/attachment.html>
David,
Please incorporate the latest TDA998x I2C driver fixes, which can be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git tda998x-fixes
with SHA1 2e9a3fc3a360ac180f5b4c3c4416a0d0dec60dd8, based on v3.13.
These are a number of fixes from the patch set which Jean-Francois has
been w
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
Here's my changes to the TDA998x
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140207/9887a737/attachment.html>
ck:1708 invalid cmd stream
[ 377.460566] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
This is with libdrm 2.4.52 and Mesa f47e5.
--
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/20140207/041adafa/attachment.html>
On Fri, 7 Feb 2014 17:33:26 +
Russell King - ARM Linux wrote:
> On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > This patch series tries to simplify the code of simple devices in case
> > they are part of componentised subsystems, are declared in a DT, and
> > are not
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/2137d307/attachment.html>
From: Sagar Kamble
With clipped sprites these transformations are not working. these
functions transform complete sprite irrespective of clipping present.
This leads to invisible portion of sprite show up when rotate 180 if
it was out of visible area before.
v4: Moved rotate transform for source
From: Sagar Kamble
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing
From: Ville Syrj?l?
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
Signed-off-by: Ville Syrj?l?
Tested-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/
From: Ville Syrj?l?
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Signed-off-by: Ville Syrj?l?
Tested-by: Sagar Kamble
---
drivers/gpu/drm/i915/intel_drv.h| 2 +-
driver
From: Ville Syrj?l?
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
Si
From: Ville Syrj?l?
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope
From: Ville Syrj?l?
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Signed-off-by: Ville Syrj?l?
Tested-by: Sagar Kamble
---
drivers/gpu/drm/drm_rect.c | 140
From: Ville Syrj?l?
Use the new drm_mode_create_rotation_property() in omapdrm.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/omapdrm/omap_plane.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/o
From: Ville Syrj?l?
Add a function to create a standards compliant rotation property.
v4: For creating rotation bitmask property send number of values
as only number of set rotations
Signed-off-by: Ville Syrj?l?
Signed-off-by: Sagar Kamble
Tested-by: Sagar Kamble
---
drivers/gpu/drm/drm_crt
From: Ville Syrj?l?
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
Si
From: Ville Syrj?l?
The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Signed-off-by: Ville Syrj?l?
Tested-by: Sagar Kamble
---
drivers/gpu/drm/omapdrm/omap_drv.h | 7 ---
include/drm/drm_crtc.h | 8
2 fi
From: Sagar Kamble
These patches will enable 180 degree rotation for CRTC and Sprite planes.
Changelog:
1. drm/i915: Add 180 degree primary plane rotation support
Addressed review comments for CRTC rotation from FBC, page flip, CRTC active/
inactive perspective.
2. drm/i915: Calling rotate and in
On Fri, Feb 07, 2014 at 07:42:04PM +0100, Jean-Francois Moine wrote:
> On Fri, 7 Feb 2014 17:33:26 +
> Russell King - ARM Linux wrote:
>
> > On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> > > This patch series tries to simplify the code of simple devices in case
> > >
P_);
+ }
}
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/305ff395/attachment.pgp>
This patch series tries to simplify the code of simple devices in case
they are part of componentised subsystems, are declared in a DT, and
are not using the component bin/unbind functions.
Jean-Francois Moine (2):
drivers/base: permit base components to omit the bind/unbind ops
drivers/base:
*** BLURB HERE ***
Jean-Francois Moine (2):
drivers/base: permit base components to omit the bind/unbind ops
drivers/base: declare phandle DT nodes as components
drivers/base/component.c | 21 +++--
drivers/base/core.c | 18 ++
include/linux/of.h |
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/6f510f10/attachment-0001.html>
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT
At system startup time, some devices depends on the availability of
some other devices before starting. The infrastructure for componentised
subsystems permits to handle this dependence, each driver defining
its own role.
This patch does an automatic creation of the lowest components in
case of DT
On Fri, Feb 07, 2014 at 05:53:27PM +0100, Jean-Francois Moine wrote:
> At system startup time, some devices depends on the availability of
> some other devices before starting. The infrastructure for componentised
> subsystems permits to handle this dependence, each driver defining
> its own role.
On Fri, Feb 07, 2014 at 04:55:00PM +0100, Jean-Francois Moine wrote:
> Some simple components don't need to do any specific action on
> bind to / unbind from a master component.
>
> This patch permits such components to omit the bind/unbind
> operations.
>
> Signed-off-by: Jean-Francois Moine
>
On Fri, Feb 07, 2014 at 06:11:08PM +0100, Jean-Francois Moine wrote:
> This patch series tries to simplify the code of simple devices in case
> they are part of componentised subsystems, are declared in a DT, and
> are not using the component bin/unbind functions.
I wonder - I said earlier today t
device. So the
above patch won't help in Borislav's case. I'm looking into this issue
anyway.
--Imre
> -Daniel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/25b5fc53/attachment.pgp>
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 delet
Some simple components don't need to do any specific action on
bind to / unbind from a master component.
This patch permits such components to omit the bind/unbind
operations.
Signed-off-by: Jean-Francois Moine
---
drivers/base/component.c | 9 +++--
1 file changed, 7 insertions(+), 2 delet
On Fri, Feb 07, 2014 at 05:32:06PM +0200, Imre Deak wrote:
> I just realized it's a different issue, since it's on the init path.
> Also we set the drm device as the parent for the sdvo i2c adapter as
> opposed to the dp i2c adapter where it's the connector device. So the
> above patch won't help i
I noticed that the hotplug IOTCLs were removed. How are monitor hotplug events
captured?
Thanks,
- Rian
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/2d11c6c8/attachment.html>
On Fri, Feb 07, 2014 at 07:15:05PM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> These patches will enable 180 degree rotation for CRTC and Sprite planes.
> Changelog:
> 1. drm/i915: Add 180 degree primary plane rotation support
> Addressed review comments for CRTC rotation f
On Fri, Feb 07, 2014 at 12:28:09PM +0100, Borislav Petkov wrote:
> On Fri, Feb 07, 2014 at 01:12:22PM +0200, Imre Deak wrote:
> > On Fri, 2014-02-07 at 13:04 +0200, Jani Nikula wrote:
> > > Imre, is this the same i2c_del_adapter issue you're looking at? Any
> > > patches to try yet?
> >
> > It loo
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/0b7c4df9/attachment.html>
ed the output of the piglit all_cl tests for both the 6750M
and the R9 270X.
--
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/20140207/fcde4dd5/attachment.html>
On Fri, 7 Feb 2014, Daniel Vetter wrote:
> Sorry for missing your report here. Before we disable this again for
> gen4 I want to make sure that it's the same irq misrouting issue which
> was already the cause for the gmbus irq mess. Can you please boot with
> pci=nomsi (so that i915 uses irq16)?
>
On Fri, Feb 7, 2014 at 2:40 PM, Jiri Kosina wrote:
> On Fri, 7 Feb 2014, Jani Nikula wrote:
>
>> >> > git://people.freedesktop.org/~airlied/linux drm-next
>> >> [ ... snip ... ]
>> >> > Daniel Vetter (59):
>> >> [ ... snip ... ]
>> >> > drm/i915: dp aux irq support for g4x/vlv
>> >>
>> >>
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #33 from Christoph Haag ---
Created attachment 125111
--> https://bugzilla.kernel.org/attachment.cgi?id=125111&action=edit
possibly call chain that calls radeon stuff
@ Hohahiu
Do you mean those?
[ 8077.648324] [drm:si_dpm_set_powe
On Fri, 7 Feb 2014, Jani Nikula wrote:
> >> > git://people.freedesktop.org/~airlied/linux drm-next
> >> [ ... snip ... ]
> >> > Daniel Vetter (59):
> >> [ ... snip ... ]
> >> > drm/i915: dp aux irq support for g4x/vlv
> >>
> >> This commit causes all kinds of havoc on my ThinkPad x200s. I
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #18 from Jan Outhuis ---
Okay, I did a test on that. It appears that 3.12.0 is also 'bad' on
radeon.dpm=1. Boot hangs in the same way as with 3.13.
So there's no use in bisecting this issue any further for the moment:
none of the avai
2014-02-07 Olof Johansson :
> On Thu, Jan 30, 2014 at 1:18 PM, Sean Paul wrote:
>> This patchset refactors parts of the exynos driver to move it closer to a
>> proper
>> drm driver (rather than just implementing a drm layer on top of the hardware
>> drivers). The hope is to get to a point where t
0.661746] [] ret_from_fork+0x7c/0xb0
> > [0.661828] [] ? rest_init+0xd0/0xd0
> > [0.747947] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit
> > banging on pin 5
> > [0.758745] fbcon: inteldrmfb (fb0) is primary device
> >
> > --
> > Regards/Gruss,
> > Boris.
> >
> > Sent from a fat crate under my desk. Formatting is fine.
> > --
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140207/0ee68aab/attachment.pgp>
On Fri, 07 Feb 2014, Jiri Kosina wrote:
> On Thu, 30 Jan 2014, Jiri Kosina wrote:
>
>> > git://people.freedesktop.org/~airlied/linux drm-next
>> [ ... snip ... ]
>> > Daniel Vetter (59):
>> [ ... snip ... ]
>> > drm/i915: dp aux irq support for g4x/vlv
>>
>> This commit causes all kinds o
Imre, is this the same i2c_del_adapter issue you're looking at? Any
patches to try yet?
BR,
Jani.
On Fri, 07 Feb 2014, Borislav Petkov wrote:
> Hi guys,
>
> so I'm seeing this on rc1 + tip during boot:
>
> [0.558106] Linux agpgart interface v0.103
> [0.558283] [drm] Initialized drm 1.1
On Fri, 7 Feb 2014 09:46:56 +
Russell King - ARM Linux wrote:
> On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote:
> > I've chatted a bit with Hans Verkuil about this topic at fosdem and
> > apparently both v4l and alsa have something like this already in their
> > helper librarie
Hi Dave,
This pull request fixes memory leak issue in exynos_drm_open() and
multiplatform breakage for ipp/gsc. And also including some cleanups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 7c4c62a04a2a80e3feb5d6c97aca1e413b11c790
Hello Alex Deucher,
The patch d03f5d5971f2: "drm/radeon: fixes for r6xx/r7xx gfx init"
from Feb 19, 2010, leads to the following static checker warning:
drivers/gpu/drm/radeon/r600_cp.c:885 r600_gfx_init()
warn: right shifting to zero
drivers/gpu/drm/radeon/r600_cp.c
879
On Fri, Feb 07, 2014 at 12:57:21PM +0100, Jean-Francois Moine wrote:
> I started to use your code (which works fine, thanks), and it avoids a
> lot of problems, especially, about probe_defer in a DT context.
>
> I was wondering if your componentised mechanism could be extended to the
> devices def
On Fri, Feb 07, 2014 at 01:12:22PM +0200, Imre Deak wrote:
> On Fri, 2014-02-07 at 13:04 +0200, Jani Nikula wrote:
> > Imre, is this the same i2c_del_adapter issue you're looking at? Any
> > patches to try yet?
>
> It looks like the same issue yes. The following patch fixed it for me:
>
> http://
Hi Sean,
On 30.01.2014 22:18, Sean Paul wrote:
> This patchset refactors parts of the exynos driver to move it closer to a
> proper
> drm driver (rather than just implementing a drm layer on top of the hardware
> drivers). The hope is to get to a point where the dp/hdmi drivers can
> implement
>
On Fri, Feb 07, 2014 at 09:22:37AM -0800, Colin Cross wrote:
> On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
> wrote:
> > On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
> >> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote:
> >> > dma_buf_map_attachment and dma_buf_vmap can ret
On Thu, 30 Jan 2014, Jiri Kosina wrote:
> > git://people.freedesktop.org/~airlied/linux drm-next
> [ ... snip ... ]
> > Daniel Vetter (59):
> [ ... snip ... ]
> > drm/i915: dp aux irq support for g4x/vlv
>
> This commit causes all kinds of havoc on my ThinkPad x200s. It results in
[ ... s
Compared to original fixes pull req that I sent yesterday, this adds
one more fix that I found for a synchronization issue which starts to
crop up when we use XA in DDX for 2d accel on 3d core. In particular,
accelerating presentation blit triggers this problem.
-
The following changes since
Hi guys,
so I'm seeing this on rc1 + tip during boot:
[0.558106] Linux agpgart interface v0.103
[0.558283] [drm] Initialized drm 1.1.0 20060810
[0.562280] [drm] Memory usable by graphics device = 2048M
[0.632301] i915 :00:02.0: irq 42 for MSI/MSI-X
[0.632401] [drm] Support
ave banding on the
built in screen.
--
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/20140207/67e69aec/attachment.html>
I've chatted a bit with Hans Verkuil about this topic at fosdem and
apparently both v4l and alsa have something like this already in their
helper libraries. Adding more people as fyi in case they want to
switch to the new driver core stuff from Russell.
-Daniel
On Thu, Jan 2, 2014 at 10:27 PM, Rus
On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote:
> I've chatted a bit with Hans Verkuil about this topic at fosdem and
> apparently both v4l and alsa have something like this already in their
> helper libraries. Adding more people as fyi in case they want to
> switch to the new driver
On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote:
> *** BLURB HERE ***
Subject and BLURB forgotten?
On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman
wrote:
> On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
>> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote:
>> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
>> > ERR_PTR on a error. This encourages a common buggy pa
On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote:
> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote:
> > dma_buf_map_attachment and dma_buf_vmap can return NULL or
> > ERR_PTR on a error. This encourages a common buggy pattern in
> > callers:
> > sgt = dma_buf_map_attachment(a
On Thu, Feb 6, 2014 at 9:53 PM, Sean Paul wrote:
> On Wed, Jan 29, 2014 at 8:44 AM, Rob Clark wrote:
>> On Tue, Jan 28, 2014 at 4:52 PM, Sean Paul wrote:
>>> On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote:
Break the mutable state of a plane out into a separate structure
and use atom
https://bugzilla.kernel.org/show_bug.cgi?id=69301
--- Comment #17 from Michel D?nzer ---
(In reply to Jan Outhuis from comment #15)
> I've also done a Git bisect, but the outcome of that doesn't seem to
> make any sense:
> [...]
> So I guess I'll have to do that all over again. I'm not that famil
https://bugzilla.kernel.org/show_bug.cgi?id=65761
--- Comment #32 from Hohahiu ---
I have the same messages in dmesg:
http://pastebin.com/vAsRRVW8
It seems like radeon driver tries to set clock and it couldn't do it. Therefore
it tries again and again and GPU does not turn off.
Christoph, does
- Original Message -
> From: "Dan Carpenter"
> To: "David Airlie"
> Cc: "Ben Skeggs" , "Martin Peres" labri.fr>, "Ilia Mirkin" ,
> "Dave Airlie" , dri-devel at lists.freedesktop.org,
> kernel-janitors at vger.kernel.org
> Sent: Thursday, 6 February, 2014 7:29:43 PM
> Subject: [patch] dr
- Original Message -
> From: "Jingoo Han"
> To: "Ben Skeggs"
> Cc: dri-devel at lists.freedesktop.org, "David Airlie" ,
> "Jingoo Han"
> Sent: Wednesday, 5 February, 2014 12:02:59 PM
> Subject: [PATCH] drm/nouveau/hwmon: replace strict_strtol() with kstrtol()
>
> The usage of strict_st
76 matches
Mail list logo
