the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/04a42fdc/attachment.html>
re oopsing.
--
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/20141119/76e67f07/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/bdf30d13/attachment.html>
2014-11-19 17:49 GMT+09:00 Andrzej Hajda :
> On 11/18/2014 04:26 PM, Inki Dae wrote:
>> This patch makes kms drivers to be independent modules.
>> For this, it removes all register codes to kms drivers
>> from exynos_drm_drv module and adds module_init/exit
>> for each kms driver so that each kms d
On Wed, Nov 19, 2014 at 03:29:30PM -0500, Rob Clark wrote:
> On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
> wrote:
> > Oversight from my kerneldoc cleanup when doing the original atomic
> > helper series - I've only applied this clarification to the modeset
> > related helpers, and not the pla
notifier
[ 36.165392] [drm] Initialized radeon 2.40.0 20080528 for :01:00.0 on
minor 0
Let me know, if you need something else.
Cheers,
Kai
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc:
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Daniel Otero changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/1f735e44/attachment-0001.sig>
Am 19.11.2014 um 19:28 schrieb Alex Deucher:
> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
> wrote:
>> From: Christian König
>>
>> Use ring structure instead of index and provide vm_id and pd_addr separately.
>>
>> Signed-off-by: Christian König
> Pushed to my 3.19-wip tree. I'll send o
On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
wrote:
> Hey,
>
> On 19-11-14 07:43, Michael Marineau wrote:
>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>> lockups shortly after startup, accompanied with one or both of the
>> following errors:
>>
>> nouveau E[ PFIFO][0
https://bugzilla.kernel.org/show_bug.cgi?id=61941
Pavol KlaÄanský changed:
What|Removed |Added
CC||pavol at klacansky.com
--- Comment #2
From: Christian König
This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.
v2: fix vm lock
v3: immediately update unmaps as well
v4: use drm_free_large instead of kfree
Signed-off-by: Christian König
Tested-by: Kai Wasserbäch
---
dri
Hi Dave, couple of regression fixes, both cc: stable.
BR,
Jani.
The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9:
Linux 3.18-rc5 (2014-11-16 16:36:20 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014
Oversight from my kerneldoc cleanup when doing the original atomic
helper series - I've only applied this clarification to the modeset
related helpers, and not the plane update code. Remedy this asap.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 12 ++--
1 file
I guess for hysterical raisins this was meant to be the way to read
blob properties. But that's done with the two-stage approach which
uses separate blob kms object and the special-purpose get_blob ioctl.
Shipping userspace seems to have never relied on this, and the kernel
also never put any blob
- Make it clear that it's a negative errno (more in line with
everything else).
- Clean up the confusion around get_properties vs. getproperty ioctls:
One reads per-obj property values, the other reads property
metadata.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 79
Yet another fallout from not considering DP MST hotplug. With the
previous patches we have stable indices, but it might still happen
that a connector gets added between when we allocate the array and
when we actually add a connector. Especially when we back off due to
ww mutex contention or similar
Otherwise the connector might have been unplugged and destroyed while
we didn't look. Yet another fallout from DP MST hotplugging that I
didn't consider.
To make sure we get this right add an appropriate WARN_ON to
drm_atomic_state_clear (obviously only when we actually have a state
to clear up).
I've totally forgotten that with DP MST connectors can now be
hotplugged. And failed to adapt Rob's drm_atomic_state code (which
predates connector hotplugging) to the new realities.
The first step is to make sure that the connector indices used to
access the arrays of pointers are stable. The con
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #4 from Alex Deucher ---
Created attachment 158211
--> https://bugzilla.kernel.org/attachment.cgi?id=158211&action=edit
possible fix
Does this patch fix the issue (against 3.17 or newer kernel)?
--
You are receiving this mail beca
Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 38 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 47 -
drive
This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/Makefile|6 +
drivers/gpu/drm/msm/edp/edp.c | 211
drivers/gpu/drm/msm/edp/edp.h
https://bugzilla.kernel.org/show_bug.cgi?id=88501
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #3 fr
From: Markus Elfring
Date: Wed, 19 Nov 2014 17:50:19 +0100
The vfree() function performes 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_drv
t(0)
[2014.11.19-17.15.00:186][ 0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:192][ 0]LogExit: Exiting.
[2014.11.19-17.15.00:299][ 0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:309][ 0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:315][ 0]LogExit: Exiting.
[2014.11.19-17.15.00:836][ 0]LogGenericPlatformMisc:
FPlatformMisc::RequestExit(0)
[2014.11.19-17.15.00:846][ 0]LogExit: Preparing to exit.
[2014.11.19-17.15.00:852][ 0]LogExit: Exiting.
--
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/20141119/0b98624e/attachment-0001.html>
[adding Paolo and Vivek as cc]
Hello,
On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>
> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
> it proceeds to panic in the workqueue code called by the asoc max98090
> codec[1].
>
> If I then disable CONFIG_SND_SOC_SNOW, I can ge
Mesa: Git:master/b69c7c5dac
>> libdrm: Git:master/00847fa48b
>> LLVM: SVN:trunk/r54 (3.6 devel)
>> X.Org: 2:1.16.1-1
>> Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/>
>> # 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin
>> # c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin
>> # 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin
>> # c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin
>> # 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin
>> # ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin
>> # 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin
>> # 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin
>> libclc: Git:master/7f6f5bff1f
>> DDX: 1:7.5.0-1
>>
>> Let me know, if you need something else; see also the original thread
>> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further
>> information.
>>
>> Cheers,
>> Kai
>>
>
--
Kai Wasserbäch (Kai Wasserbaech)
E-Mail: kai at dev.carbon-project.org
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6f1370/attachment-0001.sig>
From: Paulo Zanoni
This way, the Kernel users will be able to fully control the lifetime
of struct drm_vblank_wait_item, and they will also be able to wrap it
to store their own information. As a result, one less memory
allocation will happen, and the Kernel codepath will not set all those
drm_pe
From: Paulo Zanoni
Which means the list doesn't really need to know if the event is from
user space or kernel space.
The only place here where we have to break the abstraction is at
drm_fops, when we're releasing all the events associated with a
file_priv. Here we introduced item.from_user_space
From: Paulo Zanoni
Now that we have created drm_vblank_wait_item, let's use it as the
type passed. In the future, callers will have to use container_of to
find our their original allocated structure, just like we're doing
with the send_vblank_event() callback.
Signed-off-by: Paulo Zanoni
---
d
From: Paulo Zanoni
Store the wanted sequence in the wait_item instead of storing it in
the event structure that is eventually going to be sent to user space.
The plan is to make Kernel vblank wait items not have the user space
event, so we need to store the wanted sequence number somewhere.
It i
From: Paulo Zanoni
It's supposed to contain all the information that is required for both
kernel and user space vblank wait items, but not hold any information
required by just one of them.
For now, we just moved the struct members from one place to another,
but the long term goal is that most o
From: Paulo Zanoni
This is going to be needed by i915.ko, and I guess other drivers could
use it too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_irq.c | 46 -
drivers/gpu/drm/i915/i915_debugfs.c | 45
i
From: Paulo Zanoni
The i915.ko driver needs a way to schedule certain functions to run
after some amount of vblanks. There are many different pieces of the
driver which could benefit from that.
Since what we want is essentially the vblank ioctl, this patch does
the minimum change required to all
From: Paulo Zanoni
The drivers need a way to schedule functions to be ran after a certain
number of vblanks. The i915.ko driver has plenty of examples where
this could be used, such as for unpinning buffers after a modeset.
Since the vblank wait IOCTL does basically what we want, but for the
user
From: Paulo Zanoni
Hi
---
TL;DR summary:
I wrote patches. Help me choose the best implementation and interface.
---
So the i915.ko driver could use some mechanism to run functions after a given
number of vblanks. Implementations for this mechanism were already proposed in
the past (by Chris Wil
Am 19.11.2014 um 17:28 schrieb Javier Martinez Canillas:
> On 11/19/2014 05:22 PM, Paolo Pisati wrote:
>> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>>>
>>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
>>> the needed patches.
>>>
>>> Aja
From: Markus Elfring
Date: Wed, 19 Nov 2014 17:33:32 +0100
The vunmap() function performes 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/udl/udl_gem.c |
Hi Javier,
On Wed, Nov 19, 2014 at 5:06 PM, Javier Martinez Canillas
wrote:
> [adding Kukjin to cc list]
>
> Hello Vivek,
>
> On Wed, Nov 12, 2014 at 5:21 AM, Jingoo Han wrote:
>> On Thursday, October 30, 2014 10:24 PM, Vivek Gautam wrote:
>>>
>>> DP PHY now require pmu-system-controller to han
Hello Paolo,
On 11/19/2014 05:22 PM, Paolo Pisati wrote:
> On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>>
>> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
>> the needed patches.
>>
>> Ajay, feel free to add to your series:
>>
>> Tested
On Wed, Nov 19, 2014 at 4:59 PM, Alexandre Demers
wrote:
> Technical reminder about this patch: usually, for electronic
> stability, you'll have to raise the voltage BEFORE increasing the
> clock speed; on the other, you'll have to lower the voltage AFTER
> lowering the clock speed. You may encoun
On Wed, Nov 19, 2014 at 12:20:53PM +0100, Javier Martinez Canillas wrote:
>
> If someone else is interested, I've pushed a branch [0] with 3.18-rc5 + all
> the needed patches.
>
> Ajay, feel free to add to your series:
>
> Tested-by: Javier Martinez Canillas
>
> Best regards,
> Javier
>
> [0]
ii_mec.bin
> # 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin
> # ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin
> # 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin
> # 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin
> libclc: Git:master/7f6f5bff1f
> DDX: 1:7.5.0-1
>
> Let me know, if you need something else; see also the original thread
> <http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further
> information.
>
> Cheers,
> Kai
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-update-the-VM-after-setting-BO-address-v4.patch
Type: text/x-diff
Size: 2831 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/253ea8dc/attachment.patch>
From: Markus Elfring
Date: Wed, 19 Nov 2014 17:05:20 +0100
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elf
Technical reminder about this patch: usually, for electronic
stability, you'll have to raise the voltage BEFORE increasing the
clock speed; on the other, you'll have to lower the voltage AFTER
lowering the clock speed. You may encounter stability problem if you
don't follow this order.
The patch f
On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski wrote:
> On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer
> wrote:
>> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>>
>>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>>> wrote:
On 15.11.2014 07:21, Andy Lutomirski wrote:
>
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #7 fr
thing else; see also the original thread
<http://thread.gmane.org/gmane.comp.video.dri.devel/118415> for further
information.
Cheers,
Kai
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/5e6b6ca9/attachment.sig>
From: Markus Elfring
Date: Wed, 19 Nov 2014 16:33:17 +0100
The release_firmware() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
On 19.11.2014 09:21, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything
>>> graphics intensive seems to cause my system to become unusable for
>>>
On 19.11.2014 09:10, Maarten Lankhorst wrote:
> Hey,
>
> On 19-11-14 07:43, Michael Marineau wrote:
>> On 3.18-rc kernel's I have been intermittently experiencing GPU
>> lockups shortly after startup, accompanied with one or both of the
>> following errors:
>>
>> nouveau E[ PFIFO][:01:00.0] r
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #2 from business.kid at gmail.com ---
Created attachment 158201
--> https://bugzilla.kernel.org/attachment.cgi?id=158201&action=edit
Kernel Config 3.6.0-rc5+
--
You are receiving this mail because:
You are watching the assignee of t
On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer wrote:
> On 19.11.2014 09:21, Andy Lutomirski wrote:
>>
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>> wrote:
>>>
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:
On recent kernels (3.16 through 3.18-rc4, perhaps), doing anyth
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/76751ce7/attachment.html>
We need to call clk_put on display clock, in the same way as functional clock.
Also remove the check for priv->clk, since clk_put() is safe against NULL
pointers.
Signed-off-by: Julien CHAUVEAU
---
Changes since v1:
- remove the check for priv->clk, as suggested by Felipe Balbi
drivers/gpu/drm
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Daniel Otero changed:
What|Removed |Added
Attachment #158101|application/octet-stream|text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=88501
--- Comment #1 from business.kid at gmail.com ---
Created attachment 158191
--> https://bugzilla.kernel.org/attachment.cgi?id=158191&action=edit
LSPCI -vnn
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=88501
Bug ID: 88501
Summary: AMD/ATI RS690M Console blanks to white
Product: Drivers
Version: 2.5
Kernel Version: 3.6.0-rc5 to 3.18.0-rc4
Hardware: x86-64
OS: Linux
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> Oversight from my kerneldoc cleanup when doing the original atomic
> helper series - I've only applied this clarification to the modeset
> related helpers, and not the plane update code. Remedy this asap.
>
> Signed-off-by: Daniel Vetter
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> - Make it clear that it's a negative errno (more in line with
> everything else).
> - Clean up the confusion around get_properties vs. getproperty ioctls:
> One reads per-obj property values, the other reads property
> metadata.
>
> S
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> I guess for hysterical raisins this was meant to be the way to read
> blob properties. But that's done with the two-stage approach which
> uses separate blob kms object and the special-purpose get_blob ioctl.
>
> Shipping userspace seems to
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> Yet another fallout from not considering DP MST hotplug. With the
> previous patches we have stable indices, but it might still happen
> that a connector gets added between when we allocate the array and
> when we actually add a connector.
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> Otherwise the connector might have been unplugged and destroyed while
> we didn't look. Yet another fallout from DP MST hotplugging that I
> didn't consider.
>
> To make sure we get this right add an appropriate WARN_ON to
> drm_atomic_stat
On Wed, Nov 19, 2014 at 12:38 PM, Daniel Vetter
wrote:
> I've totally forgotten that with DP MST connectors can now be
> hotplugged. And failed to adapt Rob's drm_atomic_state code (which
> predates connector hotplugging) to the new realities.
>
> The first step is to make sure that the connector
On Wed, Nov 19, 2014 at 2:48 PM, Kai Wasserbäch
wrote:
> Christian König wrote on 19.11.2014 20:40:
>> Am 19.11.2014 um 19:28 schrieb Alex Deucher:
>>> On Wed, Nov 19, 2014 at 8:01 AM, Christian König
>>> wrote:
From: Christian König
Use ring structure instead of index and pro
We need to call clk_put on display clock, in the same way as functional clock.
Signed-off-by: Julien CHAUVEAU
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 79a34cb..c
Hi Javier,
In the cover letter, I have mentioned that it is tested on Linus tree:
"This series is based on master branch of Linus tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
Kindly test the patches with that.
Ajay
On Wed, Nov 19, 2014 at 3:05 PM, Javier Martinez
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/8a3014cc/attachment.html>
On Tue, Oct 28, 2014 at 03:29:10PM +0100, Johan Hovold wrote:
> Hi,
>
> I have had some problems with crashes involving suspend-to-disk after
> updating to v3.16.
>
> Below is a log with 3.16.6 from a failed suspend attempt after which I
> get a NULL deref in ext4 code.
>
> A couple of weeks ag
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.
The atmel,panel propert
The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.
This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
Hello,
This patch series adds support for the Atmel HLCDC Display Controller
embedded in the HLCDC block.
The drivers supports basic CRTC functionalities, several overlays and
provides an hardware cursor.
At the moment, it only supports connection to LCD panels through an RGB
connector (defined
https://bugzilla.kernel.org/show_bug.cgi?id=88481
--- Comment #6 from Daniel Otero ---
Reverting the commit ffe0245532b98efc4bc0e06f29c51d3f0e471152 from the tag
v3.17.3 does resolve the issue.
Thanks for your time.
--
You are receiving this mail because:
You are watching the assignee of the b
On Wed, 2014-11-19 at 05:28 -0800, Amitkumar Karwar wrote:
> if "CONFIG_DEV_COREDUMP=y" is added to configuration file, it
> gets removed when final configuration file is generated. The
> reason is it requires CONFIG_WANT_DEV_COREDUMP to be enabled.
>
> Currently "make menuconfig" doesn't display
This appears to be a copy-paste error. We need to check for errors on disp_clk.
Signed-off-by: Julien CHAUVEAU
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
in
Am 19.11.2014 um 14:16 schrieb Kai Wasserbäch:
> Dear Christian,
> Christian König wrote on 19.11.2014 14:01:
>> From: Christian König
>>
>> This way the necessary VM update is kicked off immediately
>> if all BOs involved are in GPU accessible memory.
>>
>> v2: fix vm lock
>> v3: immediately u
Kevin Hilman writes:
> Javier Martinez Canillas writes:
>
>> [adding Paolo and Vivek as cc]
>>
>> Hello,
>>
>> On 11/18/2014 07:41 PM, Kevin Hilman wrote:
>>>
>>> It fixes the DRM deadlock, issue for me on exynos5800-peach-pi, but then
>>> it proceeds to panic in the workqueue code called by th
On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote:
> On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote:
> > Hi
> >
> > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
> > wrote:
> > > On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> > >> On Tue, Nov 18, 2
On Wed, Nov 19, 2014 at 10:04:13AM +0100, Boris Brezillon wrote:
> AFAIU, the suggestion was to split drm_connector_init and
> drm_connector_register calls:
> - drm_connector_init call should still be part of the load procedure
>(this function adds the connector to the connector list which is
gital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/f633607a/attachment-0001.sig>
From: Christian König
This way the necessary VM update is kicked off immediately
if all BOs involved are in GPU accessible memory.
v2: fix vm lock
v3: immediately update unmaps as well
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c | 64 ++
From: Christian König
Only invalidating PTEs needs to be executed synchronized to using the PT.
v2: fix sync to uses
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_vm.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeo
From: Christian König
We never invalidate PD entries and making them valid can
run with other users in parallel.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/dri
From: Christian König
This allows us to finally remove the VM fence and
so allow concurrent use of it from different engines.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 7 +++
drivers/gpu/drm/radeon/radeon_cs.c | 6 +-
drivers/gpu/drm/radeon/radeon_vm.c
From: Christian König
Use multiple VMIDs for each VM, one for each ring. That allows
us to execute flushes separately on each ring, still not ideal
cause in a lot of cases rings can share IDs.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 4 +--
drivers/gpu/drm/rad
From: Christian König
Note for each fence if it's a VM page table update or not. This allows
us to determine the last VM update in a sync object and so to figure
out if we need to flush the TLB or not.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 18 ++--
From: Christian König
This allows us to add the real execution fence as shared.
v2: fix typo
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 19 ++
drivers/gpu/drm/radeon/radeon_object.h | 2 ++
drivers/gpu/drm/radeon/radeon_vm.c | 65 +++
From: Christian König
Previously we just allocated space for four hardware semaphores
in each software semaphore object. Make software semaphore objects
represent only one hardware semaphore address again by splitting
the sync code into it's own object.
v2: fix typo in comment
Signed-off-by: C
From: Christian König
The PD/PTs reservation object now contains everything needed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_vm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
b/drivers/gpu/drm/radeon/radeon_vm.c
index db0ed3
From: Christian König
That's useless when all callers drop the reservation
immediately after calling the function.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 2 --
drivers/gpu/drm/radeon/radeon_vm.c | 4 ++--
3 files
From: Christian König
Use ring structure instead of index and provide vm_id and pd_addr separately.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 23 ++-
drivers/gpu/drm/radeon/cik_sdma.c| 22 +-
drivers/gpu/drm/radeon/n
Hi YoungJun,
On 2014ë
11ì 19ì¼ 13:39, YoungJun Cho wrote:
> Hi Inki,
>
> There are 3 comments below.
>
> On 11/19/2014 12:19 PM, Inki Dae wrote:
>> This patch makes non kms drivers to be independent modules.
>> For this, it removes all register codes to non kms drivers
>> from exynos_drm_d
Hi Inki,
There are 3 comments below.
On 11/19/2014 12:19 PM, Inki Dae wrote:
> This patch makes non kms drivers to be independent modules.
> For this, it removes all register codes to non kms drivers
> from exynos_drm_drv module and adds module_init/exit
> for each non kms driver so that each non
On Wed, Nov 19, 2014 at 8:01 AM, Christian König
wrote:
> From: Christian König
>
> Use ring structure instead of index and provide vm_id and pd_addr separately.
>
> Signed-off-by: Christian König
Pushed to my 3.19-wip tree. I'll send out a new radeon drm-next pull
request later today or to
In finish pageflip, the driver was not selecting the root
window when dispatching events. This exposed a race where
a plane update would change the window selection and cause
tegra_dc_finish_page_flip to check the wrong base address.
This patch also protects access to the window selection register
The current code always reprogrammed the sclk levels,
but we don't currently handle disp sclk requirements
so just skip it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/driver
Preferred ordering.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 73f8c4b..630434c 100644
--- a/drive
Use unforce levels rather than enable mask instruction.
This is the preferred method.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.
Apply voltage changes for displays before changing clocks.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index c9963b5..e781628 100644
--- a
Add missing newline and print the bad gpio shift.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8312140..c9963b5 100644
--- a/drivers/gpu/
1 - 100 of 150 matches
Mail list logo