https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #12 from csp...@verizon.net ---
One thing to note, the problem doesn't seem to occur for me if a compositor
isn't running. In my case, after disabling compton I could not reproduce the
problem.
--
You are receiving this mail
On Fri, Aug 02, 2019 at 02:15:42PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: omap1_defconfig arm):
>
> drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may
> fall
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #100 from Diego Viola ---
(In reply to Michel Dänzer from comment #99)
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes
> for DPBB, might help for this as well.
Unfortunately it doesn't help, I compiled
Hi Sasha,
It's probably best *not* to backport this patch.. drm/msm abuses the
DMA API in a way that it is not intended be used, to work around the
lack of cache sync API exported to kernel modules on arm/arm64. I
couldn't really guarantee that this patch does the right thing on
older versions
On Thu, 2019-08-01 at 19:19 -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 01 Aug 2019 22:34:16 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204407
>
> Bug ID: 204407
>Summary: Bad page
https://bugs.freedesktop.org/show_bug.cgi?id=109538
--- Comment #2 from tempel.jul...@gmail.com ---
Doesn't crash anymore, but there is still a garbled line at the bottom of video
frames.
--
You are receiving this mail because:
You are the assignee for the
On Fri, 2 Aug 2019 13:57:27 -0600
Rob Herring wrote:
> There's a few features the driver supports which we forgot to remove, so
> remove them now.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
Reviewed-by: Boris Brezillon
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/panfrost/TODO |
There's a few features the driver supports which we forgot to remove, so
remove them now.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/TODO | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/TODO
Increment the driver version to expose the new BO allocation flags.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1
Executable buffers have an alignment restriction that they can't cross
16MB boundary as the GPU program counter is 24-bits. This restriction is
currently not handled and we just get lucky. As current userspace
assumes all BOs are executable, that has to remain the default. So add a
new
The midgard/bifrost GPUs need to allocate GPU heap memory which is
allocated on GPU page faults and not pinned in memory. The vendor driver
calls this functionality GROW_ON_GPF.
This implementation assumes that BOs allocated with the
PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of
In preparation to handle mapping of page faults, we need the MMU handler
to be threaded as code paths take a mutex.
As the IRQ may be shared, we can't use the default handler and must
disable the MMU interrupts locally.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
This series adds new BO allocation flags PANFROST_BO_HEAP and
PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults.
Tomeu reports he has tested this in the panfrost CI.
This is based on drm-misc-next. An updated branch is here[1].
v3:
- Retain shared irq support, splitting
Setting the GPU VA when creating the GEM object doesn't allow for any
conditional adjustments. In preparation to support adjusting the
mapping, restructure the GEM object creation to map the GEM object after
we've created the base shmem object.
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin
Panfrost has a need for pages allocated on demand via GPU page faults.
When releasing the pages, the only thing preventing using
drm_gem_put_pages() is needing to skip over unpopulated pages, so allow
for skipping over NULL struct page pointers.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean
In preparation to create partial GPU mappings of BOs on page faults,
split out the SG list handling of panfrost_mmu_map().
Cc: Tomeu Vizoso
Cc: Boris Brezillon
Cc: Robin Murphy
Cc: Steven Price
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
If a driver does its own management of pages, the shmem helper object's
pages array could be allocated when a SG table is not. There's not
really any good reason to tie putting pages with having a SG table when
freeing the object, so just put pages if the pages array is populated.
Cc: Maarten
On Fri, Aug 02, 2019 at 11:46:16AM -0700, Douglas Anderson wrote:
> In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
> resume to be early but left suspend at its normal time. This seems
> like it could be OK, but casues problems if a suspend gets interrupted
> partway through.
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning (Building: omap1_defconfig arm):
drivers/video/fbdev/omap/omapfb_main.c:449:23: warning: this statement may fall
through [-Wimplicit-fallthrough=]
drivers/video/fbdev/omap/omapfb_main.c:1549:6:
https://bugzilla.kernel.org/show_bug.cgi?id=204391
--- Comment #2 from Haxk20 (haxk...@gmail.com) ---
Can somebody look at this please ? I know this isnt experience breaking but
when the driver has support for overclocking then it should at least work.
--
You are receiving this mail because:
Hi Linus,
Dave sends his pull, everyone realizes they've been asleep at the wheel
and hits send on their own pulls :-/ Normally I'd just ignore these all
because w/e for me and Dave. But this time around the latecomers also
included drm-intel-fixes, which failed to send out a -fixes pull thus far
In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved
resume to be early but left suspend at its normal time. This seems
like it could be OK, but casues problems if a suspend gets interrupted
partway through. The OS only balances matching suspend/resume levels.
...so if suspend was
Hi,
On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
>
> Signed-off-by: Lucas Stach
> ---
>
https://bugs.freedesktop.org/show_bug.cgi?id=111021
--- Comment #7 from erhar...@mailbox.org ---
Created attachment 144933
--> https://bugs.freedesktop.org/attachment.cgi?id=144933=edit
kernel dmesg (5.3-rc2)
[...]
[ 214.315038] cp queue preemption time out
[ 214.315406] Resetting wave
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144833|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144832|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Summary|[kernel 5.2.1][amdgpu][CIK] |[kernel 5.2.1][amdgpu][CIK]
Hi,
On Fri, Aug 02, 2019 at 04:21:53PM +0200, Philipp Zabel wrote:
> Hi Guido,
>
> On Fri, 2019-08-02 at 15:39 +0200, Guido Günther wrote:
> > Hi Lucas,
> > On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> > > This allows to decouple the cmdbuf suballocator create and mapping
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #11 from csp...@verizon.net ---
@Samuele Yes, after redoing the bisect I got the same result as you did.
Thanks.
--
You are receiving this mail because:
You are the assignee for the
On Fri, Aug 2, 2019 at 9:24 AM Sasha Levin wrote:
>
> From: Rob Clark
>
> [ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
>
Hi Sasha,
FYI, this commit should be paired with
https://cgit.freedesktop.org/drm/drm/commit/?h=drm-fixes=3de433c5b38af49a5fc7602721e2ab5d39f1e69c
Sean
>
On Fri, Aug 2, 2019 at 12:33 PM Koenig, Christian
wrote:
>
>
> Am 02.08.2019 18:28 schrieb Jason Ekstrand :
>
> On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
> wrote:
>
> Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> > Just had a few exchanges with Chris about this.
> > Chris suggests
This patch only brings the syncobj documentation up-to-date for the
original form of syncobj. It does not contain any information about the
design of timeline syncobjs.
---
drivers/gpu/drm/drm_syncobj.c | 81 +++
1 file changed, 73 insertions(+), 8 deletions(-)
Am 02.08.2019 18:28 schrieb Jason Ekstrand :
On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
mailto:christian.koe...@amd.com>> wrote:
Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> Just had a few exchanges with Chris about this.
> Chris suggests that if we're about to add a point to the
Allow the mapping code to request a specific virtual address for the gem
mapping. If the virtual address is zero we fall back to the old mode of
allocating a virtual address for the mapping.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
Hi all,
this implements the last missing bits for softpin aka putting userspace
in charge of the GPU virtual address space. This builds on top of the
per-process address space series. As this is quite a stack of patches
now, I'm providing a git branch [1] with all the necessary patches.
Please
With softpin we allow the userspace to take control over the GPU virtual
address space. The new capability is relected by a bump of the minor DRM
version. There are a few restrictions for userspace to take into
account:
1. The kernel reserves a bit of the address space to implement zero page
With per-process address spaces in place, a rogue process submitting
bogus command streams can only hurt itself. There is no need to
validate the command stream before execution anymore.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 ++-
1 file changed, 2
From: Emil Velikov
As mentioned by Christian, for drivers which support only primary nodes
this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
For others, this check in particular will be a noop. So let's remove it
as suggested by Christian.
Cc: Alex Deucher
Cc:
From: Emil Velikov
Realistically no drivers, but vmwgfx care about the DRM_AUTH flag here.
Follow-up work in this driver will properly isolate primary clients from
different master realms, thus we'll no longer need to parse _any_ ioctl
flags.
Until that work lands, add a local workaround.
v2:
On Wed, Jul 31, 2019 at 11:40 PM Gerd Hoffmann wrote:
>
> On Wed, Jul 31, 2019 at 07:25:13PM -0700, Gurchetan Singh wrote:
> > The main use for udmabuf is sending guest memory pages
> > to the host.
> >
> > It's generally a bad idea to have to separate mappings with
> > different attributes. For
Prior to making the syncobj lookup lockless, update the idr to the new
XArray API.
Based on a patch by Matthew Wilcox
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 64 ++-
include/drm/drm_file.h| 7 ++--
2 files changed, 21
Relax the spinlock used for looking up the handle in the XArray and
acquiring a reference to it to an RCU protected critical section. This
incurs the requirement that we protect the syncobj struct itself using
RCU, which we achieve by simply calling kfree_rcu() and being more
careful in acquiring
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #99 from Michel Dänzer ---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1554 has some fixes for
DPBB, might help for this as well.
--
You are receiving this mail because:
You are the assignee for the
On Thu, Aug 1, 2019 at 9:05 AM Koenig, Christian
wrote:
> Am 01.08.19 um 15:45 schrieb Lionel Landwerlin:
> > Just had a few exchanges with Chris about this.
> > Chris suggests that if we're about to add a point to the timeline in
> > an unordered fashion, actually better not add it at all.
> >
https://bugs.freedesktop.org/show_bug.cgi?id=111243
jacque8...@gmail.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111287
Bug ID: 111287
Summary: Box crashes some time after installation
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
>
> On 02.08.19 07:48, John Hubbard wrote:
> > On 8/1/19 9:36 PM, Juergen Gross wrote:
> >> On 02.08.19 04:19, john.hubb...@gmail.com wrote:
> >>> From: John Hubbard
> > ...
> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index
> >>> 2f5ce7230a43..29e461dbee2d 100644
> >>> ---
Hi Jani.
> >> I mean is it useful to have this extra printing subsystem in DRM while
> >> the standard Linux one actually does a better job?
> > The added functionality of drm_xxx_err would be to keep the current
> > drm.debug=0x1f filtering on the command-line.
> > I do not think we can do this
On Fri, Aug 02, 2019 at 05:33:11PM +0900, Inki Dae wrote:
> Hi Dave,
>
>Just two fixups which fixes undefined reference error with NOMMU
>configuration and potential infinite issue of scaler module,
>and two trivial cleanups.
>
>Please kindly let me know if there is any problem.
On Fri, Aug 02, 2019 at 03:43:48PM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Bit late, but fixes for v5.3-rc3. :)
Yes, please try to prep and send out -fixes pull on Thu latest. Otherwise
there's no time to fix things up and it eats into w/e ...
>
> drm-misc-fixes-2019-08-02:
> drm-misc-fixes
On Fri, Aug 02, 2019 at 10:18:10AM -0400, Sean Paul wrote:
> On Thu, Aug 01, 2019 at 01:44:58PM +0100, Chris Wilson wrote:
> > commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> > broke all of the !llc i915-vgem coherency tests in CI, and left the HW
> > very, very unhappy
On Fri, Aug 2, 2019 at 4:50 PM Liviu Dudau wrote:
>
> On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> > > > Komeda has support
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > > [...]
> > > > 2) Convert all of the call sites for get_user_pages*(), to
On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> >
> > Hi Liviu,
> >
> > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
> > > Komeda has support to generate per-frame CRC values in the DOU
> > > backend
The 'memory-region' property of the komeda display driver DT binding
allows the use of a 'reserved-memory' node for buffer allocations. Add
the requisite of_reserved_mem_device_{init,release} calls to actually
make use of the memory if present.
Signed-off-by: Mihail Atanassov
---
On Thu, Aug 01, 2019 at 07:19:57PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide
Hi Guido,
On Fri, 2019-08-02 at 15:39 +0200, Guido Günther wrote:
> Hi Lucas,
> On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> > This allows to decouple the cmdbuf suballocator create and mapping
> > the region into the GPU address space. Allowing multiple AS to share
> > a single
Den 01.08.2019 21.43, skrev David Lechner:
> On 8/1/19 8:52 AM, Noralf Trønnes wrote:
>> Move the driver to drm/panel and take advantage of the new panel support
>> in drm_mipi_dbi. Change the file name to match the naming standard in
>> drm/panel. The DRM driver name is kept since it is ABI.
>>
On Thu, Aug 01, 2019 at 01:44:58PM +0100, Chris Wilson wrote:
> commit 7e9e5ead55be ("drm/vgem: fix cache synchronization on arm/arm64")
> broke all of the !llc i915-vgem coherency tests in CI, and left the HW
> very, very unhappy (which is even more scary).
>
> Fixes: 7e9e5ead55be ("drm/vgem:
Den 01.08.2019 21.10, skrev David Lechner:
> On 8/1/19 8:52 AM, Noralf Trønnes wrote:
>> Add support for panels that use the DPI interface.
>> ILI9341 has onboard RAM so the assumption made here is that all such
>> panels support pixel upload over DBI.
>>
>> The presence/absense of the Device
On Fri, Aug 02, 2019 at 10:13:03AM +, Brian Starkey wrote:
> Hi Daniel,
>
> On Fri, Aug 02, 2019 at 11:52:11AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:39 AM Brian Starkey wrote:
> > >
> > > Hi Liviu,
> > >
> > > On Thu, Aug 01, 2019 at 11:42:31AM +0100, Liviu Dudau wrote:
>
On Fri, Aug 02, 2019 at 10:09:05AM +, Brian Starkey wrote:
> Hi Daniel,
>
> On Fri, Aug 02, 2019 at 11:45:13AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter wrote:
> > >
> > > On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey
> > > wrote:
> > > >
> > > > Hi
Quoting Sergey Senozhatsky (2019-08-02 14:49:55)
> On (08/02/19 14:41), Chris Wilson wrote:
> [..]
> > struct vfsmount *kern_mount(struct file_system_type *type)
> > {
> > struct vfsmount *mnt;
> > mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
> > if
On (08/02/19 14:41), Chris Wilson wrote:
[..]
> struct vfsmount *kern_mount(struct file_system_type *type)
> {
> struct vfsmount *mnt;
> mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
> if (!IS_ERR(mnt)) {
> /*
> * it is a
On Mon, 29 Jul 2019, Sam Ravnborg wrote:
> Hi Christian.
>
> On Mon, Jul 29, 2019 at 03:28:15PM +, Koenig, Christian wrote:
>> Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
>> Even then it so useless (which drm driver is this message for???) that I
>> want to remove them all :(
>> >>>
Hey,
Bit late, but fixes for v5.3-rc3. :)
drm-misc-fixes-2019-08-02:
drm-misc-fixes for v5.3-rc3:
- Fix some build errors in drm/bridge.
- Do not build i810 on CONFIG_PREEMPTION.
- Fix cache sync on arm in vgem.
- Allow mapping fb in drm_client only when required, and use it to fix bochs
fbdev.
Quoting Sergey Senozhatsky (2019-08-02 14:35:03)
> On (08/02/19 22:15), Sergey Senozhatsky wrote:
> [..]
> > > > Looking around, it looks like we always need to drop type after
> > > > mounting. Should the
> > > > put_filesystem(type);
> > > > be here instead?
> > > >
> > > > Anyway, nice
Hi Lucas,
On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> This allows to decouple the cmdbuf suballocator create and mapping
> the region into the GPU address space. Allowing multiple AS to share
> a single cmdbuf suballoc.
Can you tell me where this would apply? I tried 5.2 and
Hi,
> I apologize for not having fixes for a couple of weeks, and then showing
> up late with a bunch of them. I saw Dave make the fixes pull to Linus
> for -rc3 already, but I must humbly ask you to accommodate an extra
> fixes pull.
If there is an extra -rc3 fixes pull anyway it would be
On (08/02/19 22:15), Sergey Senozhatsky wrote:
[..]
> > > Looking around, it looks like we always need to drop type after
> > > mounting. Should the
> > > put_filesystem(type);
> > > be here instead?
> > >
> > > Anyway, nice catch.
> >
> > Sigh. put_filesystem() is part of fs internals.
https://bugs.freedesktop.org/show_bug.cgi?id=111244
Samuele Decarli changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=22
Samuele Decarli changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #10 from Samuele Decarli ---
Interestingly the same commit is blamed for anther issue
https://bugs.freedesktop.org/show_bug.cgi?id=22
--
You are receiving this mail because:
You are the assignee for the
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Qian Cai
[ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ]
The "struct drm_connector" iteration cursor from
"for_each_new_connector_in_state" is never used in atomic_remove_fb()
which generates a compilation warning,
drivers/gpu/drm/drm_framebuffer.c: In function
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Alvin Lee
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]
[Why]
In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
From: Qian Cai
[ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ]
The "struct drm_connector" iteration cursor from
"for_each_new_connector_in_state" is never used in atomic_remove_fb()
which generates a compilation warning,
drivers/gpu/drm/drm_framebuffer.c: In function
From: Tai Man
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]
[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.
[How]
Incraese the audios array
From: Julian Parkin
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]
[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.
We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
From: SivapiriyanKumarasamy
[ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ]
[WHY]
Currently we don't wait for blacklight programming completion in DMCU
when setting backlight level. Some sequences such as PSR static screen
event trigger reprogramming requires it to be complete.
From: Tai Man
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]
[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 & id 5 to fail when finding corresponding
From: Qian Cai
[ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ]
The "struct drm_connector" iteration cursor from
"for_each_new_connector_in_state" is never used in atomic_remove_fb()
which generates a compilation warning,
drivers/gpu/drm/drm_framebuffer.c: In function
From: Shubhashree Dhar
[ Upstream commit 2e7b801eadbf327bf61041c943e5c44a5de4b0e5 ]
dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part of modeset init.
Signed-off-by: Shubhashree Dhar
[seanpaul resolved conflict in old init removal
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #9 from Samuele Decarli ---
Created attachment 144929
--> https://bugs.freedesktop.org/attachment.cgi?id=144929=edit
Kernel log displaying issue
Compressed here is my kernel log, which shows repeating stack traces
--
You are
From: Zi Yu Liao
[ Upstream commit 1ca068ed34d6b39d336c1b0d618ed73ba8f04548 ]
[why]
When the system is going into suspend, set_backlight gets called
after the eDP got blanked. Since smooth brightness is enabled,
the driver will make a call into the DMCU to ramp the brightness.
The DMCU would
From: Murton Liu
[ Upstream commit 492d9ec244923420af96db6b69ad7d575859aa92 ]
[why]
We reset the optimized_required in atomic_plane_disable
flag immediately after it is set in atomic_plane_disconnect, causing us to
never have flag set during next flip in UpdatePlanes.
[how]
Optimize directly
From: Tai Man
[ Upstream commit 7352193a33dfc9b69ba3bf6a8caea925b96243b1 ]
[Why]
The audios array defined in "struct resource_pool" is only 6 (MAX_PIPES)
but the max number of audio devices (num_audio) is 7. In some projects,
it will run out of audios array.
[How]
Incraese the audios array
From: Tai Man
[ Upstream commit 74eda776d7a4e69ec7aa1ce30a87636f14220fbb ]
[Why]
On some platforms, the encoder id 3 is not populated. So the encoders
are not stored in right order as index (id: 0, 1, 2, 4, 5) at pool. This
would cause encoders id 4 & id 5 to fail when finding corresponding
From: Alvin Lee
[ Upstream commit 6ac25e6d5b2fbf251e9fa2f4131d42c815b43867 ]
[Why]
In dm_helpers_parse_edid_caps, there is a corner case where no speakers
can be allocated even though the audio mode count is greater than 0.
Enabling audio when no speaker allocations exists can cause issues in
From: SivapiriyanKumarasamy
[ Upstream commit c7990daebe71d11a9e360b5c3b0ecd1846a3a4bb ]
[WHY]
Currently we don't wait for blacklight programming completion in DMCU
when setting backlight level. Some sequences such as PSR static screen
event trigger reprogramming requires it to be complete.
From: Eric Yang
[ Upstream commit feb7eb522e0a7a22c1e60d386bd3c3bfa1d5e4f7 ]
[Why]
Seamless boot optimization removed proper front end power off sequence.
In driver disable enable case, this causes driver to power gate hubp
and dpp while there is still memory fetching going on, this can cause
From: Harmanprit Tatla
[ Upstream commit 5b25e5f1a97284020abee7348427f89abdb674e8 ]
[Why]
There are certain MST displays (i.e. Dell P2715Q)
that although have the MST feature set to off may still
report it is a branch device and a non-zero
value for downstream port present.
This can lead to us
From: Derek Lai
[ Upstream commit 67fd6c0d2de8e51e84ff3fa6e68bbd524f823e49 ]
[Why]
Driver will create 0, 1, and 2 ddc engines for RV2,
but some platforms used 0, 1, and 3.
[How]
Still allocate 4 ddc engines for RV2.
Signed-off-by: Derek Lai
Reviewed-by: Aric Cyr
Acked-by: Leo Li
From: Julian Parkin
[ Upstream commit 0905f32977268149f06e3ce6ea4bd6d374dd891f ]
[Why]
It is possible (but very unlikely) that constructing dc fails
before current_state is created.
We support 666 color depth in some scenarios, but this
isn't handled in get_norm_pix_clk. It uses exactly the
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #8 from Samuele Decarli ---
Created attachment 144928
--> https://bugs.freedesktop.org/attachment.cgi?id=144928=edit
Result of git bisect
Model: HP EliteBook 745 G5
CPU/GPU: AMD Ryzen 7 PRO 2700U
I completed my bisection and
On 01/08/2019 11:02, Tomi Valkeinen wrote:
Hi JJ,
On 08/07/2019 13:45, Jean-Jacques Hiblot wrote:
A first version of this work had been sent by Tomi Valkeinen in may 2017
(https://www.spinics.net/lists/dri-devel/msg140663.html).
This series adds a few new OMAP_BO flags to help the userspace
1 - 100 of 261 matches
Mail list logo
