Hi Chris,
On Wed, 18 May 2016 11:23:57 +0100 Chris Wilson
wrote:
>
> I'm pretty sure they didn't exist when I wrote the patch!
Yeah, but they do in the drm-misc tree where your patch was applied ...
so someone should do a fix patch to be applied to that tree. In the
mean time, I will apply the
On Thu 2016-05-19 08:27:37, Ming Lei wrote:
> On Thu, May 19, 2016 at 4:24 AM, Scot Doyle wrote:
> > On Wed, 18 May 2016, Ming Lei wrote:
> >> On Wed, May 18, 2016 at 4:49 AM, Pavel Machek wrote:
> >> > On Tue 2016-05-17 11:41:04, David Daney wrote:
> >> >> From: David Daney
> >> >>
> >> >> We a
Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
>> +static void collection_check_cb_func(struct fence *fence, struct fence_cb
>> *cb)
>> +{
>> +struct fence_collection_cb *f_cb;
>> +struct fence_collection *collection;
>> +
>>
On Thu, May 19, 2016 at 09:46:47AM +0200, Christian König wrote:
> Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> >On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
> >>+static void collection_check_cb_func(struct fence *fence, struct fence_cb
> >>*cb)
> >>+{
> >>+ struct fence_c
Hi Scot,
> Use the normal cursor blink default interval of 200 ms if
> ops->cur_blink_jiffies is not in the range specified in commit
> bd63364caa8d. Since invalid values are not used, specific system
> initialization timings should not cause lockups.
This fixes an issue we're seeing with the ast
On Wed, May 18, 2016 at 10:29:57PM +0200, Daniel Vetter wrote:
> This was added in
>
> commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241
> Author: Jesse Barnes
> Date: Tue Sep 30 12:14:26 2008 -0700
>
> drm: Rework vblank-wait handling to allow interrupt reduction.
>
> to stay backwards-com
From: Ville Syrjälä
Add a small helper to parse the PSR setup time from the DPCD PSR
capabilities and return the value in microseconds.
v2: Don't waste so many bytes on the psr_setup_time_us[] table
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gp
Hi Jon/Thierry,
On Thursday 12 May 2016 05:51 PM, Laxman Dewangan wrote:
> The IO pins of Tegra SoCs are grouped for common control of IO interface
> like setting voltage signal levels and power state of the interface. The
> group is generally referred as IO pads. The power state and voltage contr
From: Christian König
Fence contexts are created on the fly (for example) by the GPU scheduler used
in the amdgpu driver as a result of an userspace request. Because of this
userspace could in theory force a wrap around of the 32bit context number
if it doesn't behave well.
Avoid this by increa
Hi!
> Two current [1] and three previous [2] systems locked during boot
> because the cursor flash timer was set using an ops->cur_blink_jiffies
> value of 0. Previous patches attempted to solve the problem by moving
> variable initialization earlier in the setup sequence [2].
>
> Use the normal
On Thu, May 19, 2016 at 11:00:36AM +0200, Christian König wrote:
> From: Christian König
>
> Fence contexts are created on the fly (for example) by the GPU scheduler used
> in the amdgpu driver as a result of an userspace request. Because of this
> userspace could in theory force a wrap around
Am 19.05.2016 um 11:14 schrieb Daniel Vetter:
> On Thu, May 19, 2016 at 11:00:36AM +0200, Christian König wrote:
>> From: Christian König
>>
>> Fence contexts are created on the fly (for example) by the GPU scheduler used
>> in the amdgpu driver as a result of an userspace request. Because of th
_
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/8c17ee53/attachment-0001.sig>
Hi,
The following branches add SI support to the amdgpu side of our
graphics driver stack.
git://people.freedesktop.org/~mareko/mesa amdgpu-si
git://people.freedesktop.org/~mareko/libdrm amdgpu-si
git://people.freedesktop.org/~mareko/xf86-video-amdgpu amdgpu-si
Thanks to Ronie Salgado for start
Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
> Use kmemdup when some other buffer is immediately copied into allocated
> region. It replaces call to allocation followed by memcpy, by a single
> call to kmemdup.
>
> Signed-off-by: Muhammad Falak R Wani
NAK, actually using memcpy() is wron
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 6 +++---
1 file changed, 3 insertions(+), 3
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 6 +++---
1 file changed, 3 insertions(
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 6 +++---
1 file changed, 3 insertions(+),
On Thu, May 19, 2016 at 11:30 AM, Christian König
wrote:
> Am 19.05.2016 um 11:14 schrieb Daniel Vetter:
>>
>> On Thu, May 19, 2016 at 11:00:36AM +0200, Christian König wrote:
>>>
>>> From: Christian König
>>>
>>> Fence contexts are created on the fly (for example) by the GPU scheduler
>>> use
Am 19.05.2016 um 13:49 schrieb Muhammad Falak R Wani:
> On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote:
>> Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
>>> Use kmemdup when some other buffer is immediately copied into allocated
>>> region. It replaces call to allocation f
Am 19.05.2016 um 14:07 schrieb Daniel Vetter:
> On Thu, May 19, 2016 at 11:30 AM, Christian König
> wrote:
>> Am 19.05.2016 um 11:14 schrieb Daniel Vetter:
>>> On Thu, May 19, 2016 at 11:00:36AM +0200, Christian König wrote:
From: Christian König
Fence contexts are created on th
On Thu, May 19, 2016 at 01:18:10PM +0200, Christian König wrote:
> Am 19.05.2016 um 13:11 schrieb Muhammad Falak R Wani:
> >Use kmemdup when some other buffer is immediately copied into allocated
> >region. It replaces call to allocation followed by memcpy, by a single
> >call to kmemdup.
> >
> >S
Hi Christian,
2016-05-19 Christian König :
> Am 19.05.2016 um 00:57 schrieb Chris Wilson:
> > On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote:
> > > +static void collection_check_cb_func(struct fence *fence, struct
> > > fence_cb *cb)
> > > +{
> > > + struct fence_collection_cb
On Thu, May 19, 2016 at 02:21:43PM +0200, Christian König wrote:
> Am 19.05.2016 um 14:07 schrieb Daniel Vetter:
> >On Thu, May 19, 2016 at 11:30 AM, Christian König
> > wrote:
> >>Am 19.05.2016 um 11:14 schrieb Daniel Vetter:
> >>>On Thu, May 19, 2016 at 11:00:36AM +0200, Christian König wrote:
So far we've got one condition when DRM drivers need to defer probing
on a dual GPU system and it's coded separately into each of the relevant
drivers. As suggested by Daniel Vetter, deduplicate that code in the
drivers and move it to a new vga_switcheroo helper. This yields better
encapsulation of
As observed with the latest ThinkPad docks, we unfortunately can't rely
on docks keeping us updated with hotplug events that happened while we
were suspended. On top of that, even if the number of connectors remains
the same between suspend and resume it's still not safe to assume that
there were n
A follow-up to the previous commit, we skip checking the status of the
MST device and completely reprobe it if drm_dp_mst_topology_mgr_resume()
returns -EINVAL.
Cc: stable at vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_dp.c | 11 +--
1 file changed, 9 insertions(+
On Thu, May 19, 2016 at 7:15 AM, Muhammad Falak R Wani
wrote:
> Use kmemdup when some other buffer is immediately copied into allocated
> region. It replaces call to allocation followed by memcpy, by a single
> call to kmemdup.
>
> Signed-off-by: Muhammad Falak R Wani
Applied the hwmgr patches.
This reverts commit 13803132818c ("drm/core: Preserve the framebuffer
after removing it.").
This commit assumes that going through drm_framebuffer_remove() is not
necessary because "the fbdev code or any system compositor should restore
the planes anyway so there's no need to do it twice". But thi
On Mon, Apr 25, 2016 at 03:19:23PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
On Thu, May 19, 2016 at 5:15 PM, Hans de Goede wrote:
> This reverts commit 13803132818c ("drm/core: Preserve the framebuffer
> after removing it.").
>
> This commit assumes that going through drm_framebuffer_remove() is not
> necessary because "the fbdev code or any system compositor should resto
On 12/05/16 13:21, Laxman Dewangan wrote:
> The IO pins of Tegra SoCs are grouped for common control of IO
> interface like setting voltage signal levels and power state of
> the interface. The group is generally referred as IO pads. The
> power state and voltage control of IO pins can be done at
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/52c05662/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/43fbc63c/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/3cb318c5/attachment.html>
org/archives/dri-devel/attachments/20160519/f55d4a1b/attachment.html>
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/88db42f3/attachment-0001.html>
On Thu, 19 May 2016, Pavel Machek wrote:
> Hi!
>
> > Two current [1] and three previous [2] systems locked during boot
> > because the cursor flash timer was set using an ops->cur_blink_jiffies
> > value of 0. Previous patches attempted to solve the problem by moving
> > variable initialization ea
On 18/05/16 18:07, Arnd Bergmann wrote:
> The mediatek DRM driver can be configured for compile testing with
> CONFIG_OF disabled, but then fails to link:
>
> drivers/gpu/built-in.o: In function `mtk_drm_bind':
> analogix_dp_reg.c:(.text+0x52888): undefined reference to
> `of_find_device_by_node
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani
---
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-
On 18/05/16 18:07, Arnd Bergmann wrote:
> The drm_gem_object_lookup() function prototype changed while this
> driver was added, so it fails to build now:
>
> drivers/gpu/drm/mediatek/mtk_drm_gem.c: In function
> 'mtk_drm_gem_dumb_map_offset':
> drivers/gpu/drm/mediatek/mtk_drm_gem.c:142:30: erro
On Thu, May 19, 2016 at 10:22 PM, Scot Doyle wrote:
> On Thu, 19 May 2016, Pavel Machek wrote:
>> Hi!
>>
>> > Two current [1] and three previous [2] systems locked during boot
>> > because the cursor flash timer was set using an ops->cur_blink_jiffies
>> > value of 0. Previous patches attempted to
On 05/18/2016 09:21 PM, Scot Doyle wrote:
> Two current [1] and three previous [2] systems locked during boot
> because the cursor flash timer was set using an ops->cur_blink_jiffies
> value of 0. Previous patches attempted to solve the problem by moving
> variable initialization earlier in the set
On Thursday 19 May 2016 09:24 PM, Jon Hunter wrote:
> On 12/05/16 13:21, Laxman Dewangan wrote:
>> The IO pins of Tegra SoCs are grouped for common control of IO
>> interface like setting voltage signal levels and power state of
>> the interface. The group is generally referred as IO pads. The
>>
perhaps it works better, without having to blacklist?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/70fc7947/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/c04a35e7/attachment.html>
or a proper fix.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160519/e3c2589c/attachment.html>
Not clearing mst manager's proposed vcpis table for destroyed
connectors when the manager is stopped leaves it pointing to
unrefernced memory, this causes pagefault when the manager is
restarted when plugging back a branch.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_dp_mst_topology
49 matches
Mail list logo
