If we don't initialize the entity to idle and the entity is never
scheduled before being destroyed we end up with an infinite wait in the
destroy path.
v2:
- Add Steven's R-b
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
This is something I noticed while debugging another issue o
Hi Alex,
adding Daniel as well.
Am 01.10.20 um 20:45 schrieb Alex Goins:
Hi Christian,
On Thu, 1 Oct 2020, Christian König wrote:
Hi Alex,
first of all accessing the underlying page of an exported DMA-buf is
illegal! So I'm not 100% sure what you're intentions are here, please
explain furth
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-randconfig-a003-20201001 (attached as .config
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
between commit:
b19515253623 ("drm/amd/pm: setup APU dpm clock table in SMU HW
initialization")
from the Linus tree and commits:
82cac71c1b64 ("drm/amd/pm: put Navi1X umc cdr w
Add support to capture the drm atomic state snapshot which
can then be wired up with the devcoredump of the relevant display
errors to give useful information to debug the issues.
Since the devcoredump is read by usermode and it is allowed
upto 5 minutes to read the coredump, capturing the snapsho
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #6 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
Created attachment 292755
--> https://bugzilla.kernel.org/attachment.cgi?id=292755&action=edit
Full Xorg resume fail output for kernel 5.8.12
Here is the Xorg.0.log log outp
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #5 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
Created attachment 292753
--> https://bugzilla.kernel.org/attachment.cgi?id=292753&action=edit
Full dmesg resume fail output for kernel 5.8.12
I suspended my computer during
On Wed, Sep 30, 2020 at 08:27:04PM -0400, Jonathan Marek wrote:
> Add a new cache mode for creating coherent host-cached BOs.
Reviewed-by: Jordan Crouse
> Signed-off-by: Jonathan Marek
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
> drivers/gpu/drm/msm/msm_drv.h | 1 +
On Wed, Sep 30, 2020 at 08:27:05PM -0400, Jonathan Marek wrote:
> This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
> which otherwise doesn't provide any method for cleaning/invalidating the
> cache to sync with the device.
>
> Signed-off-by: Jonathan Marek
> ---
> driver
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: f542d671ffcec772a561cd41c7e2394392d9dafb
commit: f542d671ffcec772a561cd41c7e2394392d9dafb [14/14] drm/i915: Init lspcon
after HPD in intel_dp_detect()
config: x86_64-rhel (attached as .config)
compiler: gcc-9 (Debian 9.3
On Tue, Sep 29, 2020 at 9:46 PM Chris Goldsworthy
wrote:
>
> On 2020-09-25 21:24, John Stultz wrote:
> > Reuse/abuse the pagepool code from the network code to speed
> > up allocation performance.
> >
> > This is similar to the ION pagepool usage, but tries to
> > utilize generic code instead of a
Patch series covers following thigns:
1. Split and differentiate between EHL and JSL platfrom
2. Update voltage swing table for eDP on JSL platform
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
- Rebased to drm master commit
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
- Changes rebased as per new drm top commit
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced wit
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
https://bugzilla.kernel.org/show_bug.cgi?id=209417
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Please change the component to Video(DRI - Intel)
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-
https://bugzilla.kernel.org/show_bug.cgi?id=209417
Juan (juantxor...@gmail.com) changed:
What|Removed |Added
CC||juantxor...@gmail.com
---
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #4 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
You are correct, the restored 5.8.5 dmesg output doesn't have the full output
either, and it's the only other output I can find in my backups. I apologize
for my error.
Unfo
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Looks like you attached the wrong file? Can you elaborate on how you use your
GPUs? If you take vfio out of the picture, do you still have the issues?
--
You are receiving this mail
Hi Christian,
On Thu, 1 Oct 2020, Christian König wrote:
> Hi Alex,
>
> first of all accessing the underlying page of an exported DMA-buf is
> illegal! So I'm not 100% sure what you're intentions are here, please
> explain further.
We have some mapping requirements that I was hoping I could add
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #2 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
Created attachment 292741
--> https://bugzilla.kernel.org/attachment.cgi?id=292741&action=edit
Resume failure, full dmesg output from kernel 5.8.5
The last full dmesg output
On Thu, Oct 1, 2020 at 7:49 AM Chris Goldsworthy
wrote:
> On 2020-09-29 21:46, Chris Goldsworthy wrote:
> > On 2020-09-25 21:24, John Stultz wrote:
> >> Reuse/abuse the pagepool code from the network code to speed
> >> up allocation performance.
> >>
> >> This is similar to the ION pagepool usage,
On Thu, Oct 1, 2020 at 7:53 PM Sam Ravnborg wrote:
>
> Hi Karol.
>
> On Thu, Oct 01, 2020 at 01:36:52PM +0200, Karol Herbst wrote:
> > On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote:
> > >
> > > Hi everybody,
> > >
> > > I think it's time to finally move our wiki from the old infrastructure
Hi Daniel,
I was finally able to test the driver with 5.9 kernel with minor changes in the
driver.
Ran the igt_vblank test and it passed/skipped all the subtests except the
pipe-A-accuracy-idle test.
Results are attached. Investigated the failing test and it seems like
drm_handle_vblank() is ta
https://bugzilla.kernel.org/show_bug.cgi?id=209457
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #74 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
(In reply to Lahfa Samy from comment #73)
> (In reply to Robert M. Muncrief from comment #72)
> > (In reply to Alex Deucher from comment #71)
> > > The original issue reported
Hi Karol.
On Thu, Oct 01, 2020 at 01:36:52PM +0200, Karol Herbst wrote:
> On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote:
> >
> > Hi everybody,
> >
> > I think it's time to finally move our wiki from the old infrastructure
> > over to gitlab pages.
> >
> > This comes with several benefits:
>
The pull request you sent on Thu, 1 Oct 2020 16:10:22 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-01-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fcadab740480e0e0e9fa9bd272acd409884d431a
Thank you!
--
Deet-doot-dot, I am a bot.
https://
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #73 from Lahfa Samy (s...@lahfa.xyz) ---
(In reply to Robert M. Muncrief from comment #72)
> (In reply to Alex Deucher from comment #71)
> > The original issue reported in this bug was fixed long ago. If you are
> > having issues, ple
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #72 from Robert M. Muncrief (rmuncr...@humanavance.com) ---
(In reply to Alex Deucher from comment #71)
> The original issue reported in this bug was fixed long ago. If you are
> having issues, please file a new report.
I just filed
https://bugzilla.kernel.org/show_bug.cgi?id=209457
Bug ID: 209457
Summary: AMDGPU resume fail with RX 580 GPU
Product: Drivers
Version: 2.5
Kernel Version: 5.8.12 to 5.9-rc6
Hardware: x86-64
OS: Linux
Tree: Ma
On Wed, Jun 10, 2020 at 03:55:10PM +0800, Kai-Heng Feng wrote:
> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> becomes useless and never responds to cable hotplugging:
> [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [3.031945] [drm:intel_dd
On 01/10/2020 16:49, Boris Brezillon wrote:
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled
On Thu, Oct 01, 2020 at 10:25:06AM +0200, Thomas Gleixner wrote:
> On Thu, Oct 01 2020 at 10:17, Joonas Lahtinen wrote:
> > Quoting paul...@kernel.org (2020-09-29 02:30:58)
> >> CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
> >> removed. Cleanup the leftovers before doing so.
> >
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangl
On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote:
>
> On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > The android userspace treats the display pipeline as a realtime problem.
> > > And arguably,
On Wed, Sep 30, 2020 at 03:47:06PM +0200, Stefan Joosten wrote:
> The fix of flagging state->modeset whenever distrust_bios_wm is set
> causes a regression when initializing display(s) attached to a Lenovo
> USB-C docking station. The display remains blank until the dock is
> reattached. Revert to
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangl
On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote:
>
> On Wed, Sep 30, 2020 at 11:16 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > The android userspace treats the display pipeline as a realtime problem.
> > And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> > it i
On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula wrote:
>
> On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
> >>
> >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> >> > Hi all,
> >> >
> >> > Today's linux-next merge of the akp
On Thu, 01 Oct 2020, Daniel Vetter wrote:
> On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
>>
>> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > Today's linux-next merge of the akpm tree got a conflict in:
>> >
>> > drivers/gpu/drm/i915/gem/i915
On 01/10/2020 15:12, Boris Brezillon wrote:
If we don't initialize the entity to idle and the entity is never
scheduled before being destroyed we end up with an infinite wait in the
destroy path.
Signed-off-by: Boris Brezillon
This seems reasonable to me - it looks like in theory if you very
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #71 from Alex Deucher (alexdeuc...@gmail.com) ---
The original issue reported in this bug was fixed long ago. If you are having
issues, please file a new report.
--
You are receiving this mail because:
You are watching the assignee
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but sti
On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote:
>
> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> >
> > between commit:
> >
> > 4caf0
If we don't initialize the entity to idle and the entity is never
scheduled before being destroyed we end up with an infinite wait in the
destroy path.
Signed-off-by: Boris Brezillon
---
This is something I noticed while debugging another issue on panfrost
causing the scheduler to be in a weird s
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but still blocks something in scheduler
thus leading
Oops, the prefix should be "drm/panfrost", will fix that in v2.
On Thu, 1 Oct 2020 16:01:43 +0200
Boris Brezillon wrote:
> If more than two or more jobs end up timeout-ing concurrently, only one
> of them (the one attached to the scheduler acquiring the lock) is fully
> handled. The other one r
Hi Dave,
Can you pick this up to drm-next? Fixes the x64 build warnings for the recent
cdns-mhdp-5.10 pull.
Tomi
On 29/09/2020 12:19, Tomi Valkeinen wrote:
> On x64 we get:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
> conversion from 'long unsigned int' to 'unsi
On 01/10/2020 12:25, Daniel Vetter wrote:
On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote:
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
As committer/maintainer for this please indicate whether you'll
On Fri, Sep 25, 2020 at 11:27 PM Karol Herbst wrote:
>
> Hi everybody,
>
> I think it's time to finally move our wiki from the old infrastructure
> over to gitlab pages.
>
> This comes with several benefits:
> * full control through git over the ikiwiki pipeline (setup files,
> plugins, system pac
This is not something drivers should use.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++-
{include => drivers/gpu}/drm/ttm/ttm_set_memory.h | 0
3 files changed, 4 insertions(+), 2 deletions(
Changing the caching on the fly never really worked
flawlessly.
So stop this completely and just let drivers specific the
desired caching in the tt or bus object.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm
And implement setting it up correctly in the drivers.
This allows getting rid of the placement flags for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 11
Instead of the placement flags use the caching of the bus
mapping or tt object for the page protection flags.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 23 ++-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c |
Remove unused parameters, shorten the function name.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
inde
Not used any more.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_tt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 91691240a509..5d1835d44084 100644
--- a/include/drm/ttm/ttm_tt.h
+++ b/include/drm/ttm/ttm_tt.h
@@ -34,7 +34
Cleanup the enum name and its values and give it a separate header file.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 -
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drivers/gpu/drm/nouveau/nouvea
On Thu, Oct 1, 2020 at 12:58 PM Steven Price wrote:
>
> On 21/09/2020 14:10, Qinglang Miao wrote:
> > Simplify the return expression.
> >
> > Signed-off-by: Qinglang Miao
>
> Reviewed-by: Steven Price
As committer/maintainer for this please indicate whether you'll merge
this or not, with just a
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_de
On 21/09/2020 14:10, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_de
On Thu, Oct 01, 2020 at 12:57:46PM +0300, Tomi Valkeinen wrote:
> Hi Dave,
>
> Can you pick this up to drm-next? Fixes the x64 build warnings for the recent
> cdns-mhdp-5.10 pull.
Applied, hopefully that's fast enough before sfr does the next round of
linux-next.
-Daniel
>
> Tomi
>
> On 29/0
Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_pages.c
between commit:
4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is
not supported
Hi all,
On Wed, 23 Sep 2020 13:36:01 +1000 Stephen Rothwell
wrote:
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
> 'cdns_mhdp_fw_activate':
> drivers/gpu/drm/bridge/ca
I don't see the patch, can you point me to it?
Thanks,
Christian.
Am 01.10.20 um 07:25 schrieb Dave Airlie:
Tracked it down to my init mem type changes, patch is on the list.
Dave.
On Wed, 30 Sep 2020 at 18:28, Christian König wrote:
That sounds like the same problem I've got when drm-next
On Wed, 30 Sep 2020, Linus Walleij wrote:
> On Fri, Aug 28, 2020 at 12:47 PM Lee Jones wrote:
>
> > > create mode 100644 drivers/video/backlight/ktd253-backlight.c
> >
> > Applied, thanks.
>
> Not to unnecessarily nag but I can't see this in linux-next and since we
> are at -rc7 it makes me a
On Wed, Sep 30, 2020 at 07:16:42PM +0200, Paul Cercueil wrote:
> Add and export the function drm_gem_cma_create_noalloc(), which is just
> __drm_gem_cma_create() renamed.
>
> This function can be used by drivers that need to create a GEM object
> without allocating the backing memory.
>
> Signed-
On Wed, Sep 30, 2020 at 01:53:46PM +0200, Alexandre Bailon wrote:
> This adds a RPMsg driver that implements communication between the CPU and an
> APU.
> This uses VirtIO buffer to exchange messages but for sharing data, this uses
> a dmabuf, mapped to be shared between CPU (userspace) and APU.
>
On Thu, Sep 24, 2020 at 05:08:56PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
>
> On 9/18/20 11:59 PM, Maxime Ripard wrote:
> > The HVS has three FIFOs that can be assigned to a number of PixelValves
> > through a mux.
> >
> > However, changing that FIFO requires that we disable and then enable the
>
Increase the minor version to indicate the presence of new features.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 305db1db1064..502aafe7d1e
Quoting Kuogee Hsieh (2020-09-29 10:10:26)
> Set link rate by using OPP set rate api so that CX level will be set
> accordingly base on the link rate.
s/base/based/
>
> Signed-off-by: Kuogee Hsieh
> ---
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> inde
Hi Stefan,
On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote:
> Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> >> Hi Nathan,
> >>
> >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> >>> On Thu,
Currently, the kernel is automatically doing an IOMMU memory mapping.
But we want to do it automatically for two reasons:
- to reduce the overhead of each APU operation
- to get the device address and use it as input for an operation
This adds 2 IOCTL to manually IOMMU map and unmap memory.
Signed
The fix of flagging state->modeset whenever distrust_bios_wm is set
causes a regression when initializing display(s) attached to a Lenovo
USB-C docking station. The display remains blank until the dock is
reattached. Revert to bring the behavior of the functional v5.6 stable.
This reverts commit 0
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
>
> On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
> > On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> > > On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > > > On Sun, Sep 27, 2020 at 09:46:47AM +03
Hi Daniel,
On Mon, Sep 28, 2020 at 11:02:11AM +0200, Daniel Vetter wrote:
> On Mon, Sep 28, 2020 at 9:06 AM Maxime Ripard wrote:
> >
> > There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
> > chip and some resolutions, most notably 1440p at 60Hz.
> >
> > In such a case, w
This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
which otherwise doesn't provide any method for cleaning/invalidating the
cache to sync with the device.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 21 +
drivers/gpu/drm/msm/msm_dr
On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
@@ -296,11 +223,17 @@ static struct ib_umem *__ib_um
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
> On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct
> > > ib_device *device,
From: Julien STEPHAN
In order to improve performances and flexibility,
add support of async request.
Signed-off-by: Julien STEPHAN
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/apu_rpmsg.c | 208 ++---
include/uapi/linux/apu_rpmsg.h | 6 +-
2 files chang
This is to support cached and cached-coherent memory types in vulkan.
I made a corresponding WIP merge request [1] which shows usage of this.
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6949
Jonathan Marek (3):
drm/msm: add MSM_BO_CACHED_COHERENT
drm/msm: add DRM_MSM_GEM_SY
Le mer. 30 sept. 2020 à 18:11, Christoph Hellwig a écrit
:
On Wed, Sep 30, 2020 at 03:33:13PM +0200, Paul Cercueil wrote:
One thing missing for remap_pfn_range(), I have no alternative for
this:
vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot,
DMA_ATTR_NON_CONSISTENT);
So I hav
This adds a driver to communicate with the APU available
in the mt8183. The driver is generic and could be used for other APU.
It mostly provides a userspace interface to send messages and
and share big buffers with the APU.
Signed-off-by: Alexandre Bailon
---
drivers/rpmsg/Kconfig |
On 9/30/2020 6:14 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 06:05:15PM +0300, Maor Gottlieb wrote:
This is right only for the last iteration. E.g. in the first iteration in
case that there are more pages (left_pages), then we allocate
SG_MAX_SINGLE_ALLOC. We don't know how many pages
It turns out that if you want to mmap GEM buffers fully cached, then
they should be allocated as such as well. Who would have known?
Introduce a custom .dumb_create callback, that will behave just like
drm_gem_cma_dumb_create(), except that it will allocate the GEM buffer
using dma_alloc_noncohere
While the signal on GPIO4 to drive the backlight controller indeed is
pulse width modulated its purpose is specifically to control the
brightness of a backlight.
Drop the #pwm-cells and instead expose a new property to configure the
granularity of the backlight PWM signal.
Signed-off-by: Bjorn An
Le mer. 30 sept. 2020 à 18:40, Christoph Hellwig a écrit
:
On Wed, Sep 30, 2020 at 06:39:18PM +0200, Paul Cercueil wrote:
dma_alloc_pages gives you cached memory, so you can't just use an
uncached protection for the userspace mmap here. If you want
uncached
memory you need to use dma_a
This adds a RPMsg driver that implements communication between the CPU and an
APU.
This uses VirtIO buffer to exchange messages but for sharing data, this uses
a dmabuf, mapped to be shared between CPU (userspace) and APU.
The driver is relatively generic, and should work with any SoC implementing
On 9/30/20 5:35 PM, Bjorn Andersson wrote:
> While the signal on GPIO4 to drive the backlight controller indeed is
> pulse width modulated its purpose is specifically to control the
> brightness of a backlight.
>
> Drop the #pwm-cells and instead expose a new property to configure the
> granulari
On 9/30/20 5:35 PM, Bjorn Andersson wrote:
> The TI SN65DSI86 can be configured to generate a PWM pulse on GPIO4,
> to be used to drive a backlight driver.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/bridge/Kconfig| 1 +
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 143 +++
The DMA API changed at the same time commit 37054fc81443 ("gpu/drm:
ingenic: Add option to mmap GEM buffers cached") was added. Rework the
code to work with the new DMA API.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 24 +++
1 file changed, 7
Because clk_disable_unprepare already checked NULL clock parameter,
so the additional checks are unnecessary, just remove it
Signed-off-by: Xu Wang
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.
On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> Hi Nathan,
>
> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > > Now that all the drivers have been adjusted for it, let's bring in the
> > > n
The TI SN65DSI86 can be configured to generate a PWM pulse on GPIO4,
to be used to drive a backlight driver.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 143 +-
2 files changed, 140 insertions(+
Hi Nathan,
On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > Now that all the drivers have been adjusted for it, let's bring in the
> > necessary device tree changes.
> >
> > The VEC and PV3 are left out for now
Add and export the function drm_gem_cma_create_noalloc(), which is just
__drm_gem_cma_create() renamed.
This function can be used by drivers that need to create a GEM object
without allocating the backing memory.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_gem_cma_helper.c | 11 ++-
On Wed, Sep 30, 2020 at 01:52:11PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2020 at 01:25:14PM +0200, Daniel Vetter wrote:
> > On Wed, Sep 30, 2020 at 12:56 PM Peilin Ye wrote:
> > > Yes, and built-in fonts don't use refcount. Or maybe we can let
> > > find_font() and get_default_font()
On 9/30/2020 2:58 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 02:53:58PM +0300, Maor Gottlieb wrote:
On 9/30/2020 2:45 PM, Jason Gunthorpe wrote:
On Wed, Sep 30, 2020 at 12:53:21PM +0300, Leon Romanovsky wrote:
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
On Sun, S
Hi Christoph,
Le mer. 30 sept. 2020 à 11:02, Christoph Hellwig a écrit
:
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote:
It's allocated with dma_alloc_wc, but then it's only accessed as
non-coherent.
Anyway, for the time being I guess you could revert 37054fc81443.
But I
Because clk_disable_unprepare already checked NULL clock parameter,
so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/i
1 - 100 of 110 matches
Mail list logo
