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
--
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>
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
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
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
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
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
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
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:
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
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 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:
> 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:
> 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:
> - 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:
> 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 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
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Daniel Otero changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
[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 handle PMU register
>> to control PHY's power isolation. Adding the same to dp-phy
>> node.
>
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
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 an option to enable
WANT_DEV_COREDUMP. This patch updates Kconfig so
Hi Johannes,
>> Currently "make menuconfig" doesn't display an option to enable
>> WANT_DEV_COREDUMP. This patch updates Kconfig so that user can enable
>> WANT_DEV_COREDUMP.
>
>This is completely intentional - drivers should "select
>WANT_DEV_COREDUMP" and users are only able to set "ALLOW_DEV_CO
On Wed, Nov 19, 2014 at 3:29 AM, Lucas Stach wrote:
> From: Philipp Zabel
>
> Signed-off-by: Philipp Zabel
> Signed-off-by: Lucas Stach
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/
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
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
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]
[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
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
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 the asoc max98090
>> codec[1].
>>
>
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
. clk_put() is safe
against NULL pointers.
--
balbi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/43862d5e/attachment.sig>
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
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
---
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
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 |
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
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
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
Paolo Pisati writes:
> On Wed, Nov 19, 2014 at 10:35:40AM +0100, Javier Martinez Canillas wrote:
>> Hello Ajay,
>>
>> On 11/18/2014 07:20 AM, Ajay kumar wrote:
>> > On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar
>> > wrote:
>> >> This series is based on master branch of Linus tree at:
>> >> git:/
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: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
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141119/bdf30d13/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>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141119/04a42fdc/attachment.html>
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
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
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
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:
>
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
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
101 - 150 of 150 matches
Mail list logo
