(Sent to dri-devel and intel-gfx lists.)
Dear Linux graphics folks,
coreboot has been accepted to participate in Google Summer of Code 2013
[1]. coreboot is a Free Software project aimed at replacing the
proprietary BIOS (firmware) found in most computers.
Please find more information about GS
Am 11.04.2013 00:20, schrieb j.gli...@gmail.com:
From: Jerome Glisse
v2: sync with radeon-next tree for 3.10
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
Signed-off-by: Jerome Glisse
Reviewed-by: Christian König
---
include/drm/radeon_drm.h | 81 ++
One of the main things to do to the driver is to support
the common display famework (CDF) to hit mainline. As this will
make some changes to the devicetree bindings necessary it makes
sense to do it before we move out of staging.
Signed-off-by: Sascha Hauer
---
drivers/staging/imx-drm/TODO | 3
On Wed, 2013-04-10 at 07:52 +1000, Dave Airlie wrote:
> > Since atm we don't take a reference on the dma buf pointer when we add
> > it to the import lookup table the dma buf can vanish leaving the stale
> > pointer behind. This can in turn lead to returning stale GEM handles
> > when userspace imp
Hi Tomi,
On Wednesday 10 April 2013 13:00:15 Tomi Valkeinen wrote:
> On 2013-03-13 10:57, Tomi Valkeinen wrote:
> > Hi Dave,
> >
> > I'm writing this mail to get some ideas how we should manage OMAP's
> > display drivers in the future.
> >
> > As a short intro, we have the following players arou
On Wed, 2013-04-10 at 10:56 +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
>
> i915 has an imported object ref
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #63 from Luca Barbato ---
I tested today and the problem is still present. Which is your .config and how
are you loading the kernel?
I'm trying to load it using grub2.
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #46 from Alex Deucher ---
Created attachment 77808
--> https://bugs.freedesktop.org/attachment.cgi?id=77808&action=edit
temporary workaround
Apply this on top of the previous patches. It's a hack to workaround the issue
until I ca
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #64 from Luca Barbato ---
The system is a macbookpro 8.2 and it fails to find the bios as reported
before. Probably the problem is in the grub configuration or in the kernel,
anybody with a working system could point me to and example
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform this
detection and a hook to perform dynamic adding of the function only for
pseries.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/include/asm/mac
After all the comments in the last patch series, I did a refactoring of what I
was proposing and came up with this. Basically, now:
1. max_bus_speed is used to set the device to gen2 speeds
2. on power there's no longer a conflict between the pseries call and other
architectures, because the
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c
https://bugs.freedesktop.org/show_bug.cgi?id=62959
--- Comment #33 from Alex Deucher ---
(In reply to comment #32)
> Attachment 77608 [details] fixes the lockups, which suggests the DRM driver
> doesn't actually flush caches when it should.
radeon_ring_vm_flush() doesn't actually flush caches pe
On Thu, Mar 28, 2013 at 12:22:55PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 09:45:35PM +0100, Daniel Vetter wrote:
> > We don't grab the modeset locks any more since
> >
> > commit 468174f748603497e73dba9b5c6d1d9f71121486
> > Author: Daniel Vetter
> > Date: Tue Dec 11 00:09:12 2012
Driver's and ->fill_modes functions are allowed to grab crtc mutexes
(for e.g. load detect). Hence we need to first only grab the general
kms mutex, and only in a second step grab all locks to do the
modesets.
This prevents a deadlock on my gm45 in the tv load detect code called
by drm_helper_prob
https://bugzilla.kernel.org/show_bug.cgi?id=56041
--- Comment #1 from Alex Deucher 2013-04-11 16:47:24
---
Created an attachment (id=98191)
--> (https://bugzilla.kernel.org/attachment.cgi?id=98191)
Possible fix
Does the attached kernel patch help?
--
Configure bugmail: https://bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=56041
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #2 f
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
>
>> That patch should crash at all, so this is not expected. Can you pls
>> check whether plain drm-intel-nightly is broken, too?
>
> I did try drm-intel-nightly just now (1dd8
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the en
2013/3/17 Chris Wilson :
> On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
>> On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
>> wrote:
>> > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
>> >> wrote:
>> >> > If *us
On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
> It will be only consistent once we've restored all the crtcs. Since a
> bunch of other callers also want to just restore a single crtc, add a
> boolean to disable checking only where it doesn't make sense.
>
> Note that intel_modeset
On Thu, Apr 11, 2013 at 08:17:42PM +0100, Chris Wilson wrote:
> On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
> > It will be only consistent once we've restored all the crtcs. Since a
> > bunch of other callers also want to just restore a single crtc, add a
> > boolean to disable c
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
> That patch should crash at all, so this is not expected. Can you pls
> check whether plain drm-intel-nightly is broken, too?
I did try drm-intel-nightly just now (1dd83e3), and it also freezes
the machine. I first verified that the
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #47 from Vladimir ---
That works.
Will any of these four patches land in 3.9 kernel ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #65 from Austin Lund ---
Works for me in 3.9-rc6.
As stated above, you cannot use grub to load the firmware as the information is
only accessible before you exit the boot services in EFI. The kernel must be
booted using EFI stub boo
Don't oops seems proper.
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_connector.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/udl/udl_connector.c
b/drivers/gpu/drm/udl/udl_connector.c
index fe5cdbc..b44d548 100644
--- a/drivers/gp
https://bugzilla.kernel.org/show_bug.cgi?id=56041
--- Comment #3 from Thomas J. Moore 2013-04-12 03:43:14 ---
Yes, that seems to have fixed it. Thanks.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are wa
This reverts commit 09495dda6a62c74b13412a63528093910ef80edd.
The description is incomplete and the location of this file
is incorrect. Based on discussion with the Samsung media and DRM subsystem
maintainers, the documentaion of Samsung G2D bindings has been placed at:
Documentation/devicetree/bin
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130411/6646cb2a/attachment.html>
deon: fence wait failed (-35).
[drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5
(-35).
What next?
Dieter.
> Christian.
>
>> Thanks,
>> Dieter
>>
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log.old-BAD-UVD.bz2
On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin wrote:
> On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter
> wrote:
>> v2: Try harder not to create a big patch (Chris).
>>
> Tested the patch applied to 3.9-rc6. Atleast on my machine that
> helped, although once I managed to get the error (but not warn
signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130411/bedf2143/attachment.pgp>
Am 11.04.2013 00:20, schrieb j.glisse at gmail.com:
> From: Jerome Glisse
>
> v2: sync with radeon-next tree for 3.10
>
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip
>
> Signed-off-by: Jerome Glisse
Reviewed-by: Christian K?nig
> ---
> include/drm/radeon_drm.h | 81
> +
One of the main things to do to the driver is to support
the common display famework (CDF) to hit mainline. As this will
make some changes to the devicetree bindings necessary it makes
sense to do it before we move out of staging.
Signed-off-by: Sascha Hauer
---
drivers/staging/imx-drm/TODO | 3
On Wed, 2013-04-10 at 07:52 +1000, Dave Airlie wrote:
> > Since atm we don't take a reference on the dma buf pointer when we add
> > it to the import lookup table the dma buf can vanish leaving the stale
> > pointer behind. This can in turn lead to returning stale GEM handles
> > when userspace imp
can take the problematic omapdrm patches via fbdev tree with the omapdss
> patches, if that's ok for you. And send the other omapdrm patches to be
> merged via drm tree.
>
> Or, I could take all the omapdrm patches via fbdev tree, if that's
> better. There aren't too many of them for 3.10.
--
Regards,
Laurent Pinchart
-- 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/20130411/9ef9/attachment.pgp>
On Wed, 2013-04-10 at 10:56 +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
>
> i915 has an imported object ref
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130411/1254bae5/attachment.html>
ssue
until I can sort out what is going on with the hw guys.
--
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/20130411/da7e7629/attachment.html>
example configuration?
--
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/20130411/86a6ffa3/attachment.html>
After all the comments in the last patch series, I did a refactoring of what I
was proposing and came up with this. Basically, now:
1. max_bus_speed is used to set the device to gen2 speeds
2. on power there's no longer a conflict between the pseries call and other
architectures, because the
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform this
detection and a hook to perform dynamic adding of the function only for
pseries.
Signed-off-by: Lucas Kannebley Tavares
---
arch/powerpc/include/asm/mac
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130411/063af0ce/attachment.html>
On Thu, Mar 28, 2013 at 12:22:55PM +0200, Ville Syrj?l? wrote:
> On Wed, Mar 27, 2013 at 09:45:35PM +0100, Daniel Vetter wrote:
> > We don't grab the modeset locks any more since
> >
> > commit 468174f748603497e73dba9b5c6d1d9f71121486
> > Author: Daniel Vetter
> > Date: Tue Dec 11 00:09:12 2012
Driver's and ->fill_modes functions are allowed to grab crtc mutexes
(for e.g. load detect). Hence we need to first only grab the general
kms mutex, and only in a second step grab all locks to do the
modesets.
This prevents a deadlock on my gm45 in the tv load detect code called
by drm_helper_prob
https://bugzilla.kernel.org/show_bug.cgi?id=56041
--- Comment #1 from Alex Deucher 2013-04-11
16:47:24 ---
Created an attachment (id=98191)
--> (https://bugzilla.kernel.org/attachment.cgi?id=98191)
Possible fix
Does the attached kernel patch help?
--
Configure bugmail: https://bugzilla.
https://bugzilla.kernel.org/show_bug.cgi?id=56041
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #
On Thu, Apr 11, 2013 at 7:52 PM, Richard Cochran
wrote:
> On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
>
>> That patch should crash at all, so this is not expected. Can you pls
>> check whether plain drm-intel-nightly is broken, too?
>
> I did try drm-intel-nightly just now (1dd8
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the en
2013/3/17 Chris Wilson :
> On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
>> On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
>> wrote:
>> > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson > >> chris-wilson.co.uk> wrot
On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
> It will be only consistent once we've restored all the crtcs. Since a
> bunch of other callers also want to just restore a single crtc, add a
> boolean to disable checking only where it doesn't make sense.
>
> Note that intel_modeset
On Thu, Apr 11, 2013 at 08:17:42PM +0100, Chris Wilson wrote:
> On Thu, Apr 11, 2013 at 08:22:50PM +0200, Daniel Vetter wrote:
> > It will be only consistent once we've restored all the crtcs. Since a
> > bunch of other callers also want to just restore a single crtc, add a
> > boolean to disable c
On Wed, Apr 10, 2013 at 10:03:25PM +0200, Daniel Vetter wrote:
> That patch should crash at all, so this is not expected. Can you pls
> check whether plain drm-intel-nightly is broken, too?
I did try drm-intel-nightly just now (1dd83e3), and it also freezes
the machine. I first verified that the
On Thu, Apr 11, 2013 at 08:14:10PM +0200, Daniel Vetter wrote:
>
> I've just tracked down and fixed an bug which can lead to a hard-hang
> in the crtc restore code (which is used both in the lid handler when
> opening and on resume). If you could please test this patch (on top of
> drm-intel-night
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130411/9affa197/attachment.html>
57 matches
Mail list logo
