On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
This is still being tested, but I figured to send it to start getting help
from the xen, amd and hfi drivers which I cannot test here.
Sorry for the delay, I never seen this. Was not on Cc list and didn't
register to me it impacted hfi. I'll take
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #117 from har...@gmx.de ---
...are this craches more frequently with VSYNC enabled?
If yes, it could be the same thing like this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=110777
--
You are receiving this mail because:
You
On Mon, Oct 21, 2019 at 06:54:25PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
>
> > > +/**
> > > + * mmu_range_read_retry - End a read side critical section against a VA
> > > range
> > > + * mrn: The range under lock
> > > + * seq: The return
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so
On Mon, Oct 21, 2019 at 07:24:53PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > > Since that reader is not locked we need release semantics here to
> > > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > > structure when
> In the impelementation of v3d_submit_cl_ioctl() there are two memory leaks.
Please avoid another typo also in this change description.
> … If kcalloc fails to allocate memory for bin then
> render->base should be put. Also, if v3d_job_init() fails to initialize
> bin->base then allocated
Hi all,
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> In file included from
In the implementation of nouveau_bo_alloc() if it fails to determine the
target page size via pi, then the allocated memory for nvbo should be
released.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Signed-off-by: Navid Emamdoost
---
From: "Lowry Li (Arm Technology China)"
Adds gamma and color-transform support for DOU-IPS.
Adds two caps members fgamma_coeffs and ctm_coeffs to komeda_improc_state.
If color management changed, set gamma and color-transform accordingly.
v5: Rebase with drm-misc-next
Signed-off-by: Lowry Li
Hi:
This series enable CRTC color-mgmt for komeda driver, for current komeda HW
which only supports color conversion and forward gamma for CRTC.
This series actually are regrouped from:
- drm/komeda: Enable layer/plane color-mgmt:
https://patchwork.freedesktop.org/series/60893/
- drm/komeda:
This function is for converting drm_color_ctm matrix to komeda hardware
required required Q2.12 2's complement CSC matrix.
v2:
Move the fixpoint conversion function s31_32_to_q2_12() to drm core
as a shared helper.
Signed-off-by: james qian wang (Arm Technology China)
Reviewed-by: Mihail
Hi,
On 20-10-2019 20:19, Hans de Goede wrote:
Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
vblank waits"), I am seeing an ugly colored flash of the first few display
lines on 2 Cherry Trail devices when the gamma table gets set for the first
time. A blue flash on a
On Fri, 18 Oct 2019 17:47:49 +0200
Daniel Vetter wrote:
> On Fri, Oct 18, 2019 at 4:34 PM Pekka Paalanen wrote:
> >
> > On Fri, 18 Oct 2019 16:19:33 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen
> > > wrote:
> > > >
> > > > On Fri, 18 Oct 2019
On 2019/10/21 下午5:36, Cornelia Huck wrote:
On Mon, 21 Oct 2019 13:59:23 +0800
Jason Wang wrote:
On 2019/10/18 下午10:20, Cornelia Huck wrote:
On Thu, 17 Oct 2019 18:48:35 +0800
Jason Wang wrote:
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
In file included from include/uapi/linux/posix_types.h:5,
from include/uapi/linux/types.h:14,
from include/linux/types.h:6,
On Mon, Oct 21, 2019 at 06:57:42PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> > On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > > From: Jason Gunthorpe
> > >
> > > The only two users of this are now converted to use
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases,
backlight flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with
the preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #4 from tempel.jul...@gmail.com ---
Thanks for the hint @ Andrew Sheldon, SPPT being possible on Linux totally
passed me by. Will test it with my cheap Polaris card first, which made me
stick with custom fan curve anyway.
Regarding
On Mon, Oct 21, 2019 at 06:34:25PM +0200, Stephan Gerhold wrote:
> The DSI PHY regulator supports two regulator modes: LDO and DCDC.
> This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
> device tree property.
>
> However, at the moment only the 20nm PHY driver actually
On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_range_start/end and
Le mer. 9 oct. 2019 à 09:13, Benjamin Gaignard
a écrit :
>
> Few for_each macro set variables that are never used later which led
> to generate unused-but-set-variable warnings.
> Add (void)(foo) inside the macros to remove these warnings
>
Gentle ping,
Thanks,
Benjamin
> Signed-off-by:
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Lucky number 13! :)
Last week in v12 I had re-added some symbol exports to support
later patches I have pending to enable loading heaps from
modules. He reminded me that back around v3 (its been awhile!) I
had removed those exports due to concerns about the fact that we
don't support module
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +- reg: Physical base addresses and lengths of the register areas.
> >
> > How many?
>
> I assume there is only one. At
On Mon, Oct 21, 2019 at 01:47:19PM -0400, Sean Paul wrote:
> On Mon, Oct 21, 2019 at 06:34:25PM +0200, Stephan Gerhold wrote:
> > The DSI PHY regulator supports two regulator modes: LDO and DCDC.
> > This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
> > device tree property.
>
e DRIVER_DATE to 20191021 (2019-10-21 12:56:07 +0300)
UAPI Changes:
- Introduce a versioning of the i915-perf uapi (Lionel)
- Add support for perf configuration queries (Lionel)
Allow listing perf configurations with IOCTL in additi
Based on work by Bjorn Andersson
The bridge can be configured to use 1, 2, or 4 DP lanes. This
configuration is independent of the input DSI lanes. Right now, the
driver assumes that there is 1:1 mapping of input lanes to output lanes
which is not correct and does not work for manu devices
On Tue, Oct 15, 2019 at 03:12:30PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_mirror's handling of ranges does not use a sequence count which
> results in this bug:
>
> CPU0 CPU1
>
In the impelementation of v3d_submit_cl_ioctl() there are two memory
leaks. One is when allocation for bin fails, and the other is when bin
initialization fails. If kcalloc fails to allocate memory for bin then
render->base should be put. Also, if v3d_job_init() fails to initialize
bin->base then
* H. Nikolaus Schaller [191021 15:46]:
> > Am 21.10.2019 um 17:07 schrieb Rob Herring :
> > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
> > wrote:
> >> +Optional properties:
> >> +- timer: the timer to be used by the driver.
> >
> > Needs a better description and vendor prefix
On Tue, Oct 15, 2019 at 03:12:29PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Of the 13 users of mmu_notifiers, 8 of them use only
> invalidate_range_start/end() and immediately intersect the
> mmu_notifier_range with some kind of internal list of VAs. 4 use an
> interval tree
On Tue, Oct 15, 2019 at 03:12:31PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Only the function calls are stubbed out with static inlines that always
> fail. This is the standard way to write a header for an optional component
> and makes it easier for drivers that only optionally
On Tue, Oct 15, 2019 at 03:12:28PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead
On Mon, Oct 21, 2019 at 2:36 AM Brian Starkey wrote:
> On Fri, Oct 18, 2019 at 11:26:52AM -0700, John Stultz wrote:
> > On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote:
> > > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote:
> > >
> > > As in v3:
> > >
> > > * Avoid EXPORT_SYMBOL
On Mon, Oct 21, 2019 at 12:03 PM John Stultz wrote:
>
> Lucky number 13! :)
>
> Last week in v12 I had re-added some symbol exports to support
> later patches I have pending to enable loading heaps from
> modules. He reminded me that back around v3 (its been awhile!) I
By "He" I mean Brian here.
https://bugs.freedesktop.org/show_bug.cgi?id=111762
--- Comment #3 from zamundaa...@gmail.com ---
I have the same (or at least a similar) bug.
/sys/class/drm/card1/device/hwmon/hwmon3/power1_cap_max in my case gives the
default 220W (value: 22000).
$ cat
On Mon, Oct 21, 2019 at 03:01:56PM +, Mihail Atanassov wrote:
> I'll be the main point of contact.
>
> Cc: James Qian Wang (Arm Technology China)
> Cc: Liviu Dudau
> Signed-off-by: Mihail Atanassov
Acked-by: Sean Paul
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
>
> Am 21.10.2019 um 19:25 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [191021 15:46]:
>>> Am 21.10.2019 um 17:07 schrieb Rob Herring :
>>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller
>>> wrote:
+Optional properties:
+- timer: the timer to be used by the driver.
On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> The only two users of this are now converted to use mmu_range_notifier,
> delete all the code and update hmm.rst.
I guess i should point out that the reasons for hmm_mirror and hmm
was for:
1) Maybe
This series adds support for CMA/DMA users to skip kernel mappings for
GEM allocations. The DMA API only guarantees a kernel mapping at
allocation time. Creating mappings with vmap() after allocation may or
may not work as not all allocations have a struct page. As virtual
memory space is limited
Hi all,
Casting parameters in debugfs_create_*() calls prevents the compiler
from performing some checks.
Hence this patch series removes superfluous casts, or reworks code to no
longer need the casts.
All patches can be applied independently, there are no dependencies.
Thanks for your
On Mon, Oct 21, 2019 at 02:28:46PM +, Koenig, Christian wrote:
> Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> > On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> >> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> >>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig,
On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote:
> On 10/15/2019 2:12 PM, Jason Gunthorpe wrote:
> > This is still being tested, but I figured to send it to start getting help
> > from the xen, amd and hfi drivers which I cannot test here.
>
> Sorry for the delay, I never seen
On Mon, Oct 21, 2019 at 02:40:41PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> > scif_dma, vhost, gntdev, hmm) drivers are using a
In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
and returns an errno, before returning the allocated memory for fence
should be released.
Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
Signed-off-by: Navid Emamdoost
---
* Adam Ford [191016 06:53]:
> With the removal of the panel-dpi from the omap drivers, the
> LCD no longer works. This patch points the device tree to
> a newly created panel named "logicpd,type28"
>
> Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
>
> Signed-off-by: Adam Ford
>
pon., 21 paź 2019 o 12:45 Daniel Thompson
napisał(a):
>
> On Sat, Oct 19, 2019 at 10:35:50AM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > The GPIO backlight driver currently requests the line 'as is', without
> > acively setting its direction. This can lead to
Hi!
On Tue, 2019-10-22 at 07:44:26 +1100, Stephen Rothwell wrote:
> Fixes tag
>
> Fixes: 7a074e96 ("aio: implement io_pgetevents")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
> Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
> or
On Mon, 07 Oct 2019, Ingo Molnar wrote:
I suppose this will be carried in -mm?
I've just sent out a new patchset for -tip that only modified the pat
tree. It seems that this series will at least take some more time due to
the mmu_notifier rework being done - and there was some worries about
https://bugs.freedesktop.org/show_bug.cgi?id=112008
--- Comment #6 from babblebo...@gmail.com ---
This may be useful to you!
[4.603742] [drm:amdgpu_dm_initialize_drm_device [amdgpu]]
amdgpu_dm_connector_init()
[4.604326] [drm:dm_dp_aux_transfer [amdgpu]] Op: Read, addr: , SideBand
In preparation to allow DRM CMA users to adjust the DMA_ATTR_* flags,
convert the CMA helper code to use the dma_*_attr APIs instead of the
dma_*_wc variants.
Only the DMA_ATTR_WRITE_COMBINE and DMA_ATTR_NO_WARN attributes are set
in this commit, so there's no functional change.
Cc: Maarten
The only reason the Mediatek driver doesn't use the CMA helpers is it
sets DMA_ATTR_NO_KERNEL_MAPPING and does a vmap() on demand. Using
vmap() is not even guaranteed to work as DMA buffers may not have a
struct page. Now that the CMA helpers support setting
DMA_ATTR_NO_KERNEL_MAPPING as needed or
drm_gem_cma_dumb_create_internal() is not supposed to be used for
.dumb_create directly. drm_gem_cma_dumb_create() should be used instead.
If we do that, we might as well convert over to using
DRM_GEM_CMA_VMAP_DRIVER_OPS instead.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Now that we have the DRM_MODE_DUMB_KERNEL_MAP flag to indicate whether
or not a kernel mapping is required, the Rockchip driver can be
converted to using the generic fbdev emulation.
This patch makes full use of the generic fbdev emulation by using its
drm_client callbacks. This means that
Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
drm_mode_create_dumb. This flag is for internal kernel use to indicate
if dumb buffer allocation needs a kernel mapping. This is needed only for
CMA where creating a kernel mapping or not has to be decided at allocation
time because
Add support in CMA helpers to handle callers specifying
DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
change. drm_gem_cma_dumb_create() always creates a kernel mapping as
before. drm_gem_cma_dumb_create_internal() lets the caller set the flags
as desired. Therefore,
Hi all,
[Some people didn't get this due to a typo]
This should have been reported against the vfs-fixes tree, sorry.
On Tue, 22 Oct 2019 08:07:34 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc-fixes tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this
There is no need to cast a typed pointer to a void pointer when calling
a function that accepts the latter. Remove it, as the cast prevents
further compiler checks.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2
On Mon, Oct 21, 2019 at 02:30:56PM -0400, Jerome Glisse wrote:
> > +/**
> > + * mmu_range_read_retry - End a read side critical section against a VA
> > range
> > + * mrn: The range under lock
> > + * seq: The return of the paired mmu_range_read_begin()
> > + *
> > + * This MUST be called under
On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > Since that reader is not locked we need release semantics here to
> > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > structure when it observes the pointer.
>
> I thought the mm_take_all_locks() would
On Sun, Oct 20, 2019 at 02:21:42PM +, Koenig, Christian wrote:
> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> > On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
> >
> >>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
> >>> called while holding
On Wed, Oct 16, 2019 at 06:35:15AM +, Oleksandr Andrushchenko wrote:
> On 10/16/19 8:11 AM, Jürgen Groß wrote:
> > On 15.10.19 20:12, Jason Gunthorpe wrote:
> >> From: Jason Gunthorpe
> >>
> >> DMA_SHARED_BUFFER can not be enabled by the user (it represents a
> >> library
> >> set in the
On Mon, Oct 21, 2019 at 02:38:24PM -0400, Jerome Glisse wrote:
> On Tue, Oct 15, 2019 at 03:12:42PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The only two users of this are now converted to use mmu_range_notifier,
> > delete all the code and update hmm.rst.
>
> I guess i
https://bugzilla.kernel.org/show_bug.cgi?id=204965
--- Comment #3 from David (dav@gmx.com) ---
Thanks for the replies. Yes, looks like a dupe; I'll try to apply the last
patch attached as soon as I've read up on how patch works. You can close this I
guess.
--
You are receiving this mail
Hi Rob,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191021]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
On Tue, 22 Oct 2019 at 01:49, Sean Paul wrote:
>
> On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen wrote:
> >
> > Hi,
> >
> > On 18/10/2019 23:11, Sean Paul wrote:
> > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen
> > > wrote:
> > >>
> > >> Hi Sean,
> > >>
> > >> On 17/10/2019 22:26, Sean
This probably hasn't caused any problems up until now since it's
probably nearly impossible to encounter this in the wild, however if we
were to receive a connection status notification from the MST hub after
resume while we're in the middle of reprobing the link addresses for a
topology then
In order for suspend/resume reprobing to work, we need to be able to
perform sideband communications during suspend/resume, along with
runtime PM suspend/resume. In order to do so, we also need to make sure
that nouveau doesn't bother grabbing a runtime PM reference to do so,
since otherwise we'll
Currently, MST lacks locking in a lot of places that really should have
some sort of locking. Hotplugging and link address code paths are some
of the offenders here, as there is actually nothing preventing us from
running a link address probe while at the same time handling a
connection status
This will allow us to add some locking for port->* members, in
particular the PDT and ->connector, which can't be done from
drm_dp_destroy_port() since we don't know what locks the caller might be
holding.
Note that we already do this in delayed_destroy_work (renamed from
destroy_connector_work
Since we're going to be implementing suspend/resume reprobing very soon,
we need to make sure we are extra careful to ensure that our locking
actually protects the topology state where we expect it to. Turns out
this isn't the case with drm_dp_port_setup_pdt() and
drm_dp_port_teardown_pdt(), both
This is a complicated one. Essentially, there's currently a problem in the MST
core that hasn't really caused any issues that we're aware of (emphasis on "that
we're aware of"): locking.
When we go through and probe the link addresses and path resources in a
topology, we hold no locks when
Once upon a time, hotplugging devices on MST branches actually worked in
DRM. Now, it only works in amdgpu (likely because of how it's hotplug
handlers are implemented). On both i915 and nouveau, hotplug
notifications from MST branches are noticed - but trying to respond to
them causes messaging
We get these warnings when build kernel W=1:
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes]
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no previous
prototype for
On Mon, Oct 21, 2019 at 01:48:35PM -0400, Sean Paul wrote:
> On Mon, Oct 21, 2019 at 03:01:56PM +, Mihail Atanassov wrote:
> > I'll be the main point of contact.
> >
> > Cc: James Qian Wang (Arm Technology China)
> > Cc: Liviu Dudau
> > Signed-off-by: Mihail Atanassov
>
> Acked-by: Sean
When reprobing an MST topology during resume, we have to account for the
fact that while we were suspended it's possible that mstbs may have been
removed from any ports in the topology. Since iterating downwards in the
topology requires that we hold >lock, destroying MSTBs from this
context would
This is the final portion of the large series for adding MST
suspend/resume reprobing that I've been working on for quite a while
now. In addition, I:
* Refactored and cleaned up any code I ended up digging through in the
process of understanding how some parts of these helpers worked.
* Added
Currently, every single piece of code in amdgpu that loops through
connectors does it incorrectly and doesn't use the proper list iteration
helpers, drm_connector_list_iter_begin() and
drm_connector_list_iter_end(). Yeesh.
So, do that.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v3:
* Fix typo in comments
Cc: Juston Li
Cc: Imre
For very subtle mistakes with topology refs, it can be rather difficult
to trace them down with the debugging info that we already have. I had
one such issue recently while trying to implement suspend/resume
reprobing for MST, and ended up coming up with this.
Inspired by Chris Wilson's wakeref
Finally! For a very long time, our MST helpers have had one very
annoying issue: They don't know how to reprobe the topology state when
coming out of suspend. This means that if a user has a machine connected
to an MST topology and decides to suspend their machine, we lose all
topology changes
Does what it says on the tin.
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 59 +--
1 file changed, 29 insertions(+), 30 deletions(-)
Currently, we enable hotplug detection only after we re-enable the
display. However, this is too late if we're planning on sending sideband
messages during the resume process - which we'll need to do in order to
reprobe the topology on resume.
So, enable hotplug events before reinitializing the
101 - 187 of 187 matches
Mail list logo
