On 06/15/2018 06:22 AM, YoungJun Cho wrote:
Dear Dan,
Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.
And the replacement IS_ERR was one of items.
IMHO it is still better to modify those two functions,
drm_gem_cma_prime_get_sg_table and
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19-wip
head: 0198cd6030f1f4bddc2fceb47971bfcbaa616db5
commit: 30e85debc13f1b8aaac16906441ee66645db10ed [121/126] drm/amd/pp: Remove
SAMU support in powerplay
reproduce:
# apt-get install sparse
git checkout
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #11 from Wolfram Sang (w...@the-dreams.de) ---
I have sent another patch, let's hope it really is this issue:
http://patchwork.ozlabs.org/patch/929798/
--
You are receiving this mail because:
You are watching the assignee of the
Hi Linus,
Just a single set of AMD fixes for stuff in -next for -rc1.
Thanks,
Dave.
drm-next-2018-06-15:
amd fixes for 4.18-rc1
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:
Merge tag 'drm-intel-next-fixes-2018-06-08-2' of
Currenty the VCO rate in the 10nm PLL driver relies
on the parent rate which is not configured.
Configure the VCO rate to 19.2 Mhz as required by
the 10nm PLL driver.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +++-
1 file changed, 3 insertions(+), 1
Dear Dan,
Your mail flashes back to my memory 5 years ago.
Back then, I had cleaned up the exynos driver.
And the replacement IS_ERR was one of items.
IMHO it is still better to modify those two functions,
drm_gem_cma_prime_get_sg_table and xen_drm_front_gem_get_sg_table.
Thank you.
Best
Here's a couple of reasonably straightforward extensions implemented
for both anv and radv drivers.
VK_EXT_display_surface_counter is a very simple extension which
adds an API, vkGetPhysicalSurfaceCapabilities2EXT, to extend the
existing vkGetPhysicalDeviceSurfaceCapabilitiesKHR and
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2: Adopt Jason Ekstrand's coding conventions
Declare variables at first use, eliminate extra whitespace
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2:
Rework fence integration into the driver so that waiting for
any of a mixture of fence types (wsi,
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v2:
Add extension to list in alphabetical order
Suggested-by: Jason Ekstrand
Signed-off-by: Keith Packard
---
src/intel/vulkan/anv_extensions.py |
Handle the case where the set of fences to wait for is not all of the
same type by either waiting for them sequentially (waitAll), or
polling them until the timer has expired (!waitAll). We hope the
latter case is not common.
While the current code makes sure that it always has fences of only
one
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
v2: Thanks to kisak
Fix spelling of VkSurfaceCapabilities2EXT in wsi_common_wayland.c,
it was using ext instead of EXT.
Fix spelling of
This extension provides fences and frame count information to direct
display contexts. It uses new kernel ioctls to provide 64-bits of
vblank sequence and nanosecond resolution.
v2: Remove DRM_CRTC_SEQUENCE_FIRST_PIXEL_OUT flag. This has
been removed from the proposed kernel API.
Add
This extension is required to support EXT_display_control as it offers
a way to query whether the vblank counter is supported.
Signed-off-by: Keith Packard
---
src/amd/vulkan/radv_extensions.py | 1 +
src/amd/vulkan/radv_wsi.c | 12
2 files changed, 13 insertions(+)
diff
Jason Ekstrand writes:
> Looks good to me. With this properly sprinkled on the appropriate patches,
> the entire series is
>
> Reviewed-by: Jason Ekstrand
Thanks so much! I've rebased the series onto current master and pushed
it back to my gitlab repo here
Looks good to me. With this properly sprinkled on the appropriate patches,
the entire series is
Reviewed-by: Jason Ekstrand
On Thu, Jun 14, 2018 at 5:57 PM, Keith Packard wrote:
> We sorted out what 'vscan' means and are trying to use it correctly.
>
> vscan = 0 is the same as vscan = 1,
We sorted out what 'vscan' means and are trying to use it correctly.
vscan = 0 is the same as vscan = 1, which is slightly annoying; we use
MAX2(vscan, 1) everywhere.
randr doesn't pass vscan at all, so we set wsi mode vscan = 0.
The doublescan flag doubles the vscan value, so we don't need to
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #38 from Samuel Sieb (samuel-kb...@sieb.net) ---
https://bugzilla.redhat.com/show_bug.cgi?id=1558023
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #7 from Ricardo Ribalda ---
BTW: Are you aware of anyway that I can validate that a video is properly
encoded, besides playing it?
Thanks!
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #6 from Ricardo Ribalda ---
I tried this combinations with gstreamer:
sw encoding + sw decoding (libva): works
sw encoding + omx decoding: works
omx encoding + sw decoding (libva): works
omx encoding + omx decoding : fails
I
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #5 from Julien Isorce ---
Can you try gstreamer-vaapi ? to compare with another hw decoder. And with sw
decoders in gstreamer it works ? And other players ?
I am trying to determine if the issue is only in the omx decoder.
--
You
On Thu, Jun 14, 2018 at 06:43:40PM +0200, Thomas Hellstrom wrote:
> Overall, I think this looks fine. I'll just fix up the FLAG_WAITERS setting
> and affected comments and do some torture testing on it.
Thanks!
> Are you OK with adding the new feature and the cleanup in the same patch?
I
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #24 from djip.per...@free.fr ---
look like LVDS is not see as attached...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #23 from djip.per...@free.fr ---
Created attachment 140167
--> https://bugs.freedesktop.org/attachment.cgi?id=140167=edit
dmesg from kernel 4.17.1 with attachment 138831 applied
recompile 4.17.1 kernel with patch an debug mod...
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #4 from Ricardo Ribalda ---
I do not know. It is the first time that I use this configuration: omx for
encoding and decoding.
The only thing that I know for sure is that the effect gets worse and worse if
I increase the frequency
https://bugs.freedesktop.org/show_bug.cgi?id=106919
Julien Isorce changed:
What|Removed |Added
CC||boyuan.zh...@amd.com,
Quoting Bloomfield, Jon (2018-06-14 17:36:29)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, June 14, 2018 9:07 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson
> > ;
> > Bloomfield, Jon ; Joonas Lahtinen
> > ; Matthew
https://bugs.freedesktop.org/show_bug.cgi?id=106921
--- Comment #2 from sam.ps...@gmail.com ---
Created attachment 140166
--> https://bugs.freedesktop.org/attachment.cgi?id=140166=edit
another dmesg w/mesa 18.0.2-1.fc28
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106921
--- Comment #1 from sam.ps...@gmail.com ---
Created attachment 140165
--> https://bugs.freedesktop.org/attachment.cgi?id=140165=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=106921
Bug ID: 106921
Summary: System lockup with Vega10 amdgpu:
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
timeout
Product: DRI
Version: unspecified
On 06/14/2018 04:42 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
The literature makes a distinction between "killed" and "wounded". In our
context, "Killed" is when a transaction actually receives an -EDEADLK and
needs to back off. "Wounded" is
> -Original Message-
> From: Chris Wilson
> Sent: Thursday, June 14, 2018 9:07 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson ;
> Bloomfield, Jon ; Joonas Lahtinen
> ; Matthew Auld
> ; David Herrmann
>
> Subject: [PATCH v2] drm/i915: Prevent
On Thu, 14 Jun 2018 18:09:01 +0200,
Mauro Carvalho Chehab wrote:
>
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #23 from sam.ps...@gmail.com ---
(In reply to Michel Dänzer from comment #22)
> (In reply to sam.psylo from comment #20)
> > I am still suffering from this issue, even with latest firmware from comment
> > 15.
>
> Please file your
On Thu, 14 Jun 2018 13:08:49 -0300
Mauro Carvalho Chehab wrote:
> +++ b/Documentation/trace/events.rst
> @@ -8,7 +8,7 @@ Event Tracing
> 1. Introduction
> ===
>
> -Tracepoints (see Documentation/trace/tracepoints.txt) can be used
> +Tracepoints (see
On Thu, 2018-06-14 at 13:09 -0300, Mauro Carvalho Chehab wrote:
> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
> ./scripts/documentation-file-ref-check --fix
>
> Manually checked that produced results are valid.
>
> Signed-off-by: Mauro
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, June 14, 2018 6:21 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org; Syrjala,
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked that produced results are valid.
Signed-off-by: Mauro Carvalho Chehab
---
.../devicetree/bindings/clock/st/st,clkgen.txt | 8
The script:
./scripts/documentation-file-ref-check --fix-rst
Gives multiple hints for broken references on some files.
Manually use the one that applies for some files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/ABI/obsolete/sysfs-gpio | 2 +-
On Thu, Jun 14, 2018 at 12:30:35PM +0530, Vivek Gautam wrote:
> Hi Jordan,
>
> On Mon, Jun 11, 2018 at 11:56 PM, Jordan Crouse
> wrote:
> > Now that the IOMMU is the master of it's own power we don't need to bring
> > up the GPU to do IOMMU operations. This is good because bringing up a6xx
> >
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least
On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> Switch to state based resource management. This patch
> overhauls the resource manager and HW allocation methods by
> maintaining the global resource pool and allocated hw
> blocks in respective drm component states.
>
> Global
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #10 from cerg2010cerg2...@mail.ru ---
Here is the output:
[ 23.056329] (null): initial SCL state 1
[ 23.056330] (null): initial SDA state 1
[ 23.056532] (null): initial SCL state 1
[ 23.056534] (null): initial SDA state 1
https://bugs.freedesktop.org/show_bug.cgi?id=106872
Michel Dänzer changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #22 from Michel Dänzer ---
(In reply to sam.psylo from comment #20)
> I am still suffering from this issue, even with latest firmware from comment
> 15.
Please file your own report. This report is resolved.
> Firmware:
On Tue, Jun 12, 2018 at 06:17:43PM -0700, Jeykumar Sankaran wrote:
> This patchset introduces drm private object in KMS to manage HW
> resource management. It modifies the resource manager by
> introducing API's to do per DRM object resource allocation/cleanups.
>
> The patchset is based on:
On Wed, Jun 13, 2018 at 12:01:21PM -0700, Jeykumar Sankaran wrote:
> On 2018-06-13 09:44, Jordan Crouse wrote:
> > On Tue, Jun 12, 2018 at 06:17:47PM -0700, Jeykumar Sankaran wrote:
> > > Switch to state based resource management. This patch
> > > overhauls the resource manager and HW allocation
On Tue, May 15, 2018 at 11:18:50AM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the errors,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #9 from Wolfram Sang (w...@the-dreams.de) ---
Created attachment 276551
--> https://bugzilla.kernel.org/attachment.cgi?id=276551=edit
print initial states to allow further debug
Thanks for testing the patches, pity it didn't help.
On Tue, Jun 12, 2018 at 05:49:03PM -0700, Abhinav Kumar wrote:
> Seamless modes are ones which do not require a display
> to be turned OFF/ON between mode switches.
>
> Remove support for seamless modes from DPU for now.
>
> This will be added later based on additional requirements.
>
> This
On Mon, Jun 11, 2018 at 02:13:17PM -0700, Jeykumar Sankaran wrote:
> Submitting a series of patches to further clean up DPU driver by stripping
> down a list of custom properties supporting proprietary features. It
> removes the property installers/handlers and cleans up relevant files of
> of
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #21 from sam.ps...@gmail.com ---
Created attachment 140159
--> https://bugs.freedesktop.org/attachment.cgi?id=140159=edit
dmesg w/mesa 18.2.0-0.11.git41dabdc.fc28
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #20 from sam.ps...@gmail.com ---
Created attachment 140158
--> https://bugs.freedesktop.org/attachment.cgi?id=140158=edit
dmesg w/mesa 18.0.2-1.fc28
I am still suffering from this issue, even with latest firmware from comment
15.
Hello,
Please pull the generic drm_writeback patches into drm-misc-next. They
have been reviewed on the mailing lists for a while, and we have the
userspace and individual kernel driver's implementations using it.
The following changes since commit 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5:
On Thu, Jun 14, 2018 at 03:43:04PM +0200, Thomas Hellstrom wrote:
> It's intended to be enforced by storing the algorithm choice in the
> WW_MUTEX_CLASS which must be common for an acquire context and the
> ww_mutexes it acquires. However, I don't think there is a check that that
> holds. I guess
On Thu, Jun 14, 2018 at 01:48:39PM +0200, Thomas Hellstrom wrote:
> The literature makes a distinction between "killed" and "wounded". In our
> context, "Killed" is when a transaction actually receives an -EDEADLK and
> needs to back off. "Wounded" is when someone (typically another transaction)
>
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #2 from Ricardo Ribalda ---
Created attachment 140156
--> https://bugs.freedesktop.org/attachment.cgi?id=140156=edit
Sluttering (how do I see the video with omx decode)
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106919
--- Comment #1 from Ricardo Ribalda ---
Created attachment 140154
--> https://bugs.freedesktop.org/attachment.cgi?id=140154=edit
Original file encoded with omx (one keyframe per second)
--
You are receiving this mail because:
You are the
Hello YoungJun Cho,
The patch 7e3d88f9cce3: "drm/prime: replace NULL with error value in
drm_prime_pages_to_sg" from Jun 24, 2013, leads to the following
static checker warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
https://bugs.freedesktop.org/show_bug.cgi?id=106919
Bug ID: 106919
Summary: Stuttering when trying to decode stream encoded with
omx
Product: Mesa
Version: 18.0
Hardware: Other
OS: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=100687
MirceaKitsune changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Dave,
Fixes for 4.18. Highlights:
- Fixes for gfxoff on Raven
- Remove an ATPX quirk now that the root cause is fixed
- Runtime PM fixes
- Vega20 register header update
- Wattman fixes
- Misc bug fixes
The following changes since commit 7ba01f9e12bb3f088f617cf69b589ea37bd5d6ed:
drm/amdgpu:
https://bugs.freedesktop.org/show_bug.cgi?id=106418
davep changed:
What|Removed |Added
CC||david.panar...@amd.com
--- Comment #5 from
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #8 from cerg2010cerg2...@mail.ru ---
Ok, I tested the patches, but they did not fix the problem. Nothing changed,
and the log is empty. I tried to apply them separately and both at the same
time. Note that second one seems to depend
On 06/14/2018 03:29 PM, Matthew Wilcox wrote:
On Thu, Jun 14, 2018 at 01:54:15PM +0200, Thomas Hellstrom wrote:
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
Currently you don't allow mixing WD and WW contexts (which is not
immediately obvious from the above code), and the above hard relies on
On 06/14/2018 02:48 PM, Thomas Hellstrom wrote:
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+ struct ww_acquire_ctx *ww_ctx,
+
https://bugzilla.kernel.org/show_bug.cgi?id=200045
--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Wolfram Sang from comment #5)
> Sure. But reading the original description above, I think the default use
> case is to not use hw_i2c. It was just added to try to work
On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Alexandru-Cosmin Gheorghe
> >Sent: Monday, June 11, 2018 3:47 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org;
Am Mittwoch, 14. März 2018, 13:02:13 CEST schrieb Emil Velikov:
> Hi Lin,
>
> On 14 March 2018 at 09:12, Lin Huang wrote:
> > From: huang lin
> >
> > Refactor Innolux P079ZCA panel driver, let it support
> > multi panel.
> >
> > Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> >
Hi, Peter,
On 06/14/2018 02:41 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
+static bool __ww_mutex_wound(struct mutex *lock,
+struct ww_acquire_ctx *ww_ctx,
+struct ww_acquire_ctx *hold_ctx)
https://bugzilla.kernel.org/show_bug.cgi?id=199025
--- Comment #37 from Alex Tucker (a...@floop.org.uk) ---
Thanks Samuel, updating to kernel-4.16.14-300.fc28.x86_64 and moving back to
Nouveau rather than the workaround with the NVIDIA driver, suspend and resume
now works again for me too.
Would
On 24.05.2018 11:32, Inki Dae wrote:
> This patch makes RC_CORE to be selected with this driver.
>
> sil_sii8620 driver calls remote controller interfaces directly
> so RC_CORE should be enabled mandatorily.
>
> And some boards not using remote controller device don't really
> need to know that
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> +static bool __ww_mutex_wound(struct mutex *lock,
> + struct ww_acquire_ctx *ww_ctx,
> + struct ww_acquire_ctx *hold_ctx)
> +{
> + struct task_struct *owner =
Resending hopefully better formatted..
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or
On 06/14/2018 01:49 PM, Andrea Parri wrote:
[...]
+ /*
+* wake_up_process() paired with set_current_state() inserts
+* sufficient barriers to make sure @owner either sees it's
+* wounded or has a wakeup pending to re-read the
On 06/14/2018 01:36 PM, Peter Zijlstra wrote:
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
__ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
*ww_ctx)
{
struct mutex_waiter *cur;
+ unsigned int is_wait_die =
On 06/14/2018 12:51 PM, Peter Zijlstra wrote:
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
In short, with Wait-Die (before the patch) it's the process _taking_ the
contended lock that backs off if necessary. No preemption required. With
Wound-Wait, it's the process
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
> __ww_mutex_wakeup_for_backoff(struct mutex *lock, struct ww_acquire_ctx
> *ww_ctx)
> {
> struct mutex_waiter *cur;
> + unsigned int is_wait_die = ww_ctx->ww_class->is_wait_die;
>
>
On 06/14/2018 12:38 PM, Andrea Parri wrote:
Hi Thomas,
On Thu, Jun 14, 2018 at 09:29:21AM +0200, Thomas Hellstrom wrote:
The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a
Hi Linus,
Please pull fbdev changes for v4.18. There is nothing really major
here, few small fixes, some cleanups and dead drivers removal (please
see the signed tag description for details).
Test merge revealed a small merge conflict, the resolution is trivial:
diff --cc
On Wed, Jun 13, 2018 at 04:05:43PM +0200, Thomas Hellstrom wrote:
> In short, with Wait-Die (before the patch) it's the process _taking_ the
> contended lock that backs off if necessary. No preemption required. With
> Wound-Wait, it's the process _holding_ the contended lock that gets wounded
>
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #25 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Yes, it works
dmesg:
[ 34.330683] amdgpu :65:00.0: Test 0 from 8 to 13
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #24 from Christian König (christian.koe...@amd.com) ---
Created attachment 276547
--> https://bugzilla.kernel.org/attachment.cgi?id=276547=edit
Possible fix
In this case please try the attached patch and see if it helps.
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #23 from Alexander Mezin (mezin.alexan...@gmail.com) ---
(In reply to Christian König from comment #22)
> Your debugging efforts are better than mine.
>
> Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
>
On Wed, Jun 13, 2018 at 11:57:25AM +0100, Sudeep Holla wrote:
> Hi Linus,
>
> I was planning to apply this and observed few things.
>
> On 28/05/18 13:26, Linus Walleij wrote:
> > The Versatile Express was submitted with the actual display
> > bridges unconnected (but defined in the device tree)
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #22 from Christian König (christian.koe...@amd.com) ---
Your debugging efforts are better than mine.
Please provide the output of "sudo setpci -s 65:00.0 ECAP15.l ECAP15+4.l
ECAP15+8.l" once before suspend and once after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=10
Christian König changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
The current Wound-Wait mutex algorithm is actually not Wound-Wait but
Wait-Die. Implement also Wound-Wait as a per-ww-class choice. Wound-Wait
is, contrary to Wait-Die a preemptive algorithm and is known to generate
fewer backoffs. Testing reveals that this is true if the
number of simultaneous
For modeset locks we don't expect a high number of contending
transactions so change algorithm from Wait-Die to Wound-Wait.
Signed-off-by: Thomas Hellstrom
---
v2: Update to API change.
---
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This is a small fallout from a work to allow batching WW mutex locks and
unlocks.
Our Wound-Wait mutexes actually don't use the Wound-Wait algorithm but
the Wait-Die algorithm. One could perhaps rename those mutexes tree-wide to
"Wait-Die mutexes" or "Deadlock Avoidance mutexes". Another approach
Hi,
On Wed, 2018-06-13 at 23:52 +0200, Giulio Benetti wrote:
> Hello,
>
> sorry for my ignorance.
> I don't know the right patch workflow in the case of "revert commit".
> When I fix this bug, should I have to re-submit the previous patch
> entire plus bug-fix?
>
> Or do I have to submit patch
https://bugs.freedesktop.org/show_bug.cgi?id=81678
Michel Dänzer changed:
What|Removed |Added
Product|DRI |xorg
QA Contact|
Hi Andrzej,
On 01/15/2018 06:33 PM, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
>
> Signed-off-by: Andrzej Hajda
Looks fine to me.
Reviewed-by: Maciej Purski
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 31
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
> On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
>>
>>
>> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
>>
>>> int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
>>> fd)
>>> {
>>> - return -EINVAL;
>>> +
On 06/14/2018 01:03 AM, Boris Ostrovsky wrote:
On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote:
On 06/13/2018 06:14 AM, Boris Ostrovsky wrote:
On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote:
int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32
fd)
{
-
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with existing
bindings (Andrzej Hajda).
- Add missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp
On 13 June 2018 at 16:22, Sinan Kaya wrote:
> Hi Ard,
>
> On 5/18/2018 10:17 AM, Sinan Kaya wrote:
>> A host bridge is allowed to remap BAR addresses using _TRA attribute in
>> _CRS windows.
>>
>> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
>> (bus address
On 2018-06-06 04:29, Sean Paul wrote:
On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c
Hi Andrzej,
On 06/08/2018 08:04 AM, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Maciej Purski
> ---
> Hi,
>
> This is v2 of forgotten patch, awaiting
1 - 100 of 131 matches
Mail list logo
