do you need to split
the two? Can't you just merge them?
> > > > > +int de2_plane_init(struct drm_device *drm, struct lcd *lcd)
> > > > > +{
> > > > > + int ret, possible_crtcs = 1 << lcd->crtc_idx;
> > > > > +
> > > > > + ret = de2_one_plane_init(drm, &lcd->planes[DE2_PRIMARY_PLANE],
> > > > > + DRM_PLANE_TYPE_PRIMARY, possible_crtcs,
> > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > > > + if (ret >= 0)
> > > > > + ret = de2_one_plane_init(drm,
> > > > > &lcd->planes[DE2_CURSOR_PLANE],
> > > > > + DRM_PLANE_TYPE_CURSOR, possible_crtcs,
> > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > >
> > > > Nothing looks really special about that cursor plane. Any reasion not
> > > > to make it an overlay?
> > >
> > > As explained above (channel/layer/pipe plane definitions), the cursor
> > > cannot go in a channel lower or equal to the one of the primary plane.
> > > Then, it must be known and, so, have an explicit plane.
> >
> > If you were to make it a plane, you could use atomic_check to check
> > this and make sure this doesn't happen. And you would gain a generic
> > plane that can be used for other purposes if needed.
>
> The function drm_crtc_init_with_planes() offers a cursor plane for free.
> On the other side, having 6 overlay planes is more than the SoCs can
> support.
It's not really for free, it costs you a generic plane that could
definitely be used for something else and cannot anymore because
they've been hardcoded to a cursor.
And having a camera, the VPU or even an application directly output
directly into one of these planes seems a much better use of a generic
plane than a cursor.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/1138769a/attachment-0001.sig>
sys/class/drm/card0/error = no error state collected
--
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/20161107/a1ac7281/attachment.html>
Regards
Shashank
On 11/7/2016 8:56 PM, Emil Velikov wrote:
> On 7 November 2016 at 07:43, Sharma, Shashank
> wrote:
>> If I was not very clear for the first time, every time we send a patch to
>> drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not only
>> Android).
>>
>> So even
On Fri, 04 Nov 2016, Dhinakaran Pandiyan
wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix this by increasing the array
> size to 7 and initialize
On 11/7/2016 8:18 PM, Rob Clark wrote:
> On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja
> wrote:
>>
>>
>> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>>
>>> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
>>> pipes are statically assigned to planes, but next step is to ass
ns.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/a27a59e7/attachment.sig>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/e2279274/attachment.html>
On 11/07/2016 08:55 AM, Christian König wrote:
> Am 07.11.2016 um 04:29 schrieb Michel Dänzer:
>> On 07/11/16 11:47 AM, Mario Kleiner wrote:
>>> External clients which import our bo's wait only
>>> for exclusive dmabuf-fences, not on shared ones,
>>> so attach fences on exported buffers as exclus
In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_p
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-pe
The maximum OA sampling frequency is now configurable via a
dev.i915.oa_max_sample_rate sysctl parameter.
Following the precedent set by perf's similar
kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 61 ++
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
Review
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
v2:
Make sure to initialize ->specific_ctx_id when opening, withou
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gpu
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
Reviewed-by: Sourab Gupta
---
drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
drivers/
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
Rebased and updated with more feedback from Sourab and Matt.
In particular the patch that added the oa_min_timer_exponent sysctl parameter
has now been replaced with one adding an oa_max_sample_rate parameter in Hz.
This way userspace policy won't need to be tailored to different systems when
gen
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/b8cc6823/attachment.sig>
On Mon, 07 Nov 2016, Eric Engestrom wrote:
> On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
>> On Mon, 07 Nov 2016, Eric Engestrom wrote:
>> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>> >
>> > drm: make drm_get_format_name thread-safe
>> >
>> > Signed-off-by: Eric Engest
From: Gustavo Padovan
Some of the members of struct drm_plane had extra comments so for these
add inline kernel comment to consolidate all documentation in one place.
Signed-off-by: Gustavo Padovan
---
include/drm/drm_plane.h | 61 +++--
1 file chang
From: Gustavo Padovan
drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_atomic.c | 3 ++-
1 file changed, 2 inse
From: Gustavo Padovan
drm_atomic_set_fence_for_plane() is smart and won't overwrite
plane_state->fence if the user already set an explicit fence there.
Cc: Philipp Zabel
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/imx/imx-drm-core.c | 6 --
1 file change
From: Gustavo Padovan
This new function should be used by drivers when setting a implicit
fence for the plane. It abstracts the fact that the user might have
chosen explicit fencing instead.
Signed-off-by: Gustavo Padovan
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 30 ++
Mika,
Can you take a look at this?
-DK
On Fri, 2016-11-04 at 14:06 -0700, Dhinakaran Pandiyan wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix t
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/9ebb0be4/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/643085ed/attachment.html>
> -Original Message-
> From: Pavel Machek [mailto:pavel at ucw.cz]
> Sent: Monday, November 07, 2016 1:40 PM
> To: Deucher, Alexander; Koenig, Christian; dri-devel at lists.freedesktop.org;
> kernel list
> Subject: v4.9-rc3: radeon oops on shutdown
>
> Hi!
>
> On old thinkpad T40p... with
On Sun, Nov 6, 2016 at 7:09 PM, Icenowy Zheng wrote:
> The enable gpio of simple-panel may be used by a simplefb or other
> driver on the panel's display before the KMS driver get load.
>
> Get the GPIO as-is, so the panel won't be disabled, and the simplefb
> can work.
>
> Signed-off-by: Icenowy
On 05/11/16 00:21, Daniel Kurtz wrote:
> On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
> wrote:
>>
>> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
>> [...]
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> [...]
+
+/* Firmware */
+#define PS_F
On 4 November 2016 at 20:41, Christophe Fergeau wrote:
> On Thu, Nov 03, 2016 at 06:08:39PM +0100, Gerd Hoffmann wrote:
>> > Or maybe other parts of the
>> > kernel/userspace rely on this rounding down.
>>
>> This is where I suspect we could run in trouble. Odd resolutions simply
>> don't happen
2016ë
11ì 07ì¼ 17:05ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 07.11.2016 02:45, Inki Dae wrote:
>>
>> 2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> Use core helpers to generate infoframes and generate vendor frame if
>>> necessary.
>>>
>>> Signed-off-by: Andrzej Hajda
>>>
On Monday, 2016-11-07 10:10:13 +0200, Jani Nikula wrote:
> On Mon, 07 Nov 2016, Eric Engestrom wrote:
> > Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
> >
> > drm: make drm_get_format_name thread-safe
> >
> > Signed-off-by: Eric Engestrom
> > [danvet: Clarify that the returned poin
On 7 November 2016 at 15:48, Sharma, Shashank
wrote:
> Regards
>
> Shashank
>
>
> On 11/7/2016 8:56 PM, Emil Velikov wrote:
>>
>> On 7 November 2016 at 07:43, Sharma, Shashank
>> wrote:
>>>
>>> If I was not very clear for the first time, every time we send a patch to
>>> drm-intel/dri-devel, we
~
ac_nir_to_llvm.c: In function 'si_llvm_init_export_args':
ac_nir_to_llvm.c:4059:13: error: 'LLVMReadNoneAttribute' undeclared (first use
in this function)
LLVMReadNoneAttribute);
^
ac_nir_to_llvm.c: In function 'e
On 07/11/16 04:24 PM, Michel Dänzer wrote:
> On 07/11/16 03:56 AM, Sandeep wrote:
>> Hello,
>>
>> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
>> upstream kernel (or is this upto individual distros?)
>>
>> Is there any work left to be done/bugs to be fixed before it can
On 07/11/16 03:56 AM, Sandeep wrote:
> Hello,
>
> I was wondering when DRM_AMDGPU_CIK would be turned on by default in the
> upstream kernel (or is this upto individual distros?)
>
> Is there any work left to be done/bugs to be fixed before it can be
> enabled by default?
There are still some fu
From: Christian König
This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
Otherwise signaling might never be activated on the fences. This can
result in infinite waiting with hardware which has unreliable interrupts.
v2: still return one when the timeout is zero and we don't have any
From: Christian König
reservation_object_wait_timeout_rcu() should enable signaling even with a zero
timeout, but ttm_bo_wait() can also be called from atomic context and then it
is not a good idea to do this.
Reviewed-by: Alex Deucher
Signed-off-by: Christian König
Signed-off-by: Alex Deuch
This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.
When we don't call the wait function software signaling might never be
activated. This can cause infinite polling loops with unreliable interrupt
driven hardware.
v2: rebase on drm-next
Reviewed-by: Alex Deucher
Signed-off-by: Christ
Kernel functions taking a timeout usually return 1 on success even
when they get a zero timeout.
v2: agd: rebase on drm-next
Reviewed-by: Alex Deucher
Signen-off-by: Christian König
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher
---
These are the same patches Christian sent out prev
/free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/310f8f7b/attachment.sig>
erscaned problem is always going to be there, and each driver
> should not be dealing with it in their own specific ways.
I agree with you, however, without any directions on how to do this,
and willingness to merge this, I don't really see why we would work on
such a generic implementation in the first place.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/8a156bb1/attachment.sig>
On 11/05/2016 09:55 PM, Rob Clark wrote:
> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
> pipes are statically assigned to planes, but next step is to assign the
> hw pipes during plane->atomic_check() based on requested caps (scaling,
> YUV, etc). And then hw pipe re
Use core helpers to generate infoframes and generate vendor frame if necessary.
Signed-off-by: Andrzej Hajda
---
- changed 'ret >= 0' checks to '!ret'
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 141 ++-
drivers/gpu/drm/exynos/regs-hdmi.h | 2 +
2 files changed
Hi,
Minor comments below. LGTM otherwise.
On 11/05/2016 09:56 PM, Rob Clark wrote:
> (re)assign the hw pipes to planes based on required caps, and to handle
> situations where we could not modify an in-use plane (ie. SMP block
> reallocation).
>
> This means all planes advertise the superset of f
On 11/05/2016 09:55 PM, Rob Clark wrote:
> Add basic state duplication/apply mechanism. Following commits will
> move actual global hw state into this.
>
> The state_lock allows multiple concurrent updates to proceed as long as
> they don't both try to alter global state. The ww_mutex mechanism
Am Montag, den 07.11.2016, 19:03 +0900 schrieb Gustavo Padovan:
> From: Gustavo Padovan
>
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
>
> Cc: Philipp Zabel
> Signed-off-by: Gustavo Padovan
> Reviewed-by:
On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote:
> Hi Russell,
>
> On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote:
> > > Yes. And that is an XBMC only solution, that doesn't work with the
> > > fbdev emulation and is probably doing an additional composition
Am Montag, den 07.11.2016, 14:17 +0100 schrieb Thierry Reding:
> On Mon, Nov 07, 2016 at 06:12:43PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Nov 6, 2016 at 7:09 PM, Icenowy Zheng wrote:
> > > The enable gpio of simple-panel may be used by a simplefb or other
> > > driver on the panel's display befor
On 7 November 2016 at 07:43, Sharma, Shashank
wrote:
> If I was not very clear for the first time, every time we send a patch to
> drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not only
> Android).
>
> So even these aspect ratio patches were tested with full gnome-desktop, and
>
hes (as Russell suggested)?
I'll reply to his mail.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/f6460e69/attachment-0001.sig>
osing the whole thing if I tried like that :-)
--
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/20161107/cf827281/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/f304fbce/attachment-0001.html>
On Mon, Nov 07, 2016 at 03:50:00AM +, Kuninori Morimoto wrote:
>
> Hi Russell
>
> > > + platform = platform_device_register_full(&pdevinfo);
> > > + if (IS_ERR_OR_NULL(platform))
> > > + return PTR_ERR(platform);
> >
> > This is wrong. If platform is NULL, PTR_ERR() will return zero
>-Original Message-
>From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>Of Michel Dänzer
>Sent: Monday, November 07, 2016 2:24 AM
>To: Sandeep
>Cc: dri-devel at lists.freedesktop.org
>Subject: Re: Enable AMDGPU for CIK by default
>
>On 07/11/16 03:56 AM, Sandee
ot;download raw diff" and have to search/sort out the
> paths by hand.
Hello Andy,
how did you solved this?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.
d previously been enabled?
And even if we go this extra mile there's a possibility that the GPIO
was just left dangling by earlier software (or hardware) and leaving it
on would actually be worse than turning the panel off.
Thierry
-- next part --
A non-text attac
On Fri, 2016-11-04 at 06:19 -0700, Robert Bragg wrote:
>
>
> On Fri, Nov 4, 2016 at 8:59 AM, sourab gupta
> wrote:
> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance
> metrics.
> >
> > This a
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/08980b9d/attachment.html>
If I was not very clear for the first time, every time we send a patch
to drm-intel/dri-devel, we do basic testing on Gnome-desktop too (Not
only Android).
So even these aspect ratio patches were tested with full gnome-desktop,
and it worked well.
Regards
Shashank
On 11/3/2016 9:49 PM, Sharma
5 deletions(-)
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/31d3aa77/attachment.sig>
e.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/49843cca/attachment.sig>
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/fd9b4f90/attachment.sig>
hanged, 2 insertions(+), 2 deletions(-)
Applied, thanks.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/544f81c6/attachment.sig>
On Sun, Nov 6, 2016 at 8:07 PM, Gustavo Padovan wrote:
> Hi Christian,
>
> 2016-10-20 Christian König :
>
>> From: Christian König
>>
>> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>>
>> Otherwise signaling might never be activated on the fences. This can
>> result in infinite
On Fri, Nov 4, 2016 at 6:03 PM, Sumit Semwal wrote:
> Hi Alex,
>
> Thanks for the patches.
>
> On 4 November 2016 at 14:16, Alex Deucher wrote:
>> From: "monk.liu"
>>
>> Return the index of the first signaled fence. This information
>> is useful in some APIs like Vulkan.
>>
>> v2: rebase on drm
On 07/11/16 11:47 AM, Mario Kleiner wrote:
> External clients which import our bo's wait only
> for exclusive dmabuf-fences, not on shared ones,
> so attach fences on exported buffers as exclusive
> ones, if the buffers get imported by an external
> client.
>
> See discussion in thread:
> https://
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/86771c04/attachment.html>
On Mon, Oct 31, 2016 at 10:02:27AM +, Lorenzo Stoakes wrote:
> This patch adds an int *locked parameter to get_user_pages() to allow
> VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().
>
> It additionally clears the way for get_user_pages_locked() to be removed as
> it
> create mode 100644 drivers/gpu/drm/zte/zx_hdmi_regs.h
> > create mode 100644 drivers/gpu/drm/zte/zx_plane.c
> > create mode 100644 drivers/gpu/drm/zte/zx_plane.h
> > create mode 100644 drivers/gpu/drm/zte/zx_plane_regs.h
> > create mode 100644 drivers/gpu/drm/zte/zx_vou.c
> > create mode 100644 drivers/gpu/drm/zte/zx_vou.h
> > create mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h
> >
> > --
> > 1.9.1
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/113f38c4/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=107381
madbiologist changed:
What|Removed |Added
CC||madbiologist2016 at outlook.co
use:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/e494912e/attachment.html>
Hi Dave,
Please consider to pull the following initial ZTE zxdrm driver support
for 4.10. The pull request is based on v4.9-rc1. If you need it to
be on other base, just let me know, and I will update it. Thanks.
Shawn
The following changes since commit 1001354ca34179f3db924eb66672442a173147
esa fix this bug.
--
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/20161107/394da367/attachment.html>
On Mon, Nov 07, 2016 at 11:49:18AM +0100, Jesper Nilsson wrote:
> For the cris-part:
> Acked-by: Jesper Nilsson
Thanks very much for that, however just to avoid any confusion, I realised this
series was not not the right way forward after discussion with Paolo and rather
it makes more sense to ke
On Mon, Nov 7, 2016 at 5:03 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> drm_atomic_set_fence_for_plane() is smart and won't overwrite
> plane_state->fence if the user already set an explicit fence there.
>
> Cc: Rob Clark
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Daniel Vetter
2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Use core helpers to generate infoframes and generate vendor frame if
> necessary.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 141
> ++-
> drivers/gpu/drm/exynos
Hi Christophe,
2016-11-04 Christophe JAILLET :
> If 'sun4i_layers_init()' returns an error, propagate it instead of
> returning -EINVAL unconditionally.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Revi
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/8255cfc1/attachment.sig>
-test
everything.
--
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/20161107/05757a04/attachment.html>
On Mo, 2016-11-07 at 09:00 +0100, Christophe Fergeau wrote:
> Hey,
>
> Same series as v2 except that I removed the use of camel case in patch 6/7.
> Now it's only using an anonymous enum + int.
Can you please not drop the "PATCH" from $subject?
thanks,
Gerd
Thomas has already acked the earlier version, but in case you need
it for this one, too.
vmwgfx portion: Acked-by: Sinclair Yeh
On Mon, Nov 07, 2016 at 12:48:09AM +, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
Hi Alex,
2016-11-04 Alex Deucher :
> From: Junwei Zhang
>
> v2: agd: rebase and squash in all the previous optimizations and
> changes so everything compiles.
> v3: squash in Slava's 32bit build fix
> v4: rebase on drm-next (fence -> dma_fence),
> squash in Monk's ioctl update patch
>
> Si
On Mon, 07 Nov 2016, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vett
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> This reverts commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9.
>
> Otherwise signaling might never be activated on the fences. This can
> result in infinite waiting with hardware which has unreliable interrupts.
>
> v2: s
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> reservation_object_wait_timeout_rcu() should enable signaling even with a zero
> timeout, but ttm_bo_wait() can also be called from atomic context and then it
> is not a good idea to do this.
>
> Signed-off-by: Christian
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> This reverts commit 847b19a39e4c9b5e74c40f0842c48b41664cb43c.
>
> When we don't call the wait function software signaling might never be
> activated. This can cause infinite polling loops with unreliable interrupt
> drive
Hi Christian,
2016-10-20 Christian König :
> From: Christian König
>
> Kernel functions taking a timeout usually return 1 on success even
> when they get a zero timeout.
>
> Signen-off-by: Christian König
> Reviewed-by: Chunming Zhou
> ---
> drivers/dma-buf/fence.c | 8 +---
> 1 file
On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja wrote:
>
>
> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>
>> Split out the hardware pipe specifics from mdp5_plane. To start, the hw
>> pipes are statically assigned to planes, but next step is to assign the
>> hw pipes during plane->atomic_check() bas
On Sun, Nov 6, 2016 at 7:48 PM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by:
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161107/bb596270/attachment.html>
Hi David, Daniel,
On Mon, Oct 31, 2016 at 05:17:22PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The series adds the initial ZTE VOU display controller DRM/KMS driver.
> There are still some features to be added, like overlay plane, scaling,
> and more output devices support. But it's already
Hi,
> I think we should try it an see,
Ok, lets try. I'll go pick them up and prepare a pull with this and
some virtio-gpu bits,
Gerd
On 07.11.2016 02:45, Inki Dae wrote:
>
> 2016ë
10ì 26ì¼ 21:36ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> Use core helpers to generate infoframes and generate vendor frame if
>> necessary.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 141
>> ++--
Am 07.11.2016 um 02:10 schrieb Gustavo Padovan:
> Hi Alex,
>
> 2016-11-04 Alex Deucher :
>
>> From: Junwei Zhang
>>
>> v2: agd: rebase and squash in all the previous optimizations and
>> changes so everything compiles.
>> v3: squash in Slava's 32bit build fix
>> v4: rebase on drm-next (fence -> dm
The use of drm_cvt_mode() in qxl_add_monitors_config_modes() means that
the resolutions we are going to present to user-space are going to be
rounded down to a multiple of 8. In the QXL arbitrary resolution case,
this is not useful.
This commit forces the actual width/height that was requested by t
When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt,
we currently always notify userspace that there was some hotplug event.
However, gnome-shell/mutter is reacting to this event by attempting a
resolution change, which it does by issueing drmModeRmFB, drmModeAddFB,
and t
1 - 100 of 124 matches
Mail list logo
