On Mon, Jul 06, 2015 at 09:06:28PM +0100, Steven Newbury wrote:
> On Mon, 2015-07-06 at 15:42 -0400, Alex Deucher wrote:
> > On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury > > wrote:
> > > On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
> > > > On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury
bdrm (although surprising this would compile with
> everything else).
> -Daniel
It's the latest in portage:
x11-libs/libdrm-2.4.62::gentoo USE="libkms -static-libs
-valgrind"VIDEO_CARDS="radeon (-exynos) (-freedreno) -intel -nouveau (-omap)
(-tegra) -vmware"
I'll know tomorrow whether downgrading works, if not, I'm suspecting it's a
compiler bug. I have wondered though how much testing R200 could be getting
with the latest stack.
If it is a mis-compile, I guess it must be either in libdrm or the ddx
- hopefully, at least that shouldn't mean too much compiling!
Slightly off topic, I'm curious whether R200 could be used with
Wayland. How difficult/possible would it be to get R200 working with
gles1? Obviously, gles2 would be a non-starter given it's OpenGL1.3
hardware. Would gles1 be sufficient to run a Wayland compositor, I'm
guessing probably not..?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/06a7112f/attachment.sig>
roughly
> > under qemu (with qxl) before deployment, but that of course didn't
> > exercise the R200 driver. FWIW, other than the failing DRI,
> > performance is surprisingly OK, not super fast obviously, but a
> > *lot*
> > better than under Ubuntu! (start-up time is alot quicker, by an
> > order
> > of magnitude!)
> >
> > I'm attempting to downgrade the xserver and drivers (on the live
> > system) to see if that works, you can imagine that takes a little
> > while on a Coppermine-128! I'll find out tomorrow. Otherwise, I
> > guess I'm recompiling the stack with gcc-4.9 and no-LTO...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/4a535280/attachment.sig>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/d01a21e8/attachment.html>
Hi Thierry,
On Mon, Jun 29, 2015 at 10:30 PM, Thierry Reding wrote:
> On Mon, Jun 15, 2015 at 04:15:36PM +0900, Alexandre Courbot wrote:
>> On 06/15/2015 04:09 PM, Alexandre Courbot wrote:
>> >From: Ari Hirvonen
>> >
>> >Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
>> >mode for imp
On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> struct drm_crtc already stores the enabled state of the crtc
> thus we don't need to replicate enabled in exynos_drm_crtc.
>
> Signed-off-by: Gustavo Padovan
Note that exynos_crtc->enabled doesn't matc
h gcc-4.9 and no-LTO...
-- next part ------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/cfb0bc02/attachment-0001.sig>
case.
--
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/20150706/9211105b/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/e74270dc/attachment.html>
Hi Jérôme,
On 13.08.2014 12:52, Jérôme Glisse wrote:
> From: Jérôme Glisse
>
> Current code never allowed the page pool to actualy fill in anyway. This fix
> it and also allow it to grow over its limit until it grow beyond the batch
> size for allocation and deallocation.
>
> Signed-off
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/0de7ab4e/attachment.html>
Linux seems to pick this up via another header, but Solaris needs it
explictly included, or we get undefined symbol errors for major & minor.
Signed-off-by: Alan Coopersmith
---
libkms/linux.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libkms/linux.c b/libkms/linux.c
index 4d47148..f
On Mon, Jul 06, 2015 at 04:56:19PM -0400, Alex Deucher wrote:
> On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones
> wrote:
> > I wanted to switch my LCD to a different machine momentarily.
> > When I plugged the cable back in, this was on the screen..
>
> Is this readily reproducible?
I just di
On Fri, Jul 3, 2015 at 5:38 AM, Christian König
wrote:
> On 03.07.2015 10:54, Dan Carpenter wrote:
>>
>> The "if (pass_size > buf->total)" can underflow so I have changed the
>> type of size and pass_size to unsigned to avoid this problem.
>>
>> Signed-off-by: Dan Carpenter
>
>
> Reviewed-by: Ch
On Fri, Jul 3, 2015 at 5:45 AM, Christian König
wrote:
> On 03.07.2015 01:54, Grigori Goronzy wrote:
>>
>> We don't need to call the (expensive) radeon_bo_wait, checking the
>> fences via RCU is much faster. The reservation done by radeon_bo_wait
>> does not save us from any race conditions.
>>
On Fri, Jul 3, 2015 at 5:51 AM, Christian König
wrote:
> On 03.07.2015 06:03, Mario Kleiner wrote:
>>
>> Trying to resolve issues with missed vblanks and impossible
>> values inside delivered kms pageflip completion events showed
>> that radeon's irq handling sometimes doesn't handle valid irqs,
On Mon, Jul 6, 2015 at 3:19 PM, Dave Jones wrote:
> I wanted to switch my LCD to a different machine momentarily.
> When I plugged the cable back in, this was on the screen..
Is this readily reproducible? Did it happen with 4.1? If it also
happens with 4.1 does reverting
39fa10f7e21574a70cecf1f
The current names were guessed based on downstream driver.
This change replaces the filter fields' names to avoid any
confusion.
Signed-off-by: Stephane Viau
---
rnndb/mdp/mdp5.xml | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/
enum mdp_chroma_samp_type's first value (0) is actually shared by
all non-subsampled formats; that is RGB but also some YUV formats
(eg: YUV444). This change makes the name a little less confusing.
Signed-off-by: Stephane Viau
Signed-off-by: Wentao Xu
---
rnndb/mdp/mdp_common.xml | 2 +-
1 file
Add packed YUV422 and planar YUV420 formats to MDP supported
formats.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 105 +-
drivers/gpu/drm/msm/mdp/mdp_format.c | 19 ++
2 files changed, 77 insertions(+), 47 deletions(-)
diff
From: Wentao Xu
Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
For example, if VIG0 is used to fetch data in YUYV format, it will use
VIG0_Y for Y component, and VIG0_Cr for UV packed.
Signed-off-by: Wentao Xu
[rebase]
Signed-off-by: Stephane Viau
Change-Id: I24df222372
From: Wentao Xu
This makes it easy to determine if a format is YUV. The old
method of using chroma sample type incorrectly marks YUV444 as
RGB format.
Signed-off-by: Wentao Xu
[rebase]
Signed-off-by: Stephane Viau
Change-Id: I3e1fa4473be8421fac8d79100f30bff5823be5f4
---
drivers/gpu/drm/msm/m
See Envytools patch:
rnndb: Rename 1st Source Chroma Sampling option
Signed-off-by: Wentao Xu
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp_common.xml.h | 37 +++-
1 file changed, 3 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/
The current names were guessed based on downstream driver.
This change replaces the filter fields' names to avoid any
confusion.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/g
See envytools commit: "rnndb: Rename scalers' filter fields"
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 58 -
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
b/drivers/gpu/drm
Well, I think this patch set sums up the YUV formats support for MDP5.
Some tricks need to be done around the SMP client allocation to reflect
the newer MDP5 hardware, where all U and V pixels are fetched together.
Envytools patches will be sent separately for the two generated headers.
Rgds,
Step
On Mon, Jul 6, 2015 at 2:40 PM, Steven Newbury wrote:
> On Mon, 2015-07-06 at 12:25 -0400, Alex Deucher wrote:
>> On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury > > wrote:
>> > Hi,
>> > I've been trying to get DRM/KMS working with the current graphics
>> > stack (xf86-video-ati 7.5, xserver-1.17)
ture for PRIME-imported buffers.
That would make a much better comment than what you currently have. =)
> This is why I would have preferred to have this information somehow
> attached to the buffer itself, or specified at import time, since
> having a dedicated ioctl tends to suggest that it is to change the
> tiling settings.
>
> I wanted your thoughts on the topic because I know you had the same
> issue with tegra DRM and actively looked for a solution - but from
> your comments, it seems like that solution is to simply use a
> dedicated IOCTL for this.
Yes, I know of no other way to do this.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/c0b7fbf0/attachment.sig>
I wanted to switch my LCD to a different machine momentarily.
When I plugged the cable back in, this was on the screen..
WARNING: CPU: 1 PID: 209 at kernel/locking/mutex.c:526
__mutex_lock_slowpath+0x322/0x340()
DEBUG_LOCKS_WARN_ON(l->magic != l)
CPU: 1 PID: 209 Comm: kworker/1:3 Not tainted 4.2.
cation/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/0dde718f/attachment.sig>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/15963e46/attachment.html>
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocat
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a
From: Julien Cristau
Add sys/sysctl.h to get sysctlbyname declaration on kFreeBSD
Updated by Thorsten âmirabilosâ Glaser
to add autoconf check and only include if it
is detected by configure as itâs unusable on Linux/x32 (and
others, e.g. other new architectures).
---
A trivial patch pi
top.org/archives/dri-devel/attachments/20150706/7607c213/attachment-0001.html>
On Mon, Jul 6, 2015 at 9:39 AM, Steven Newbury wrote:
> Hi,
> I've been trying to get DRM/KMS working with the current graphics
> stack (xf86-video-ati 7.5, xserver-1.17) on a R200 series card. I
> assumed this should be working since KMS was implemented for it a
> while back, and it has been wor
On Mon, Jul 06, 2015 at 06:11:29PM +0900, Michel Dänzer wrote:
>
> Hi Jérôme,
>
> On 13.08.2014 12:52, Jérôme Glisse wrote:
> > From: Jérôme Glisse
> >
> > Current code never allowed the page pool to actualy fill in anyway. This fix
> > it and also allow it to grow over its limit until i
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/9ec75b2d/attachment.html>
From: Gustavo Padovan
struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had
only a drm_encoder member and the internal exynos_drm_encoders ops that
was directly mapped to the drm_encoder helper funcs.
So now exynos DRM uses struct drm_encoder directly, this removes
completely
From: Gustavo Padovan
As we are removing the exynos encoder move the encoder setup operation
directly inside the exynos_drm_load()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++--
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 13 -
d
From: Gustavo Padovan
This functions was just hiding the encoder and connector creation in
a way that was less clean than if we get rid of it. For example,
exynos_encoder ops had .create_connector() defined only because we were
handing off the encoder and connector creation to
exynos_drm_create_e
From: Gustavo Padovan
.commit() is not used anymore, Exynos encoders now follow the
.enable()/.disable() semantics from drm atomic core, so remove this
callback.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
drivers/gpu/drm/exynos/exynos_drm_encoder.c |
From: Gustavo Padovan
exynos_dp_commit() was getting called twice by exynos encoder core, once
inside the .enable() call and another time by .commit() itself.
The remove of the second call caused the wake of a bug, the operations
orders inside exynos_dp_commit was wrong and we had to move
exynos
From: Gustavo Padovan
hdmi_commit() was getting called twice by exynos encoder core, once inside
the .enable() call and another time by .commit() itself.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +
1 file changed, 1 insertion(+), 16 deletions
From: Gustavo Padovan
This struct was just representing encoder information, it was a member of
struct exynos_drm_encoder, so any code trying to access encoder data would
have to go through the encoder struct, get the display struct and then get
the data it want.
During this patchset we also rea
From: Gustavo Padovan
All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a
possible CRTCs. This patch removes an extra function with switch that was
only checking if the CRTC type was one of those three above.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
These two display_ops are not used anywhere, remove them.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
From: Gustavo Padovan
phy_power_on() and phy_power_off() already checks for NULL pointer.
This patch removes the wrappers exynos_dp_phy_init() and
exynos_dp_phy_exit() since the only think they were doing was a check for
NULL phy.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
The DRM Core doesn't have a dpms() operation anymore, everything
now is enable() or disable().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 37
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 36
drivers/
From: Gustavo Padovan
struct drm_crtc already stores the enabled state of the crtc
thus we don't need to replicate enabled in exynos_drm_crtc.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
2 f
From: Gustavo Padovan
Instead of blindly ignore the return value of enable_vblank return it
to the upper DRM layer for error handling.
Suggested-by: Joonyoung Shim
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Gustavo Padovan
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14
From: Gustavo Padovan
Now after the move to use drm_plane_state directly struct drm_plane_state
has many unused fields, along with others that weren't used before the
plane state change. Thus remove them all.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 18 -
From: Gustavo Padovan
For some fields the use of struct exynos_drm_plane filled with data from
the plane state just creates a source of duplicated information and
overhead. Here we change the crtc drivers to access the plane state
directly simplifying the code by not relying on a exynos internal
From: Gustavo Padovan
We already have the plane pointer in before calling .update_plane() or
disable_plane() so pass it directly to those calls avoiding a new
conversion from zpos to struct exynos_drm_plane.
v2: don't remove check for suspended in FIMD (comment by Joonyoung)
Signed-off-by: Gust
From: Gustavo Padovan
Rename win_commit() helper to update_plane() and win_disable() to
disable_plane().
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will schedule a work task to run the update later.
It also waits an update to finish before schedule a new one.
S
From: Gustavo Padovan
The same check is placed twice in fimd/decon_update_plane(), remove
one of them.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/driver
From: Gustavo Padovan
Get rid of legacy DRM vblank function that are less clear to use.
The new ones basically requires only the crtc as parameters.
It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a
consequence.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exyno
From: Gustavo Padovan
When mode's vrefresh is zero we should ask DRM core to calculate vrefresh
for us so we can get the correct value instead of relying on fixed value
defined in a macro. But if vrefresh is still zero we should fail the
update.
v2: fix comment by Joonyoung
- assign vref
From: Gustavo Padovan
Instead of giving -1 to as arg to drm_send_vblank_event() pass the
correct pipe number to it.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm
From: Gustavo Padovan
Hi,
This set improves exynos in a number of ways. The first five patches are
general clean up/fixes.
Patches 06 to 12 are improveme
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/bcf87a0e/attachment.html>
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Furthermore there is devm_gpiod_get_optional which is designed to get
optional g
Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.
Use this to simplify the driver. Furthermore this is one caller less
that stops
Hello,
now that all patches that were in next hit Linus Torvalds' tree and
v4.2-rc1 is out here comes the promised pull request that makes usage of
the flags parameter mandatory for gpiod_get et al:
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (201
s bug
that's more than enough to say it's good.
--
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/20150706/d509d10f/attachment.html>
y
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/104a9b62/attachment-0001.html>
From: Markus Elfring
Date: Mon, 6 Jul 2015 09:49:11 +0200
The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/vmwgfx/vmwgfx_execb
On Mon, Jul 06, 2015 at 10:01:52AM +0800, John Hunter wrote:
> On Mon, Jul 6, 2015 at 4:00 AM, SF Markus Elfring <
> elfring at users.sourceforge.net> wrote:
>
> > From: Markus Elfring
> > Date: Sun, 5 Jul 2015 21:55:10 +0200
> >
> > The drm_property_unreference_blob() function tests whether its
eiving 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/20150706/e6732bba/attachment-0001.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/b86a41d8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #13 from Lorenzo Bona ---
(In reply to Alex Deucher from comment #12)
> What are the pci ids of the audio devices on the GPU? Does adding or
> updating your audio devices' entries in the hda driver like the following
> patch does help
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150706/97b29744/attachment.html>
://lists.freedesktop.org/archives/dri-devel/attachments/20150706/defd5ad4/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=86351
--- Comment #12 from Alex Deucher ---
What are the pci ids of the audio devices on the GPU? Does adding or updating
your audio devices' entries in the hda driver like the following patch does
help?
http://git.kernel.org/cgit/linux/kernel/git/tor
lists.freedesktop.org/archives/dri-devel/attachments/20150706/d051771c/attachment.html>
78 matches
Mail list logo
