Hi Enric,
On Tue, Aug 7, 2018 at 12:53 AM Enric Balletbo i Serra
wrote:
>
> Add support to async updates of cursors by using the new atomic
> interface for that.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> Hi,
>
> This first version is slightly different from the RFC, note that I did
> not
Am Montag, 13. August 2018, 09:11:07 CEST schrieb Tomasz Figa:
> Hi Enric,
>
> On Tue, Aug 7, 2018 at 12:53 AM Enric Balletbo i Serra
> wrote:
> >
> > Add support to async updates of cursors by using the new atomic
> > interface for that.
> >
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
On Mon, Aug 13, 2018 at 4:26 PM Heiko Stuebner wrote:
>
> Am Montag, 13. August 2018, 09:11:07 CEST schrieb Tomasz Figa:
> > Hi Enric,
> >
> > On Tue, Aug 7, 2018 at 12:53 AM Enric Balletbo i Serra
> > wrote:
> > >
> > > Add support to async updates of cursors by using the new atomic
> > > interf
On 09.07.2018 15:48, Heiko Stuebner wrote:
> __dw_mipi_dsi_probe() does all the grabbing of resources and does it using
> devm-helpers. So this is happening on each try of master bringup possibly
> slowing down things a lot.
>
> Drivers using the component framework may instead want call dw_mipi_ds
On 09.07.2018 15:48, Heiko Stuebner wrote:
> When the panel-driver is build as a module it currently fails hard as the
> panel cannot be probed directly:
>
> dw_mipi_dsi_bind()
> __dw_mipi_dsi_probe()
> creates dsi bus
> creates panel device
> triggers panel module load
> panel no
Hi Andrzej,
Am Montag, 13. August 2018, 10:28:39 CEST schrieb Andrzej Hajda:
> On 09.07.2018 15:48, Heiko Stuebner wrote:
> > When the panel-driver is build as a module it currently fails hard as the
> > panel cannot be probed directly:
> >
> > dw_mipi_dsi_bind()
> > __dw_mipi_dsi_probe()
> >
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
---
include/drm/ttm/ttm_bo_driver.h | 28 +
The idea and proposal is originally from Christian, and I continue to work to
deliver it.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact perfor
From: Christian König
When move a BO to the end of LRU, it need remember the BO positions.
Make sure all moved bo in between "first" and "last". And they will be bulk
moving together.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
---
drivers/gpu/drm/amd/amdg
The new bulk moving functionality is ready, the overhead of moving PD/PT bos to
LRU is fixed. So move them on LRU again.
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriousl
This function allow us to bulk move a group of BOs to the tail of their LRU.
The positions of group of BOs are stored on the (first, last) bulk_move_pos
structure.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
---
drivers/gpu/drm/ttm/ttm_bo.c | 52
On 06/06/18 12:36, Laurent Pinchart wrote:
> The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
> operations are called recursively from the display device back to the
> HDMI encoder. This isn't required, as all components other than the HDMI
> encoder just forward the operation to t
Am 13.08.2018 um 11:58 schrieb Huang Rui:
From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
Tested-by: Mike Lothian
If you ask me that lo
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 53d5f1e4a6d91457678a24b03d0a66edafb800ea
commit: 711c989d235ffd044fb04b971049e204b33fde3f [1/4] drm/scheduler: add a
list of run queues to the entity
New smatch warnings:
drivers/gpu/drm/scheduler/gpu_scheduler.c:1
On 13.08.2018 10:44, Heiko Stuebner wrote:
> Hi Andrzej,
>
> Am Montag, 13. August 2018, 10:28:39 CEST schrieb Andrzej Hajda:
>> On 09.07.2018 15:48, Heiko Stuebner wrote:
>>> When the panel-driver is build as a module it currently fails hard as the
>>> panel cannot be probed directly:
>>>
>>> dw_m
So far, struct ttm_bo_global_ref was the only way of initializing a struct
ttm_bo_global. Providing separate initializer and release functions for
struct ttm_bo_global gives drivers the option of implementing their own
init and release callbacks for drm_global_references of type
DRM_GLOBAL_TTM_BO.
TTM uses global memory and BO for backing graphics buffers. These are
represented by struct ttm_mem_global and struct ttm_bo_global.
Currently, struct ttm_bo_global can only be initialized and released through
struct ttm_bo_global_ref. This is a workaround for passing an instance of
ttm_mem_global
The functions ttm_bo_global_init() and ttm_bo_global_release() do not
receive an argument of type struct ttm_bo_global. Both take a struct
drm_global_reference that contains points to a struct ttm_bo_global_ref.
Renaming them reflects this.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/am
Yes, please! I had it on my TODO list to clean that up for an eternity.
Actually I never understood why that should be driver work to setup TTM?
I mean can't we just have a module_init/module_exit for TTM?
Thanks,
Christian.
Am 13.08.2018 um 12:24 schrieb Thomas Zimmermann:
TTM uses global me
Op 05-06-18 om 11:07 schreef Lowry Li:
> On Mon, Jun 04, 2018 at 02:49:26PM +0100, Emil Velikov wrote:
>> On 1 June 2018 at 13:41, Lowry Li wrote:
>>> Pixel blend modes represent the alpha blending equation
>>> selection, describing how the pixels from the current
>>> plane are composited with the
On Fri, 2018-08-10 at 13:02 +, Lisovskiy, Stanislav wrote:
> On Thu, 2018-08-09 at 14:13 +0300, Gwan-gyeong Mun wrote:
> >
> > The hotplug detection routine of i915 uses
> > drm_helper_hpd_irq_event(). This
> > helper can detect changing of status of connector, but it can not
> > detect
> > ch
On 06/08/18 23:36, Laurent Pinchart wrote:
> The two functions implement the .set_timings() and .check_timings()
> operations. Rename them to hdmi_disply_set_timings() and
> hdmi_display_check_timings() respectively to match the operations names
> and make searching the source code easier.
>
> Sig
On 06/08/18 23:36, Laurent Pinchart wrote:
> The series is based on top of the previously submitted "[PATCH v2 00/21]
> omapdrm: Rework the HPD-related operations" patch series. For convenience I've
> pushed it to my tree at
>
> git://linuxtv.org/pinchartl/media.git omapdrm/bridge/timings
On 07.08.2018 10:53, Inki Dae wrote:
>
> 2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
>> From: Maciej Purski
>>
>> The current implementation assumes that the only possible peripheral
>> device for DSIM is a panel. Using an output bridge child device
>> should also be possible.
>>
>> If an output
https://bugs.freedesktop.org/show_bug.cgi?id=107001
cla...@mathr.co.uk changed:
What|Removed |Added
Summary|hard system freeze with |hard system freeze with
On 25.07.2018 05:56, Icenowy Zheng wrote:
> Currently dw_hdmi_setup is only run when the dw-hdmi bridge is enabled,
> with the mode set last time.
>
> When the bridge is enabled before any mode is set (this may happen when
> booting), the mode won't be set at all, some setup steps will be
> skipped
On Fri, 2018-08-10 at 19:01 +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Stanislav,
>
> FYI, we are trying to add same format under a slightly different
> name.
> See https://lists.freedesktop.org/archives/dri-devel/2018-
> July/184598.html
So we probably just need to decide, if this should be DR
Hey,
Op 08-08-18 om 17:26 schreef Mahesh Kumar:
> This patch implements get_crc_sources callback, which returns list of
> all the crc sources supported by driver in current platform.
>
> Changes Since V1:
> - move sources list per-crtc
> - init sources-list only for gen3
> Changes Since V2:
>
https://bugs.freedesktop.org/show_bug.cgi?id=106940
--- Comment #27 from Przemek ---
Now it is in stable 4.18.
Same situation here. Gentoo ~amd64 on Lenovo G50-45 A6-6310 APU with R4
Mullins.
Laptop monitor is off (eDP), but there is picture on external one, connected
through hdmi port.
Reverti
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
> Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post it when the
current patches got some feed back.
I'
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #10 from Przemek ---
I cannot reproduce this on stable 4.18 kernel any more.
It seems that WARNING message has been fixed for my hardware.
Thanks,
Przemek.
--
You are receiving this mail because:
You are the assignee for the bug
On 08/13/2018 02:28 PM, Thomas Zimmermann wrote:
Hi
Am 13.08.2018 um 12:33 schrieb Christian König:
Yes, please! I had it on my TODO list to clean that up for an eternity.
On top of these patches, I have a patch set that provides a single
init/release interface for TTM global data. I'll post i
https://bugs.freedesktop.org/show_bug.cgi?id=107454
--- Comment #1 from Gert Wollny ---
Can you retry with
R600_DEBUG=nosb blender?
For me it seems to mostly fix ESM (when comparing to VSM)
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Aug 07, 2018 at 08:12:28PM -0700, Jeykumar Sankaran wrote:
> cleans up left out scalar config definitions from headers
>
> changes in v2:
> - none
> changes in v3:
> - none
>
> Change-Id: Id824dd5075c666f97b964573c97215bb786eac75
Please strip Change-Id before sending patches.
Hi Peter,
On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
> This enables more flexible devicetrees. You can e.g. have two output
> nodes where one is not enabled, without the ordering affecting things.
>
> Prior to this patch the active node had to have endpoint id zero.
>
> Signed-
https://bugs.freedesktop.org/show_bug.cgi?id=100400
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=100069
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=104602
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=106287
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101978
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=106224
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=103915
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=106875
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101384
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
https://bugs.freedesktop.org/show_bug.cgi?id=101675
Gregor Münch changed:
What|Removed |Added
Blocks||77449
Referenced Bugs:
https://bugs.fr
On Sun, Aug 12, 2018 at 3:55 AM Christian König
wrote:
>
> Adding Harry as well.
>
> Am 11.08.2018 um 17:54 schrieb Arnd Bergmann:
> > Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> > and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many
> > functions
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
Cc:
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup o
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Ch
This patch implements "verify_crc_source" callback function for
Virtual KMS drm driver.
Cc: dri-devel@lists.freedesktop.org
Cc: Haneen Mohammed
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/vkms/vkms_crc.c | 36
drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
dr
On Mon, Aug 13, 2018 at 4:49 PM Alex Deucher wrote:
>
> On Sun, Aug 12, 2018 at 3:55 AM Christian König
> wrote:
> > Adding Harry as well.
> > Am 11.08.2018 um 17:54 schrieb Arnd Bergmann:
> > >
> > > Fixes: bf2e2e2e0ea9 ("drm/amd/display: Limit DCN to x86 arch")
> > > Fixes: 4841203102a3 ("drm/a
Track whenever an virtual output (crtc) is enabled or disabled.
On atomic updates check for both framebuffer being present and crtc
being enabled to figure whenever the output is active or not.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virt
https://bugs.freedesktop.org/show_bug.cgi?id=107560
Bug ID: 107560
Summary: radeon (amdgpu) GDM flip queue failed invalid
argument, DisplayPort issues
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=107560
--- Comment #1 from Fermulator ---
Created attachment 141068
--> https://bugs.freedesktop.org/attachment.cgi?id=141068&action=edit
full stack trace after the issue eventually
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=97025
--- Comment #30 from Fermulator ---
note, experiencing the same (or at least similar) issues -- my story is bug'd
here:
* https://bugs.freedesktop.org/show_bug.cgi?id=107560
--
You are receiving this mail because:
You are the assignee for the
Attached.
If the general idea in the patch is OK I can think of a test (and maybe
add to libdrm amdgpu tests) to actually simulate this scenario with 2 forked
concurrent processes working on same entity's job queue when one is
dying while the other keeps pushing to the same queue. For now I o
On Thu, Aug 02, 2018 at 03:25:24PM +0530, Souptick Joarder wrote:
> On Wed, Aug 1, 2018 at 12:11 AM, Souptick Joarder
> wrote:
> > On Tue, Jul 31, 2018 at 4:04 PM, Liviu Dudau wrote:
> >> Hi Souptick,
> >>
> >> On Tue, Jul 31, 2018 at 12:31:37AM +0530, Souptick Joarder wrote:
> >>> convert drm_a
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #2 from Sylvain BERTRAND ---
I did a lot of testing and dumped cores (libsegfault.so or catchsegv do not
work with steam/dota2), the issue is actually random: sometimes it works, most
of the time it crashes or hangs the vulkan dota2
https://bugs.freedesktop.org/show_bug.cgi?id=107561
Bug ID: 107561
Summary: [amdgpu] / rx550 / half the fps after thaw
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_en
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probi
Latest version of https://patchwork.freedesktop.org/series/46815/ with
some significant improvements:
- I finally figured out a clean way to do this entirely with runtime PM
helpers, no avoiding grabbing refs required!
- Since this new method removes the need for a lot of the other changes
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
drm_fb_helper_hotplug_event()
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
On Mon, 2018-08-13 at 15:11 -0400, Ilia Mirkin wrote:
> On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> > +bool
> > +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> > +{
> > + bool hotplug;
> > +
> > + if (!fbcon)
> > + return false;
> > +
> > +
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
Signed-off-
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
drm_fb_helper_hotplug_event()
Latest version of https://patchwork.freedesktop.org/series/46815/ , with
one small change re: ilia
Lyude Paul (5):
drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement
drm/nouveau: Remove duplicate poll_enable() in pmops_runtime_suspend()
drm/nouveau: Fix deadlock with fb_helper wit
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
drm_kms_helper_poll_en
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector probi
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely avoiding
https://bugzilla.kernel.org/show_bug.cgi?id=200809
Bug ID: 200809
Summary: lightdm/Xorg freezes on startup everytime
Product: Drivers
Version: 2.5
Kernel Version: 4.18.0-rc8
Hardware: x86-64
OS: Linux
Tree: Ma
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 1 -
1 file changed, 1 deleti
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_vga
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Reviewed-by: Karol Herbst
Cc: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --
Does what it says on the label, a lot of these calls are already handled
somewhere else and don't appear to be here for a legitimate reason
anymore.
Lyude Paul (3):
drm/nouveau: Remove useless poll_enable() call in
switcheroo_set_state()
drm/nouveau: Remove useless poll_disable() call in
Hi,
On Mon, Aug 13, 2018 at 02:12:44PM +0300, Tomi Valkeinen wrote:
> On 06/08/18 23:36, Laurent Pinchart wrote:
>
> > The series is based on top of the previously submitted "[PATCH v2 00/21]
> > omapdrm: Rework the HPD-related operations" patch series. For convenience
> > I've
> > pushed it to
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #20 from Jordan L ---
Hi Brad,
Would you happen to have a *full* dmesg and Xorg.0 log of the latest? Generally
that error message shouldn't cause a hang, just that one connector the bios is
reporting isn't mapped/supported properly.
Hi Souptick,
On Monday, 13 August 2018 21:51:31 EEST Souptick Joarder wrote:
> On Mon, Aug 13, 2018 at 10:46 PM, Liviu Dudau wrote:
> > On Thu, Aug 02, 2018 at 03:25:24PM +0530, Souptick Joarder wrote:
> >> On Wed, Aug 1, 2018 at 12:11 AM, Souptick Joarder wrote:
> >>> On Tue, Jul 31, 2018 at 4:0
On Mon, Aug 13, 2018 at 8:25 AM Peter Rosin wrote:
>
> On 2018-08-13 15:59, jacopo mondi wrote:
> > Hi Peter,
> >
> > On Fri, Aug 10, 2018 at 03:03:58PM +0200, Peter Rosin wrote:
> >> This enables more flexible devicetrees. You can e.g. have two output
> >> nodes where one is not enabled, without
When debugfs is disabled, but coredump is turned on, the adreno driver fails to
build:
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:4: error: 'struct msm_gpu_funcs' has
no member named 'show'
.show = adreno_show,
^~~~
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:460:11: note: (near initialization f
The function prototype recently changed, but the patch missed the
second prototype that is used when CONFIG_DEV_COREDUMP is disabled:
drivers/gpu/drm/msm/msm_gpu.c: In function 'recover_worker':
drivers/gpu/drm/msm/msm_gpu.c:461:34: error: passing argument 2 of
'msm_gpu_crashstate_capture' from i
From: Sean Paul
The panel datasheet specifies a 500ms delay after power-down before
re-enabling.
Changes in v2:
- None
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
From: Sean Paul
Order registers by offset and rename bits & masks to match the
datasheet. This makes the driver a bit easier to grok and
cross-reference with the datasheet.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c
From: Sean Paul
We noticed the bridge/panel on our devices stopped working if the
regulator wasn't always-on/boot-on. In an attempt to fix that, I came up
with the following patches. I've sent some of them up to the list
already, but none have landed, so I'll concatonate them in this series
going
From: Sean Paul
Instead of just waiting and hoping, actually poll for the pll lock to be
acquired. As a bonus, this should be significantly faster than the
sleep.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 10 +
From: Sean Paul
This was hand-rolled in the first version, and will surely be useful as
we expand the driver to support more varied use cases.
Changes in v2:
- Change subject prefix s/panel/bridge/
- Downgrade warning in poll function to error message
- Fix DP_EDP_CONFIGURATION_SET write value (
From: Sean Paul
Instead of just waiting 20ms for training to complete, actually poll the
status to ensure training is finished.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 +++-
1 file changed, 11 inserti
From: Sean Paul
This patch adds a 70ms mystery delay to the bridge driver in enable.
By experimentation, it seems like it can go anywhere up until we
initiate semi-auto link training. If we don't have the delay, link
training fails.
I tried to root cause this as best I could, but neither the dat
From: Sean Paul
prepare() is the old-timey way to say pre_enable(). It should be called
before modeset. This fixes an issue where the panel on cheza must have
the regulator always-on/boot-on for it to work.
Changes in v3:
- Added to the set
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
driv
On Mon, Aug 13, 2018 at 08:18:08PM +0200, Sam Ravnborg wrote:
> Hi Nicholas.
>
> On Mon, Aug 13, 2018 at 05:54:48PM +0200, Nicolas Ferre wrote:
> > On 12/08/2018 at 20:41, Sam Ravnborg wrote:
> > >New DRM based driver for at91sam9 SOC's that uses the
> > >Atmel LCDC IP core.
> >
> > I'm delighted
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: 6a77c1ba182d156a8b0b4057e23e8a01d9f451a7
commit: d49f1308cd52389f3ba64b0cd98c7a50ed83932a [62/85] drm/amdgpu:add VCN
booting with firmware loaded by PSP
reproduce:
# apt-get install sparse
git checkout
On Tue, Jul 31, 2018 at 01:11:13AM +0200, Giulio Benetti wrote:
> This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited
>
> Website: www.cdtech-lcd.com
>
> Signed-off-by: Giulio Benetti
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 in
On Tue, Jul 31, 2018 at 01:11:17AM +0200, Giulio Benetti wrote:
> Add documentation for S043WQ26H-CT7 panel
>
> Signed-off-by: Giulio Benetti
> ---
> .../bindings/display/panel/cdtech,s043wq26h-ct7.txt | 12
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/
On Tue, Jul 31, 2018 at 01:11:15AM +0200, Giulio Benetti wrote:
> Add documentation for S070WV95-CT16 panel
>
> Signed-off-by: Giulio Benetti
> ---
> .../bindings/display/panel/cdtech,s070wv95-ct16.txt | 12
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/
https://bugs.freedesktop.org/show_bug.cgi?id=107552
--- Comment #3 from Bas Nieuwenhuizen ---
Even if you cannot get a backtrace, can you bisect to show the exact commit
which causes the issue?
--
You are receiving this mail because:
You are the assignee for the bug.
msm_drm.h file Generated using make headers_install.
Generated from
tree - git://people.freedesktop.org/~airlied/linux
branch - drm-next
commit - 6d08b06e67cd117f6992c46611dfb4ce267cd71e
Remove freedreno/msm/msm_drm.h to maintain only
one copy of msm_drm.h and change freedreno Makefile
and meson.
1 - 100 of 132 matches
Mail list logo
