On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse wrote:
> Yes preemption and gpu scheduling would break such scheme, but my point is
> that when you have such gpu you want to implement a proper solution. Which
> of course require quite some work accross the stack. So the past can live
> on but the f
On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse wrote:
> Cost 1 uint32 per buffer and simple if without locking to check status of
> a buffer.
Yeah well except it doesn't and that's why we switch to full blown
fence objects internally instead of smacking seqno values all over the
place. At least i
On Thu, Aug 14, 2014 at 9:56 PM, Jerome Glisse wrote:
> Android fence are not in my mind a nice thing :)
Well I'll have a very close look at the proposed ioctl interface on
top of these fence fds to make sure it's sane. But it will come that's
pretty much for sure. And similar fence integration w
On 14-08-14 21:15, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote:
>>> Sucks because you can not do weird synchronization like one i depicted in
>>> another
>>> mail in this thread and for as long as
On 14-08-14 20:26, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 05:58:48PM +0200, Daniel Vetter wrote:
>> On Thu, Aug 14, 2014 at 10:12:06AM -0400, Jerome Glisse wrote:
>>> On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse
wrot
On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote:
> Sucks because you can not do weird synchronization like one i depicted in
> another
> mail in this thread and for as long as cmdbuf_ioctl do not give you
> fence|syncpt
> you can not such thing cleanly in non hackish way.
Actually i915 can
t be in PPA. You can probably wait to worry about it until such a
> patch exists.
Ok, hope the process is seamless.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists
/dri-devel/attachments/20140814/a4c23b2b/attachment.html>
On Wed, Aug 13, 2014 at 9:01 PM, wrote:
> From: Wei Yongjun
>
> Add the missing unlock before return from function msm_fbdev_create()
> in the error handling case.
>
> Signed-off-by: Wei Yongjun
Thanks, I've got it queued up..
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
> 1 file
On Thu, Aug 14, 2014 at 11:23:01PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse wrote:
> > Cost 1 uint32 per buffer and simple if without locking to check status of
> > a buffer.
>
> Yeah well except it doesn't and that's why we switch to full blown
> fence objects
https://bugzilla.kernel.org/show_bug.cgi?id=77181
--- Comment #5 from Rostislav Devyatov ---
(In reply to Alex Deucher from comment #4)
> Did it used to work previously? If so what kernel? If you know what kernel
> used to work, you can use git to bisect the changes and identify what change
> b
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140814/c46ff7e8/attachment.html>
might help...
--
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/20140814/43f19833/attachment-0001.html>
ves/dri-devel/attachments/20140814/60dd60d0/attachment.html>
From: Christian K?nig
This is useful and only allowed with pure sync objects. E.g.
the CS depends on finishing a previous CS, but should not add
the new fence the handle.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_cs.c | 29 -
include/uapi/drm/
From: Christian K?nig
This allows userspace to explicitly don't sync submission to
different rings as long as all uses stay in the same client.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 3 +++
drivers/gpu/drm/radeon/radeon_cs.c | 23 ++-
dri
From: Christian K?nig
This patch allows concurrent access of different engines to the same BO
as long as everybody only reads from it. Since TTM can't (yet) handle
multiple fences for one BO we still sync the fence after executing the IB.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/rade
From: Christian K?nig
This allows us to run different engines concurrently and
still have the fences sync to all operations as currently
required by TTM.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 3 ++-
drivers/gpu/drm/radeon/radeon_cs.c | 18 --
Hello everyone,
this set of patch adds the ability for userspace to better control when
synchronization between the different hardware engines on radeon happens.
Previously every access to a buffer object was serialized and concurrent
execution could only happen if command submissions didn't sh
On Thu, Aug 14, 2014 at 10:12 AM, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
>> On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse wrote:
>> > So this is fundamentaly different, fence as they are now allow random
>> > driver
>> > callback and this is bound to g
On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote:
> Make sure plane rotation is reset correctly when restoring the fbdev
> configuration by using drm_mode_plane_set_obj_prop. This calls the
> driver's set_property callback and ensures the rotation is actually
> changed.
>
> Bugzilla: ht
ts.freedesktop.org/archives/dri-devel/attachments/20140814/5ce5ed5a/attachment.html>
nstalling lib32-mesa-git and mesa-git.
--
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/20140814/8fac088f/attachment.html>
On Thu, Aug 14, 2014 at 10:12:06AM -0400, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
> > On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse
> > wrote:
> > > So this is fundamentaly different, fence as they are now allow random
> > > driver
> > > callback and th
On Thu, Aug 14, 2014 at 10:23:30AM -0400, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 11:08:34AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 13, 2014 at 01:07:20PM -0400, Jerome Glisse wrote:
> > > Let me make this crystal clear this must be a valid kernel page that have
> > > a
> > > valid ker
ing as well. It's must
easier to just install the oibaf PPA. I have no issues after the fix.
--
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/arc
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/e3c8d58b/attachment-0001.html>
es any difference.
At least it's a small time window to bisect.
--
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/201
On Thu, Aug 14, 2014 at 04:34:29PM -0400, Alex Deucher wrote:
> On Thu, Aug 14, 2014 at 2:43 PM, Jerome Glisse wrote:
> > On Thu, Aug 14, 2014 at 06:12:04PM +0200, Christian K?nig wrote:
> >> From: Christian K?nig
> >>
> >> This allows userspace to explicitly don't sync submission to
> >> differe
https://bugzilla.kernel.org/show_bug.cgi?id=77181
--- Comment #4 from Alex Deucher ---
(In reply to Rostislav Devyatov from comment #3)
> (In reply to Alex Deucher from comment #2)
>
> I am sorry, but I don't think I understand you. What do you mean by
> "regression"? What am I trying to bisect?
that won't be in PPA. You can probably wait to worry about it until such a
patch exists.
--
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/20140814/18a879a1/attachment.html>
On Thu, Aug 14, 2014 at 2:43 PM, Jerome Glisse wrote:
> On Thu, Aug 14, 2014 at 06:12:04PM +0200, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> This allows userspace to explicitly don't sync submission to
>> different rings as long as all uses stay in the same client.
>>
>> Signed-off-by:
Make sure plane rotation is reset correctly when restoring the fbdev
configuration by using drm_mode_plane_set_obj_prop. This calls the
driver's set_property callback and ensures the rotation is actually
changed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
Signed-off-by: Thomas Wo
Am 14.08.2014 um 14:37 schrieb Maarten Lankhorst:
> Op 14-08-14 om 13:53 schreef Christian K?nig:
>>> But because of driver differences I can't implement it as a straight wait
>>> queue. Some drivers may not have a reliable interrupt, so they need a
>>> custom wait function. (qxl)
>>> Some may ne
ry>;
port {
lcd_in0: endpoint {
remote-endpoint = <&dsi1_out_ep>;
};
};
};
};
&dsi2 {
port {
dsi2_out_ep: endpoint {
remote-endpoint = <&lcd_in1>;
lanes = <0 1 2 3 4 5>;
};
};
panel_secondary: display {
compatible = "sharp,lq101r1sx01-secondary";
port {
lcd_in1: endpoint {
remote-endpoint = <&dsi2_out_ep>;
};
};
};
};
I guess the above was already more or less presented in the thread, but I
didn't see it written out.
So there would two two devices, a master and a slave, and in the driver side
the slave would not do anything by itself.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/79f17c19/attachment-0001.sig>
On Thu, Aug 14, 2014 at 09:40:08PM +0200, Maarten Lankhorst wrote:
>
>
> On 14-08-14 21:15, Jerome Glisse wrote:
> > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse
> >> wrote:
> >>> Sucks because you can not do weird synchroniz
https://bugzilla.kernel.org/show_bug.cgi?id=77181
--- Comment #3 from Rostislav Devyatov ---
(In reply to Alex Deucher from comment #2)
I am sorry, but I don't think I understand you. What do you mean by
"regression"? What am I trying to bisect?
--
You are receiving this mail because:
You are
On Wed, 13 Aug 2014 17:13:56 +0200
Thomas Hellstrom wrote:
> On 08/13/2014 03:01 PM, Daniel Vetter wrote:
> > On Wed, Aug 13, 2014 at 02:35:52PM +0200, Thomas Hellstrom wrote:
> >> On 08/13/2014 12:42 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 13, 2014 at 11:06:25AM +0200, Thomas Hellstrom wrote:
On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote:
> > Sucks because you can not do weird synchronization like one i depicted in
> > another
> > mail in this thread and for as long as cmdbuf_ioctl do not give you
> > fence|syncp
On Thu, Aug 14, 2014 at 06:12:04PM +0200, Christian K?nig wrote:
> From: Christian K?nig
>
> This allows userspace to explicitly don't sync submission to
> different rings as long as all uses stay in the same client.
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon.h
Op 14-08-14 om 13:53 schreef Christian K?nig:
>> But because of driver differences I can't implement it as a straight wait
>> queue. Some drivers may not have a reliable interrupt, so they need a custom
>> wait function. (qxl)
>> Some may need to do extra flushing to get fences signaled (vmwgfx),
On Thu, Aug 14, 2014 at 06:12:01PM +0200, Christian K?nig wrote:
> Hello everyone,
>
> this set of patch adds the ability for userspace to better control when
> synchronization between the different hardware engines on radeon happens.
> Previously every access to a buffer object was serialized and
On Thu, Aug 14, 2014 at 05:58:48PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 10:12:06AM -0400, Jerome Glisse wrote:
> > On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
> > > On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse
> > > wrote:
> > > > So this is fundamentaly differen
Am 14.08.2014 um 14:17 schrieb Andreas Ruprecht:
> In the Makefile, radeon_uvd.o is added to radeon-y twice.
>
> As it belongs to the UVD block marked with a comment, the other include
> from the block of includes labelled as "KMS driver" is deleted.
>
> Signed-off-by: Andreas Ruprecht
Nice catch
On Thu, Aug 14, 2014 at 05:55:51PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 10:23:30AM -0400, Jerome Glisse wrote:
> > On Thu, Aug 14, 2014 at 11:08:34AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 13, 2014 at 01:07:20PM -0400, Jerome Glisse wrote:
> > > > Let me make this crystal cl
In the Makefile, radeon_uvd.o is added to radeon-y twice.
As it belongs to the UVD block marked with a comment, the other include
from the block of includes labelled as "KMS driver" is deleted.
Signed-off-by: Andreas Ruprecht
---
drivers/gpu/drm/radeon/Makefile | 2 +-
1 file changed, 1 inserti
> But because of driver differences I can't implement it as a straight wait
> queue. Some drivers may not have a reliable interrupt, so they need a custom
> wait function. (qxl)
> Some may need to do extra flushing to get fences signaled (vmwgfx), others
> need some locking to protect against gp
https://bugzilla.kernel.org/show_bug.cgi?id=77181
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 fr
;Can you try a build of master?"
Can't I just wait for new build in PPA?
--
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/20140814/30fc627c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=77181
Rostislav Devyatov changed:
What|Removed |Added
CC||deviatov at gmail.com
--- Comment #1
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/3ba79b1c/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78221
Tomasz Mloduchowski changed:
What|Removed |Added
CC||q at qdot.me
--- Comment #17 from T
"good" kernel for both.
--
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/20140814/916d470b/attachment.html>
The type of this function is unsigned long, and it is expected
to return proper fout value or zero if something is wrong.
So this patch fixes wrong return value for error cases.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c |
Op 13-08-14 om 19:07 schreef Jerome Glisse:
> On Wed, Aug 13, 2014 at 05:54:20PM +0200, Daniel Vetter wrote:
>> On Wed, Aug 13, 2014 at 09:36:04AM -0400, Jerome Glisse wrote:
>>> On Wed, Aug 13, 2014 at 10:28:22AM +0200, Daniel Vetter wrote:
On Tue, Aug 12, 2014 at 06:13:41PM -0400, Jerome Gli
On Wed, Aug 13, 2014 at 01:07:20PM -0400, Jerome Glisse wrote:
> Let me make this crystal clear this must be a valid kernel page that have a
> valid kernel mapping for the lifetime of the device. Hence there is no access
> to mmio space or anything, just a regular kernel page. If can not rely on th
This else statement wasn't indented so it was confusing.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nouveau_usif.c
b/drivers/gpu/drm/nouveau/nouveau_usif.c
index cb1182d..41c9b404 100644
--- a/drivers/gpu/drm/nouveau/nouveau_usif.c
+++ b/drivers/gpu/drm/nouveau/nouveau_us
On Thu, Aug 14, 2014 at 11:08:34AM +0200, Daniel Vetter wrote:
> On Wed, Aug 13, 2014 at 01:07:20PM -0400, Jerome Glisse wrote:
> > Let me make this crystal clear this must be a valid kernel page that have a
> > valid kernel mapping for the lifetime of the device. Hence there is no
> > access
> >
On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
> On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse wrote:
> > So this is fundamentaly different, fence as they are now allow random driver
> > callback and this is bound to get ugly this is bound to lead to one driver
> > doing something tha
On Thu, Aug 14, 2014 at 11:15:11AM +0200, Maarten Lankhorst wrote:
> Op 13-08-14 om 19:07 schreef Jerome Glisse:
> > On Wed, Aug 13, 2014 at 05:54:20PM +0200, Daniel Vetter wrote:
> >> On Wed, Aug 13, 2014 at 09:36:04AM -0400, Jerome Glisse wrote:
> >>> On Wed, Aug 13, 2014 at 10:28:22AM +0200, Dan
Hi YoungJun,
Thanks for spotting it.
On 08/14/2014 04:22 AM, YoungJun Cho wrote:
> The type of this function is unsigned long, and it is expected
> to return proper fout value or zero if something is wrong.
> So this patch fixes wrong return value for error cases.
>
> Signed-off-by: YoungJun Cho
On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse wrote:
> So this is fundamentaly different, fence as they are now allow random driver
> callback and this is bound to get ugly this is bound to lead to one driver
> doing something that seems innocuous but turn out to break heavoc when call
> from som
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/e1a4f7de/attachment.html>
From: Wei Yongjun
Add the missing unlock before return from function msm_fbdev_create()
in the error handling case.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/d
From: Wei Yongjun
In case of error, the function platform_device_register_resndata()
returns ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/sti/sti_drm_drv.c | 4 ++--
1 file changed, 2
From: Wei Yongjun
In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/sti/sti_hda.c | 8
1 file changed, 4 insertions(+),
From: Wei Yongjun
In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/sti/sti_hdmi.c | 8
1 file changed, 4 insertions(+)
From: Wei Yongjun
In case of error, the function devm_ioremap_nocache() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/sti/sti_tvout.c | 4 ++--
1 file changed, 2 insertions(+), 2
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/24f61fb7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=82371
Pablo Wagner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sun, Aug 10, 2014 at 6:34 PM, Bruno Pr?mont
wrote:
> On Sun, 10 August 2014 Andreas Noever wrote:
>> On Sun, Aug 10, 2014 at 11:26 AM, Bruno Pr?mont wrote:
>> > On Sun, 10 August 2014 Andreas Noever wrote:
>> >
>> >> On Sun, Aug 10, 2014 at 2:21 AM, Andreas Noeverwrote:
>> >> > I just tried to
https://bugzilla.kernel.org/show_bug.cgi?id=82371
--- Comment #2 from Michel D?nzer ---
Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=82428 , fixed in
current Mesa Git.
--
You are receiving this mail because:
You are watching the assignee of the bug.
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/7b9d4466/attachment.html>
Compare the clock in the limits table to the requested evclk rather
than just taking the first value.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/kv_dpm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/kv_
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/4da337fe/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/9c263599/attachment.html>
76 matches
Mail list logo
