-HDMI-info/20161221-065128
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-i0-201651 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new
-HDMI-info/20161221-065128
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-s1-201651 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new
archives/dri-devel/attachments/20161221/f338f967/attachment.html>
Hi Ville,
>Fengguang, assuming 0day has bandwidth for it adding my repo [1] to your
>list might be nice. I tend to push most non-trivial patch series there
>when I post the patches.
>
>[1] git://github.com/vsyrjala/linux.git
Sure, bandwidth will never be a limitation. I just added your tree to
th
Thanks for the review Jose.
My comments, inline.
Regards
Shashank
On 12/20/2016 7:49 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 20-12-2016 13:47, Shashank Sharma wrote:
>> This patch creates a new structure drm_hdmi_info (inspired from
>> drm_display_info). Driver will parse HDMI sink's advanc
Regards
Shashank
On 12/20/2016 8:05 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 20-12-2016 13:47, Shashank Sharma wrote:
>> HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
>> called hdmi-forum vendor specific data block (HF-VSDB). This block
>> contains information about sink
On 12/20/2016 07:10 PM, Maarten Lankhorst wrote:
> Op 20-12-16 om 07:23 schreef Archit Taneja:
>>
>>
>> On 12/19/2016 06:20 PM, Maarten Lankhorst wrote:
>>> Op 19-12-16 om 13:08 schreef Archit Taneja:
This code has been more or less picked up from the vc4 and intel
implementations of up
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/2f179cfa/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/59ff8eab/attachment.html>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/eee83d84/attachment.html>
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/20161221/ab15f0a6/attachment.html>
On Tue, Dec 20, 2016 at 05:03:02PM -0800, Dhinakaran Pandiyan wrote:
> This check is useful for drivers that do not have DRIVER_ATOMIC set but
> have atomic modesetting internally implemented. Wrap the check into a
> function since this is used in many places and as a bonus, the function
> name hel
On Tue, Dec 20, 2016 at 05:03:03PM -0800, Dhinakaran Pandiyan wrote:
> i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
> atomic_commit. drm_object_property_get_value() does not read the correct
> value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
> the
On Tue, Dec 20, 2016 at 11:38:52AM +0100, Michael Thayer wrote:
> The suggested X and Y connector properties are intended as a way for drivers
> for virtual machine GPUs to provide information about the layout of the
> host system windows (or whatever) corresponding to given guest connectors.
> The
On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote:
> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> wrote:
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index ce7efe2..cea3de3 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/dr
On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote:
> On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote:
> > On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> > wrote:
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index ce7efe2..cea3d
On Wed, Dec 21, 2016 at 11:38:15AM +0800, Fengguang Wu wrote:
> Hi Ville,
>
> >Fengguang, assuming 0day has bandwidth for it adding my repo [1] to your
> >list might be nice. I tend to push most non-trivial patch series there
> >when I post the patches.
> >
> >[1] git://github.com/vsyrjala/linux.g
On Tue, Dec 20, 2016 at 05:03:02PM -0800, Dhinakaran Pandiyan wrote:
> This check is useful for drivers that do not have DRIVER_ATOMIC set but
> have atomic modesetting internally implemented. Wrap the check into a
> function since this is used in many places and as a bonus, the function
> name hel
On Wed, Sep 28, 2016 at 05:27:25PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Devices can have multiple planes, so allow the user to choose between
> them.
>
> Signed-off-by: Ville Syrjälä
Didn't get any objectioms, so I pushed this to master.
> ---
> tests
When writing the generic nonblocking commit code I assumed that
through clever lifetime management I can assure that the completion
(stored in drm_crtc_commit) only gets freed after it is completed. And
that worked.
I also wanted to make nonblocking helpers resilient against driver
bugs, by having
I was lazy, rectify that! Also align with drm_atomic_state_get/put for
ocd.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 9 ++---
include/drm/drm_atomic.h | 21 -
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_a
Regards
Shashank
On 12/21/2016 3:02 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 21-12-2016 03:49, Sharma, Shashank wrote:
>> Thanks for the review Jose.
>>
>> My comments, inline.
>>
>> Regards
>> Shashank
>> On 12/20/2016 7:49 PM, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> On 20-12-2016 1
On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> When writing the generic nonblocking commit code I assumed that
> through clever lifetime management I can assure that the completion
> (stored in drm_crtc_commit) only gets freed after it is completed. And
> that worked.
>
> I also
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/ae8550ae/attachment-0001.html>
Op 21-12-16 om 11:36 schreef Chris Wilson:
> On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
>> When writing the generic nonblocking commit code I assumed that
>> through clever lifetime management I can assure that the completion
>> (stored in drm_crtc_commit) only gets freed after
On Wed, Dec 21, 2016 at 10:36:41AM +, Chris Wilson wrote:
> On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> > When writing the generic nonblocking commit code I assumed that
> > through clever lifetime management I can assure that the completion
> > (stored in drm_crtc_commit)
I was lazy, rectify that! Also align with drm_atomic_state_get/put for
ocd.
v2: Git add helps.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 9 ++---
include/drm/drm_atomic.h | 21 -
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/d
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/52a9b7d2/attachment.html>
org/archives/dri-devel/attachments/20161221/403a2164/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/526bd0a5/attachment.html>
On Thu, Dec 15, 2016 at 03:45:47PM +0100, Bartlomiej Zolnierkiewicz wrote:
> I would like to help with fbdev maintenance. I can dedicate some time
> for reviewing and handling patches but won't have time for much more.
>
I thought usually someone takes over the maintainer role after
proving that
On 16.12.2016 03:49, zhoucm1 wrote:
> On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> Ensure that the driver can listen to evictions even when they don't
>> take the
>> path through ttm_bo_driver::move.
>>
>> This is crucial for amdgpu, which relies on an eviction
This patch creates a new structure drm_hdmi_info (inspired from
drm_display_info). Driver will parse HDMI sink's advance capabilities
from HF-VSDB and populate this structure. This structure will be kept
and used as a sub-class within drm_display_info.
We are adding parsing of HF-VSDB In the next
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (HF-VSDB). This block
contains information about sink's support for HDMI 2.0 compliant
features. These features are:
- Deep color YUV 420 support and BPC
- 3D flags for
- O
This patch adds a small helper function, which clears the cached
information about a hot-pluggable display, from connector. On event
This will run on event of a hot-unplug, keeping the connector's display
info up-to-date, avoiding any errors due to invalid cached data.
Cc: Jose Abreu
Suggested-b
On Wed, Dec 21, 2016 at 4:15 AM, Daniel Vetter wrote:
>> Also I guess it limits you to modifiers only with the first 64
>> formats.. maybe not a problem right away, but a quick look and drm/msm
>> is already at 23 formats (and there are probably some more it could
>> do.. without even starting to
On Wed, Dec 21, 2016 at 4:19 AM, Ville Syrjälä
wrote:
> On Wed, Dec 21, 2016 at 10:15:15AM +0100, Daniel Vetter wrote:
>> On Tue, Dec 20, 2016 at 07:46:12PM -0500, Rob Clark wrote:
>> > On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
>> > wrote:
>> > > diff --git a/include/uapi/drm/drm_
geblit.
--
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/20161221/186fef40/attachment-0001.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/d2b6766f/attachment.html>
(pinned x 1) (display)
(ggtt offset: 0008, size: 0030, type: 0)
--
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/20161
mand_str);
print_version();
--
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/20161221/b4552579/attachment.html>
,
Dieter
--
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/20161221/7bb2e2a6/attachment.html>
ives/dri-devel/attachments/20161221/adf22ace/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/15c34162/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/ff472abc/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/0c8284b4/attachment.html>
t; > u64 modifiers[]
> > bool (*format_mod_supported)(u32 format, u64 modifier);
> >
> > The driver provides those, and the core will then just go through the
> > combinations and build up the masks. We could then also reuse that stuff
> > for addfb2 so that the core will call that same hook to check whether
> > the format+modifier is supported. That way the driver .fb_create() will
> > never see any unsupported combinations and we avoid having to duplicate
> > any logic there to see which hardware supports which formats.
> >
>
> I do like this for internal API better, rather than driver building up
> tables itself.
>
Yeah, I like Ville's suggestion too, I'll give it a try.
Kristian
> BR,
> -R
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/88a862d8/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/d3b45f69/attachment.html>
Rob Clark writes:
> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen
> wrote:
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index ce7efe2..cea3de3 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -209,6 +209,33 @@ struct
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
v3: rename to __ww_ctx_stamp_after (Chris Wilson)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
Rev
From: Nicolai Hähnle
There's a possible race where the waiter in front of us leaves the wait list
due to a signal, and the current owner subsequently hands the lock off to us
even though we never observed ourselves at the front of the list.
Set the task state before checking our position in the
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
Keep the documentation in the header file since there is no good
place for it in mutex.c: there are two rather different
implementations with different EXPORT_SYMBOLs for each function.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
On Thu, 2016-02-25 at 16:15 -0500, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
>
> v2: don't try to hexdump the universe if driver returns -errno, and
> change the "too many retries" traces to DRM_ERROR()
> v3: rename to mor
On Wed, Dec 21, 2016 at 05:50:05PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, December 21, 2016 03:06:55 PM Sudip Mukherjee wrote:
> > On Thu, Dec 15, 2016 at 03:45:47PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > I would like to help with fbdev maintenance. I can dedica
On Wed, Dec 21, 2016 at 3:41 PM, Imre Deak wrote:
> On Thu, 2016-02-25 at 16:15 -0500, Rob Clark wrote:
>> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
>> with troublesome monitors.
>>
>> v2: don't try to hexdump the universe if driver returns -errno, and
>> change the "to
achment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/f4d2910a/attachment.html>
On 12/14, Eric Anholt wrote:
>
> /* the gates */
>
> @@ -1890,8 +1976,18 @@ static int bcm2835_clk_probe(struct platform_device
> *pdev)
> if (IS_ERR(cprman->regs))
> return PTR_ERR(cprman->regs);
>
> - cprman->osc_name = of_clk_get_parent_name(dev->of_node, 0);
We'll only be missing parents from
the end of the array.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161221/0343dbad/attachment.sig>
i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
atomic_commit. drm_object_property_get_value() does not read the correct
value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
the driver uses atomic modeset is a better check instead as the property
values
Hi,
On Wednesday, December 21, 2016 03:06:55 PM Sudip Mukherjee wrote:
> On Thu, Dec 15, 2016 at 03:45:47PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > I would like to help with fbdev maintenance. I can dedicate some time
> > for reviewing and handling patches but won't have time for much more.
This check is useful for drivers that do not have DRIVER_ATOMIC set but
have atomic modesetting internally implemented. Wrap the check into a
function since this is used in many places and as a bonus, the function
name helps to document what the check is for.
v2:
Change return type to bool (Ville)
21.12.2016 10:05, Daniel Vetter wrote:
> On Tue, Dec 20, 2016 at 11:38:52AM +0100, Michael Thayer wrote:
>> The suggested X and Y connector properties are intended as a way for drivers
>> for virtual machine GPUs to provide information about the layout of the
>> host system windows (or whatever) co
Here, If devm_ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference. This error check
will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/sti/sti_vtac.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gp
Here, If devm_ioremap_nocache will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference. This error check
will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav
---
drivers/gpu/drm/sti/sti_vtg.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu
Hello list,
I've been playing with an unaccelerated drm program[1] and have been
annoyed that whenever this program exits the fbcon isn't restored, with
the display left completely off.
This seems to happen because Xorg is still running from a different VT.
Upon further investigation, it seems l
Function hsw_psr_setup handles vsc header setup for psr1 and
skl_psr_setup_vsc handles vsc header setup for psr2.
Setup VSC header in function skl_psr_setup_vsc for psr2 support,
as per edp 1.4 spec, table 6-11:VSC SDP HEADER Extension for psr2
operation.
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-o
PSR2 vsc revision number hb2( as per table 6-11)is updated to
4 or 5 based on Y cordinate and Colorimetry Format as below
04h = 3D stereo + PSR/PSR2 + Y-coordinate.
05h = -3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry
Format indication. A DP Source device is allowed to indicate
Hi Shashank,
On 21-12-2016 03:49, Sharma, Shashank wrote:
> Thanks for the review Jose.
>
> My comments, inline.
>
> Regards
> Shashank
> On 12/20/2016 7:49 PM, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 20-12-2016 13:47, Shashank Sharma wrote:
>>> This patch creates a new structure drm_hdmi_i
77 matches
Mail list logo
