nouveau's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
nouveau_connector_detect() which waits for the ongoing suspend to finish,
causing a deadlock.
Fix
radeon's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
radeon's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by
Introduce a helper to retrieve the current task's work struct if it is
a workqueue worker.
This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for a specific worker to
finish and that worker in turn calls a function which waits for run
Fix a deadlock on hybrid graphics laptops that's been present since 2013:
DRM drivers poll connectors in 10 sec intervals. The poll worker is
stopped on ->runtime_suspend with cancel_delayed_work_sync(). However
the poll worker invokes the DRM drivers' ->detect callbacks, which call
pm_runtime_g
Introduce a helper to determine if the current task is an output poll
worker.
This allows us to fix a long-standing deadlock in several DRM drivers
wherein the ->runtime_suspend callback waits for the output poll worker
to finish and the worker in turn calls a ->detect callback which waits
for run
amdgpu's ->runtime_suspend hook calls drm_kms_helper_poll_disable(),
which waits for the output poll worker to finish if it's running.
The output poll worker meanwhile calls pm_runtime_get_sync() in
amdgpu's ->detect hooks, which waits for the ongoing suspend to finish,
causing a deadlock.
Fix by
https://bugs.freedesktop.org/show_bug.cgi?id=105030
Christian König changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104082
Christian König changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #29 from Christian König ---
(In reply to Matthew Scheirer from comment #27)
> I do still get the swiotlib OOM errors without DC enabled, but they are
> fairly infrequent and don't panic crash the kernel. With DC enabled,
> swiotlib
Daniel Vetter writes:
> On Tue, Jan 30, 2018 at 01:56:43PM -0800, Eric Anholt wrote:
>> When we debug print what ioctl we're calling into, we include the pid.
>> If you have multiple processes rendering simulataneously, the error
>> return also needs the pid so you can see which of the ioctl call
Boris Brezillon writes:
> The V3D engine has various hardware counters which might be interesting
> to userspace performance analysis tools.
>
> Expose new ioctls to create/destroy a performance monitor object and
> query the counter values of this perfmance monitor.
>
> Note that a perfomance mo
https://bugs.freedesktop.org/show_bug.cgi?id=103736
--- Comment #8 from Lennart Sauerbeck ---
I was able to record an ApiTrace which shows the problem consistently. However,
it's 2.5 gigabytes and contains personal information I'd rather not share on a
public bugtracker -- I think a trace can onl
These clocks are in kHz not in Hz, oops. Fix it so my
new bandwidth calculations patch starts working with these
panels.
Cc: Eric Anholt
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- The Epson clock was still wrong, off by one order of
magnitude. It is now fixed. The only source of the
On Thu, Feb 8, 2018 at 11:50 AM, Eric Anholt wrote:
>> - .clock = 62500,
>> + .clock = 625000,
>
> 625000kHz still seems really suspicious.
Right, an order of magnitude typo on my part :(
It is even correct in the fbdev driver.
I sent a v2 fixing it.
https://bugs.freedesktop.org/show_bug.cgi?id=105042
Bug ID: 105042
Summary: [LLVM Regression] Shadow of Mordor stucks at intro
video
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
On Sat, Feb 10, 2018 at 6:14 PM, Eric Anholt wrote:
> Linus Walleij writes:
>> +static enum drm_mode_status
>> +pl111_mode_valid(struct drm_crtc *crtc,
>> + const struct drm_display_mode *mode)
>> +{
>> + struct drm_device *drm = crtc->dev;
>> + struct pl111_drm_dev_private
Hello,
Most of this series has previously been posted as part of "[PATCH 00/48]
omapdrm: Merge omapdrm and omapdss". I've decided to split out the
miscellaneous fixes and cleanups as they are (in my opinion) ready for
upstream.
Patch 10/15 and 11/15 are new and trivial. Patch 12/15 is new as well
The standard kernel integer types are [us]{8,16,32}. Use them instead of
the u?int{8,16,32}_t types.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 12 -
drivers/gpu/drm/omapdrm/omap_crtc.h | 2 +-
drivers/gpu/drm/omap
The connector drivers need a handle to the source they are connected to
in order to control the source.
All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.
Move ret
The kernel favours 'unsigned int' over plain 'unsigned'. Replace all
occurences of the latter by the former. This avoid lots of checkpatch
complaints in patches that touch lines where a plain 'unsigned' is used.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/
No encoder is instantiated through platform data anymore, there is no
need to check for OF node presence.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c| 3 -
The function is unused, remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dss.c | 14 --
drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/
No panel is instantiated through platform data anymore, there is no
need to check for OF node presence.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 3 ---
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
No connector is instantiated through platform data anymore, there is no
need to check for OF node presence.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 ---
drivers/gpu/drm/omapdrm/displays/connector-dvi.c |
The encoder drivers need a handle to the source they are connected to in
order to control the source.
All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.
Move retri
The wait_for_bit_change() function returns the value of the bit it
polls. This requires the caller to compare the return value to the
expected bit value. As all the existing callers need is to check whether
the bit has reached the expected value, it's easier to return a boolean
status from the func
The tvc_of_match variable is never referenced before its definition.
Remove the forward declaration.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/oma
A few functions defined in omapdss-base are internal to the module.
Don't export them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dss-of.c | 2 --
drivers/gpu/drm/omapdrm/dss/output.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c
There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.
This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.
The bind handler performs the following
The omap_dss_register_driver(), omap_dss_unregister_driver() and
dispc_enable_gamma_table() functions don't exist anymore, remove their
prototypes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dss.h | 1 -
1 file changed, 1 deletion(-)
diff --g
The function isn't used outside of its compilation unit, make it static.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/display.c | 5 ++---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/
The connector drivers need a handle to the source they are connected to
in order to control the source.
All drivers get that handle at probe time, resulting in probe deferral
when the source hasn't been probed yet. However they don't need the
handle until their connect handler is called.
Move ret
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #30 from mikhail.v.gavri...@gmail.com ---
(In reply to Christian König from comment #28)
> Ok setting this as fixed which hopefully makes people stop adding new
> comments to this bug report.
I didn't understand It's already fixed in
Hi,
On 06-02-18 15:12, Hans de Goede wrote:
Add an intel_bios_cleanup() function to act as counterpart of
intel_bios_init() and move the cleanup of vbt related resources there,
putting it in the same file as the allocation.
Signed-off-by: Hans de Goede
Can I get an Acked-by for this patch an
https://bugzilla.kernel.org/show_bug.cgi?id=198745
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=105046
Bug ID: 105046
Summary: Screen resolution reset to 1368x768 when turning
monitor off
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (
https://bugzilla.kernel.org/show_bug.cgi?id=198745
--- Comment #5 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274115
--> https://bugzilla.kernel.org/attachment.cgi?id=274115&action=edit
dmesg log
--
You are receiving this mail because:
You are watching the assignee of the
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #31 from Christian König ---
(In reply to mikhail.v.gavrilov from comment #30)
> I didn't understand It's already fixed in which commit?
> If yes why I see this issue with latest build amd-staging-drm-next?
See here https://lkml.org
https://bugzilla.kernel.org/show_bug.cgi?id=198745
--- Comment #6 from Kyle De'Vir (kyle.de...@mykolab.com) ---
Created attachment 274117
--> https://bugzilla.kernel.org/attachment.cgi?id=274117&action=edit
xorg log
--
You are receiving this mail because:
You are watching the assignee of the b
On 11 February 2018 at 09:38, Lukas Wunner wrote:
> Fix a deadlock on hybrid graphics laptops that's been present since 2013:
>
> DRM drivers poll connectors in 10 sec intervals. The poll worker is
> stopped on ->runtime_suspend with cancel_delayed_work_sync(). However
> the poll worker invokes
https://bugs.freedesktop.org/show_bug.cgi?id=105042
--- Comment #1 from Bas Nieuwenhuizen ---
What happens with the range in between? There are quite a few commits ot the
AMDGPU backend in there so would be good if we can reduce that range and
pinpoint the exact revision that is causing it.
--
On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> On 11 February 2018 at 09:38, Lukas Wunner wrote:
> > The patches for radeon and amdgpu are compile-tested only, I only have a
> > MacBook Pro with an Nvidia GK107 to test. To test the patches, add an
> > "msleep(12*1000);" at the to
On Sun, Feb 11, 2018 at 08:23:14PM +0100, Lukas Wunner wrote:
> On Sun, Feb 11, 2018 at 06:58:11PM +, Mike Lothian wrote:
> > On 11 February 2018 at 09:38, Lukas Wunner wrote:
> > > The patches for radeon and amdgpu are compile-tested only, I only have a
> > > MacBook Pro with an Nvidia GK107
https://bugs.freedesktop.org/show_bug.cgi?id=105039
--- Comment #1 from Matthew Scheirer ---
Same issue with 4.15 / Mesa 17.3 / Xorg 1.19.6 on a 290 + Acer GN246HL. No DC
the 144 / 120 / etc modes show up, DC only 60hz does.
--
You are receiving this mail because:
You are the assignee for the b
https://bugzilla.kernel.org/show_bug.cgi?id=198551
illuslion1...@gmail.com changed:
What|Removed |Added
Attachment #273797|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=198551
illuslion1...@gmail.com changed:
What|Removed |Added
Kernel Version|4.14.14-1 |4.15.1
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=104932
--- Comment #7 from Robin Kauffman ---
(In reply to Michel Dänzer from comment #4)
> Which versions of Mesa & LLVM are you using?
I should also add that LLVM & Clang were compiled/installed *prior* to merging
libclc & Mesa (probably prior to li
Hi
I've not been able to reproduce the original problem you're trying to
solve on amdgpu thats with or without your patch set and the above
"trigger" too
Is anything else required to trigger it, I started multiple DRI_PRIME
glxgears, in parallel, serial waiting the 12 seconds and serial within
th
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #32 from mikhail.v.gavri...@gmail.com ---
Created attachment 137285
--> https://bugs.freedesktop.org/attachment.cgi?id=137285&action=edit
system log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #33 from mikhail.v.gavri...@gmail.com ---
Why are you sure what this totally harmless?
I have proof this this isn't it.
Look at my system log:
- I got message "amdgpu :07:00.0: swiotlb buffer is full (sz: 2097152
bytes)" at Feb 10
On Mon, Feb 12, 2018 at 12:35:51AM +, Mike Lothian wrote:
> I've not been able to reproduce the original problem you're trying to
> solve on amdgpu thats with or without your patch set and the above
> "trigger" too
>
> Is anything else required to trigger it, I started multiple DRI_PRIME
> glx
https://bugs.freedesktop.org/show_bug.cgi?id=105021
--- Comment #5 from arne_woer...@yahoo.com ---
the new kernel 4.15.2-2-MANJARO still says during the second resume:
Feb 11 14:07:21 vaako.intern.wgboome.org kernel: [drm:uvd_v6_0_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 12 test failed (0xCAF
From: Archit Taneja
Newer DSI host controllers (SDM845 in particular) require a new clock
called byte_intf_clk. A recent patch tried to add this as an optional
clock, but it still set 'ret' to an error number if it didn't find it.
This breaks the host's probe for all previous DSI host versions.
On 11/02/18 15:07, Laurent Pinchart wrote:
> The standard kernel integer types are [us]{8,16,32}. Use them instead of
> the u?int{8,16,32}_t types.
I presume you used a script to do the conversion? I think I need to do
the same for TI's kernel, which has some non-mainline patches.
Tomi
--
Texa
Hi Tomi,
On Monday, 12 February 2018 08:46:22 EET Tomi Valkeinen wrote:
> On 11/02/18 15:07, Laurent Pinchart wrote:
> > The standard kernel integer types are [us]{8,16,32}. Use them instead of
> > the u?int{8,16,32}_t types.
>
> I presume you used a script to do the conversion? I think I need to
https://bugs.freedesktop.org/show_bug.cgi?id=105051
Bug ID: 105051
Summary: circular locking,
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medi
https://bugs.freedesktop.org/show_bug.cgi?id=105051
bugzi...@colorremedies.com changed:
What|Removed |Added
Summary|circular locking, |circular locking,
https://bugs.freedesktop.org/show_bug.cgi?id=105051
--- Comment #2 from bugzi...@colorremedies.com ---
Created attachment 137287
--> https://bugs.freedesktop.org/attachment.cgi?id=137287&action=edit
journalctl -b -o short-monotonic
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=105051
--- Comment #1 from bugzi...@colorremedies.com ---
Created attachment 137286
--> https://bugs.freedesktop.org/attachment.cgi?id=137286&action=edit
dmesg.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=105051
--- Comment #3 from bugzi...@colorremedies.com ---
Created attachment 137288
--> https://bugs.freedesktop.org/attachment.cgi?id=137288&action=edit
lspci -vvnn
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105051
--- Comment #4 from bugzi...@colorremedies.com ---
Created attachment 137289
--> https://bugs.freedesktop.org/attachment.cgi?id=137289&action=edit
dmidecode
--
You are receiving this mail because:
You are the assignee for the bug.
On 11/02/18 15:07, Laurent Pinchart wrote:
> Hello,
>
> Most of this series has previously been posted as part of "[PATCH 00/48]
> omapdrm: Merge omapdrm and omapdss". I've decided to split out the
> miscellaneous fixes and cleanups as they are (in my opinion) ready for
> upstream.
>
> Patch 10/1
Hi,
On Sun, Feb 11, 2018 at 03:07:42PM +0200, Laurent Pinchart wrote:
> The function isn't used outside of its compilation unit, make it static.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Sebastian Reichel
-- Sebastian
> ---
> drivers/gpu/drm/omapdrm/dss/display.c | 5 ++---
> drivers
Hi,
On Thu, Feb 8, 2018 at 2:28 PM, Bartlomiej Zolnierkiewicz
wrote:
> On Wednesday, January 31, 2018 08:51:23 PM Mathieu Malaterre wrote:
>> Bartlomiej,
>>
>> On Wed, Jan 31, 2018 at 12:57 PM, Bartlomiej Zolnierkiewicz
>> wrote:
>> > On Tuesday, January 30, 2018 02:14:10 PM Mathieu Malaterre w
Calling request_irq() followed by disable_irq() is usually a bad idea,
specially if the interrupt can be pending, and you're not yet in a
position to handle it.
This is exactly what happens on my kevin system when rebooting in a
second kernel using kexec: Some interrupt is left pending from
the pr
Hi Eric,
> Eric Anholt hat am 10. Februar 2018 um 18:24 geschrieben:
>
>
> Stefan Wahren writes:
>
> > Hi, i'm having problems while booting Raspberry Pi 1 B (Linux 4.15,
> > bcm2835_defconfig) on my display, which is connected via HDMI. Mostly
> > the screen stays black and i'm getting the f
Now that drm_do_get_edid() handles override and firmware EDIDs it makes
no sense to conditionalize it with a DCC probe. On the contrary -- the
overrides are useful specifically when DCC is not functioning.
drm_do_get_edid() already bails out when DCC fails, there's no need for
an extra check. It s
The rockchip DRM driver is quite careful to disable interrupts
when taking a lock that is also taken in interrupt context,
which is a good thing.
What is a bit over the top is to use spin_lock_irqsave when
already in interrupt context, as you cannot take another
interrupt again, and disabling inte
Hi,
On Sun, Feb 11, 2018 at 03:07:43PM +0200, Laurent Pinchart wrote:
> A few functions defined in omapdss-base are internal to the module.
> Don't export them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
> drivers/gpu/drm/omapdrm/dss/dss-of.c | 2 -
Hi Boris,
> Boris Brezillon hat am 10. Februar 2018 um
> 17:40 geschrieben:
>
>
> Hi Stefan,
>
> On Sat, 10 Feb 2018 16:57:23 +0100 (CET)
> Stefan Wahren wrote:
>
> > Hi,
> > i'm having problems while booting Raspberry Pi 1 B (Linux 4.15,
> > bcm2835_defconfig) on my display, which is conn
Hi,
i'm having problems while booting Raspberry Pi 1 B (Linux 4.15,
bcm2835_defconfig) on my display, which is connected via HDMI. Mostly the
screen stays black and i'm getting the following warnings via debug UART.
Sometimes after disconnecting HDMI, i'm getting the expected screen.
[3.253
Hi,
On Sun, Feb 11, 2018 at 03:07:44PM +0200, Laurent Pinchart wrote:
> There's no reason to delay initialization of most of the driver (such as
> mapping memory I/O, getting clocks or enabling runtime PM) to the
> component master bind handler.
>
> This additionally fixes a real PM issue caused
On Fri, 2018-02-09 at 12:18 +, Chris Wilson wrote:
> Quoting Shreeya Patel (2018-02-09 12:10:56)
> >
> > dev->struct_mutex is the Big DRM Lock and the only bit where
> > it’s mandatory is serializing GEM buffer object destruction.
> > Which unfortunately means drivers have to keep track of tha
On Sat, 2018-02-10 at 19:03 +0100, Lubomir Rintel wrote:
> Now that drm_do_get_edid() handles override and firmware EDIDs it makes
> no sense to conditionalize it with a DCC probe. On the contrary -- the
> overrides are useful specifically when DCC is not functioning.
>
> drm_do_get_edid() already
74 matches
Mail list logo
