next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/b45be0a0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=150731
--- Comment #6 from Jimi ---
Created attachment 228431
--> https://bugzilla.kernel.org/attachment.cgi?id=228431&action=edit
dmesg log
And now I've tried unbinding it from amdgpu without X running at all, and it of
course didn't work, confirmin
https://bugzilla.kernel.org/show_bug.cgi?id=150731
--- Comment #5 from Jimi ---
Created attachment 228421
--> https://bugzilla.kernel.org/attachment.cgi?id=228421&action=edit
X post-crash log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=150731
--- Comment #4 from Jimi ---
Created attachment 228411
--> https://bugzilla.kernel.org/attachment.cgi?id=228411&action=edit
X crash log
Here are my Xorg logs for when I unbind from vfio-pci, remove, and rescan, and
X crashes and comes back wit
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/a6970a85/attachment-0001.html>
Hi Chris,
On 11 August 2016 at 20:16, Chris Wilson wrote:
> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> need to handle such conversion in the caller. The only challenge are
> those callers that wi
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/938eb30d/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/27dc6892/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/e1243d99/attachment.html>
Den 10.08.2016 11:15, skrev Daniel Vetter:
> On Tue, Aug 09, 2016 at 07:45:41PM +0200, Noralf Trønnes wrote:
>> This adds support for outputting kernel messages on panic().
>> The drivers that supports it, provides a framebuffer that the
>> messages can be rendered on.
>>
>> Signed-off-by: Noralf
get one cap, and a texture
> buffer can be any offset.
That's what we already do.
--
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/20160811/33d3825a/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/32a8af36/attachment.html>
r the texture buffer
alignment.
--
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/20160811/6000b6d2/attachment-0001.html>
check it.
--
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/20160811/c1d7f574/attachment.html>
u 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/20160811/4e0f1baf/attachment.html>
s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/9ed22d26/attachment.html>
gging/patches you wish to try.
--
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/20160811/b29c2529/attachment.html>
Hi Jonathan,
not sure if this is already on your radar or if you're at all the
right person to contact, but I just noticed that the gpu htmldocs
are gone from https://www.kernel.org/doc/htmldocs/gpu/
Actually all the rst-formatted docs are missing. It would be great
if they could be reinstated so
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/99df1ece/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/d6d30196/attachment.html>
On Thu, Aug 11, 2016 at 10:21:36AM -0700, Jim Bride wrote:
> On Thu, Aug 11, 2016 at 11:22:15AM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 11, 2016 at 11:14:43AM +0300, Mika Kahola wrote:
> > > On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 08, 2016 at 04:00:26PM +
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160811/7caeb9fc/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/93556167/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/06f2891f/attachment.html>
16-but-not-256 alignment?
--
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/20160811/391aa3a1/attachment.html>
Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware
g/archives/dri-devel/attachments/20160811/6351a977/attachment.html>
offsets don't start at 0.
I believe NVIDIA GPUs also require buffer offsets of 256. I don't know about
Intel cards.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lis
desktop.org/archives/dri-devel/attachments/20160811/c7154dd3/attachment.html>
This variant of fence_get_rcu() takes an RCU protected pointer to a
fence and carefully returns a reference to the fence ensuring that it is
not reallocated as it does. This is required when mixing fences and
SLAB_DESTROY_BY_RCU - although it serves a more pedagogical function atm
Signed-off-by: C
On Thu, Aug 11, 2016 at 11:19:50PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> On 11 August 2016 at 20:16, Chris Wilson wrote:
> > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> > need to handle suc
Apologies, please ignore these 2. Didn't pass the right start point to
git-send-email.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
Hi Markus,
On 11 August 2016 at 17:28, Markus Heiser wrote:
> Hi Sumit,
>
> I haven't compiled your patch yet, just my 2cent about the
> reStructuredText (reST) ASCII markup ...
>
Thanks very much for your detailed review comments - highly appreciated!
> Here are some handy links about reST and
This little helper only exists to safely discard the upper unused 32bits
of the general 64-bit VMA address - as we know that all Global GTT
currently are less than 4GiB in size and so that the upper bits must be
zero. In many places, we use a u32 for the global GTT offset and we want
to document wh
Treat the VMA as the primary struct responsible for tracking bindings
into the GPU's VM. That is we want to treat the VMA returned after we
pin an object into the VM as the cookie we hold and eventually release
when unpinning. Doing so eliminates the ambiguity in pinning the object
and then searchi
Hello Jani,
On 11 August 2016 at 17:17, Jani Nikula wrote:
> On Thu, 11 Aug 2016, Sumit Semwal wrote:
>> diff --git a/Documentation/dma-buf/guide.rst
>> b/Documentation/dma-buf/guide.rst
>> new file mode 100644
>> index ..fd3534fdccb3
>> --- /dev/null
>> +++ b/Documentation/dma-buf/
We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common under
e a R9 380.
--
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/20160811/fbbe30d4/attachment-0001.html>
This reverts commit 2ab9f5879162499e1c4e48613287e3f59e593c4f.
The of_get_next_parent will drop refcount on the passed node, so the reverted
patch is wrong, thanks for Tomi Valkeinen points it.
Cc: Tomi Valkeinen
Signed-off-by: Peter Chen
---
drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 +++
1
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/d39a2784/attachment.html>
On Thu, Aug 11, 2016 at 03:26:42PM +0300, Mika Kahola wrote:
> On Thu, 2016-08-11 at 12:56 +0200, Daniel Vetter wrote:
> > On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > > > On Thu, 2016-08-11 at 10:18 +0300, V
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/3cebf278/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/a88a1278/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/1fba1a27/attachment.html>
x27;s still a small
hit to performance.
Note: I've only tested "The Talos Principle" so far, if you need me to test
XCOM 2 or other titles as well, let me know.
Do you still need the bisect?
--
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/20160811/09c0fd61/attachment-0001.html>
drm/dp/mst
Signed-off-by: Anusha Srivatsa
Add a function that returns the available link bandwidth for
MST port so that we can accurately determine whether a new
mode is valid for the link or not.
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12 +++
On Thu, Aug 11, 2016 at 12:26:43PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This interface is hidden from kernel headers and it is intended for use
> only for testing. So testers would have to add the ioctl information
> internally. This is to prevent misuse of this feature.
>
>
s scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/1adb23ec/attachment.html>
On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 22/07/16 16:43, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_property.
> >
> > Not sure I got t
In order to be completely generic, we have to double check the read
seqlock after acquiring a reference to the fence. If the driver is
allocating fences from a SLAB_DESTROY_BY_RCU, or similar freelist, then
within an RCU grace period a fence may be freed and reallocated. The RCU
read side critical
Include dma-buf sphinx documentation into top level index.
Signed-off-by: Sumit Semwal
---
Documentation/index.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 43c722f15292..2fe8e82d7d8c 100644
--- a/Documentation/index.rst
+++ b/D
Branch out dma-buf related documentation into its own rst file to allow
adding it to the sphinx documentation generated.
While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too.
Signed-off-by: Sumit Semwal
---
Documentation/DocBook/device-drivers.tmpl | 37 ---
Documentation/dm
Commit e941759c74a44d6ac2eed21bb0a38b21fe4559e2 ("fence: dma-buf
cross-device synchronization (v18)") had a spurious kerneldoc section
header that caused Sphinx to complain. Fix it.
Fixes: e941759c74a4 ("fence: dma-buf cross-device synchronization (v18)")
Signed-off-by: Sumit Semwal
---
include
Commit 0431b9065f28ecf6c320fefebe0241620049984f ("staging/android: bring
struct sync_pt back") removed child_list and active_list from struct fence,
but left it in kernel doc. Delete them.
Fixes: 0431b9065f28 ("staging/android: bring struct sync_pt back")
Signed-off-by: Sumit Semwal
---
include
Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
Sumit Semwal (4):
dma-buf/fence:
Convert dma-buf documentation over to sphinx; also cleanup to
address sphinx warnings.
While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.
There is no content change yet; only format conversion and creation of
some hyperlinks.
Sumit Semwal (4):
dma-buf/fence:
t was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/274e73d6/attachment.html>
Hey,
Op 10-08-16 om 16:28 schreef Lyude:
> Now that we can hook into update_crtcs and control the order in which we
> update CRTCs at each modeset, we can finish the final step of fixing
> Skylake's watermark handling by performing DDB updates at the same time
> as plane updates and watermark upda
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: R
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
In order to add proper support for the SAGV, we need to be able to know
what the cause of a failure to change the SAGV through the pcode mailbox
was. The reasoning for this is that some very early pre-release Skylake
machines don't actually allow you to control the SAGV on them, and
indicate an inv
Maarten Lankhorst unfortunately found that some early pre-release skl machines
were failing tests due to them apparently not having SAGVs. As a result, a
patch had to be added to check for invalid pcode commands, and the SAGV support
patch has been reworked to stop trying to play with the SAGV if i
hdmi->disabled maybe not match to the real hardware status.
->dw_hdmi_bridge_enable()
hdmi->disabled = false;
-->dw_hdmi_update_power()
if (hdmi->rxsense)
force = DRM_FORCE_ON;
else
force = DRM_FORCE_OFF;
hdmi->rxsense maybe false on bridge enable path, then hdmi->disabled
i
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy chec
From: Gustavo Padovan
If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.
Also adds the necessary e
From: Gustavo Padovan
Add an extra arg to drm_atomic_helper_wait_for_fences() to inform
if fence_wait() should be called interruptible or uninterruptible.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic_helper.c | 19 ++-
drivers/gpu/drm/msm/msm_atomic.c| 2
On Thu, 2016-08-11 at 12:56 +0200, Daniel Vetter wrote:
> On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > > On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 08, 2016 at 04:00:28PM +030
Hi, YT:
On Wed, 2016-08-10 at 15:24 +0800, YT Shen wrote:
> Hi CK,
>
> On Fri, 2016-08-05 at 18:08 +0800, CK Hu wrote:
> > Hi, YT:
> >
> > On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> > > From: shaoming chen
> > >
> > > add dsi read/write commands for transfer function
> > >
> > > Sign
While clk_register_divider will write register as little endian,
Modified the param "shift" from 0 to 24 since DCU is big endian.
Or reg "DCU_DIV_RATIO" will be seted as a incorrect value which
will cause vblank timing issue etc.
Signed-off-by: Meng Yi
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv
On Thu, 11 Aug 2016, Sumit Semwal wrote:
> diff --git a/Documentation/dma-buf/guide.rst b/Documentation/dma-buf/guide.rst
> new file mode 100644
> index ..fd3534fdccb3
> --- /dev/null
> +++ b/Documentation/dma-buf/guide.rst
> @@ -0,0 +1,503 @@
> +
> +.. _dma-buf-guide:
> +
> +=
on/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/57d1035b/attachment.sig>
Am 11.08.2016 um 13:58 schrieb Markus Heiser :
>> +.. note:: Until this stage, the buffer-exporter has the option to choose
>> not to
>> + actually allocate the backing storage for this buffer, but wait for the
>> + first buffer-user to request use of buffer for allocation.
>
> Use newlines
np;
>> }
>>
>> struct device_node *
>> --
>> 1.9.1
>>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/d5ebe0e8/attachment-0001.sig>
Hi Sumit,
I haven't compiled your patch yet, just my 2cent about the
reStructuredText (reST) ASCII markup ...
Here are some handy links about reST and the Sphinx markup constructs,
we have not yet added to the documentation (sorry):
* reST primer:http://www.sphinx-doc.org/en/stable/rest.htm
On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > Filter out a mode that exceeds the max pixel rate setting
> > > for DP to VGA dongle. This is defined in DP
From: Gustavo Padovan
This interface is hidden from kernel headers and it is intended for use
only for testing. So testers would have to add the ioctl information
internally. This is to prevent misuse of this feature.
v2: take in Eric suggestions for the Documentation
v3: really take in Eric su
2016-08-11 Eric Engestrom :
> On Thu, Aug 11, 2016 at 12:26:43PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This interface is hidden from kernel headers and it is intended for use
> > only for testing. So testers would have to add the ioctl information
> > internally. This i
4.9.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160811/a8c988c0/attachment.sig>
. Re-assigning to Mesa core.
--
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/20160811/292ac42a/attachment.html>
es/dri-devel/attachments/20160811/4636465a/attachment-0001.html>
On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > > Filter out a mode that exceeds the
On Thu, Aug 11, 2016 at 09:44:55AM +, Peter Chen wrote:
>
>
> >On 15/07/16 06:17, Peter Chen wrote:
> >> of_node_put needs to be called when the device node which is got from
> >> of_parse_phandle has finished using.
> >>
> >> Cc: Tomi Valkeinen
> >> Signed-off-by: Peter Chen
> >> ---
> >>
On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > Filter out a mode that exceeds the max pixel rate setting
> > for DP to VGA dongle. This is defined in DPCD register 0x81
> > if detailed cap info i.e. info field is 4 bytes
On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> From: Johannes Berg
>
> This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
>
> As Peter explained:
> [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
>
> [...]
>
> Also, clue is in the nam
From: Gustavo Padovan
SW_SYNC allows to run tests on the sync_file framework via debugfs on
/sync/sw_sync
Opening and closing the file triggers creation and release of a sync
timeline. To create fences on this timeline the SW_SYNC_IOC_CREATE_FENCE
ioctl should be used. To increment the timeline
From: Gustavo Padovan
This interface is hidden from kernel headers and it is intended for use
only for testing. So testers would have to add the ioctl information
internally. This is to prevent misuse of this feature.
v2: take in Eric suggestions for the Documentation
Signed-off-by: Gustavo Pad
From: Gustavo Padovan
remove file paths in the comments and add short description about each
file.
v2: remove file paths instead of just change them.
v3: improve header description as sugggested by Eric
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
drivers/staging/android/s
From: Gustavo Padovan
The common behaviour for trace headers is to have them in the same folder
they are used, instead of creating a special trace/ directory.
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
drivers/staging/android/sw_sync.c | 2 +-
drivers/
From: Gustavo Padovan
Closing the timeline without waiting all fences to signal is not
a critical failure, it is just bad usage from userspace so avoid
calling WARN_ON in this case.
Signed-off-by: Gustavo Padovan
---
drivers/staging/android/sw_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 d
From: Gustavo Padovan
Hi Greg,
This is the last step in the Sync Framwork de-stage task. It de-stage
the SW_SYNC validation framework and the sync_debug info debugfs file.
The first 2 patches are clean up and improvements and the rest is preparation
to de-stage and then finally the actual de-st
1 - 100 of 154 matches
Mail list logo
