Hi,
2014/1/8 Daniel Vetter :
> On Tue, Jan 07, 2014 at 01:59:12PM +, Mark Brown wrote:
>> From: Mark Brown
>>
>> Commit 57ed0f7b4375 (drm: Kill DRM_WAKUP and DRM_INIT_WAITQUEUE) removed
>> the definition of DRM_WAKUP but did not remove the use of it in the Exynos
>> DRM driver causing it to f
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/20140108/904fa8f5/attachment.html>
org/archives/dri-devel/attachments/20140108/cb58aa26/attachment.html>
org/archives/dri-devel/attachments/20140108/ef4df32c/attachment.html>
From: Michel D?nzer
It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.
Should fix an oops I encountered while resetting the GPU after a lockup
on my PowerBook with an RV350.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_pm.c | 6 --
1 file changed, 4 inse
not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/e527326a/attachment-0001.pgp>
Hi Dave,
Just a revert (gen4 backlight seems a lost cause) and a tlb coherency fix
for bdw, plus the patch to sign up Jani for co-maintainer. Thanks to Ben
for taking care of -fixes while I've enjoyed a bit of vacation.
Cheers, Daniel
The following changes since commit d6e0a2dd12f4067a5bcefb8bb
On Tue, Jan 7, 2014 at 8:17 PM, Laurent Pinchart
wrote:
> Hi Dave,
>
> On Thursday 19 December 2013 15:37:36 Laurent Pinchart wrote:
>> Hi Dave,
>>
>> It's been two weeks and a half already, is there anything holding this back
>> ?
>
> PING ??
just realised I hadn't pushed drm-next-staging to drm
Hi Dave,
On Wednesday 08 January 2014 18:09:05 Dave Airlie wrote:
> On Tue, Jan 7, 2014 at 8:17 PM, Laurent Pinchart wrote:
> > On Thursday 19 December 2013 15:37:36 Laurent Pinchart wrote:
> >> Hi Dave,
> >>
> >> It's been two weeks and a half already, is there anything holding this
> >> back ?
Hi Linus,
LCA fixes tree,
i915 and nouveau fixes, a revert for i915 gm45 backlight, and a
MAINTAINERS update for the i915 driver, as it now has a co-maintainer.
Dave.
The following changes since commit ef350bb7c5e0748f7d17f1d70c6b0eec5f64f446:
Merge tag 'ext4_for_linus_stable' of
git://gi
On Mon, 30 Dec 2013, Jani Nikula wrote:
> On Mon, 23 Dec 2013, der-b wrote:
>> Hello,
>>
>> i got a new Notebook with an Intel Core i7-3689Y whit a Intel HD
>> Graphics 4000. I got a blank screen while booting but I could use ssh.
>> This happened each time, when I enabled CONFIG_I915_KMS in th
When a client looks up a ttm object, don't look it up through the device hash
table, but rather from the file hash table. That makes sure that the client
has indeed put a reference on the object, or in gem terms, has opened
the object; either using prime or using the global "name".
To avoid a perf
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
drivers/gpu/drm/ttm/ttm_bo_vm.c |5 +
drivers/gpu/drm/ttm/ttm_tt.c| 27 +++
include/drm/ttm/ttm_bo_driver.h |
https://bugzilla.kernel.org/show_bug.cgi?id=68111
--- Comment #7 from CameronPoe ---
I did the tests. I installed:
kernel-desktop-3.12.6-1.1.x86_64.rpm
and
kernel-desktop-3.13.rc6-4.1.x86_64.rpm
but this problem is still unsolved in newer kernels.
I forgot to mention I found this problem alre
2014? 1? 7? Jakob Bornecrantz?? ??:
> On Tue, Jan 7, 2014 at 7:40 AM, Hyungwon Hwang
> wrote:
>> tests/kmstest: support exynos
>>
>> Add exynos to list of kmstest supported modules.
>>
>> Signed-off-by: Hyungwon Hwang
>> ---
>> libkms/internal.h|2 ++
>> libkms/linux.c |
Hello,
On 2014? 01? 08? 21:03, Mark Brown wrote:
> On Wed, Jan 08, 2014 at 10:15:25AM +0900, Inki Dae wrote:
>> 2014/1/8 Daniel Vetter :
>
>>> Oops, looks like something slipped past between me making the patches and
>>> them getting merged. Thanks for taking care of this. Both patches are
>
>>
Patch 78-80/85
Reviewed-by: Thomas Hellstrom
Queued for ttm-next.
Thanks.
Thomas
On 01/06/2014 05:42 PM, Rashika Kheria wrote:
> Mark function as static because it is not used outside file
> drm/ttm/ttm_bo.c.
>
> This eliminates the following warning in drm/ttm/ttm_bo.c:
> drivers/gpu/drm/ttm/t
_
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/c871c907/attachment.html>
On 01/07/2014 11:51 AM, Josh Triplett wrote:
> On Tue, Jan 07, 2014 at 11:21:12AM +0100, Jakob Bornecrantz wrote:
>> On Mon, Jan 6, 2014 at 5:48 PM, Rashika Kheria
>> wrote:
>>> Mark functions as static because they are not used outside the file
>>> drm/vmwgfx/vmwgfx_kms.c.
>>>
>>> This eliminate
ing, I'm not sure it warrants a patch this
late in the release cycle that will cause conflicts during the merge
window.
It also seems like there are other issues that prevent allmodconfig to
build successfully on ARM not all of them being as easy to fix as this
one.
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/20140108/a047d768/attachment.pgp>
Okay, if this is indeed the only remaining issue then I think it makes
sense indeed to go through the trouble of fixing it right away rather
than waiting for 3.14.
> If arm:allmodconfig is not pursued as buildable, trying to build it is
> worthless,
> and I'll drop it from my list of test builds for -stable. Thanks for letting
> me know.
Right, I hadn't considered -stable builds and this is an issue that's
new in 3.13, isn't it? In that case, and since this is the only
remaining issue, the above patch:
Acked-by: Thierry Reding
Dave, since this is a single patch for 3.13 it might be easier for you
to pick it up directly rather than have me send out a pull request.
Either way is fine with me, though.
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/20140108/9c34bd54/attachment.pgp>
lists.freedesktop.org/archives/dri-devel/attachments/20140108/7a753fb5/attachment.pgp>
was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/20c2e49f/attachment.pgp>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/a5d40683/attachment.html>
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/3b73adc7/attachment-0001.html>
On Tue, Jan 7, 2014 at 1:40 AM, Hyungwon Hwang
wrote:
> tests/kmstest: support exynos
>
> Add exynos to list of kmstest supported modules.
>
> Signed-off-by: Hyungwon Hwang
> ---
> libkms/internal.h|2 ++
> libkms/linux.c |4
> tests/kmstest/main.c |1 +
> 3 files cha
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/20140108/4d083e8f/attachment.html>
On Tue, Jan 7, 2014 at 9:40 PM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.
>
> Should fix an oops I encountered while resetting the GPU after a lockup
> on my PowerBook with an RV350.
>
> Signed-off-by: Michel D?nzer
Applie
On Mon, Jan 6, 2014 at 10:21 AM, Rashika Kheria
wrote:
> Mark functions radeon_doorbell_init() and radeon_doorbell_fini() as
> static in drm/radeon/radeon_device.c because they are not used outside
> this file.
>
> This eliminates the following warning in drm/radeon/radeon_device.c:
> drivers/gpu/
From: Marek Ol??k
This fixes a bug which was causing rejections of valid GPU commands
from userspace.
Signed-off-by: Marek Ol??k
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen_cs.c | 5 -
drivers/gpu/drm/radeon/r600_cs.c | 5 -
2 files changed, 8 insertions(+),
On Wed, Jan 8, 2014 at 12:16 PM, Marek Ol??k wrote:
> From: Marek Ol??k
>
> This fixes a bug which was causing rejections of valid GPU commands
> from userspace.
>
> Signed-off-by: Marek Ol??k
> Cc: stable at vger.kernel.org
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/radeon/evergreen_cs.
I was reminded on Monday that we'd like to be able to subclass struct
drm_device so we don't have to always juggle between a pointer to a struct
drm_device and its drv_private field to access everything we care about.
It'd be nicer for those two pointers to have the same value to avoid a few
extra
Not specifying it makes it a bit easier to identify drivers that really
need this field, and down the line, ease refactoring. This field doesn't
make sense for KMS drivers anyway.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.c | 1
This field is only used when creating a new buffer and can already be
found in the drm_driver structure, so no need to duplicate the
information for every buffer.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_bufs.c | 13 ++---
include/drm/drmP.h | 1 -
2 files changed,
This field is really the size of the per-driver private data attached to
a struct drm_buf. Name it accordingly and add a comment so it doesn't
get confused with, say, the size of the private data attatched to a struct
drm_device.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_bufs.c
Currently, drivers are expected to allocate private data and attach it
to dev_private in struct drm_device.
This has the unfortunate property to require driver code to juggle
between the pointer to struct drm_device and dev->dev_private instead of
using the same pointer if they could embed the dev
This patch is the result of running:
sed -i -e 's/\([^&]\)dev_priv->dev\([^-]\)/\1\&dev_priv->dev\2/g'
drivers/gpu/drm/i915/*.[ch]
sed -i -e 's/dev_priv->dev->/dev_priv->dev./g' drivers/gpu/drm/i915/*.[ch]
and a minor correction in gem_context.c that the 2 regex above didn't
catch.
In addition:
Hi
On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau
wrote:
> Currently, drivers are expected to allocate private data and attach it
> to dev_private in struct drm_device.
>
> This has the unfortunate property to require driver code to juggle
> between the pointer to struct drm_device and dev->dev_
dri-devel/attachments/20140108/73182b8d/attachment.html>
dri-devel/attachments/20140108/7f65c28e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=68301
Bug ID: 68301
Summary: [bisected] Headless OpenCL broken
Product: Drivers
Version: 2.5
Kernel Version: 3.13
Hardware: All
OS: Linux
Tree: Mainline
:allmodconfig is not pursued as buildable, trying to build it is
> > > worthless,
> > > and I'll drop it from my list of test builds for -stable. Thanks for
> > > letting me know.
> >
> > Right, I hadn't considered -stable builds and this is an issue that's
> > new in 3.13, isn't it? In that case, and since this is the only
> > remaining issue, the above patch:
> >
> > Acked-by: Thierry Reding
> >
> > Dave, since this is a single patch for 3.13 it might be easier for you
> > to pick it up directly rather than have me send out a pull request.
> > Either way is fine with me, though.
> >
>
> For now I have dropped arm:allmodconfig from my list of build tests and
> replaced
> it with a number of additional individual target builds. As I had this or
> similar discussions ever since I started testing -stable builds, my conclusion
> is that the arm community isn't much interested in keeping arm:allmodconfig
> buildable. If that ever changes, I'll be happy to add it back in.
I can't speak for the community as a whole, but I'm certainly interested
in having more automated build coverage. Last time I attempted an allmod
build on ARM myself, which must have been at least 3 months ago, there
were quite a few issues and I didn't have the time to fix all of them. I
hadn't realize that things had improved that much recently.
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/20140108/aacb399b/attachment.pgp>
On Wed, Jan 08, 2014 at 08:01:19PM +0100, David Herrmann wrote:
> Hi
>
> On Wed, Jan 8, 2014 at 7:31 PM, Damien Lespiau
> wrote:
> > Currently, drivers are expected to allocate private data and attach it
> > to dev_private in struct drm_device.
> >
> > This has the unfortunate property to requir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alex Deucher (2):
radeon: avoid possible divide by 0 in surface manager
radeon: fix sumo2 pci id
Damien Lespiau (2):
gitignore: Ignore various generated files
intel/test_decode: Allow gen8 to be infered from the batch
radeon.audio=1 libahci.ignore_sss=1 rhgb quiet
--
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/20140108/9f789b3a/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/b7786bdd/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/902ccf27/attachment-0001.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/1870f8ca/attachment.html>
On Wed, Jan 8, 2014 at 4:36 PM, Russell King - ARM Linux
wrote:
> On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote:
>> On Thu, Jan 2, 2014 at 4:27 PM, Russell King
>> wrote:
>> > Subsystems such as ALSA, DRM and others require a single card-level
>> > device structure to represent a subs
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/4071bb24/attachment.html>
t in the weekend.
--
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/20140108/92339647/attachment.html>
Hi Dave,
This is the drm-next pull for radeon for 3.14. Highlights include:
- dpm rework which fixes some issues and allows us to enable dpm by
default on CIK parts
- enable clockgating on CIK parts
- pci config reset. This is a bus-level chip reset that can be more
reliable than soft reset in ce
Hi Tomasz,
Thanks for the review comments, please find my replies inline.
On Thu, Dec 19, 2013 at 6:49 PM, Tomasz Figa wrote:
> On Thursday 19 of December 2013 17:42:28 Shirish S wrote:
>> This patch adds dt support to hdmiphy config settings
>> as it is board specific and depends on the signal p
On Tue, Jan 07, 2014 at 02:49:50PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:28:19PM +, Russell King wrote:
> > @@ -449,6 +458,24 @@ static int imx_drm_driver_load(struct drm_device *drm,
> > unsigned long flags)
> > }
> > }
> >
> > + /*
> > +* All components
sc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/bf560d5d/attachment.pgp>
On Wed, Jan 08, 2014 at 11:40:28AM -0500, Alex Deucher wrote:
> On Mon, Jan 6, 2014 at 10:21 AM, Rashika Kheria
> wrote:
> > Mark functions radeon_doorbell_init() and radeon_doorbell_fini() as
> > static in drm/radeon/radeon_device.c because they are not used outside
> > this file.
> >
> > This el
On 01/08/2014 05:29 AM, Thierry Reding wrote:
> On Mon, Jan 06, 2014 at 08:20:55AM -0800, Guenter Roeck wrote:
>> On Mon, Jan 06, 2014 at 04:39:47PM +0100, Thierry Reding wrote:
>>> On Sun, Jan 05, 2014 at 10:22:51AM -0800, Guenter Roeck wrote:
arm:allmodconfig fails to build with several unde
With the current implementation of collecting edid modes,
in case rb mode exists for a non rb mode of same resolution and
vrefresh, the non-rb mode is never fed to display controller to be
probed, as a result we lose on using the non-rb mode, if the display
controller does not support rb mode but
The current solution checks for the existing RB mode,
if available in the edid block returns by adding it,
but does not populate the connector with the modes
of same resolution but which are non-rb modes.
As a result the probing and listing of non-rb modes can't
be made, in case the rb mode's pixe
On Tue, Jan 07, 2014 at 04:59:35PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:28:03PM +, Russell King wrote:
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > index e75e11b36dff..0e005f21d241 100644
> > --- a/arch/arm/boot/dts/im
On Tue, Jan 07, 2014 at 05:29:55PM +0100, Philipp Zabel wrote:
> Thanky you. This is what I came up with so far:
>
> From: Philipp Zabel
> Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if
> HPD is unreliable
>
> On some boards HPD might not reliably detect DVI monitor
On Wed, Jan 08, 2014 at 03:01:39PM +0100, Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 05:48:44AM -0800, Guenter Roeck wrote:
> > On 01/08/2014 05:29 AM, Thierry Reding wrote:
> > >On Mon, Jan 06, 2014 at 08:20:55AM -0800, Guenter Roeck wrote:
> > >>On Mon, Jan 06, 2014 at 04:39:47PM +0100, Thie
On Tue, Jan 07, 2014 at 02:38:05PM +0800, Shawn Guo wrote:
> On Thu, Jan 02, 2014 at 09:27:48PM +, Russell King wrote:
> > diff --git a/drivers/staging/imx-drm/imx-drm.h
> > b/drivers/staging/imx-drm/imx-drm.h
> > index 5649f180dc44..4eb594ce9cff 100644
> > --- a/drivers/staging/imx-drm/imx-dr
On 01/08/2014 05:09 PM, Jani Nikula wrote:
> On Mon, 30 Dec 2013, Jani Nikula wrote:
>> On Mon, 23 Dec 2013, der-b wrote:
>>> Hello,
>>>
>>> i got a new Notebook with an Intel Core i7-3689Y whit a Intel HD
>>> Graphics 4000. I got a blank screen while booting but I could use ssh.
>>> This happe
n-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140108/6e160738/attachment.pgp>
On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote:
> On Thu, Jan 2, 2014 at 4:27 PM, Russell King
> wrote:
> > Subsystems such as ALSA, DRM and others require a single card-level
> > device structure to represent a subsystem. However, firmware tends to
> > describe the individual devices
66 matches
Mail list logo
