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
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
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.
--
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/e68e899d/attachment.html>
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 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
https://bugzilla.kernel.org/show_bug.cgi?id=70701
Abhinav K changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
eedesktop.org/archives/dri-devel/attachments/20140227/da8efbe1/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
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/ebd8bc5b/attachment.html>
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 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
|--- |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>
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>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/b99c5fb7/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>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/3f7560ba/attachment.html>
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>
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>
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
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
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
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.
>
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
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
>>>
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
: 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>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/f26346be/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/0904e1b2/attachment.html>
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
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
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 ++
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
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
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
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
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/,
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
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.
>
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
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>
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
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
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>
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
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
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: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 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
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
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 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
-
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>
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
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.
> 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
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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140227/b2ca8c1b/attachment.html>
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/2cf052b0/attachment-0001.html>
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
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>
ee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/f70231d6/attachment.html>
ubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/173d4061/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>
"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>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/94b07478/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/ebb32be2/attachment-0001.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140227/d283eae6/attachment.html>
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
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
75 matches
Mail list logo
