Dammit. I renamed the RADEON_INFO definitions for the new queries to
0xd, e, f in the kernel tree, but I forgot to update the Mesa code,
which used 0xc, d, e. Sorry.
Marek
On Wed, Feb 26, 2014 at 7:26 PM, Christian K?nig
wrote:
> Am 26.02.2014 18:56, schrieb Marek Ol??k:
>
>> On Mon, Feb 24, 201
On Mit, 2014-02-26 at 19:25 +0100, Marek Ol??k wrote:
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index f28a8d8..d49a3f7 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> [...]
> @@ -303,6 +314,18 @@ sta
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/d283eae6/attachment.html>
Hi Tomasz,
2014-02-08 11:48 GMT+09:00 Tomasz Figa :
> On 06.02.2014 20:54, Olof Johansson wrote:
>>
>> 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 dr
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/ebb32be2/attachment-0001.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/94b07478/attachment.html>
"EXA" just disables all hardware acceleration with those.
--
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/20140227/2905f1cc/attachment.html>
s also happen with DPM disabled?
--
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/20140227/2b743709/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/173d4061/attachment.html>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/f70231d6/attachment.html>
s not DRI2 capable".
Nothing on dmesg though.
--
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/20140227/326fa073/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140227/2cf052b0/attachment-0001.html>
On Thu, Feb 27, 2014 at 12:11:39AM -0800, Carl Worth wrote:
> With Haswell, 5.4Gbps is supported. And almost all of the code was
> already in place already. All that was missing was this tiny bit of
> additional wiring.
Todd already implemented 5.4Gbps support a while back. So it seems your
tree i
you need in more info?
--
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/20140227/0447532b/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140227/b2ca8c1b/attachment.html>
Am 27.02.2014 01:22, schrieb j.glisse at gmail.com:
> From: Jerome Glisse
>
> Need to free the uvd ring. Also reshuffle gart tear down to
> happen after uvd tear down.
>
> Signed-off-by: J?r?me Glisse
> Cc: stable at vger.kernel.org
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon
Am 26.02.2014 19:25, schrieb Marek Ol??k:
> From: Marek Ol??k
>
> Userspace should set the first 4 bits of drm_radeon_cs_reloc::flags to
> a number from 0 to 15. The higher the number, the higher the priority,
> which means a buffer with a higher number will be validated sooner.
>
> The old behavi
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> there to BAR is at a completely different address. Same thing on my
> Haswell desktop system.
Hrrm, I'd like to see what Rafael finds out, whether what we're
On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
> not so sure this is all related to the uncore IMC support, though.
Unstable
On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
> wrote:
> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> >> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
> >> They hang if I ty
On Thu, Feb 27, 2014 at 01:06:52PM +0200, Tomi Valkeinen wrote:
> On 25/02/14 16:23, Philipp Zabel wrote:
>
> > +Freescale i.MX DRM master device
> > +
> > +
> > +The freescale i.MX DRM master device is a virtual device needed to list all
> > +IPU or other display i
also introduced a
regression.
--
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/20140227/f9d87fb5/attachment.html>
Am Donnerstag, den 27.02.2014, 13:06 +0200 schrieb Tomi Valkeinen:
> On 25/02/14 16:23, Philipp Zabel wrote:
>
> > +Freescale i.MX DRM master device
> > +
> > +
> > +The freescale i.MX DRM master device is a virtual device needed to list all
> > +IPU or other displa
On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> For the i.MX6 display subsystem there is no clear single master device,
> and the physical configuration changes across the SoC family. The
> i.MX6Q/i.MX6D SoCs have two separate display controller devices IPU1 and
> IPU2, with two ou
On Thu, Feb 27, 2014 at 8:00 AM, Russell King - ARM Linux
wrote:
> On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
>> For the i.MX6 display subsystem there is no clear single master device,
>> and the physical configuration changes across the SoC family. The
>> i.MX6Q/i.MX6D SoCs ha
On Thu, Feb 27, 2014 at 03:16:03PM +0200, Tomi Valkeinen wrote:
> On 27/02/14 13:56, Russell King - ARM Linux wrote:
>
> >> Is there even need for such a master device? You can find all the
> >> connected display devices from any single display device, by just
> >> following the endpoint links.
>
Hi Inki,
On 27.02.2014 05:43, Inki Dae wrote:
> Hi Tomasz,
>
>
> 2014-02-08 11:48 GMT+09:00 Tomasz Figa :
>> On 06.02.2014 20:54, Olof Johansson wrote:
>>>
>>> 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
>>>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/0904e1b2/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/b91b6882/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/f26346be/attachment.html>
: GPU reset succeeded, trying to resume
--
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/20140227/c6601089/attachment-0001.html>
Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html
There is a bit in the HDMI info frame that can request that the
remote display
On Thu, Feb 27, 2014 at 09:19:30AM -0600, Daniel Drake wrote:
> Working with HDMI TVs is a real pain as they tend to overscan by
> default, meaning that the pixels around the edge of the framebuffer
> are not displayed. This is well explained here:
> http://mjg59.dreamwidth.org/8705.html
>
> There
On Thu, Feb 27, 2014 at 05:42:36PM +0200, Ville Syrj?l? wrote:
> On Thu, Feb 27, 2014 at 09:19:30AM -0600, Daniel Drake wrote:
> > Working with HDMI TVs is a real pain as they tend to overscan by
> > default, meaning that the pixels around the edge of the framebuffer
> > are not displayed. This is
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/3f7560ba/attachment.html>
tps://bft.usu.edu/bf8x6
it's correctly?
--
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/20140227/873b9533/attachment.html>
Hi Tomi,
Am Donnerstag, den 27.02.2014, 15:55 +0200 schrieb Tomi Valkeinen:
> On 27/02/14 15:00, Russell King - ARM Linux wrote:
> > On Thu, Feb 27, 2014 at 02:06:25PM +0100, Philipp Zabel wrote:
> >> For the i.MX6 display subsystem there is no clear single master device,
> >> and the physical con
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/b99c5fb7/attachment.html>
a separate ticket for issues.
--
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/20140227/6cd35b54/attachment.html>
|--- |FIXED
--
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/20140227/3a247722/attachment.html>
Applied to my -fixes tree. thanks!
On Wed, Feb 26, 2014 at 7:22 PM, wrote:
> From: Jerome Glisse
>
> Need to free the uvd ring. Also reshuffle gart tear down to
> happen after uvd tear down.
>
> Signed-off-by: J?r?me Glisse
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/everg
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/ebd8bc5b/attachment.html>
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/2903a617/attachment.pgp>
2014-02-27 15:21 GMT-03:00 Keith Packard :
> Ville Syrj?l? writes:
>
>> Todd already implemented 5.4Gbps support a while back. So it seems your
>> tree is a bit out of date.
>
> I didn't find it on drm-intel-fixes-2014-02-14; can you explain which
> tree it is present in?
It's on the drm-intel-ne
Hi Dave,
Some more radeon fixes.
The following changes since commit b0447888dc29f4fb91c3b3b02e3f1f0bfc6e1222:
MAINTAINERS: update drm git tree entry (2014-02-27 14:49:55 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-fixes-3.14
for you to
Without this, a bo may get created in the cpu-inaccessible vram.
Before the CP engines get setup, all copies are done via cpu memcpy.
This means that the cpu tries to read from inaccessible memory, fails,
and the radeon module proceeds to disable acceleration.
Doing this has no downsides, as the
eedesktop.org/archives/dri-devel/attachments/20140227/da8efbe1/attachment.html>
Allocating small bos from one end and large ones from the other helps
improve the quality of fragmentation.
I have measured a suitable threshold to reduce eviction by up to 20%,
and to cause no harm in normal cases that fit VRAM fully (PTS gaming suite).
In some cases, even the VRAM-fitting cases
https://bugzilla.kernel.org/show_bug.cgi?id=70701
Abhinav K changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
One of the stepping stones on the way to atomic/nuclear operation is to expose
CRTC primary planes (and eventually cursor planes too) to userspace in the same
manner that sprites/overlays are today. This patch series takes the first step
of allowing drivers to register a CRTC's primary plane with
Add a plane type property to allow userspace to distinguish
sprite/overlay planes from primary planes. In the future we may extend
this to cover cursor planes as well.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 32
include/drm/drm_crtc.h |
Allow drivers to provide a drm_plane structure corresponding to a CRTC's
primary plane. These planes will be included in the plane list for any
clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crtc.c | 168 ++
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disab
Create a primary plane at CRTC init and hook up handlers for the various
operations that may be performed on it. The DRM core will only
advertise the primary planes to clients that set the appropriate
capability bit.
Since we're limited to the legacy plane operations at the moment
(SetPlane and s
On Thu, Feb 27, 2014 at 11:12:17PM +0100, Rafael J. Wysocki wrote:
> I won't be able to look at that before Monday I'm afraid (personal
> stuff).
No worries, sir, whenever. It can wait.
Thanks a lot!
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Thu, Feb 27, 2014 at 5:14 PM, Matt Roper
wrote:
> Add a plane type property to allow userspace to distinguish
> sprite/overlay planes from primary planes. In the future we may extend
> this to cover cursor planes as well.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/drm_crtc.c | 3
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/e68e899d/attachment.html>
On Thu, Feb 27, 2014 at 05:39:00PM -0500, Rob Clark wrote:
> On Thu, Feb 27, 2014 at 5:14 PM, Matt Roper
> wrote:
> > Add a plane type property to allow userspace to distinguish
> > sprite/overlay planes from primary planes. In the future we may extend
> > this to cover cursor planes as well.
>
With Haswell, 5.4Gbps is supported. And almost all of the code was
already in place already. All that was missing was this tiny bit of
additional wiring.
Signed-off-by: Carl Worth
Reviewed-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 20 in
On Wed, Feb 26, 2014 at 10:59 AM, Borislav Petkov wrote:
> Can you please, pretty please, not top-post...
>
> On Wed, Feb 26, 2014 at 10:47:05AM +0100, Stephane Eranian wrote:
>> Hi,
>>
>> Ok, so I am getting the same error message as you.
>> I checked my syslog now.
>>
>> I have my uncore_imc add
gt; + to the four LVDS multiplexer inputs.
Is the ldb something that's on the imx SoC?
Do you have a public branch somewhere? It'd be easier to look at the
final result, as I'm not familiar with imx.
Tomi
-- next part --
A non-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/20140227/ef94feb6/attachment-0001.pgp>
Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.
Si
At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.
If I'm not mistaken, this is caused by the drivers depending on o
The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.
Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.
No
Hi,
This is a re-send of the series, with RFC removed from the subject, and a bunch
of acks added.
I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
make sure this is not a bad idea, doomed to fail horribly.
So this series creates a new directory, drivers/video/fbdev/,
On Thu, Feb 27, 2014 at 12:08 PM, Peter Zijlstra
wrote:
> On Thu, Feb 27, 2014 at 11:32:58AM +0100, Stephane Eranian wrote:
>> On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
>> wrote:
>> > On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> >> As a asides, my SNB and HSW desk
all the display components installed,
or if the user didn't compile all the drivers.
Tomi
-- next part --
A non-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/20140227/b5234f59/attachment-0001.pgp>
From: Heinrich Schuchardt
In case of failure memory was not freed.
Signed-off-by: Heinrich Schuchardt
---
drivers/gpu/drm/nouveau/nouveau_sgdma.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau
On Thursday, February 27, 2014 11:27:22 AM Borislav Petkov wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
> > My Lenovo IVB is like yours. But I tried on my SandyBridge desktop and
> > there to BAR is at a completely different address. Same thing on my
> > Haswell deskto
On 02/27/2014 03:54 AM, Tomi Valkeinen wrote:
> Hi,
>
> This is a re-send of the series, with RFC removed from the subject, and a
> bunch
> of acks added.
>
> I'm cc'ing more people, to make sure this doesn't come as a surprise, and to
> make sure this is not a bad idea, doomed to fail horribly.
On Thu, Feb 27, 2014 at 11:30 AM, Peter Zijlstra
wrote:
> On Thu, Feb 27, 2014 at 11:12:32AM +0100, Stephane Eranian wrote:
>> As a asides, my SNB and HSW desktops with 3.14-rc4 are totally unstable.
>> They hang if I type make in my kernel tree. Whereas 3.14-rc3 is stable. I am
>> not so sure t
es in the DT data), and I have a problem requiring
everyone to have a master device node if it's only needed for special cases.
And yes, this series is about IMX bindings, not generic ones. And I'm
also fine with requiring everyone to have a master device node, if it
can be shown that it's the only sensible approach.
Tomi
-- next part --
A non-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/20140227/d9b87663/attachment.pgp>
> Either we should have two range properties (eg. crtc_width and crtc_height),
> or we could define a new property type that has both in the same value.
> Not sure if it's worth adding another type for this. Although we might be
> able to use such a type to reduce the number of properties a bit f
e very same things that had already been
discussed with CDF.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/d
On Thu, Feb 27, 2014 at 6:24 PM, Matt Roper
wrote:
> On Thu, Feb 27, 2014 at 05:39:00PM -0500, Rob Clark wrote:
>> On Thu, Feb 27, 2014 at 5:14 PM, Matt Roper
>> wrote:
>> > Add a plane type property to allow userspace to distinguish
>> > sprite/overlay planes from primary planes. In the futur
75 matches
Mail list logo
