On Wed, Jul 23, 2014 at 11:34:00PM +0200, Daniel Vetter wrote:
> On Wed, Jul 23, 2014 at 03:38:14PM -0400, Rob Clark wrote:
> > The 'atomic' mechanism allows for multiple properties to be updated,
> > checked, and commited atomically. This will be the basis of atomic-
> > modeset and nuclear-pagef
On Wed, Jul 23, 2014 at 03:38:14PM -0400, Rob Clark wrote:
> The 'atomic' mechanism allows for multiple properties to be updated,
> checked, and commited atomically. This will be the basis of atomic-
> modeset and nuclear-pageflip.
>
> The basic flow is:
>
>state = dev->atomic_begin();
>
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Jesse Barnes
>Sent: Wednesday, July 23, 2014 5:00 PM
>To: dri-devel at lists.freedesktop.org
>Subject: Re: [PATCH v2 00/25] AMDKFD kernel driver
>
>On Mon, 21 Jul 2014 19:05:46 +0200
>dan
On Wed, Jul 23, 2014 at 09:29:48PM +0200, Daniel Vetter wrote:
> On Wed, Jul 23, 2014 at 05:26:41PM +0200, David Herrmann wrote:
> > Testing the return value of list_entry() for NULL is a no-op (as it is
> > just a fancy container_of() / offsetof()). Drop the superfluous if-clause
> > and instead v
On Wed, Jul 23, 2014 at 05:26:37PM +0200, David Herrmann wrote:
> This object is unused, drop it.
>
> Signed-off-by: David Herrmann
Funny how after even all my "kill stuff with fire" series there's still
such low hanging fruit left ;-)
Reviewed-by: Daniel Vetter
> ---
> include/drm/drmP.h |
On Wed, Jul 23, 2014 at 05:26:45PM +0200, David Herrmann wrote:
> All that is left in drm_drv.c is ioctl management. Merge it into
> drm_ioctl.c so we have all ioctl management in one file (and the name is
> much more fitting).
>
> Maybe we should now rename drm_stub.c to drm_drv.c again?
>
> Sig
On Wed, Jul 23, 2014 at 05:26:41PM +0200, David Herrmann wrote:
> Testing the return value of list_entry() for NULL is a no-op (as it is
> just a fancy container_of() / offsetof()). Drop the superfluous if-clause
> and instead verify the actual root-node is available. This is probably
> what it was
On Wed, Jul 23, 2014 at 05:26:39PM +0200, David Herrmann wrote:
> The ctxbitmap code is only used by legacy drivers so lets try to keep it
> as separated as possible. Furthermore, the locking is non-obvious and
> kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
> access in o
On Wed, Jul 23, 2014 at 05:26:38PM +0200, David Herrmann wrote:
> Lets order things correctly:
> ->load()
>->fistopen()
> ->open()
> ->close()
>->lastclose()
> ->unload()
>
> This doesn't change much as only savage and radeon use ->firstopen() and
> they just do map-initializat
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/20140723/423b9eed/attachment.html>
On Wed, Jul 23, 2014 at 05:26:36PM +0200, David Herrmann wrote:
> This object is not used except for static fields in drm_bufs *cough*.
> Inline the watermark fields and drop the unused structure definition.
>
> Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/d
On Wed, Jul 23, 2014 at 8:12 PM, Sean Paul wrote:
> On Wed, Jul 23, 2014 at 7:22 AM, Ajay kumar wrote:
>> Sean,
>>
>> On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul wrote:
>>> On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar
>>> wrote:
Move the DP training and video enable from the hotplug handler
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/3545e7fa/attachment.html>
||
--
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/20140723/6cdf6e0e/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/769f7e21/attachment-0001.html>
-12
Is this bug known? Any ideas or suggestion, how i can help to solve this issue?
--
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/attac
Hi
On Wed, Jul 23, 2014 at 5:26 PM, David Herrmann
wrote:
> All that is left in drm_drv.c is ioctl management. Merge it into
> drm_ioctl.c so we have all ioctl management in one file (and the name is
> much more fitting).
>
> Maybe we should now rename drm_stub.c to drm_drv.c again?
>
> Signed-o
On 23.07.2014 16:47, Christian K?nig wrote:
> From: Christian K?nig
>
> We must mask out the overflow bit as well, otherwise
> the wptr will never match the rptr again and the interrupt
> handler will loop forever.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
> Cc: stable a
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140723/2d53535f/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/20140723/6a83595d/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/277a13a8/attachment.html>
On Wed, Jul 23, 2014 at 03:38:17PM -0400, Rob Clark wrote:
...
> @@ -2702,10 +2895,11 @@ static int drm_mode_cursor_universal(struct drm_crtc
> *crtc,
>* setplane_internal will take care of deref'ing either the old or new
>* framebuffer depending on success.
>*/
> - ret
For each minor we allocate a sysfs device as minor->kdev. Currently, this
is allocated and registered in drm_minor_register(). This makes it
impossible to add sysfs-attributes to the device before it is registered.
Therefore, they are not added atomically, nor can we move device_add()
*after* ->loa
Instead of allocating the minor-index during registration, we now do this
during allocation. This way, debug-messages between minor-allocation and
minor-registration will now use the correct minor instead of 0. Same is
done for unregistration vs. free, so debug-messages between
device-shutdown and
All that is left in drm_drv.c is ioctl management. Merge it into
drm_ioctl.c so we have all ioctl management in one file (and the name is
much more fitting).
Maybe we should now rename drm_stub.c to drm_drv.c again?
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 412 ---
Most of the new DRM management functions are nowadays in drm_stub.c. By
moving the core module initialization to drm_stub.c we can make several
global variables static and keep the stub-open helper local.
The core files now look like this:
drm_stub.c: Core management
drm_drv.c: Ioctl dispatch
If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:
1) If this was used as security mechanism, it fails horribly if a master
close
The drm_file->is_master field is redundant as it's equivalent to:
drm_file->master && drm_file->master == drm_file->minor->master
1) "=>"
Whenever we set drm_file->is_master, we also set:
drm_file->minor->master = drm_file->master;
Whenever we clear drm_file->is_master, we also call
Testing the return value of list_entry() for NULL is a no-op (as it is
just a fancy container_of() / offsetof()). Drop the superfluous if-clause
and instead verify the actual root-node is available. This is probably
what it was meant to test for from the beginning, anyway.
Signed-off-by: David Her
Linux doesn't run on i386, anymore. See:
commit d55c5a93db2d5fa95f233ab153f594365d95b777
Author: H. Peter Anvin
Date: Wed Nov 28 11:50:24 2012 -0800
x86, 386 removal: Remove CONFIG_CMPXCHG
All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
co
The ctxbitmap code is only used by legacy drivers so lets try to keep it
as separated as possible. Furthermore, the locking is non-obvious and
kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
access in one file is much easier to review and makes drm_release() more
readable.
Lets order things correctly:
->load()
->fistopen()
->open()
->close()
->lastclose()
->unload()
This doesn't change much as only savage and radeon use ->firstopen() and
they just do map-initialization. Therefore, the global drm mutex makes
sure there cannot be any other f_op betwe
This object is unused, drop it.
Signed-off-by: David Herrmann
---
include/drm/drmP.h | 17 -
1 file changed, 17 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 335b7b8..d3d9be6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -430,23 +430,6 @@
This object is not used except for static fields in drm_bufs *cough*.
Inline the watermark fields and drop the unused structure definition.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_bufs.c | 17 -
drivers/gpu/drm/drm_info.c | 2 +-
include/drm/drmP.h | 15 ++-
Hi
A bunch of random cleanups I stumbled on when reworking the init-logic. Most of
them should be fairly trivial.
Also available in my fdo-repository:
http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=drm-next
Comments welcome!
David
David Herrmann (12):
drm: remove unused "struct drm_freel
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/4db82534/attachment.html>
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, lea
Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
if the G2D was succesfully probe. If that is not the case, then g2d_priv
is just NULL and extracting 'dev' from it in the next step is going to
produce a kernel oops.
Add proper checks and return ENODEV if the G2D is not avai
I blame it on the heat... *sigh*
- Tobias
On Sun, 13 Jul 2014 12:40:32 -0400
j.glisse at gmail.com (Jerome Glisse) wrote:
> On Sun, Jul 13, 2014 at 11:42:58AM +0200, Daniel Vetter wrote:
> > On Sat, Jul 12, 2014 at 6:49 PM, Jerome Glisse
> > wrote:
> > >> Hm, so the hsa part is a completely new driver/subsystem, not just an
> > >> addit
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, lea
Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
if the G2D was succesfully probe. If that is not the case, then g2d_priv
is just NULL and extracting 'dev' from it in the next step is going to
produce a kernel oops.
Add proper checks and return ENODEV if the G2D is not avai
Again, sorry for the noise. These two patches should now really fix what
they're supposed to fix.
- Tobias
Sean,
On Tue, Jul 22, 2014 at 8:29 PM, Sean Paul wrote:
> On Thu, Jul 17, 2014 at 4:43 PM, Ajay Kumar
> wrote:
>> Move the DP training and video enable from the hotplug handler into
>> a seperate function and call the same during dpms ON.
>>
>> With existing code, DP HPD should be generated jus
On Wed, Jul 23, 2014 at 01:33:24PM +, Bridgman, John wrote:
>
>
> >-Original Message-
> >From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> >Sent: Wednesday, July 23, 2014 3:06 AM
> >To: Gabbay, Oded
> >Cc: Jerome Glisse; Christian K?nig; David Airlie; Alex Deucher; Andrew
> >Mo
Sorry for the noise! Please disregard the patch for now, it causes more trouble
than it solves!
- Tobias
?
Gesendet:?Mittwoch, 23. Juli 2014 um 15:57 Uhr
Von:?"Tobias Jakobi"
An:?linux-samsung-soc at vger.kernel.org
Cc:?dri-devel at lists.freedesktop.org, t.figa at samsung.com, inki.dae at
sam
On Wed, Jul 23, 2014 at 03:49:57PM -0400, Alex Deucher wrote:
> On Wed, Jul 23, 2014 at 10:56 AM, Jerome Glisse wrote:
> > On Wed, Jul 23, 2014 at 09:04:24AM +0200, Christian K?nig wrote:
> >> Am 23.07.2014 08:50, schrieb Oded Gabbay:
> >> >On 22/07/14 14:15, Daniel Vetter wrote:
> >> >>On Tue, Ju
On 23.07.2014 15:42, Christian K?nig wrote:
> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>> On 21.07.2014 17:07, Christian K?nig wrote:
>>> Am 19.07.2014 03:15, schrieb Michel D?nzer:
On 19.07.2014 00:47, Christian K?nig wrote:
> Am 18.07.2014 05:07, schrieb Michel D?nzer:
[PATCH
op 23-07-14 15:16, Maarten Lankhorst schreef:
> op 23-07-14 14:36, Christian K?nig schreef:
>> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>>> wrote:
> And the dma-buf would still have fences belonging to both drivers, and it
> would st
Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.
This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, lea
On Wed, Jul 23, 2014 at 10:56 AM, Jerome Glisse wrote:
> On Wed, Jul 23, 2014 at 09:04:24AM +0200, Christian K?nig wrote:
>> Am 23.07.2014 08:50, schrieb Oded Gabbay:
>> >On 22/07/14 14:15, Daniel Vetter wrote:
>> >>On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
>> >>>On 22/07/14 12:
From: Sean Paul
BUG=chromium:336809
TEST=Tested on snow & peppy
Change-Id: Icd864ac52da9c973202f3ac4629824ef5eec2ac9
Signed-off-by: Sean Paul
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_atomic.c | 4
drivers/gpu/drm/drm_crtc.c | 11 ---
include/drm/drm_crtc.h | 1 +
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 57 ++--
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 ++
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 5 --
Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes. This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in thei
Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes. This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in t
From: Ville Syrj?l?
Refactor the code to check whether an object has a specific property
to a new function.
v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT
Signed-off-by: Ville Syrj?l?
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 25 ++---
1
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
And since we are touching all the same code, add support for mut
The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically. This will be the basis of atomic-
modeset and nuclear-pageflip.
The basic flow is:
state = dev->atomic_begin();
for (... one or more ...)
obj->set_property(obj, state, prop, value);
This is mostly just a rebase+resend. Was going to send it a bit earlier
but had a few things to fix up as a result of the rebase.
At this point, I think next steps are roughly:
1) introduce plane->mutex
2) decide what we want to do about events
3) add actual ioctl
I think we could shoot for merg
uls the purpose of the DCS functions. They should
really be making it easier for both host and peripheral drivers by
translating between DCS and the raw DSI packet data.
So what I'm currently thinking is that we need a better definition for
exactly what data should go into a struct mipi_dsi_msg. I think it
should be raw DSI data (that is, including the header and the payload)
so that the only job of drivers is to write it into the corresponding
FIFO registers and start the transmission.
Similarly, when receiving data the .transfer() function should pass up a
complete buffer (including the header and payload) to the receive buffer
and let some upper layer handle this. That way we can layer things in
helpers rather than having to duplicate the same code in each DSI host
driver.
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/20140723/481aec68/attachment.sig>
On 18.07.2014 20:45, Marek Ol??k wrote:
> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
> patch is okay.
AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call
glMemoryBarrier() to ensure coherency between access to the mapping and
GL commands. Since we don't nee
op 23-07-14 14:36, Christian K?nig schreef:
> Am 23.07.2014 12:52, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
>> wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
>>>
>>> Calling fro
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Bridgman, John
>Sent: Wednesday, July 23, 2014 11:07 AM
>To: Daniel Vetter
>Cc: Lewycky, Andrew; linux-mm; Daniel Vetter; Daenzer, Michel; linux-
>kernel at vger.kernel.org; Sellek, Tom;
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
>Vetter
>Sent: Wednesday, July 23, 2014 10:42 AM
>To: Bridgman, John
>Cc: Daniel Vetter; Gabbay, Oded; Jerome Glisse; Christian K?nig; David Airlie;
>Alex Deucher; Andrew Morton; Joerg Roedel;
On Wed, Jul 23, 2014 at 2:36 PM, Christian K?nig
wrote:
> My idea was more that the fence framework provides a
> fence->process_signaling callback that is periodically called after
> enable_signaling is called to trigger manual signal processing in the
> driver.
>
> This would both be suitable as
Am 23.07.2014 12:52, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
> wrote:
>>> And the dma-buf would still have fences belonging to both drivers, and it
>>> would still call from outside the driver.
>>
>> Calling from outside the driver is fine as long as the driver c
On 23 July 2014 06:02, Paulo Zanoni wrote:
> 2014-06-05 1:01 GMT-03:00 Dave Airlie :
>> From: Dave Airlie
>>
>> This adds DP 1.2 MST support on Haswell systems.
>
> Hi
>
> It looks like drm-intel-nightly now includes this patch. It actually
> includes v7, but I couldn't find it on my mail dirs.
>
On 22 July 2014 18:51, Russell King wrote:
> On Fri, Jul 11, 2014 at 09:03:44PM +0100, Russell King wrote:
>> David,
>>
>> Please incorporate the latest Armada DRM updates, which can be found at:
>>
>> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel
>
> Ping?
>
sorry I wanted to c
On Wed, Jul 23, 2014 at 9:21 AM, Michel D?nzer wrote:
> On 23.07.2014 15:42, Christian K?nig wrote:
>> Am 23.07.2014 05:54, schrieb Michel D?nzer:
>>> On 21.07.2014 17:07, Christian K?nig wrote:
Am 19.07.2014 03:15, schrieb Michel D?nzer:
> On 19.07.2014 00:47, Christian K?nig wrote:
On Mon, 21 Jul 2014 19:05:46 +0200
daniel at ffwll.ch (Daniel Vetter) wrote:
> On Mon, Jul 21, 2014 at 11:58:52AM -0400, Jerome Glisse wrote:
> > On Mon, Jul 21, 2014 at 05:25:11PM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 21, 2014 at 03:39:09PM +0200, Christian K?nig wrote:
> > > > Am 21.07.2
This sounds good to me.
Marek
On Wed, Jul 23, 2014 at 8:32 AM, Michel D?nzer wrote:
> On 18.07.2014 20:45, Marek Ol??k wrote:
>> If the requirements of GL_MAP_COHERENT_BIT are satisfied, then the
>> patch is okay.
>
> AFAICT GL_MAP_COHERENT_BIT simply means the app doesn't need to call
> glMemor
>-Original Message-
>From: Christian K?nig [mailto:deathsimple at vodafone.de]
>Sent: Wednesday, July 23, 2014 3:04 AM
>To: Gabbay, Oded; Jerome Glisse; David Airlie; Alex Deucher; Andrew
>Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel;
>Goz, Ben; Skidanov, Alexey;
>-Original Message-
>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
>Sent: Wednesday, July 23, 2014 3:06 AM
>To: Gabbay, Oded
>Cc: Jerome Glisse; Christian K?nig; David Airlie; Alex Deucher; Andrew
>Morton; Bridgman, John; Joerg Roedel; Lewycky, Andrew; Daenzer, Michel;
>Goz, Ben;
On 06/18/2014 04:21 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> When tegra-drm.ko is built as a module, these MODULE_DEVICE_TABLEs allow
> the module to be auto-loaded since the module will match the devices
> instantiated from device tree.
>
> (Notes for stable: in 3.14+, just git rm a
;
intel_display_power_get(dev_priv, power_domain);
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/bc8e9037/attachment-0001.sig>
non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/d85aabca/attachment.sig>
On 07/23/2014 09:51 AM, Thierry Reding wrote:
> On Tue, Jul 22, 2014 at 11:33:11AM +0200, Andrzej Hajda wrote:
>> On 07/22/2014 10:12 AM, Thierry Reding wrote:
>>> On Tue, Jul 22, 2014 at 09:32:58AM +0200, Andrzej Hajda wrote:
On 07/22/2014 09:12 AM, Thierry Reding wrote:
> From: Thierry R
On 21.07.2014 17:07, Christian K?nig wrote:
> Am 19.07.2014 03:15, schrieb Michel D?nzer:
>> On 19.07.2014 00:47, Christian K?nig wrote:
>>> Am 18.07.2014 05:07, schrieb Michel D?nzer:
>> [PATCH 5/5] drm/radeon: Use VRAM for indirect buffers on >= SI
> I'm still not very keen with this chan
On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig
wrote:
>
>> And the dma-buf would still have fences belonging to both drivers, and it
>> would still call from outside the driver.
>
>
> Calling from outside the driver is fine as long as the driver can do
> everything necessary to complete it's wo
part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140723/a189799a/attachment.sig>
On Wed, Jul 23, 2014 at 11:26 AM, David Herrmann
wrote:
> Hi
>
> A bunch of random cleanups I stumbled on when reworking the init-logic. Most
> of
> them should be fairly trivial.
>
> Also available in my fdo-repository:
>http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=drm-next
>
> Comments
Am 23.07.2014 11:55, schrieb Maarten Lankhorst:
> op 23-07-14 11:47, Christian K?nig schreef:
>> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>>> wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to regi
Am 23.07.2014 11:07, schrieb Michel D?nzer:
> On 23.07.2014 16:47, Christian K?nig wrote:
>> From: Christian K?nig
>>
>> We must mask out the overflow bit as well, otherwise
>> the wptr will never match the rptr again and the interrupt
>> handler will loop forever.
>>
>> Signed-off-by: Christian K
https://bugzilla.kernel.org/show_bug.cgi?id=81001
Bug ID: 81001
Summary: radeon: fence wait failed (-35) after hybrid suspend,
leading to GPU reset and hangs
Product: Drivers
Version: 2.5
Kernel Version: 3.15+
Hardware:
op 23-07-14 11:47, Christian K?nig schreef:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> wrote:
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait function. We must kee
On Wed, Jul 23, 2014 at 11:47 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:44, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
>> wrote:
>>>
>>> The scheduler needs to keep track of a lot of fences, so I think we'll
>>> have to register callbacks, not a simple wait func
Am 23.07.2014 11:44, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
> wrote:
>> The scheduler needs to keep track of a lot of fences, so I think we'll
>> have to register callbacks, not a simple wait function. We must keep
>> track of all the non-i915 fences for all oust
On Tue, Jul 22, 2014 at 9:14 PM, Jesse Barnes
wrote:
>> We don't have the code yet ready, but that's the direction i915 will
>> move towards for the near future. Jesse is working on some patches
>> already.
>
> Yeah I'd like to get some feedback from Maarten on my bits so I can get
> them ready f
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter
wrote:
> The scheduler needs to keep track of a lot of fences, so I think we'll
> have to register callbacks, not a simple wait function. We must keep
> track of all the non-i915 fences for all oustanding batches. Also, the
> scheduler doesn't elimi
Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
> op 23-07-14 11:36, Christian K?nig schreef:
>> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>>> wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be f
On Wed, Jul 23, 2014 at 11:36 AM, Christian K?nig
wrote:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>>
>>> You submit a job to the hardware and then block the job to wait for
>>> radeon
>>> to be finished? Well than this would i
op 23-07-14 11:36, Christian K?nig schreef:
> Am 23.07.2014 11:30, schrieb Daniel Vetter:
>> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
>> wrote:
>>> You submit a job to the hardware and then block the job to wait for radeon
>>> to be finished? Well than this would indeed require a hardware
On Wed, Jul 23, 2014 at 3:47 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> We must mask out the overflow bit as well, otherwise
> the wptr will never match the rptr again and the interrupt
> handler will loop forever.
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
A
Am 23.07.2014 11:30, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
> wrote:
>> You submit a job to the hardware and then block the job to wait for radeon
>> to be finished? Well than this would indeed require a hardware reset, but
>> wouldn't that make the whole proble
On 23/07/14 10:05, Daniel Vetter wrote:
> On Wed, Jul 23, 2014 at 8:50 AM, Oded Gabbay wrote:
>> On 22/07/14 14:15, Daniel Vetter wrote:
>>>
>>> On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
On 22/07/14 12:21, Daniel Vetter wrote:
>
> On Tue, Jul 22, 2014 at 10:19
On Wed, Jul 23, 2014 at 11:27 AM, Christian K?nig
wrote:
> You submit a job to the hardware and then block the job to wait for radeon
> to be finished? Well than this would indeed require a hardware reset, but
> wouldn't that make the whole problem even worse?
>
> I mean currently we block one use
Am 23.07.2014 10:54, schrieb Daniel Vetter:
> On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
> wrote:
>> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>>
>>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>>> wrote:
In this case if the sync was to i915 the i915 lockup procedure would t
On 07/08/14 10:40, Jean-Francois Moine wrote:
> This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF input and does dynamic input
> switch in the TDA998x I2C driver on start/stop audio streaming.
>
> Signed-off-by: Jean-Francois Moine
>
On Wed, Jul 23, 2014 at 09:04:24AM +0200, Christian K?nig wrote:
> Am 23.07.2014 08:50, schrieb Oded Gabbay:
> >On 22/07/14 14:15, Daniel Vetter wrote:
> >>On Tue, Jul 22, 2014 at 12:52:43PM +0300, Oded Gabbay wrote:
> >>>On 22/07/14 12:21, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:19 A
On Wed, Jul 23, 2014 at 10:46 AM, Christian K?nig
wrote:
> Am 23.07.2014 10:42, schrieb Daniel Vetter:
>
>> On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
>> wrote:
>>>
>>> In this case if the sync was to i915 the i915 lockup procedure would take
>>> care of itself. It wouldn't fix radeon, b
1 - 100 of 140 matches
Mail list logo
