[PATCH] Revert "drm/qxl: drop prime import/export callbacks"
This reverts commit f4c34b1e2a37d5676180901fa6ff188bcb6371f8.
Simliar to commit a0cecc23cfcb Revert "drm/virtio: drop prime
import/export callbacks". We have to do the same with qxl,
for the same reasons (it breaks DRI3).
Drop the WARN_ON_ONCE().
Fixes: f4c34b1e2a37d5676180901fa6ff188bcb6371f8
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 4
drivers/gpu/drm/qxl/qxl_prime.c | 12
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 578d867a81d5..f33e349c4ec5 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -255,10 +255,14 @@ static struct drm_driver qxl_driver = {
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = qxl_debugfs_init,
#endif
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = qxl_gem_prime_pin,
.gem_prime_unpin = qxl_gem_prime_unpin,
+ .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
+ .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
.gem_prime_vmap = qxl_gem_prime_vmap,
.gem_prime_vunmap = qxl_gem_prime_vunmap,
.gem_prime_mmap = qxl_gem_prime_mmap,
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c b/drivers/gpu/drm/qxl/qxl_prime.c
index 8b448eca1cd9..114653b471c6 100644
--- a/drivers/gpu/drm/qxl/qxl_prime.c
+++ b/drivers/gpu/drm/qxl/qxl_prime.c
@@ -42,6 +42,18 @@ void qxl_gem_prime_unpin(struct drm_gem_object *obj)
qxl_bo_unpin(bo);
}
+struct sg_table *qxl_gem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
+struct drm_gem_object *qxl_gem_prime_import_sg_table(
+ struct drm_device *dev, struct dma_buf_attachment *attach,
+ struct sg_table *table)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
void *qxl_gem_prime_vmap(struct drm_gem_object *obj)
{
struct qxl_bo *bo = gem_to_qxl_bo(obj);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/
Daniel, drm-misc-next-fixes?
Dave.
On Fri, 26 Apr 2019 at 12:25, wrote:
>
> Hi Dave,
>
> > -Original Message-
> > From: Dave Airlie [mailto:airl...@gmail.com]
> > Sent: Friday, April 26, 2019 11:19 AM
> > To: Yamada, Masahiro/山田 真弘
> > Cc: David Airlie ; Daniel Vetter ;
> > dri-devel ; nouveau
> > ; Sam Ravnborg ; David
> > (ChunMing) Zhou ; amd-gfx mailing list
> > ; James (Qian) Wang
> > ; Ben Skeggs ;
> > linux-arm-msm ; Intel Graphics
> > Development ;
> > intel-gvt-...@lists.freedesktop.org; Linux Kernel Mailing List
> > ; Christian König
> > ; Alex Deucher ;
> > freedr...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with
> > $(srctree)/
> >
> > On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
> > wrote:
> > >
> > > Hi.
> > >
> > >
> > > On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> > > wrote:
> > > >
> > > > Currently, the Kbuild core manipulates header search paths in a crazy
> > > > way [1].
> > > >
> > > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > > > the search paths in the srctree. Some Makefiles are already written
> > in
> > > > that way, but not all. The goal of this work is to make the notation
> > > > consistent, and finally get rid of the gross hacks.
> > > >
> > > > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > > > ("kbuild: do not drop -I without parameter").
> > > >
> > > > [1]: https://patchwork.kernel.org/patch/9632347/
> > > >
> > > > Signed-off-by: Masahiro Yamada
> > > > Reviewed-by: Sam Ravnborg
> > > > ---
> > > >
> > > > I put all gpu/drm changes into a single patch because
> > > > they are trivial conversion.
> > > >
> > > > If you are interested in the big picture of this work,
> > > > the full patch set is available at the following URL.
> > > >
> > > >
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.g
> > it build-test
> > >
> > >
> > > Is somebody taking care of this?
> > >
> >
> > Are you expecting this to be merged in the drm tree? if so please
> > indicate that when posting.
>
>
> Sorry for unclearness.
>
> Could you apply this to your drm tree?
>
> Thanks.
>
>
>
>
> > I'd assumed this would go via kbuild tree.
> >
> > If the later,
> > Acked-by: Dave Airlie
> > Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] drm: prefix header search paths with $(srctree)/
On Fri, 26 Apr 2019 at 11:46, Masahiro Yamada
wrote:
>
> Hi.
>
>
> On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
> wrote:
> >
> > Currently, the Kbuild core manipulates header search paths in a crazy
> > way [1].
> >
> > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> > the search paths in the srctree. Some Makefiles are already written in
> > that way, but not all. The goal of this work is to make the notation
> > consistent, and finally get rid of the gross hacks.
> >
> > Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> > ("kbuild: do not drop -I without parameter").
> >
> > [1]: https://patchwork.kernel.org/patch/9632347/
> >
> > Signed-off-by: Masahiro Yamada
> > Reviewed-by: Sam Ravnborg
> > ---
> >
> > I put all gpu/drm changes into a single patch because
> > they are trivial conversion.
> >
> > If you are interested in the big picture of this work,
> > the full patch set is available at the following URL.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> > build-test
>
>
> Is somebody taking care of this?
>
Are you expecting this to be merged in the drm tree? if so please
indicate that when posting.
I'd assumed this would go via kbuild tree.
If the later,
Acked-by: Dave Airlie
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/gpu/drm/virtio/virtgpu_prime.c:43:18: error: redefinition of
'virtgpu_gem_prime_get_sg_table'
struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
^~
drivers/gpu/drm/virtio/virtgpu_prime.c:31:18: note: previous definition of
'virtgpu_gem_prime_get_sg_table' was here
struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
^~
Caused by a bad automaic merge between commit
a0cecc23cfcb ("Revert "drm/virtio: drop prime import/export callbacks"")
from Linus' tree and commit
98f41dc3b3ee ("drm/virtio: implement prime export")
from the drm tree.
I dropped the version of this function from the drm-fixes tree:
From: Stephen Rothwell
Date: Fri, 26 Apr 2019 12:13:26 +1000
Subject: [PATCH] drm/virtio: fix up bad merge of virtgpu_gem_prime_get_sg_table
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/virtio/virtgpu_prime.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index 0f670fc6c954..8fbf71bd0c5e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -40,11 +40,6 @@ struct sg_table *virtgpu_gem_prime_get_sg_table(struct
drm_gem_object *obj)
bo->tbo.ttm->num_pages);
}
-struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
- return ERR_PTR(-ENODEV);
-}
-
struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *table)
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpYATnTnR_Ki.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105819] Window system hang due to GPU Fault
https://bugs.freedesktop.org/show_bug.cgi?id=105819 --- Comment #11 from xom --- Still happening on 5.1.0-0.rc5, system hangs and only solution is a reboot. Happens somewhat randomly, gpu can be underload or just browsing with firefox. Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev e7) (prog-if 00 [VGA controller]) Subsystem: Tul Corporation / PowerColor Device 2378 Flags: bus master, fast devsel, latency 0, IRQ 27 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f000 (64-bit, prefetchable) [size=2M] I/O ports at e000 [size=256] Memory at f7e0 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: amdgpu Kernel modules: amdgpu dmesg: Apr 24 18:25:14 abyss kernel: amdgpu :01:00.0: GPU fault detected: 146 0x480c for process gnome-shell pid 4536 thread gnome-shel:cs0 pi> Apr 24 18:25:14 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x Apr 24 18:25:14 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C04800C Apr 24 18:25:14 abyss kernel: amdgpu :01:00.0: VM fault (0x0c, vmid 6, pasid 32778) at page 0, read from 'TC4' (0x54433400) (72) Apr 24 18:25:20 abyss /usr/libexec/gdm-x-session[4290]: (II) event5 - Kingsis Peripherals ZOWIE Gaming mouse: SYN_DROPPED event - some input e> Apr 24 18:25:20 abyss kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out. Apr 24 18:25:20 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0c023d10 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:20 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00101780 Apr 24 18:25:20 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0F03D010 Apr 24 18:25:20 abyss kernel: amdgpu :01:00.0: VM fault (0x10, vmid 7, pasid 32777) at page 1054592, write from 'SDM1' (0x53444d31) (61) Apr 24 18:25:24 abyss kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered Apr 24 18:25:25 abyss /usr/libexec/gdm-x-session[4290]: (II) event5 - Kingsis Peripherals ZOWIE Gaming mouse: SYN_DROPPED event - some input e> Apr 24 18:25:29 abyss firefox.desktop[4536]: Fontconfig warning: Directory/file mtime in the future. New fonts may not be detected. Apr 24 18:25:30 abyss kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out. Apr 24 18:25:35 abyss kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out. Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0d080408 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x03A1 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A004008 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM fault (0x08, vmid 5, pasid 32777) at page 929, read from 'TC1' (0x54433100) (4) Apr 24 18:25:35 abyss kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0d088808 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x03A1 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A088008 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM fault (0x08, vmid 5, pasid 32777) at page 929, read from 'TC6' (0x54433600) (136) Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0d088808 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x03A1 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A088008 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM fault (0x08, vmid 5, pasid 32777) at page 929, read from 'TC6' (0x54433600) (136) Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0d088408 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x03A1 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A084008 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM fault (0x08, vmid 5, pasid 32777) at page 929, read from 'TC7' (0x54433700) (132) Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: GPU fault detected: 147 0x0d08c808 for process Xorg pid 4292 thread Xorg:cs0 pid 4293 Apr 24 18:25:35 abyss kernel: amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR
[git pull] drm fixes for 5.1-rc7
Hi Linus, Regular drm fixes pull, nothing too outstanding, I'm guessing Easter was slowing people down. i915: - FEC enable fix - BXT display lanes fix ttm: - fix reinit for reloading drivers regression imx: - DP CSC fix sun4i: - module unload/load fix vc4: - memory leak fix - compile fix dw-hdmi: - rockchip scdc overflow fix sched: - docs fix vmwgfx: - dma api layering fix. Dave. drm-fixes-2019-04-26: drm: i915, sched, sun4i, vmwgfx, vc4, imx, dw-hdmi fixes The following changes since commit a0cecc23cfcbf2626497a8c8770856dd56b67917: Revert "drm/virtio: drop prime import/export callbacks" (2019-04-24 10:52:52 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-26 for you to fetch changes up to 6db71bea59f964d241bdcf1e73e47aebb7427888: Merge tag 'imx-drm-fixes-2019-04-25' of git://git.pengutronix.de/pza/linux into drm-fixes (2019-04-26 10:33:33 +1000) drm: i915, sched, sun4i, vmwgfx, vc4, imx, dw-hdmi fixes Christian König (1): drm/ttm: fix re-init of global structures Dave Airlie (5): Merge tag 'drm-intel-fixes-2019-04-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-fixes-5.1' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-04-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'vmwgfx-fixes-5.1' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'imx-drm-fixes-2019-04-25' of git://git.pengutronix.de/pza/linux into drm-fixes Jonas Karlman (2): drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus Jonathan Neuschäfer (1): drm/sched: Fix description of drm_sched_stop Lucas Stach (2): gpu: ipu-v3: dp: fix CSC handling drm/imx: don't skip DP channel disable for background plane Maarten Lankhorst (2): drm/vc4: Fix memory leak during gpu reset. drm/vc4: Fix compilation error reported by kbuild test bot Paul Kocialkowski (4): drm/sun4i: Add missing drm_atomic_helper_shutdown at driver unbind drm/sun4i: Set device driver data at bind time for use in unbind drm/sun4i: Fix component unbinding and component master deletion drm/sun4i: Unbind components before releasing DRM and memory Thomas Hellstrom (1): drm/vmwgfx: Fix dma API layer violation Ville Syrjälä (2): drm/i915: Do not enable FEC without DSC drm/i915: Restore correct bxt_ddi_phy_calc_lane_lat_optim_mask() calculation drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 16 +++ drivers/gpu/drm/i915/intel_ddi.c | 6 -- drivers/gpu/drm/i915/intel_dp.c | 6 +++--- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- drivers/gpu/drm/scheduler/sched_main.c| 3 +-- drivers/gpu/drm/sun4i/sun4i_drv.c | 9 + drivers/gpu/drm/ttm/ttm_bo.c | 10 +- drivers/gpu/drm/ttm/ttm_memory.c | 5 +++-- drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 33 +-- drivers/gpu/ipu-v3/ipu-dp.c | 12 --- include/drm/ttm/ttm_bo_driver.h | 1 - 12 files changed, 53 insertions(+), 52 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: check for equals 0 only
On Thu, Apr 25, 2019 at 7:09 AM Nicholas Mc Guire wrote: > > wait_for_completion_timeout() returns 0 on timeout and aleast 1 otherwise > so checking for < makes no sense here. > > Signed-off-by: Nicholas Mc Guire > --- > > Problem located with an experimental coccinelle script > > While this check does no harm in this form - it should be fixed anyway > to comply with the API see: kernel/sched/completion.c > > Also noticed that get_maintainer.pl will not list linux-ker...@vger.kernel.org > when run on drivers/gpu/drm/msm/dsi/dsi_host.c - is that intentional ? Thanks, I'll pull this in for -fixes as far as get_maintainer.pl.. I'm not entirely sure.. we don't list linux-ker...@vger.kernel.org explicitly, but neither do a lot of the other driver entries. Possibly this is a oversight in the MAINTAINERS entry? Either way, I guess I'd say that it isn't intentional. BR, -R > > Patch was compile-tested with: qcom_defconfig (implies DRM_MSM_DSI=y) > > Patch is against v5.1-rc6 (localversion-next is next-20190424) > > drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c > b/drivers/gpu/drm/msm/dsi/dsi_host.c > index 610183d..dc16067 100644 > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c > @@ -1049,7 +1049,7 @@ static void dsi_wait4video_done(struct msm_dsi_host > *msm_host) > ret = wait_for_completion_timeout(_host->video_comp, > msecs_to_jiffies(70)); > > - if (ret <= 0) > + if (ret == 0) > DRM_DEV_ERROR(dev, "wait for video done timed out\n"); > > dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0); > -- > 2.1.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110517] Running any OpenGL related command with DRI_PRIME=1 crashes the system
https://bugs.freedesktop.org/show_bug.cgi?id=110517 --- Comment #1 from Alex Deucher --- Closed source OpenGL does not support PRIME. For hybrid laptops, please use mesa. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110517] Running any OpenGL related command with DRI_PRIME=1 crashes the system
https://bugs.freedesktop.org/show_bug.cgi?id=110517 Alex Deucher changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #39 from Alex Deucher --- (In reply to Adrian Garay from comment #38) > (In reply to Alex Deucher from comment #33) > > (In reply to Talha Khan from comment #31) > > > I moved the raven_dcmu.bin file to another directory, but unfortunately I > > > am > > > still unable to boot any kernel newer 4.20. For me at least, I get a black > > > screen with a horizontal line near the bottom of orange pixels. I will > > > attach the journalctl output from my last boot into kernel 5.0.5. > > > > Make sure you update your initrd if you move the file, otherwise, the driver > > will pick it up from the initrd at load time. > > Alex, is there a known issue with raven_dmcu.bin and this chipset or is it > specific to this laptop? I think it's specific to the sbios version. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm/msm: check for equals 0 only
On 2019-04-25 07:03, Nicholas Mc Guire wrote: wait_for_completion_timeout() returns 0 on timeout and aleast 1 otherwise so checking for < makes no sense here. Signed-off-by: Nicholas Mc Guire Reviewed-by: Abhinav Kumar --- Problem located with an experimental coccinelle script While this check does no harm in this form - it should be fixed anyway to comply with the API see: kernel/sched/completion.c Also noticed that get_maintainer.pl will not list linux-ker...@vger.kernel.org when run on drivers/gpu/drm/msm/dsi/dsi_host.c - is that intentional ? Patch was compile-tested with: qcom_defconfig (implies DRM_MSM_DSI=y) Patch is against v5.1-rc6 (localversion-next is next-20190424) drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 610183d..dc16067 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -1049,7 +1049,7 @@ static void dsi_wait4video_done(struct msm_dsi_host *msm_host) ret = wait_for_completion_timeout(_host->video_comp, msecs_to_jiffies(70)); - if (ret <= 0) + if (ret == 0) DRM_DEV_ERROR(dev, "wait for video done timed out\n"); dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is not for s390, right?
> >
> > No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> > and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> > s390 is the reason for having compat_ptr_ioctl() in the first place;
> > that thing works on all biarch architectures, as long as all stuff
> > handled by ->ioctl() takes pointer to arch-independent object as
> > argument. IOW,
> > argument ignored => OK
> > any arithmetical type => no go, compat_ptr() would bugger it
> > pointer to int => OK
> > pointer to string => OK
> > pointer to u64 => OK
> > pointer to struct {u64 addr; char s[11];} => OK
>
> To be extra pedantic, the 'struct {u64 addr; char s[11];} '
> case is also broken on x86, because sizeof (obj) is smaller
> on i386, even though the location of the members are
> the same. i.e. you can copy_from_user() this
Actually, you can't even do that because the struct might sit at the end
of a page and then you'd erroneously fault in this case.
We had this a while ago with struct ifreq, see commit 98406133dd and its
parents.
johannes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 11/17] kunit: test: add test managed resource tests
On Wed, Apr 24, 2019 at 12:00 PM Masayoshi Mizuma wrote:
>
> On Thu, Apr 04, 2019 at 03:06:46PM -0700, Brendan Higgins wrote:
> > From: Avinash Kondareddy
> >
> > Tests how tests interact with test managed resources in their lifetime.
> >
> > Signed-off-by: Avinash Kondareddy
> > Signed-off-by: Brendan Higgins
> > ---
> > kunit/test-test.c | 122 ++
> > 1 file changed, 122 insertions(+)
> >
> > diff --git a/kunit/test-test.c b/kunit/test-test.c
> > index 4bd7a34d0a6cb..54add8ca418a0 100644
> > --- a/kunit/test-test.c
> > +++ b/kunit/test-test.c
> > @@ -135,3 +135,125 @@ static struct kunit_module
> > kunit_try_catch_test_module = {
> > .test_cases = kunit_try_catch_test_cases,
> > };
> > module_test(kunit_try_catch_test_module);
> > +
> > +/*
> > + * Context for testing test managed resources
> > + * is_resource_initialized is used to test arbitrary resources
> > + */
> > +struct kunit_test_resource_context {
> > + struct kunit test;
> > + bool is_resource_initialized;
> > +};
> > +
> > +static int fake_resource_init(struct kunit_resource *res, void *context)
> > +{
> > + struct kunit_test_resource_context *ctx = context;
> > +
> > + res->allocation = >is_resource_initialized;
> > + ctx->is_resource_initialized = true;
> > + return 0;
> > +}
> > +
> > +static void fake_resource_free(struct kunit_resource *res)
> > +{
> > + bool *is_resource_initialized = res->allocation;
> > +
> > + *is_resource_initialized = false;
> > +}
> > +
> > +static void kunit_resource_test_init_resources(struct kunit *test)
> > +{
> > + struct kunit_test_resource_context *ctx = test->priv;
> > +
> > + kunit_init_test(>test, "testing_test_init_test");
> > +
> > + KUNIT_EXPECT_TRUE(test, list_empty(>test.resources));
> > +}
> > +
> > +static void kunit_resource_test_alloc_resource(struct kunit *test)
> > +{
> > + struct kunit_test_resource_context *ctx = test->priv;
> > + struct kunit_resource *res;
> > + kunit_resource_free_t free = fake_resource_free;
> > +
> > + res = kunit_alloc_resource(>test,
> > +fake_resource_init,
> > +fake_resource_free,
> > +ctx);
> > +
>
> > + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, res);
>
> KUNIT_EXPECT_NOT_ERR_OR_NULL(test, res);
See my reply to your email on the 14/17 patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 14/17] Documentation: kunit: add documentation for KUnit
On Wed, Apr 24, 2019 at 11:58 AM Masayoshi Mizuma wrote: > > Hi Brendan, > > KUNIT_ASSERT_NOT_ERR_OR_NULL() should be replaced to > KUNIT_EXPECT_NOT_ERR_OR_NULL(), right? Generally speaking, no. There may be places that I have used it improperly, but I think it is generally okay to use. If you are refering to the discussion with Frank and Stephen in RFC v4, my take was that the resolution was that there were some things I needed to fix in its implementation, but it is conceptually okay, and that Frank doesn't want me to use it in drivers/of/unittest.c. Consequently, I fixed the implementation issues that Frank and Stephen pointed out, and I am holding off on drivers/of/unittest.c for this patchset. The usage in this file should be fine. > > On Thu, Apr 04, 2019 at 03:06:49PM -0700, Brendan Higgins wrote: > > Add documentation for KUnit, the Linux kernel unit testing framework. > > - Add intro and usage guide for KUnit > > - Add API reference > > > > Signed-off-by: Felix Guo > > Signed-off-by: Brendan Higgins > > --- > > Cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] vmwgfx-fixes-5.1
Dave, Daniel A single fix for a layer violation requested by Cristoph. The following changes since commit c2d311553855395764e2e5bf401d987ba65c2056: drm/vmwgfx: Don't double-free the mode stored in par->set_mode (2019-03-20 07:57:01 +0100) are available in the Git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-5.1 for you to fetch changes up to 81103355b1e23345dbcdeccad59962a424da4a34: drm/vmwgfx: Fix dma API layer violation (2019-04-25 09:05:03 +0200) Thomas Hellstrom (1): drm/vmwgfx: Fix dma API layer violation drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 33 + 1 file changed, 5 insertions(+), 28 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #15 from Jaap Buurman --- That's bad to hear :( Worth a try though. How often do you experience freezes by the way? And is this for all games, or are some games completely stable? For me, I am getting crashes in Kerbal Space Program, but not in Final Fantasy XII or World of Warcraft, even after hundreds of hours in both of these stable games. Also, have you ever figured out which kernel parameter in particular makes your setup stable? It might help identify where the problem exists. Or do you need that exact combination of all those parameters to get your system stable? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #38 from Adrian Garay --- (In reply to Alex Deucher from comment #33) > (In reply to Talha Khan from comment #31) > > I moved the raven_dcmu.bin file to another directory, but unfortunately I am > > still unable to boot any kernel newer 4.20. For me at least, I get a black > > screen with a horizontal line near the bottom of orange pixels. I will > > attach the journalctl output from my last boot into kernel 5.0.5. > > Make sure you update your initrd if you move the file, otherwise, the driver > will pick it up from the initrd at load time. Alex, is there a known issue with raven_dmcu.bin and this chipset or is it specific to this laptop? No distro with a recent kernel is installable on my laptop unless I nomodeset the kernel and remove this firmware file from the initramfs. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110517] Running any OpenGL related command with DRI_PRIME=1 crashes the system
https://bugs.freedesktop.org/show_bug.cgi?id=110517 Bug ID: 110517 Summary: Running any OpenGL related command with DRI_PRIME=1 crashes the system Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: amillho...@seznam.cz Created attachment 144096 --> https://bugs.freedesktop.org/attachment.cgi?id=144096=edit logs Running DRI_PRIME=1 glxinfo crashes the system (I don't know if Xorg crashes or driver crashes). Then I need to login into system again. Basically I cannot start any graphic program with DRI_PRIME=1 Open source stack (amdgpu) is fine. I need to start the system with these kernel boot parameters: ivrs_ioapic[4]=00:14.0 ivrs_ioapic[5]=00:00.2 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 9/9] platform/chrome: chromeos_laptop: use helper pci_dev_id
Hi Heiner, On Wed, Apr 24, 2019 at 09:17:19PM +0200, Heiner Kallweit wrote: > Use new helper pci_dev_id() to simplify the code. > > Signed-off-by: Heiner Kallweit Acked-By: Benson Leung > --- > drivers/platform/chrome/chromeos_laptop.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/chrome/chromeos_laptop.c > b/drivers/platform/chrome/chromeos_laptop.c > index 24326eecd..7abbb6167 100644 > --- a/drivers/platform/chrome/chromeos_laptop.c > +++ b/drivers/platform/chrome/chromeos_laptop.c > @@ -125,7 +125,7 @@ static bool chromeos_laptop_match_adapter_devid(struct > device *dev, u32 devid) > return false; > > pdev = to_pci_dev(dev); > - return devid == PCI_DEVID(pdev->bus->number, pdev->devfn); > + return devid == pci_dev_id(pdev); > } > > static void chromeos_laptop_check_adapter(struct i2c_adapter *adapter) > -- > 2.21.0 > > -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote: > Convert the PM documents to ReST, in order to allow them to > build with Sphinx. This is massively CCed covering a large range of subsystems and is patch 25 of a 79 patch series so I've no context for what's going on here or why... signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable
On Thu, Apr 25, 2019 at 08:59:15PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 25, 2019 at 12:39:27PM +, Matt Redfearn wrote:
> > On 25/04/2019 13:13, Andrzej Hajda wrote:
> >> On 24.04.2019 16:22, Matt Redfearn wrote:
> >>> The DRM documentation states that post_disable is an optional callback.
> >>> As such an implementing device may not populate it. To avoid panicing
> >>> the kernel by calling a NULL function pointer, we should NULL check it
> >>> before blindy calling it.
> >>>
> >>> Signed-off-by: Matt Redfearn
> >>
> >>> ---
> >>>
> >>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> >>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> index 38e88071363..0ee440216b8 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >>> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct
> >>> drm_bridge *bridge)
> >>>* This needs to be fixed in the drm_bridge framework and the
> >>> API
> >>>* needs to be updated to manage our own call chains...
> >>>*/
> >>> - dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> >>> + if (dsi->panel_bridge->funcs->post_disable)
> >>> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> >>>
> >>
> >> Why not drm_bridge_post_disable ?
> >
> > Ah - that seems like a nicer fix! Do you think the comment above
> > describing why this function pointer is called directly can be removed
> > as well if we go this route?
>
> It shouldn't be necessary to call ->post_disable manually here as the
> bridge core handles it internally. This is a hack to work around a
> problem, and should be fixed properly.
>
> > If someone calls drm_bridge_post_disable() on the Synposys DSI
> > drm_bridge it will go on to call post_disable on all other bridges in
> > the chain, in addition to us calling them here. Is it an issue to call
> > it multiple times?
>
> It depends on the panel implementation, but in general it's not a good
> idea. It may happen to work, but could break at any time in the future.
Double-checking the driver, the .attach() operation doesn't propagate to
the next bridge, so the bridge core will not know about it, and will not
propagate .post_disable() either. I think this should be fixed in a way
that uses the drm bridge core infrastructure.
> >>> if (dsi->slave) {
> >>> dw_mipi_dsi_disable(dsi->slave);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable
Hi Matt,
On Thu, Apr 25, 2019 at 12:39:27PM +, Matt Redfearn wrote:
> On 25/04/2019 13:13, Andrzej Hajda wrote:
> > On 24.04.2019 16:22, Matt Redfearn wrote:
> >> The DRM documentation states that post_disable is an optional callback.
> >> As such an implementing device may not populate it. To avoid panicing
> >> the kernel by calling a NULL function pointer, we should NULL check it
> >> before blindy calling it.
> >>
> >> Signed-off-by: Matt Redfearn
> >
> >> ---
> >>
> >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> index 38e88071363..0ee440216b8 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct
> >> drm_bridge *bridge)
> >> * This needs to be fixed in the drm_bridge framework and the API
> >> * needs to be updated to manage our own call chains...
> >> */
> >> - dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> >> + if (dsi->panel_bridge->funcs->post_disable)
> >> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> >>
> >
> > Why not drm_bridge_post_disable ?
>
> Ah - that seems like a nicer fix! Do you think the comment above
> describing why this function pointer is called directly can be removed
> as well if we go this route?
It shouldn't be necessary to call ->post_disable manually here as the
bridge core handles it internally. This is a hack to work around a
problem, and should be fixed properly.
> If someone calls drm_bridge_post_disable() on the Synposys DSI
> drm_bridge it will go on to call post_disable on all other bridges in
> the chain, in addition to us calling them here. Is it an issue to call
> it multiple times?
It depends on the panel implementation, but in general it's not a good
idea. It may happen to work, but could break at any time in the future.
> >>if (dsi->slave) {
> >>dw_mipi_dsi_disable(dsi->slave);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 4/4] drm/vc4: Allocate binner bo when starting to use the V3D
Paul Kocialkowski writes:
> The binner BO is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
>
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left, using a kref. Protect the logic with a
> mutex to avoid race conditions.
>
> The binner BO is created at the time of the first render ioctl and is
> destroyed when there is no client and no exec job using it left.
>
> The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
> enabling it before having allocated a binner bo.
>
> We also want to keep the BO alive during runtime suspend/resume to avoid
> failing to allocate it at resume. This happens when the CMA pool is
> full at that point and results in a hard crash.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/vc4/vc4_bo.c | 33 +++-
> drivers/gpu/drm/vc4/vc4_drv.c | 6
> drivers/gpu/drm/vc4/vc4_drv.h | 14 +
> drivers/gpu/drm/vc4/vc4_gem.c | 13
> drivers/gpu/drm/vc4/vc4_irq.c | 21 +
> drivers/gpu/drm/vc4/vc4_v3d.c | 58 +++
> 6 files changed, 125 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 88ebd681d7eb..2b3ec5926fe2 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -799,13 +799,38 @@ vc4_prime_import_sg_table(struct drm_device *dev,
> return obj;
> }
>
> +static int vc4_grab_bin_bo(struct vc4_dev *vc4, struct vc4_file *vc4file)
> +{
> + int ret;
> +
> + if (!vc4->v3d)
> + return -ENODEV;
> +
> + if (vc4file->bin_bo_used)
> + return 0;
> +
> + ret = vc4_v3d_bin_bo_get(vc4);
> + if (ret)
> + return ret;
> +
> + vc4file->bin_bo_used = true;
I think I found one last race. Multiple threads could be in an ioctl
trying to grab the bin BO at the same time (while this is only during
app startup, since the fd only needs to get the ref once, it's
particularly plausible given that allocating the bin BO is slow). I
think if you replace this line with:
mutex_lock(>bin_bo_lock);
if (vc4file->bin_bo_used) {
mutex_unlock(>bin_bo_lock);
vc4_v3d_bin_bo_put(vc4);
} else {
vc4file->bin_bo_used = true;
mutex_unlock(>bin_bo_lock);
}
that will be the last change we need. If you agree with this, feel free
to squash it in and apply the series with:
Reviewed-by: Eric Anholt
> +
> + return 0;
> +}
> +
> int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> struct drm_vc4_create_bo *args = data;
> + struct vc4_file *vc4file = file_priv->driver_priv;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_bo *bo = NULL;
> int ret;
>
> + ret = vc4_grab_bin_bo(vc4, vc4file);
> + if (ret)
> + return ret;
> +
> /*
>* We can't allocate from the BO cache, because the BOs don't
>* get zeroed, and that might leak data between users.
> @@ -846,6 +871,8 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
> *data,
> struct drm_file *file_priv)
> {
> struct drm_vc4_create_shader_bo *args = data;
> + struct vc4_file *vc4file = file_priv->driver_priv;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_bo *bo = NULL;
> int ret;
>
> @@ -865,6 +892,10 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
> *data,
> return -EINVAL;
> }
>
> + ret = vc4_grab_bin_bo(vc4, vc4file);
> + if (ret)
> + return ret;
> +
> bo = vc4_bo_create(dev, args->size, true, VC4_BO_TYPE_V3D_SHADER);
> if (IS_ERR(bo))
> return PTR_ERR(bo);
> @@ -894,7 +925,7 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
> *data,
>*/
> ret = drm_gem_handle_create(file_priv, >base.base, >handle);
>
> - fail:
> +fail:
> drm_gem_object_put_unlocked(>base.base);
>
> return ret;
Extraneous whitespace change?
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/prime: split drm_gem_prime_handle_to_fd()
Hi Emil.
Thans, again a nice simplification.
But the export_handle_to_buf now have to mutex_unlock.
Please use proper goto error handlign with a single
unlock in the end of the fuction.
This makes it simple to check that we always do the unlock.
Likewise in next function. Avoid two mutex_unlock, we prefer goto error
handling.
Sam
On Thu, Apr 25, 2019 at 04:51:14PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently drm_gem_prime_handle_to_fd() consists of illegible amount of
> goto labels, for no obvious reason.
>
> Split it in two (as below) making the code far simpler and obvious.
>
> drm_gem_prime_handle_to_fd()
> - prime mtx handling
> - drm_gem_object lookup and refcounting
> - creating an fd for the dmabuf
> - hash table lookup
>
> export_handle_to_buf()
> - drm_gem_object export and locking
> - adding the handle/fd to the hash table
>
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> Currently we dma_buf_put() [in the error path] even for re-export of
> original imported object and "self-export" - aka
> obj->import_attach->dmabuf and obj->dmabuf.
>
> Have not looked at it too closely, but gut suggests that may be off.
> ---
> drivers/gpu/drm/drm_prime.c | 106 +++-
> 1 file changed, 57 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 0d83b9bbf793..2b0b6e7a6a47 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -545,11 +545,54 @@ static struct dma_buf
> *export_and_register_object(struct drm_device *dev,
>* will clean it up.
>*/
> obj->dma_buf = dmabuf;
> - get_dma_buf(obj->dma_buf);
>
> return dmabuf;
> }
>
> +static struct dma_buf *export_handle_to_buf(struct drm_device *dev,
> + struct drm_file *file_priv,
> + struct drm_gem_object *obj,
> + uint32_t handle,
> + uint32_t flags)
> +{
> + struct dma_buf *dmabuf = NULL;
> + int ret;
> +
> + mutex_lock(>object_name_lock);
> + /* re-export the original imported object */
> + if (obj->import_attach)
> + dmabuf = obj->import_attach->dmabuf;
> +
> + if (!dmabuf)
> + dmabuf = obj->dma_buf;
> +
> + if (!dmabuf)
> + dmabuf = export_and_register_object(dev, obj, flags);
> +
> + if (IS_ERR(dmabuf)) {
> + /* normally the created dma-buf takes ownership of the ref,
> + * but if that fails then drop the ref
> + */
> + mutex_unlock(>object_name_lock);
One mutex_unlock
> + return dmabuf;
> + }
> +
> + get_dma_buf(dmabuf);
> +
> + /*
> + * If we've exported this buffer then cheat and add it to the import
> list
> + * so we get the correct handle back. We must do this under the
> + * protection of dev->object_name_lock to ensure that a racing gem close
> + * ioctl doesn't miss to remove this buffer handle from the cache.
> + */
> + ret = drm_prime_add_buf_handle(_priv->prime, dmabuf, handle);
> + mutex_unlock(>object_name_lock);
Second mutex_unlock
> + if (ret) {
> + dma_buf_put(dmabuf);
> + dmabuf = ERR_PTR(ret);
> + }
This error handling looks a little off. It assume it works correct, but
please try to make it more obvious.
> + return dmabuf;
> +}
> /**
> * drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
> * @dev: dev to export the buffer from
> @@ -569,7 +612,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> int *prime_fd)
> {
> struct drm_gem_object *obj;
> - int ret = 0;
> + int ret;
> struct dma_buf *dmabuf;
>
> mutex_lock(_priv->prime.lock);
HEre we have the mutex_lock
> @@ -580,49 +623,14 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
> }
>
> dmabuf = drm_prime_lookup_buf_by_handle(_priv->prime, handle);
> - if (dmabuf) {
> - get_dma_buf(dmabuf);
> - goto out_have_handle;
> - }
> + if (!dmabuf)
> + dmabuf = export_handle_to_buf(dev, file_priv, obj, handle,
> flags);
>
> - mutex_lock(>object_name_lock);
> - /* re-export the original imported object */
> - if (obj->import_attach) {
> - dmabuf = obj->import_attach->dmabuf;
> - get_dma_buf(dmabuf);
> - goto out_have_obj;
> - }
> -
> - if (obj->dma_buf) {
> - get_dma_buf(obj->dma_buf);
> - dmabuf = obj->dma_buf;
> - goto out_have_obj;
> - }
> -
> - dmabuf = export_and_register_object(dev, obj, flags);
> if (IS_ERR(dmabuf)) {
> - /* normally the created dma-buf takes ownership of the ref,
> - * but if that fails then drop the ref
> -
Re: [PATCH 1/2] drm/prime: split drm_gem_prime_fd_to_handle()
Hi Emil.
Thanks for the patch - it looks like a good simplification.
The changes introduced in import_buf_to_handle() changes the logic
a little to avoid goto - this hurts readability.
It would be better to keep the current structure and use goto label
to hanlde the error situations.
Then error handlind is more consistent and it is easier when we
need to extend this in the future.
Sam
Thu, Apr 25, 2019 at 04:51:13PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently drm_gem_prime_fd_to_handle() consists of illegible amount of
> goto labels, for no obvious reason.
>
> Split it in two (as below) making the code far simpler and obvious.
>
> drm_gem_prime_fd_to_handle()
> - prime mtx handling
> - fd/dmabuf refcounting
> - hash table lookup
>
> import_buf_to_handle()
> - drm_gem_object import and locking
> - creating a handle for the gem object
> - adding the handle/fd to the hash table
>
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/drm_prime.c | 86 ++---
> 1 file changed, 41 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index dc079efb3b0f..0d83b9bbf793 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -777,37 +777,14 @@ struct drm_gem_object *drm_gem_prime_import(struct
> drm_device *dev,
> }
> EXPORT_SYMBOL(drm_gem_prime_import);
>
> -/**
> - * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
> - * @dev: dev to export the buffer from
> - * @file_priv: drm file-private structure
> - * @prime_fd: fd id of the dma-buf which should be imported
> - * @handle: pointer to storage for the handle of the imported buffer object
> - *
> - * This is the PRIME import function which must be used mandatorily by GEM
> - * drivers to ensure correct lifetime management of the underlying GEM
> object.
> - * The actual importing of GEM object from the dma-buf is done through the
> - * gem_import_export driver callback.
> - */
> -int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> -struct drm_file *file_priv, int prime_fd,
> -uint32_t *handle)
> +static int import_buf_to_handle(struct drm_device *dev,
> + struct drm_file *file_priv,
> + struct dma_buf *dma_buf,
> + uint32_t *handle)
> {
> - struct dma_buf *dma_buf;
> struct drm_gem_object *obj;
> int ret;
>
> - dma_buf = dma_buf_get(prime_fd);
> - if (IS_ERR(dma_buf))
> - return PTR_ERR(dma_buf);
> -
> - mutex_lock(_priv->prime.lock);
> -
> - ret = drm_prime_lookup_buf_handle(_priv->prime,
> - dma_buf, handle);
> - if (ret == 0)
> - goto out_put;
> -
> /* never seen this one, need to import */
> mutex_lock(>object_name_lock);
> if (dev->driver->gem_prime_import)
> @@ -816,7 +793,8 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> obj = drm_gem_prime_import(dev, dma_buf);
> if (IS_ERR(obj)) {
> ret = PTR_ERR(obj);
> - goto out_unlock;
> + mutex_unlock(>object_name_lock);
> + return ret;
> }
>
> if (obj->dma_buf) {
> @@ -830,29 +808,47 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> ret = drm_gem_handle_create_tail(file_priv, obj, handle);
> drm_gem_object_put_unlocked(obj);
> if (ret)
> - goto out_put;
> + return ret;
>
> - ret = drm_prime_add_buf_handle(_priv->prime,
> - dma_buf, *handle);
> - mutex_unlock(_priv->prime.lock);
> + ret = drm_prime_add_buf_handle(_priv->prime, dma_buf, *handle);
> if (ret)
> - goto fail;
> + /* hmm, if driver attached, we are relying on the free-object
> + * path to detach.. which seems ok..
> + */
> + drm_gem_handle_delete(file_priv, *handle);
>
> - dma_buf_put(dma_buf);
> + return ret;
> +}
>
> - return 0;
> +/**
> + * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
> + * @dev: dev to export the buffer from
> + * @file_priv: drm file-private structure
> + * @prime_fd: fd id of the dma-buf which should be imported
> + * @handle: pointer to storage for the handle of the imported buffer object
> + *
> + * This is the PRIME import function which must be used mandatorily by GEM
> + * drivers to ensure correct lifetime management of the underlying GEM
> object.
> + * The actual importing of GEM object from the dma-buf is done through the
> + * gem_import_export driver callback.
> + */
> +int drm_gem_prime_fd_to_handle(struct drm_device *dev,
> +struct drm_file *file_priv, int prime_fd,
> +uint32_t *handle)
> +{
> + struct dma_buf *dma_buf;
> + int ret;
Re: [PATCH] dma-buf: call kfree() w/o mutex held in dma_buf_attach()
On Thu, Apr 25, 2019 at 04:48:50PM +0100, Emil Velikov wrote: > From: Emil Velikov > > In dma_buf_attach() we allocate memory w/o a mutex being held, thus in > the error path we should kfree() it after the mutex_unlock. > > The inverse function dma_buf_deattach() gets this right. > > Cc: Sumit Semwal > Signed-off-by: Emil Velikov I don't think this matters, but +1 on ocd. Reviewed-by: Daniel Vetter > --- > drivers/dma-buf/dma-buf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 3ae6c0c2cc02..57ddeb735b8b 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -579,8 +579,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf > *dmabuf, > return attach; > > err_attach: > - kfree(attach); > mutex_unlock(>lock); > + kfree(attach); > return ERR_PTR(ret); > } > EXPORT_SYMBOL_GPL(dma_buf_attach); > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #37 from Talha Khan --- The issue occurs (and workaround works) on kernels 5.0.8 and 5.0.9. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
>
> On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
>
> > If I understand your patch description well, using compat_ptr_ioctl
> > only works if the driver is not for s390, right?
>
> No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> s390 is the reason for having compat_ptr_ioctl() in the first place;
> that thing works on all biarch architectures, as long as all stuff
> handled by ->ioctl() takes pointer to arch-independent object as
> argument. IOW,
> argument ignored => OK
> any arithmetical type => no go, compat_ptr() would bugger it
> pointer to int => OK
> pointer to string => OK
> pointer to u64 => OK
> pointer to struct {u64 addr; char s[11];} => OK
To be extra pedantic, the 'struct {u64 addr; char s[11];} '
case is also broken on x86, because sizeof (obj) is smaller
on i386, even though the location of the members are
the same. i.e. you can copy_from_user() this, but not
copy_to_user(), which overwrites 4 bytes after the end of
the 20-byte user structure.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Em Thu, 25 Apr 2019 16:35:34 +0100
Al Viro escreveu:
> On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
>
> > If I understand your patch description well, using compat_ptr_ioctl
> > only works if the driver is not for s390, right?
>
> No; s390 is where "oh, just set ->compat_ioctl same as ->unlocked_ioctl
> and be done with that; compat_ptr() is a no-op anyway" breaks. IOW,
> s390 is the reason for having compat_ptr_ioctl() in the first place;
> that thing works on all biarch architectures, as long as all stuff
> handled by ->ioctl() takes pointer to arch-independent object as
> argument. IOW,
> argument ignored => OK
> any arithmetical type => no go, compat_ptr() would bugger it
> pointer to int => OK
That's the case for all LIRC ioctls: they all use a pointer to u32
argument.
> pointer to string => OK
> pointer to u64 => OK
> pointer to struct {u64 addr; char s[11];} => OK
> pointer to long => needs explicit handler
> pointer to struct {void *addr; char s[11];} => needs explicit handler
> pointer to struct {int x; u64 y;} => needs explicit handler on amd64
> For "just use ->unlocked_ioctl for ->ioctl" we have
> argument ignored => OK
> any arithmetical type => OK
> any pointer => instant breakage on s390, in addtion to cases that break
> with compat_ptr_ioctl().
>
> Probably some form of that ought to go into commit message for
> compat_ptr_ioctl()
> introduction...
Agreed.
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/prime: split drm_gem_prime_handle_to_fd()
From: Emil Velikov
Currently drm_gem_prime_handle_to_fd() consists of illegible amount of
goto labels, for no obvious reason.
Split it in two (as below) making the code far simpler and obvious.
drm_gem_prime_handle_to_fd()
- prime mtx handling
- drm_gem_object lookup and refcounting
- creating an fd for the dmabuf
- hash table lookup
export_handle_to_buf()
- drm_gem_object export and locking
- adding the handle/fd to the hash table
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Currently we dma_buf_put() [in the error path] even for re-export of
original imported object and "self-export" - aka
obj->import_attach->dmabuf and obj->dmabuf.
Have not looked at it too closely, but gut suggests that may be off.
---
drivers/gpu/drm/drm_prime.c | 106 +++-
1 file changed, 57 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 0d83b9bbf793..2b0b6e7a6a47 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -545,11 +545,54 @@ static struct dma_buf *export_and_register_object(struct
drm_device *dev,
* will clean it up.
*/
obj->dma_buf = dmabuf;
- get_dma_buf(obj->dma_buf);
return dmabuf;
}
+static struct dma_buf *export_handle_to_buf(struct drm_device *dev,
+ struct drm_file *file_priv,
+ struct drm_gem_object *obj,
+ uint32_t handle,
+ uint32_t flags)
+{
+ struct dma_buf *dmabuf = NULL;
+ int ret;
+
+ mutex_lock(>object_name_lock);
+ /* re-export the original imported object */
+ if (obj->import_attach)
+ dmabuf = obj->import_attach->dmabuf;
+
+ if (!dmabuf)
+ dmabuf = obj->dma_buf;
+
+ if (!dmabuf)
+ dmabuf = export_and_register_object(dev, obj, flags);
+
+ if (IS_ERR(dmabuf)) {
+ /* normally the created dma-buf takes ownership of the ref,
+* but if that fails then drop the ref
+*/
+ mutex_unlock(>object_name_lock);
+ return dmabuf;
+ }
+
+ get_dma_buf(dmabuf);
+
+ /*
+* If we've exported this buffer then cheat and add it to the import
list
+* so we get the correct handle back. We must do this under the
+* protection of dev->object_name_lock to ensure that a racing gem close
+* ioctl doesn't miss to remove this buffer handle from the cache.
+*/
+ ret = drm_prime_add_buf_handle(_priv->prime, dmabuf, handle);
+ mutex_unlock(>object_name_lock);
+ if (ret) {
+ dma_buf_put(dmabuf);
+ dmabuf = ERR_PTR(ret);
+ }
+ return dmabuf;
+}
/**
* drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
* @dev: dev to export the buffer from
@@ -569,7 +612,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
int *prime_fd)
{
struct drm_gem_object *obj;
- int ret = 0;
+ int ret;
struct dma_buf *dmabuf;
mutex_lock(_priv->prime.lock);
@@ -580,49 +623,14 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
}
dmabuf = drm_prime_lookup_buf_by_handle(_priv->prime, handle);
- if (dmabuf) {
- get_dma_buf(dmabuf);
- goto out_have_handle;
- }
+ if (!dmabuf)
+ dmabuf = export_handle_to_buf(dev, file_priv, obj, handle,
flags);
- mutex_lock(>object_name_lock);
- /* re-export the original imported object */
- if (obj->import_attach) {
- dmabuf = obj->import_attach->dmabuf;
- get_dma_buf(dmabuf);
- goto out_have_obj;
- }
-
- if (obj->dma_buf) {
- get_dma_buf(obj->dma_buf);
- dmabuf = obj->dma_buf;
- goto out_have_obj;
- }
-
- dmabuf = export_and_register_object(dev, obj, flags);
if (IS_ERR(dmabuf)) {
- /* normally the created dma-buf takes ownership of the ref,
-* but if that fails then drop the ref
-*/
ret = PTR_ERR(dmabuf);
- mutex_unlock(>object_name_lock);
- goto out;
+ goto out_object_put;
}
-out_have_obj:
- /*
-* If we've exported this buffer then cheat and add it to the import
list
-* so we get the correct handle back. We must do this under the
-* protection of dev->object_name_lock to ensure that a racing gem close
-* ioctl doesn't miss to remove this buffer handle from the cache.
-*/
- ret = drm_prime_add_buf_handle(_priv->prime,
- dmabuf, handle);
- mutex_unlock(>object_name_lock);
- if (ret)
-
[PATCH 1/2] drm/prime: split drm_gem_prime_fd_to_handle()
From: Emil Velikov
Currently drm_gem_prime_fd_to_handle() consists of illegible amount of
goto labels, for no obvious reason.
Split it in two (as below) making the code far simpler and obvious.
drm_gem_prime_fd_to_handle()
- prime mtx handling
- fd/dmabuf refcounting
- hash table lookup
import_buf_to_handle()
- drm_gem_object import and locking
- creating a handle for the gem object
- adding the handle/fd to the hash table
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_prime.c | 86 ++---
1 file changed, 41 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index dc079efb3b0f..0d83b9bbf793 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -777,37 +777,14 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
}
EXPORT_SYMBOL(drm_gem_prime_import);
-/**
- * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
- * @dev: dev to export the buffer from
- * @file_priv: drm file-private structure
- * @prime_fd: fd id of the dma-buf which should be imported
- * @handle: pointer to storage for the handle of the imported buffer object
- *
- * This is the PRIME import function which must be used mandatorily by GEM
- * drivers to ensure correct lifetime management of the underlying GEM object.
- * The actual importing of GEM object from the dma-buf is done through the
- * gem_import_export driver callback.
- */
-int drm_gem_prime_fd_to_handle(struct drm_device *dev,
- struct drm_file *file_priv, int prime_fd,
- uint32_t *handle)
+static int import_buf_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv,
+ struct dma_buf *dma_buf,
+ uint32_t *handle)
{
- struct dma_buf *dma_buf;
struct drm_gem_object *obj;
int ret;
- dma_buf = dma_buf_get(prime_fd);
- if (IS_ERR(dma_buf))
- return PTR_ERR(dma_buf);
-
- mutex_lock(_priv->prime.lock);
-
- ret = drm_prime_lookup_buf_handle(_priv->prime,
- dma_buf, handle);
- if (ret == 0)
- goto out_put;
-
/* never seen this one, need to import */
mutex_lock(>object_name_lock);
if (dev->driver->gem_prime_import)
@@ -816,7 +793,8 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
obj = drm_gem_prime_import(dev, dma_buf);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
- goto out_unlock;
+ mutex_unlock(>object_name_lock);
+ return ret;
}
if (obj->dma_buf) {
@@ -830,29 +808,47 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
ret = drm_gem_handle_create_tail(file_priv, obj, handle);
drm_gem_object_put_unlocked(obj);
if (ret)
- goto out_put;
+ return ret;
- ret = drm_prime_add_buf_handle(_priv->prime,
- dma_buf, *handle);
- mutex_unlock(_priv->prime.lock);
+ ret = drm_prime_add_buf_handle(_priv->prime, dma_buf, *handle);
if (ret)
- goto fail;
+ /* hmm, if driver attached, we are relying on the free-object
+* path to detach.. which seems ok..
+*/
+ drm_gem_handle_delete(file_priv, *handle);
- dma_buf_put(dma_buf);
+ return ret;
+}
- return 0;
+/**
+ * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
+ * @dev: dev to export the buffer from
+ * @file_priv: drm file-private structure
+ * @prime_fd: fd id of the dma-buf which should be imported
+ * @handle: pointer to storage for the handle of the imported buffer object
+ *
+ * This is the PRIME import function which must be used mandatorily by GEM
+ * drivers to ensure correct lifetime management of the underlying GEM object.
+ * The actual importing of GEM object from the dma-buf is done through the
+ * gem_import_export driver callback.
+ */
+int drm_gem_prime_fd_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv, int prime_fd,
+ uint32_t *handle)
+{
+ struct dma_buf *dma_buf;
+ int ret;
-fail:
- /* hmm, if driver attached, we are relying on the free-object path
-* to detach.. which seems ok..
-*/
- drm_gem_handle_delete(file_priv, *handle);
- dma_buf_put(dma_buf);
- return ret;
+ dma_buf = dma_buf_get(prime_fd);
+ if (IS_ERR(dma_buf))
+ return PTR_ERR(dma_buf);
+
+ mutex_lock(_priv->prime.lock);
+
+ ret = drm_prime_lookup_buf_handle(_priv->prime, dma_buf, handle);
+ if (ret)
+ ret = import_buf_to_handle(dev, file_priv, dma_buf, handle);
-out_unlock:
-
[Bug 110355] radeonsi: GTK elements become invisible in some applications (GIMP, LibreOffice)
https://bugs.freedesktop.org/show_bug.cgi?id=110355 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Marek Olšák --- Fixed by 440135e5a0d178c537db3f96e6823bc8220a0f3f. Closing. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: call kfree() w/o mutex held in dma_buf_attach()
From: Emil Velikov In dma_buf_attach() we allocate memory w/o a mutex being held, thus in the error path we should kfree() it after the mutex_unlock. The inverse function dma_buf_deattach() gets this right. Cc: Sumit Semwal Signed-off-by: Emil Velikov --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 3ae6c0c2cc02..57ddeb735b8b 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -579,8 +579,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, return attach; err_attach: - kfree(attach); mutex_unlock(>lock); + kfree(attach); return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(dma_buf_attach); -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
On Thu, Apr 25, 2019 at 5:22 PM Mauro Carvalho Chehab wrote: > Em Tue, 16 Apr 2019 22:25:33 +0200 Arnd Bergmann escreveu: > > If I understand your patch description well, using compat_ptr_ioctl > only works if the driver is not for s390, right? No, the purpose of compat_ptr_ioctl() is to make sure it works everywhere including s390. Even on s390 it tends to work most of the time, but for correctness the upper bit of a 32-bit pointer needs to be cleared, as compat_ptr_ioctl does, in case some application passes a pointer with that bit set. [IIRC, in the instruction pointer, the high bit is set, in data references it is ignored but usually cleared, but it may be left on for IP-relative address generation] Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/26] compat_ioctl: move more drivers to compat_ptr_ioctl
Em Tue, 16 Apr 2019 22:25:33 +0200
Arnd Bergmann escreveu:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Acked-by: Jason Gunthorpe
> Acked-by: Daniel Vetter
> Acked-by: Mauro Carvalho Chehab
> Acked-by: Greg Kroah-Hartman
> Acked-by: David Sterba
> Acked-by: Darren Hart (VMware)
> Acked-by: Jonathan Cameron
> Acked-by: Bjorn Andersson
> Signed-off-by: Arnd Bergmann
> ---
> drivers/android/binder.c| 2 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +---
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 2 +-
> drivers/hid/hidraw.c| 4 +---
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 ++--
> drivers/media/rc/lirc_dev.c | 4 +---
If I understand your patch description well, using compat_ptr_ioctl
only works if the driver is not for s390, right?
In thesis, nothing prevents to use LIRC API on s390 - as this isn't
a driver but, instead, RC core feature to expose raw remote controller
codes to userspace.
Yet, lirc_dev will only work if the system has a remote controller driver.
Well, we don't have any for s390. Despite we don't have such driver,
I can't possible see why someone would use a remote controller for a
mainframe :-p
Anyway, if someone ever come with such driver/usecase, reverting this
change (or adding an #ifdef to check if arch is 390) should be
pretty straight forward.
So:
Acked-by: Mauro Carvalho Chehab
> drivers/mfd/cros_ec_dev.c | 4 +---
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/nvdimm/bus.c| 4 ++--
> drivers/nvme/host/core.c| 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 ++--
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +---
> drivers/scsi/3w-.c | 4 +---
> drivers/scsi/cxlflash/main.c| 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/pmcraid.c | 4 +---
> drivers/staging/android/ion/ion.c | 4 +---
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +---
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c| 2 +-
> fs/ceph/dir.c | 2 +-
> fs/ceph/file.c | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c| 2 +-
> net/rfkill/core.c | 2 +-
> 36 files changed, 39 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 4b9c7ca492e6..48109ade7234 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -5998,7 +5998,7 @@ const struct file_operations binder_fops = {
> .owner = THIS_MODULE,
> .poll = binder_poll,
> .unlocked_ioctl = binder_ioctl,
> - .compat_ioctl = binder_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> .mmap = binder_mmap,
> .open = binder_open,
> .flush = binder_flush,
> diff --git a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> index abc7a7f64d64..ef0e482ee04f 100644
> --- a/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> +++ b/drivers/crypto/qat/qat_common/adf_ctl_drv.c
> @@ -68,7 +68,7 @@ static long adf_ctl_ioctl(struct file *fp, unsigned int
> cmd, unsigned long arg);
> static const struct file_operations adf_ctl_ops = {
> .owner = THIS_MODULE,
> .unlocked_ioctl = adf_ctl_ioctl,
> - .compat_ioctl = adf_ctl_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
> };
>
> struct adf_ctl_drv_info {
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 7c858020d14b..0cb336fe6324 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++
Re: Support for 2D engines/blitters in V4L2 and DRM
On 2019-04-24 7:43 p.m., Nicolas Dufresne wrote: > Le mercredi 24 avril 2019 à 18:54 +0200, Michel Dänzer a écrit : >> On 2019-04-24 5:44 p.m., Nicolas Dufresne wrote: >>> Le mercredi 24 avril 2019 à 17:06 +0200, Daniel Vetter a écrit : On Wed, Apr 24, 2019 at 4:41 PM Paul Kocialkowski wrote: > On Wed, 2019-04-24 at 16:39 +0200, Michel Dänzer wrote: >> On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote: >>> Rendering a video stream is more complex then what you describe here. >>> Whenever there is a unexpected delay (late delivery of a frame as an >>> example) you may endup in situation where one frame is ready after the >>> targeted vblank. If there is another frame that targets the following >>> vblank that gets ready on-time, the previous frame should be replaced >>> by the most recent one. >>> >>> With fences, what happens is that even if you received the next frame >>> on time, naively replacing it is not possible, because we don't know >>> when the fence for the next frame will be signalled. If you simply >>> always replace the current frame, you may endup skipping a lot more >>> vblank then what you expect, and that results in jumpy playback. >> >> So you want to be able to replace a queued flip with another one then. >> That doesn't necessarily require allowing more than one flip to be >> queued ahead of time. > > There might be other ways to do it, but this one has plenty of > advantages. The point of kms (well one of the reasons) was to separate the implementation of modesetting for specific hw from policy decisions like which frames to drop and how to schedule them. Kernel gives tools, userspace implements the actual protocols. There's definitely a bit a gap around scheduling flips for a specific frame or allowing to cancel/overwrite an already scheduled flip, but no one yet has come up with a clear proposal for new uapi + example implementation + userspace implementation + big enough support from other compositors that this is what they want too. >> >> Actually, the ATOMIC_AMEND patches propose a way to replace a scheduled >> flip? >> >> >> Note that this can also be done in userspace with explicit fencing (by >> only selecting a frame and submitting it to the kernel after all >> corresponding fences have signalled), at least to some degree, but the >> kernel should be able to do it up to a later point in time and more >> reliably, with less risk of missing a flip for a frame which becomes >> ready just in time. > > Indeed, but it would be great if we could do that with implicit fencing > as well. 1. extract implicit fences from dma-buf. This part is just an idea, but easy to implement once we have someone who actually wants this. All we need is a new ioctl on the dma-buf to export the fences from the reservation_object as a sync_file (either the exclusive or the shared ones, selected with a flag). 2. do the exact same frame scheduling as with explicit fencing 3. supply explicit fences in your atomic ioctl calls - these should overrule any implicit fences (assuming correct kernel drivers, but we have helpers so you can assume they all work correctly). By design this is possible, it's just that no one yet bothered enough to make it happen. -Daniel >>> >>> I'm not sure I understand the workflow of this one. I'm all in favour >>> leaving the hard work to userspace. Note that I have assumed explicit >>> fences from the start, I don't think implicit fence will ever exist in >>> v4l2, but I might be wrong. What I understood is that there was a >>> previous attempt in the past but it raised more issues then it actually >>> solved. So that being said, how do handle exactly the follow use cases: >>> >>> - A frame was lost by capture driver, but it was schedule as being the >>> next buffer to render (normally previous frame should remain). >> >> Userspace just doesn't call into the kernel to flip to the lost frame, >> so the previous one remains. > > We are stuck in a loop you a me. Considering v4l2 to drm, where fences > don't exist on v4l2, it makes very little sense to bring up fences if > we are to wait on the fence in userspace. It makes sense insofar as no V4L specific code would be needed to make sure that the contents of a buffer produced via V4L aren't consumed before they're ready to be. >>> - The scheduled frame is late for the next vblank (didn't signal on- >>> time), a new one may be better for the next vlbank, but we will only >>> know when it's fence is signaled. >> >> Userspace only selects a frame and submits it to the kernel after all >> its fences have signalled. >> >>> Better in this context means the the presentation time of this frame is >>> closer to the next vblank time. Keep in mind that the idea is to >>> schedule the
Re: [PATCH] drm/gem: Fix sphinx warnings
On Wed, Apr 24, 2019 at 02:59:00PM -0700, Eric Anholt wrote: > Sean Paul writes: > > > From: Sean Paul > > > > Sphinx really wants colons after arguments :/ > > > > Fixes the following warnings: > > drm_gem.c:1384: warning: Function parameter or member 'fence_array' not > > described in 'drm_gem_fence_array_add' > > drm_gem.c:1384: warning: Function parameter or member 'fence' not described > > in 'drm_gem_fence_array_add' > > drm_gem.c:1435: warning: Function parameter or member 'fence_array' not > > described in 'drm_gem_fence_array_add_implicit' > > drm_gem.c:1435: warning: Function parameter or member 'obj' not described > > in 'drm_gem_fence_array_add_implicit' > > drm_gem.c:1435: warning: Function parameter or member 'write' not described > > in 'drm_gem_fence_array_add_implicit' > > Hopefully some day we can move to gitlab and have CI and make sure we > don't screw this stuff up ever again. Fingers crossed :) Until then, this has been pushed with your R-b, thanks! Sean > > Reviewed-by: Eric Anholt -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: check for equals 0 only
wait_for_completion_timeout() returns 0 on timeout and aleast 1 otherwise so checking for < makes no sense here. Signed-off-by: Nicholas Mc Guire --- Problem located with an experimental coccinelle script While this check does no harm in this form - it should be fixed anyway to comply with the API see: kernel/sched/completion.c Also noticed that get_maintainer.pl will not list linux-ker...@vger.kernel.org when run on drivers/gpu/drm/msm/dsi/dsi_host.c - is that intentional ? Patch was compile-tested with: qcom_defconfig (implies DRM_MSM_DSI=y) Patch is against v5.1-rc6 (localversion-next is next-20190424) drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index 610183d..dc16067 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -1049,7 +1049,7 @@ static void dsi_wait4video_done(struct msm_dsi_host *msm_host) ret = wait_for_completion_timeout(_host->video_comp, msecs_to_jiffies(70)); - if (ret <= 0) + if (ret == 0) DRM_DEV_ERROR(dev, "wait for video done timed out\n"); dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0); -- 2.1.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110510] Radeon VII HDMI issues: Flicking/system crashing
https://bugs.freedesktop.org/show_bug.cgi?id=110510 --- Comment #4 from Tom B --- Unfortunately this workaround does not work. As soon as I launch a game on either monitor the whole system freezes despite the performance setting. Nothing appeared in journalctl this time but it seems like the same kind of freeze. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 18/29] lockdep: Remove save argument from check_prev_add()
On Thu, Apr 25, 2019 at 11:45:11AM +0200, Thomas Gleixner wrote: > There is only one caller which hands in save_trace as function pointer. > > Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 00/29] stacktrace: Consolidate stack trace usage
On Thu, Apr 25, 2019 at 11:44:53AM +0200, Thomas Gleixner wrote: > This is an update to V2 which can be found here: > > https://lkml.kernel.org/r/20190418084119.056416...@linutronix.de > > Changes vs. V2: > > - Fixed the kernel-doc issue pointed out by Mike > > - Removed the '-1' oddity from the tracer > > - Restricted the tracer nesting to 4 > > - Restored the lockdep magic to prevent redundant stack traces > > - Addressed the small nitpicks here and there > > - Picked up Acked/Reviewed tags Other than the 2 minor nits: Reviewed-by: Josh Poimboeuf -- Josh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 24/29] tracing: Remove the last struct stack_trace usage
On Thu, Apr 25, 2019 at 11:45:17AM +0200, Thomas Gleixner wrote:
> Simplify the stack retrieval code by using the storage array based
> interface.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Steven Rostedt (VMware)
> ---
> kernel/trace/trace_stack.c | 37 -
> 1 file changed, 16 insertions(+), 21 deletions(-)
>
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -23,11 +23,7 @@
> static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES];
> static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
>
> -struct stack_trace stack_trace_max = {
> - .max_entries= STACK_TRACE_ENTRIES,
> - .entries= _dump_trace[0],
> -};
> -
> +static unsigned int stack_trace_entries;
"stack_trace_entries" -> "nr_stack_trace_entries"
--
Josh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 21/29] tracing: Use percpu stack trace buffer more intelligently
On Thu, Apr 25, 2019 at 11:45:14AM +0200, Thomas Gleixner wrote:
> @@ -2788,29 +2798,32 @@ static void __ftrace_trace_stack(struct
>*/
> preempt_disable_notrace();
>
> - use_stack = __this_cpu_inc_return(ftrace_stack_reserve);
> + stackidx = __this_cpu_inc_return(ftrace_stack_reserve);
> +
> + /* This should never happen. If it does, yell once and skip */
> + if (WARN_ON_ONCE(stackidx >= FTRACE_KSTACK_NESTING))
> + goto out;
> +
> /*
> - * We don't need any atomic variables, just a barrier.
> - * If an interrupt comes in, we don't care, because it would
> - * have exited and put the counter back to what we want.
> - * We just need a barrier to keep gcc from moving things
> - * around.
> + * The above __this_cpu_inc_return() is 'atomic' cpu local. An
> + * interrupt will either see the value pre increment or post
> + * increment. If the interrupt happens pre increment it will have
> + * restored the counter when it returns. We just need a barrier to
> + * keep gcc from moving things around.
>*/
> barrier();
> - if (use_stack == 1) {
> - trace.entries = this_cpu_ptr(ftrace_stack.calls);
> - trace.max_entries = FTRACE_STACK_MAX_ENTRIES;
> -
> - if (regs)
> - save_stack_trace_regs(regs, );
> - else
> - save_stack_trace();
> -
> - if (trace.nr_entries > size)
> - size = trace.nr_entries;
> - } else
> - /* From now on, use_stack is a boolean */
> - use_stack = 0;
> +
> + fstack = this_cpu_ptr(ftrace_stacks.stacks) + (stackidx - 1);
nit: it would be slightly less surprising if stackidx were 0-based:
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d3f6ec7eb729..4fc93004feab 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2798,10 +2798,10 @@ static void __ftrace_trace_stack(struct ring_buffer
*buffer,
*/
preempt_disable_notrace();
- stackidx = __this_cpu_inc_return(ftrace_stack_reserve);
+ stackidx = __this_cpu_inc_return(ftrace_stack_reserve) - 1;
/* This should never happen. If it does, yell once and skip */
- if (WARN_ON_ONCE(stackidx >= FTRACE_KSTACK_NESTING))
+ if (WARN_ON_ONCE(stackidx > FTRACE_KSTACK_NESTING))
goto out;
/*
@@ -2813,7 +2813,7 @@ static void __ftrace_trace_stack(struct ring_buffer
*buffer,
*/
barrier();
- fstack = this_cpu_ptr(ftrace_stacks.stacks) + (stackidx - 1);
+ fstack = this_cpu_ptr(ftrace_stacks.stacks) + stackidx;
trace.entries = fstack->calls;
trace.max_entries = FTRACE_KSTACK_ENTRIES;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Daniel, Dave, Here is a new drm-misc-fixes PR. Thanks! Maxime drm-misc-fixes-2019-04-25: - sun4i: Fix module loading / unloading - vc4: Fix a compilation error and memory leak - dw-hdmi: Fix an overflow on Rockchip and SCDC configuration The following changes since commit 1a07a94b47b1f528f39c3e6187b5eaf02efe44ea: drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind (2019-04-08 10:30:23 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-04-25 for you to fetch changes up to c4cba44eeecab9d5ccd3dd2d5520a7d1e5be544f: drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus (2019-04-25 10:38:21 +0200) - sun4i: Fix module loading / unloading - vc4: Fix a compilation error and memory leak - dw-hdmi: Fix an overflow on Rockchip and SCDC configuration Jonas Karlman (2): drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus Maarten Lankhorst (2): drm/vc4: Fix memory leak during gpu reset. drm/vc4: Fix compilation error reported by kbuild test bot Paul Kocialkowski (4): drm/sun4i: Add missing drm_atomic_helper_shutdown at driver unbind drm/sun4i: Set device driver data at bind time for use in unbind drm/sun4i: Fix component unbinding and component master deletion drm/sun4i: Unbind components before releasing DRM and memory drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 16 drivers/gpu/drm/sun4i/sun4i_drv.c | 9 + drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- 3 files changed, 22 insertions(+), 5 deletions(-) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip
https://bugs.freedesktop.org/show_bug.cgi?id=110514 --- Comment #3 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * CML: igt@kms_addfb_basic@* - skip - Test requirement: gen = 9, SKIP - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12873/fi-cml-u/igt@kms_addfb_ba...@addfb25-y-tiled-small.html - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2918/fi-cml-u/igt@kms_addfb_ba...@addfb25-y-tiled-small.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50
On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> On a very specific subset of ThinkPad P50 SKUs, particularly ones that
> come with a Quadro M1000M chip instead of the M2000M variant, the BIOS
> seems to have a very nasty habit of not always resetting the secondary
> Nvidia GPU between full reboots if the laptop is configured in Hybrid
> Graphics mode. The reason for this happening is unknown, but the
> following steps and possibly a good bit of patience will reproduce the
> issue:
>
> 1. Boot up the laptop normally in Hybrid graphics mode
> 2. Make sure nouveau is loaded and that the GPU is awake
> 2. Allow the nvidia GPU to runtime suspend itself after being idle
> 3. Reboot the machine, the more sudden the better (e.g sysrq-b may help)
> 4. If nouveau loads up properly, reboot the machine again and go back to
> step 2 until you reproduce the issue
>
> This results in some very strange behavior: the GPU will
> quite literally be left in exactly the same state it was in when the
> previously booted kernel started the reboot. This has all sorts of bad
> sideaffects: for starters, this completely breaks nouveau starting with a
> mysterious EVO channel failure that happens well before we've actually
> used the EVO channel for anything:
>
> nouveau :01:00.0: disp: chid 0 mthd data 0400 1000
> 0002
> ...
> So to do this, we add a new pci quirk using
> DECLARE_PCI_FIXUP_CLASS_FINAL that will be invoked before the PCI probe
> at boot finishes. From there, we check to make sure that this is indeed
> the specific P50 variant of this GPU. We also make sure that the GPU PCI
> device is advertising NoReset- in order to prevent us from trying to
> reset the GPU when the machine is in Dedicated graphics mode (where the
> GPU being initialized by the BIOS is normal and expected). Finally, we
> try mapping the MMIO space for the GPU which should only work if the GPU
> is actually active in D0 mode. We can then read the magic 0x2240c
> register on the GPU, which will have bit 1 set if the GPU's firmware has
> already been posted during a previous boot. Once we've confirmed all of
> this, we reset the PCI device and re-disable it - bringing the GPU back
> into a healthy state.
>
> Signed-off-by: Lyude Paul
> Cc: nouv...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Karol Herbst
> Cc: Ben Skeggs
> Cc: sta...@vger.kernel.org
Applied to pci/misc for v5.2, thanks!
> ---
> drivers/pci/quirks.c | 65
> 1 file changed, 65 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b0a413f3f7ca..948492fda8bf 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5117,3 +5117,68 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */
> SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
> SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
> SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
> +
> +/*
> + * On certain Lenovo Thinkpad P50 SKUs, specifically those with a Nvidia
> + * Quadro M1000M, the BIOS will occasionally make the mistake of not
> resetting
> + * the nvidia GPU between reboots if the system is configured to use hybrid
> + * graphics mode. This results in the GPU being left in whatever state it was
> + * in during the previous boot which causes spurious interrupts from the GPU,
> + * which in turn cause us to disable the wrong IRQs and end up breaking the
> + * touchpad. Unsurprisingly, this also completely breaks nouveau.
> + *
> + * Luckily, it seems a simple reset of the PCI device for the nvidia GPU
> + * manages to bring the GPU back into a clean state and fix all of these
> + * issues. Additionally since the GPU will report NoReset+ when the machine
> is
> + * configured in Dedicated display mode, we don't need to worry about
> + * accidentally resetting the GPU when it's supposed to already be
> + * initialized.
> + */
> +static void
> +quirk_lenovo_thinkpad_p50_nvgpu_survives_reboot(struct pci_dev *pdev)
> +{
> + void __iomem *map;
> + int ret;
> +
> + if (pdev->subsystem_vendor != PCI_VENDOR_ID_LENOVO ||
> + pdev->subsystem_device != 0x222e ||
> + !pdev->reset_fn)
> + return;
> +
> + /*
> + * If we can't enable the device's mmio space, it's probably not even
> + * initialized. This is fine, and means we can just skip the quirk
> + * entirely.
> + */
> + if (pci_enable_device_mem(pdev)) {
> + pci_dbg(pdev, "Can't enable device mem, no reset needed\n");
> + return;
> + }
> +
> + /* Taken from drivers/gpu/drm/nouveau/engine/device/base.c */
> + map = ioremap(pci_resource_start(pdev, 0), 0x102000);
> + if (!map) {
> + pci_err(pdev, "Can't map MMIO space, this is probably very
> bad\n");
> + goto out_disable;
> + }
> +
> + /*
> + * Be extra careful, and make sure that the GPU firmware is posted
> + * before trying a reset
> + */
> + if
Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable
Hi Andrzej,
On 25/04/2019 13:13, Andrzej Hajda wrote:
> On 24.04.2019 16:22, Matt Redfearn wrote:
>> The DRM documentation states that post_disable is an optional callback.
>> As such an implementing device may not populate it. To avoid panicing
>> the kernel by calling a NULL function pointer, we should NULL check it
>> before blindy calling it.
>>
>> Signed-off-by: Matt Redfearn
>
>> ---
>>
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index 38e88071363..0ee440216b8 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct
>> drm_bridge *bridge)
>> * This needs to be fixed in the drm_bridge framework and the API
>> * needs to be updated to manage our own call chains...
>> */
>> -dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
>> +if (dsi->panel_bridge->funcs->post_disable)
>> +dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
>>
>
> Why not drm_bridge_post_disable ?
Ah - that seems like a nicer fix! Do you think the comment above
describing why this function pointer is called directly can be removed
as well if we go this route?
If someone calls drm_bridge_post_disable() on the Synposys DSI
drm_bridge it will go on to call post_disable on all other bridges in
the chain, in addition to us calling them here. Is it an issue to call
it multiple times?
Thanks,
Matt
>
>
> Regards
>
> Andrzej
>
>
>> if (dsi->slave) {
>> dw_mipi_dsi_disable(dsi->slave);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Allow VPG to be enabled via debugfs
Hi Laurent,
Thanks for the review!
On 25/04/2019 10:31, Laurent Pinchart wrote:
> On Wed, Apr 24, 2019 at 02:22:18PM +, Matt Redfearn wrote:
>> The Synopsys MIPI DSI IP contains a video test pattern generator which
>> is helpful in debugging video timing with connected displays.
>> Add a debugfs directory containing files which allow the VPG to be
>> enabled and disabled, and it's orientation to be changed.
>
> s/it's/its/
>>
>> Signed-off-by: Matt Redfearn
>>
>> ---
>>
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 55 +++
>> 1 file changed, 55 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index 0ee440216b8..a1ee2306382 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -10,6 +10,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -86,6 +87,8 @@
>> #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
>> #define VID_MODE_TYPE_BURST0x2
>> #define VID_MODE_TYPE_MASK 0x3
>> +#define VID_MODE_VPG_ENABLE BIT(16)
>> +#define VID_MODE_VPG_HORIZONTAL BIT(24)
>>
>> #define DSI_VID_PKT_SIZE 0x3c
>> #define VID_PKT_SIZE(p)((p) & 0x3fff)
>> @@ -234,6 +237,15 @@ struct dw_mipi_dsi {
>> u32 format;
>> unsigned long mode_flags;
>>
>> +#ifdef CONFIG_DEBUG_FS
>> +struct dentry *debugfs_root;
>> +struct dentry *debugfs_vpg;
>> +struct dentry *debugfs_vpg_horizontal;
>> +
>> +bool vpg;
>> +bool vpg_horizontal;
>> +#endif /* CONFIG_DEBUG_FS */
>> +
>> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
>> struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
>>
>> @@ -525,6 +537,11 @@ static void dw_mipi_dsi_video_mode_config(struct
>> dw_mipi_dsi *dsi)
>> else
>> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>>
>> +if (dsi->vpg) {
>
> Won't this break if CONFIG_DDEBUG_FS is not defined ?
Ah yes - quite right.
>
>> +val |= VID_MODE_VPG_ENABLE;
>> +val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
>> +}
>> +
>> dsi_write(dsi, DSI_VID_MODE_CFG, val);
>> }
>>
>> @@ -935,6 +952,41 @@ static const struct drm_bridge_funcs
>> dw_mipi_dsi_bridge_funcs = {
>> .attach = dw_mipi_dsi_bridge_attach,
>> };
>>
>> +#ifdef CONFIG_DEBUG_FS
>> +
>> +static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi)
>> +{
>> +struct dentry *d;
>> +
>> +d = debugfs_create_dir(dev_name(dsi->dev), NULL);
>> +if (IS_ERR(d)) {
>> +dev_err(dsi->dev, "failed to create debugfs root\n");
>> +return;
>> +}
>> +dsi->debugfs_root = d;
>> +
>> +d = debugfs_create_bool("vpg", 0660, dsi->debugfs_root, >vpg);
>> +dsi->debugfs_vpg = d;
>
> If you don't handle failures here you don't need the intermediate d
> variable, you can just assign dsi->debugfs_vpg directly.
True - I will update it.
>
>> +
>> +d = debugfs_create_bool("vpg_horizontal", 0660, dsi->debugfs_root,
>> +>vpg_horizontal);
>> +dsi->debugfs_vpg_horizontal = d;
>
> Same here.
And here - thanks!
Matt
>
>> +}
>> +
>> +static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi)
>> +{
>> +debugfs_remove(dsi->debugfs_vpg_horizontal);
>> +debugfs_remove(dsi->debugfs_vpg);
>> +debugfs_remove(dsi->debugfs_root);
>> +}
>> +
>> +#else
>> +
>> +static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi) { }
>> +static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi) { }
>> +
>> +#endif /* CONFIG_DEBUG_FS */
>> +
>> static struct dw_mipi_dsi *
>> __dw_mipi_dsi_probe(struct platform_device *pdev,
>> const struct dw_mipi_dsi_plat_data *plat_data)
>> @@ -1005,6 +1057,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
>> clk_disable_unprepare(dsi->pclk);
>> }
>>
>> +dw_mipi_dsi_debugfs_init(dsi);
>> pm_runtime_enable(dev);
>>
>> dsi->dsi_host.ops = _mipi_dsi_host_ops;
>> @@ -1012,6 +1065,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
>> ret = mipi_dsi_host_register(>dsi_host);
>> if (ret) {
>> dev_err(dev, "Failed to register MIPI host: %d\n", ret);
>> +dw_mipi_dsi_debugfs_remove(dsi);
>> return ERR_PTR(ret);
>> }
>>
>> @@ -1029,6 +1083,7 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi
>> *dsi)
>> mipi_dsi_host_unregister(>dsi_host);
>>
>> pm_runtime_disable(dsi->dev);
>> +dw_mipi_dsi_debugfs_remove(dsi);
>> }
>>
>> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi
>> *slave)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip
https://bugs.freedesktop.org/show_bug.cgi?id=110514 --- Comment #2 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * CML: igt@* - skip - Test requirement: is_i915_device(fd) has_known_intel_chipset(fd), Skip (No new failures associated) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110514] [CI][BAT] igt@* - skip - Test requirement: is_i915_device(fd) && has_known_intel_chipset(fd), Skip
https://bugs.freedesktop.org/show_bug.cgi?id=110514 Martin Peres changed: What|Removed |Added Component|DRM/Intel |IGT Priority|medium |highest QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Whiteboard||ReadyForDev i915 platform||CFL Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #1 from Martin Peres --- Moving to IGT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/4] drm/vc4: Allocate binner bo when starting to use the V3D
The binner BO is not required until the V3D is in use, so avoid
allocating it at probe and do it on the first non-dumb BO allocation.
Keep track of which clients are using the V3D and liberate the buffer
when there is none left, using a kref. Protect the logic with a
mutex to avoid race conditions.
The binner BO is created at the time of the first render ioctl and is
destroyed when there is no client and no exec job using it left.
The Out-Of-Memory (OOM) interrupt also gets some tweaking, to avoid
enabling it before having allocated a binner bo.
We also want to keep the BO alive during runtime suspend/resume to avoid
failing to allocate it at resume. This happens when the CMA pool is
full at that point and results in a hard crash.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_bo.c | 33 +++-
drivers/gpu/drm/vc4/vc4_drv.c | 6
drivers/gpu/drm/vc4/vc4_drv.h | 14 +
drivers/gpu/drm/vc4/vc4_gem.c | 13
drivers/gpu/drm/vc4/vc4_irq.c | 21 +
drivers/gpu/drm/vc4/vc4_v3d.c | 58 +++
6 files changed, 125 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 88ebd681d7eb..2b3ec5926fe2 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -799,13 +799,38 @@ vc4_prime_import_sg_table(struct drm_device *dev,
return obj;
}
+static int vc4_grab_bin_bo(struct vc4_dev *vc4, struct vc4_file *vc4file)
+{
+ int ret;
+
+ if (!vc4->v3d)
+ return -ENODEV;
+
+ if (vc4file->bin_bo_used)
+ return 0;
+
+ ret = vc4_v3d_bin_bo_get(vc4);
+ if (ret)
+ return ret;
+
+ vc4file->bin_bo_used = true;
+
+ return 0;
+}
+
int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_vc4_create_bo *args = data;
+ struct vc4_file *vc4file = file_priv->driver_priv;
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_bo *bo = NULL;
int ret;
+ ret = vc4_grab_bin_bo(vc4, vc4file);
+ if (ret)
+ return ret;
+
/*
* We can't allocate from the BO cache, because the BOs don't
* get zeroed, and that might leak data between users.
@@ -846,6 +871,8 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv)
{
struct drm_vc4_create_shader_bo *args = data;
+ struct vc4_file *vc4file = file_priv->driver_priv;
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_bo *bo = NULL;
int ret;
@@ -865,6 +892,10 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ ret = vc4_grab_bin_bo(vc4, vc4file);
+ if (ret)
+ return ret;
+
bo = vc4_bo_create(dev, args->size, true, VC4_BO_TYPE_V3D_SHADER);
if (IS_ERR(bo))
return PTR_ERR(bo);
@@ -894,7 +925,7 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
*data,
*/
ret = drm_gem_handle_create(file_priv, >base.base, >handle);
- fail:
+fail:
drm_gem_object_put_unlocked(>base.base);
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 6d9be20a32be..0f99ad03614e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -128,8 +128,12 @@ static int vc4_open(struct drm_device *dev, struct
drm_file *file)
static void vc4_close(struct drm_device *dev, struct drm_file *file)
{
+ struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_file *vc4file = file->driver_priv;
+ if (vc4file->bin_bo_used)
+ vc4_v3d_bin_bo_put(vc4);
+
vc4_perfmon_close_file(vc4file);
kfree(vc4file);
}
@@ -274,6 +278,8 @@ static int vc4_drm_bind(struct device *dev)
drm->dev_private = vc4;
INIT_LIST_HEAD(>debugfs_list);
+ mutex_init(>bin_bo_lock);
+
ret = vc4_bo_cache_init(drm);
if (ret)
goto dev_put;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4f13f6262491..5bfca83deb8e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -216,6 +216,11 @@ struct vc4_dev {
* the minor is available (after drm_dev_register()).
*/
struct list_head debugfs_list;
+
+ /* Mutex for binner bo allocation. */
+ struct mutex bin_bo_lock;
+ /* Reference count for our binner bo. */
+ struct kref bin_bo_kref;
};
static inline struct vc4_dev *
@@ -584,6 +589,11 @@ struct vc4_exec_info {
* NULL otherwise.
*/
struct vc4_perfmon *perfmon;
+
+ /* Whether the exec has taken a reference to the binner BO, which should
+* happen with a VC4_PACKET_TILE_BINNING_MODE_CONFIG packet.
+*/
+
[PATCH v7 2/4] drm/vc4: Check for V3D before binner bo alloc
Check that we have a V3D device registered before attempting to allocate a binner buffer object. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c index 7c490106e185..c16db4665af6 100644 --- a/drivers/gpu/drm/vc4/vc4_v3d.c +++ b/drivers/gpu/drm/vc4/vc4_v3d.c @@ -241,6 +241,9 @@ static int bin_bo_alloc(struct vc4_dev *vc4) int ret = 0; struct list_head list; + if (!v3d) + return -ENODEV; + /* We may need to try allocating more than once to get a BO * that doesn't cross 256MB. Track the ones we've allocated * that failed so far, so that we can free them when we've got -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/4] drm/vc4: Reformat and the binner bo allocation helper
In preparation for wrapping the binner bo allocation helper with
put/get helpers, pass the vc4 dev directly and drop the vc4 prefix.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_v3d.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index a4b6859e3af6..7c490106e185 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -213,7 +213,7 @@ int vc4_v3d_get_bin_slot(struct vc4_dev *vc4)
}
/**
- * vc4_allocate_bin_bo() - allocates the memory that will be used for
+ * bin_bo_alloc() - allocates the memory that will be used for
* tile binning.
*
* The binner has a limitation that the addresses in the tile state
@@ -234,9 +234,8 @@ int vc4_v3d_get_bin_slot(struct vc4_dev *vc4)
* overall CMA pool before they make scenes complicated enough to run
* out of bin space.
*/
-static int vc4_allocate_bin_bo(struct drm_device *drm)
+static int bin_bo_alloc(struct vc4_dev *vc4)
{
- struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_v3d *v3d = vc4->v3d;
uint32_t size = 16 * 1024 * 1024;
int ret = 0;
@@ -251,7 +250,7 @@ static int vc4_allocate_bin_bo(struct drm_device *drm)
INIT_LIST_HEAD();
while (true) {
- struct vc4_bo *bo = vc4_bo_create(drm, size, true,
+ struct vc4_bo *bo = vc4_bo_create(vc4->dev, size, true,
VC4_BO_TYPE_BIN);
if (IS_ERR(bo)) {
@@ -333,7 +332,7 @@ static int vc4_v3d_runtime_resume(struct device *dev)
struct vc4_dev *vc4 = v3d->vc4;
int ret;
- ret = vc4_allocate_bin_bo(vc4->dev);
+ ret = bin_bo_alloc(vc4);
if (ret)
return ret;
@@ -403,7 +402,7 @@ static int vc4_v3d_bind(struct device *dev, struct device
*master, void *data)
if (ret != 0)
return ret;
- ret = vc4_allocate_bin_bo(drm);
+ ret = bin_bo_alloc(vc4);
if (ret) {
clk_disable_unprepare(v3d->clk);
return ret;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/4] drm/vc4: Binner BO management improvements
Changes since v6: * Removed vc4_v3d_bin_bo_put from error paths; * Added WARN_ON_ONCE when no bin BO at refcount release. Changes since v5: * Fix more locking mistakes; * Introduce get/put helpers; * Grabbed a reference when submitting an exec job with a binner slot. * Addressed misc comments. Changes since v4: * Used a kref on the binner bo instead of firstopen/lastclose; * Added a mutex to prevent race conditions; * Took care of enabling the OOM interrupt when we have a binner BO allocated. Changes since v3: * Split changes into more commits when possible; * Reworked binner bo alloc condition as discussed. Changes since v2: * Removed deprecated sentence about fristopen; * Added collected Reviewed-By tags. Changes since v1: * Squashed the two final patches into one. Paul Kocialkowski (4): drm/vc4: Reformat and the binner bo allocation helper drm/vc4: Check for V3D before binner bo alloc drm/vc4: Check for the binner bo before handling OOM interrupt drm/vc4: Allocate binner bo when starting to use the V3D drivers/gpu/drm/vc4/vc4_bo.c | 33 - drivers/gpu/drm/vc4/vc4_drv.c | 6 drivers/gpu/drm/vc4/vc4_drv.h | 14 drivers/gpu/drm/vc4/vc4_gem.c | 13 +++ drivers/gpu/drm/vc4/vc4_irq.c | 20 --- drivers/gpu/drm/vc4/vc4_v3d.c | 68 ++- 6 files changed, 132 insertions(+), 22 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/4] drm/vc4: Check for the binner bo before handling OOM interrupt
Since the OOM interrupt directly deals with the binner bo, it doesn't
make sense to try and handle it without a binner buffer registered.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index ffd0a4388752..723dc86b4511 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -64,6 +64,9 @@ vc4_overflow_mem_work(struct work_struct *work)
struct vc4_exec_info *exec;
unsigned long irqflags;
+ if (!bo)
+ return;
+
bin_bo_slot = vc4_v3d_get_bin_slot(vc4);
if (bin_bo_slot < 0) {
DRM_ERROR("Couldn't allocate binner overflow mem\n");
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable
On 24.04.2019 16:22, Matt Redfearn wrote:
> The DRM documentation states that post_disable is an optional callback.
> As such an implementing device may not populate it. To avoid panicing
> the kernel by calling a NULL function pointer, we should NULL check it
> before blindy calling it.
>
> Signed-off-by: Matt Redfearn
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 38e88071363..0ee440216b8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct
> drm_bridge *bridge)
>* This needs to be fixed in the drm_bridge framework and the API
>* needs to be updated to manage our own call chains...
>*/
> - dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> + if (dsi->panel_bridge->funcs->post_disable)
> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
>
Why not drm_bridge_post_disable ?
Regards
Andrzej
> if (dsi->slave) {
> dw_mipi_dsi_disable(dsi->slave);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4 0/1] drm/fb-helper: Move modesetting code to drm_client
Den 25.04.2019 11.25, skrev Daniel Vetter: > On Thu, Apr 25, 2019 at 10:31 AM Noralf Trønnes wrote: >> >> The Intel CI [1] was not happy with the previous version and I don't >> know which part it didn't like. So I'll split up the series and feed it >> piece by piece until I know where the problem is. > > You can also send stuff to intel-gfx-try...@lists.fd.o for test runs > that you don't want the world to see (it's still public, but no one > looks really). Thanks, that's a better solution. Noralf. > -Daniel > >> >> Noralf. >> >> [1] https://patchwork.freedesktop.org/series/58597/ >> >> Noralf Trønnes (1): >> drm/fb-helper: Avoid race with DRM userspace >> >> drivers/gpu/drm/drm_auth.c | 20 >> drivers/gpu/drm/drm_fb_helper.c | 90 - >> drivers/gpu/drm/drm_internal.h | 2 + >> 3 files changed, 67 insertions(+), 45 deletions(-) >> >> -- >> 2.20.1 >> >> ___ >> Intel-gfx mailing list >> intel-...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607 --- Comment #12 from Arek Hiler --- This is an infrastructure deficiency coming from technical limitations. It is especially bad as it requires us to create a catch-all bug for incompletes, that may obscure some serious problems. To mitigate that we look at all the failures under this bug periodically, and if we see anything that looks suspicious we file it separately. This generates manual labor and increases latency in detecting new issues causing incomplete. This is important to fix from CI infrastructure point of view. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/3] drm: Add CRTC background color property (v5)
Op 26-02-2019 om 17:17 schreef Matt Roper: > On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote: >> Hey, >> >> Op 21-02-2019 om 01:28 schreef Matt Roper: >>> Some display controllers can be programmed to present non-black colors >>> for pixels not covered by any plane (or pixels covered by the >>> transparent regions of higher planes). Compositors that want a UI with >>> a solid color background can potentially save memory bandwidth by >>> setting the CRTC background property and using smaller planes to display >>> the rest of the content. >>> >>> To avoid confusion between different ways of encoding RGB data, we >>> define a standard 64-bit format that should be used for this property's >>> value. Helper functions and macros are provided to generate and dissect >>> values in this standard format with varying component precision values. >>> >>> v2: >>> - Swap internal representation's blue and red bits to make it easier >>>to read if printed out. (Ville) >>> - Document bgcolor property in drm_blend.c. (Sean Paul) >>> - s/background_color/bgcolor/ for consistency between property name and >>>value storage field. (Sean Paul) >>> - Add a convenience function to attach property to a given crtc. >>> >>> v3: >>> - Restructure ARGB component extraction macros to be easier to >>>understand and enclose the parameters in () to avoid calculations >>>if expressions are passed. (Sean Paul) >>> - s/rgba/argb/ in helper function/macro names. Even though the idea is >>>to not worry about the internal representation of the u64, it can >>>still be confusing to look at code that uses 'rgba' terminology, but >>>stores values with argb ordering. (Ville) >>> >>> v4: >>> - Drop the bgcolor_changed flag. (Ville, Brian Starkey) >>> - Clarify in kerneldoc that background color is expected to undergo the >>>same pipe-level degamma/csc/gamma transformations that planes do. >>>(Brian Starkey) >>> - Update kerneldoc to indicate non-opaque colors are allowed, but are >>>generally only useful in special cases such as when writeback >>>connectors are used (Brian Starkey / Eric Anholt) >>> >>> v5: >>> - Set crtc->state->bgcolor to solid black inside >>>drm_crtc_add_bgcolor_property() in case drivers don't do this >>>themselves. (Ville) >>> - Add kerneldoc to drm_crtc_add_bgcolor_property() function. >>> >>> Cc: dri-devel@lists.freedesktop.org >>> Cc: wei.c...@intel.com >>> Cc: harish.krupo@intel.com >>> Cc: Ville Syrjälä >>> Cc: Sean Paul >>> Cc: Brian Starkey >>> Cc: Eric Anholt >>> Cc: Stéphane Marchesin >>> Cc: Daniel Vetter >>> Signed-off-by: Matt Roper >>> Reviewed-by(v2): Sean Paul >>> Reviewed-by: Brian Starkey >> I like how bgcolor is a u64 now, but there is an issue with setting >> crtc->state->bgcolor in attaching the property. >> >> We should do it in atomic core init instead, like we already do for >> connector/plane properties.. >> >> See for example https://patchwork.freedesktop.org/series/52363/ >> >> This was specificallly for the background color proposal, but we >> probalby have to split out the non-trivial conversions of >> __drm_atomic_helper_crtc_reset. > Makes sense. What's the status of that patch? It looks like it has a > lot of a-b's/r-b's but hasn't landed yet. Is there anything blocking > it? If you're still driving it forward, I can wait for that to land and > then build on top of it. > > > Matt > I've split out the patch and landed some of the preparation patches, it should be good enough to unblock this patch series at least now. :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6 v2] libdrm: Patches from AOSP
On Wed, 24 Apr 2019 at 18:08, John Stultz wrote: > > Recently I've been trying to sync the AOSP libdrm tree with > the upstream freedesktop branch. > > Thanks to input from Sean, Alistair and Marissa, we've managed > to drop a bunch of stale patches AOSP was carrying, and get > the AOSP libdrm updated to 2.4.97 > > I've gone through the remaining patch delta and wanted to submit > the non-Android.bp changes, which seemed like they might be > relevant for upstream, for review. > Thanks for the follow-up John. I've swapped the order of 1/6 and 2/6 and pushed the series to master. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/libkms-test-plane: fix possbile memory leak
On Thu, 25 Apr 2019 at 10:49, Seung-Woo Kim wrote: > > The pointer p aquired with drmModeGetPlane() is not free in error > path. Fix possible memory leak by calling drmModeFreePlane() in > the error path. > > Signed-off-by: Seung-Woo Kim Reviewed-by: Emil Velikov and pushed to master. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch V3 00/29] stacktrace: Consolidate stack trace usage
* Thomas Gleixner wrote:
> - if (unlikely(!ret))
> + if (unlikely(!ret)) {
> + if (!trace->nr_entries) {
> + /*
> + * If save_trace fails here, the printing might
> + * trigger a WARN but because of the !nr_entries it
> + * should not do bad things.
> + */
> + save_trace(trace);
> + }
> return print_circular_bug(, target_entry, next, prev);
> + }
> else if (unlikely(ret < 0))
> return print_bfs_bug(ret);
Just a minor style nit: the 'else' should probably on the same line as
the '}' it belongs to, to make it really obvious that the 'if' has an
'else' branch?
At that point the condition should probably also use balanced curly
braces.
Interdiff looks good otherwise.
Thanks,
Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] tests/libkms-test-plane: fix possbile memory leak
The pointer p aquired with drmModeGetPlane() is not free in error
path. Fix possible memory leak by calling drmModeFreePlane() in
the error path.
Signed-off-by: Seung-Woo Kim
---
tests/kms/libkms-test-plane.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tests/kms/libkms-test-plane.c b/tests/kms/libkms-test-plane.c
index 6c40a3c..4cb2737 100644
--- a/tests/kms/libkms-test-plane.c
+++ b/tests/kms/libkms-test-plane.c
@@ -55,8 +55,10 @@ static int kms_plane_probe(struct kms_plane *plane)
}
plane->formats = calloc(p->count_formats, sizeof(uint32_t));
- if (!plane->formats)
+ if (!plane->formats) {
+ drmModeFreePlane(p);
return -ENOMEM;
+ }
for (i = 0; i < p->count_formats; i++)
plane->formats[i] = p->formats[i];
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: initialize idle mask before querying the HW db
On Wed, 2019-04-17 at 14:21 +0200, Lucas Stach wrote: > If there is a match in the HW DB, the function is left early, before > inititalizing the idle mask. Fix this by doing the init earlier, as > only old GPUs, not present in the HW DB need a different idle mask. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/17] drm/vkms: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Op 06-03-2019 om 23:43 schreef Rodrigo Siqueira:
> On 03/01, Maarten Lankhorst wrote:
>> Convert vkms to using __drm_atomic_helper_crtc_reset(), instead of
>> writing its own version. Instead of open coding destroy_state(),
>> call it directly for freeing the old state.
>>
>> Signed-off-by: Maarten Lankhorst
>> Cc: Rodrigo Siqueira
>> Cc: Haneen Mohammed
>> Cc: Daniel Vetter
>> ---
>> drivers/gpu/drm/vkms/vkms_crtc.c | 33 +---
>> 1 file changed, 13 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
>> b/drivers/gpu/drm/vkms/vkms_crtc.c
>> index 8a9aeb0a9ea8..550888e72c96 100644
>> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
>> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
>> @@ -83,26 +83,6 @@ bool vkms_get_vblank_timestamp(struct drm_device *dev,
>> unsigned int pipe,
>> return true;
>> }
>>
>> -static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
>> -{
>> -struct vkms_crtc_state *vkms_state = NULL;
>> -
>> -if (crtc->state) {
>> -vkms_state = to_vkms_crtc_state(crtc->state);
>> -__drm_atomic_helper_crtc_destroy_state(crtc->state);
>> -kfree(vkms_state);
>> -crtc->state = NULL;
>> -}
>> -
>> -vkms_state = kzalloc(sizeof(*vkms_state), GFP_KERNEL);
>> -if (!vkms_state)
>> -return;
>> -INIT_WORK(_state->crc_work, vkms_crc_work_handle);
>> -
>> -crtc->state = _state->base;
>> -crtc->state->crtc = crtc;
>> -}
>> -
>> static struct drm_crtc_state *
>> vkms_atomic_crtc_duplicate_state(struct drm_crtc *crtc)
>> {
>> @@ -135,6 +115,19 @@ static void vkms_atomic_crtc_destroy_state(struct
>> drm_crtc *crtc,
>> }
>> }
>>
>> +static void vkms_atomic_crtc_reset(struct drm_crtc *crtc)
>> +{
>> +struct vkms_crtc_state *vkms_state =
>> +kzalloc(sizeof(*vkms_state), GFP_KERNEL);
>> +
>> +if (crtc->state)
>> +vkms_atomic_crtc_destroy_state(crtc, crtc->state);
>> +
>> +__drm_atomic_helper_crtc_reset(crtc, _state->base);
>> +if (vkms_state)
>> +INIT_WORK(_state->crc_work, vkms_crc_work_handle);
>> +}
>> +
>> static const struct drm_crtc_funcs vkms_crtc_funcs = {
>> .set_config = drm_atomic_helper_set_config,
>> .destroy= drm_crtc_cleanup,
>> --
>> 2.20.1
>>
> Hi Maarten,
>
> First of all, thanks for the patch :)
>
> I tested it on my VM with the IGT test, and everything looks fine.
>
> Reviewed-by: Rodrigo Siqueira
>
Thanks, pushed patches 1-3, and rockchip, tegra, msm, vkms, mali and i915
patches with reviews. :)
Will resend the rest of the series and address the feedback.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/8] drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get
On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote: > In preparation to having a context per process, etnaviv_gem_mapping_get > should not use the current GPU context, but needs to be told which > context to use. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Allow VPG to be enabled via debugfs
On Wed, Apr 24, 2019 at 02:22:18PM +, Matt Redfearn wrote:
> The Synopsys MIPI DSI IP contains a video test pattern generator which
> is helpful in debugging video timing with connected displays.
> Add a debugfs directory containing files which allow the VPG to be
> enabled and disabled, and it's orientation to be changed.
s/it's/its/
>
> Signed-off-by: Matt Redfearn
>
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 55 +++
> 1 file changed, 55 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 0ee440216b8..a1ee2306382 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -86,6 +87,8 @@
> #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS 0x1
> #define VID_MODE_TYPE_BURST 0x2
> #define VID_MODE_TYPE_MASK 0x3
> +#define VID_MODE_VPG_ENABLE BIT(16)
> +#define VID_MODE_VPG_HORIZONTAL BIT(24)
>
> #define DSI_VID_PKT_SIZE 0x3c
> #define VID_PKT_SIZE(p) ((p) & 0x3fff)
> @@ -234,6 +237,15 @@ struct dw_mipi_dsi {
> u32 format;
> unsigned long mode_flags;
>
> +#ifdef CONFIG_DEBUG_FS
> + struct dentry *debugfs_root;
> + struct dentry *debugfs_vpg;
> + struct dentry *debugfs_vpg_horizontal;
> +
> + bool vpg;
> + bool vpg_horizontal;
> +#endif /* CONFIG_DEBUG_FS */
> +
> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
>
> @@ -525,6 +537,11 @@ static void dw_mipi_dsi_video_mode_config(struct
> dw_mipi_dsi *dsi)
> else
> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>
> + if (dsi->vpg) {
Won't this break if CONFIG_DDEBUG_FS is not defined ?
> + val |= VID_MODE_VPG_ENABLE;
> + val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
> + }
> +
> dsi_write(dsi, DSI_VID_MODE_CFG, val);
> }
>
> @@ -935,6 +952,41 @@ static const struct drm_bridge_funcs
> dw_mipi_dsi_bridge_funcs = {
> .attach = dw_mipi_dsi_bridge_attach,
> };
>
> +#ifdef CONFIG_DEBUG_FS
> +
> +static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi)
> +{
> + struct dentry *d;
> +
> + d = debugfs_create_dir(dev_name(dsi->dev), NULL);
> + if (IS_ERR(d)) {
> + dev_err(dsi->dev, "failed to create debugfs root\n");
> + return;
> + }
> + dsi->debugfs_root = d;
> +
> + d = debugfs_create_bool("vpg", 0660, dsi->debugfs_root, >vpg);
> + dsi->debugfs_vpg = d;
If you don't handle failures here you don't need the intermediate d
variable, you can just assign dsi->debugfs_vpg directly.
> +
> + d = debugfs_create_bool("vpg_horizontal", 0660, dsi->debugfs_root,
> + >vpg_horizontal);
> + dsi->debugfs_vpg_horizontal = d;
Same here.
> +}
> +
> +static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi)
> +{
> + debugfs_remove(dsi->debugfs_vpg_horizontal);
> + debugfs_remove(dsi->debugfs_vpg);
> + debugfs_remove(dsi->debugfs_root);
> +}
> +
> +#else
> +
> +static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi) { }
> +static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi) { }
> +
> +#endif /* CONFIG_DEBUG_FS */
> +
> static struct dw_mipi_dsi *
> __dw_mipi_dsi_probe(struct platform_device *pdev,
> const struct dw_mipi_dsi_plat_data *plat_data)
> @@ -1005,6 +1057,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> clk_disable_unprepare(dsi->pclk);
> }
>
> + dw_mipi_dsi_debugfs_init(dsi);
> pm_runtime_enable(dev);
>
> dsi->dsi_host.ops = _mipi_dsi_host_ops;
> @@ -1012,6 +1065,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> ret = mipi_dsi_host_register(>dsi_host);
> if (ret) {
> dev_err(dev, "Failed to register MIPI host: %d\n", ret);
> + dw_mipi_dsi_debugfs_remove(dsi);
> return ERR_PTR(ret);
> }
>
> @@ -1029,6 +1083,7 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi
> *dsi)
> mipi_dsi_host_unregister(>dsi_host);
>
> pm_runtime_disable(dsi->dev);
> + dw_mipi_dsi_debugfs_remove(dsi);
> }
>
> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi
> *slave)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/8] drm/etnaviv: split out starting of FE idle loop
On Wed, 2019-04-17 at 15:50 +0200, Lucas Stach wrote: > Move buffer setup and starting of the FE loop in the kernel ringbuffer > into a separate function. This is a preparation to start the FE later > in the submit process. > > Signed-off-by: Lucas Stach Reviewed-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4 0/1] drm/fb-helper: Move modesetting code to drm_client
On Thu, Apr 25, 2019 at 10:31 AM Noralf Trønnes wrote: > > The Intel CI [1] was not happy with the previous version and I don't > know which part it didn't like. So I'll split up the series and feed it > piece by piece until I know where the problem is. You can also send stuff to intel-gfx-try...@lists.fd.o for test runs that you don't want the world to see (it's still public, but no one looks really). -Daniel > > Noralf. > > [1] https://patchwork.freedesktop.org/series/58597/ > > Noralf Trønnes (1): > drm/fb-helper: Avoid race with DRM userspace > > drivers/gpu/drm/drm_auth.c | 20 > drivers/gpu/drm/drm_fb_helper.c | 90 - > drivers/gpu/drm/drm_internal.h | 2 + > 3 files changed, 67 insertions(+), 45 deletions(-) > > -- > 2.20.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Don't blindly call post_disable
Hi Matt,
Thank you for the patch.
On Wed, Apr 24, 2019 at 02:22:00PM +, Matt Redfearn wrote:
> The DRM documentation states that post_disable is an optional callback.
> As such an implementing device may not populate it. To avoid panicing
> the kernel by calling a NULL function pointer, we should NULL check it
> before blindy calling it.
>
> Signed-off-by: Matt Redfearn
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 38e88071363..0ee440216b8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -805,7 +805,8 @@ static void dw_mipi_dsi_bridge_post_disable(struct
> drm_bridge *bridge)
>* This needs to be fixed in the drm_bridge framework and the API
>* needs to be updated to manage our own call chains...
>*/
> - dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
> + if (dsi->panel_bridge->funcs->post_disable)
> + dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
>
> if (dsi->slave) {
> dw_mipi_dsi_disable(dsi->slave);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Wait for all active lanes to reach stop
Hi Matt,
Thank you for the patch.
On Wed, Apr 24, 2019 at 02:21:40PM +, Matt Redfearn wrote:
> The Synopsys manual states that software should wait for all active
> lanes to reach stop state (User manual section 3.1.5). Currently the
> driver only waits for / checks that the clock lane is in stop state. Fix
> this by waiting for the mask of PHY STATUS bits corresponding to the
> active lanes to be set.
>
> Signed-off-by: Matt Redfearn
I don't have access to the datasheet, but the change makes sense.
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index bd15c21a177..38e88071363 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -189,6 +189,10 @@
> #define DSI_PHY_TX_TRIGGERS 0xac
>
> #define DSI_PHY_STATUS 0xb0
> +#define PHY_STOP_STATE_LANE_3BIT(11)
> +#define PHY_STOP_STATE_LANE_2BIT(9)
> +#define PHY_STOP_STATE_LANE_1BIT(7)
> +#define PHY_STOP_STATE_LANE_0BIT(4)
> #define PHY_STOP_STATE_CLK_LANE BIT(2)
> #define PHY_LOCK BIT(0)
>
> @@ -752,7 +756,7 @@ static void dw_mipi_dsi_dphy_init(struct dw_mipi_dsi *dsi)
>
> static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi *dsi)
> {
> - u32 val;
> + u32 val, mask;
> int ret;
>
> dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
> @@ -763,11 +767,16 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi
> *dsi)
> if (ret)
> DRM_DEBUG_DRIVER("failed to wait phy lock state\n");
>
> + mask = PHY_STOP_STATE_CLK_LANE | PHY_STOP_STATE_LANE_0;
> + mask |= (dsi->lanes >= 2) ? PHY_STOP_STATE_LANE_1 : 0;
> + mask |= (dsi->lanes >= 3) ? PHY_STOP_STATE_LANE_2 : 0;
> + mask |= (dsi->lanes == 4) ? PHY_STOP_STATE_LANE_3 : 0;
> +
> ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
> - val, val & PHY_STOP_STATE_CLK_LANE, 1000,
> + val, (val & mask) == mask, 1000,
>PHY_STATUS_TIMEOUT_US);
> if (ret)
> - DRM_DEBUG_DRIVER("failed to wait phy clk lane stop state\n");
> + DRM_DEBUG_DRIVER("failed to wait phy stop state\n");
> }
>
> static void dw_mipi_dsi_clear_err(struct dw_mipi_dsi *dsi)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct
Am 25.04.2019 10:35 schrieb Thomas Hellstrom :
Hi, Christian,
On Wed, 2019-04-24 at 16:20 +0200, Thomas Hellström wrote:
> On Wed, 2019-04-24 at 14:10 +, Koenig, Christian wrote:
> > Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> > > Add a pointer to the struct vm_operations_struct in the
> > > bo_device,
> > > and
> > > assign that pointer to the default value currently used.
> > >
> > > The driver can then optionally modify that pointer and the new
> > > value
> > > can be used for each new vma created.
> > >
> > > Cc: "Christian König"
> > >
> > > Signed-off-by: Thomas Hellstrom
> > > Reviewed-by: Christian König
> >
> > Going to pick those two TTM patches up for amd-staging-drm-next.
>
> Will you be relying on either patch for related work? Otherwise it
> would be simpler for us to use vmwgfx-next for the whole series,
> targeting 5.3.
>
> Thomas
Is this OK with you?
I wanted to base some cleanup work on this, but this can wait as well.
So fine with me to merge this through vmwgfx-next.
Regards,
Christian.
Thanks,
Thomas
>
> > Christian.
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo.c| 1 +
> > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +++---
> > > include/drm/ttm/ttm_bo_driver.h | 6 ++
> > > 3 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index 3f56647cdb35..1c85bec00472 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1656,6 +1656,7 @@ int ttm_bo_device_init(struct ttm_bo_device
> > > *bdev,
> > >mutex_lock(_global_mutex);
> > >list_add_tail(>device_list, >device_list);
> > >mutex_unlock(_global_mutex);
> > > + bdev->vm_ops = _bo_vm_ops;
> > >
> > >return 0;
> > > out_no_sys:
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > index e86a29a1e51f..bfb25b81fed7 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > @@ -395,7 +395,7 @@ static int ttm_bo_vm_access(struct
> > > vm_area_struct *vma, unsigned long addr,
> > >return ret;
> > > }
> > >
> > > -static const struct vm_operations_struct ttm_bo_vm_ops = {
> > > +const struct vm_operations_struct ttm_bo_vm_ops = {
> > >.fault = ttm_bo_vm_fault,
> > >.open = ttm_bo_vm_open,
> > >.close = ttm_bo_vm_close,
> > > @@ -445,7 +445,7 @@ int ttm_bo_mmap(struct file *filp, struct
> > > vm_area_struct *vma,
> > >if (unlikely(ret != 0))
> > >goto out_unref;
> > >
> > > - vma->vm_ops = _bo_vm_ops;
> > > + vma->vm_ops = bdev->vm_ops;
> > >
> > >/*
> > > * Note: We're transferring the bo reference to
> > > @@ -477,7 +477,7 @@ int ttm_fbdev_mmap(struct vm_area_struct
> > > *vma,
> > > struct ttm_buffer_object *bo)
> > >
> > >ttm_bo_get(bo);
> > >
> > > - vma->vm_ops = _bo_vm_ops;
> > > + vma->vm_ops = bo->bdev->vm_ops;
> > >vma->vm_private_data = bo;
> > >vma->vm_flags |= VM_MIXEDMAP;
> > >vma->vm_flags |= VM_IO | VM_DONTEXPAND;
> > > diff --git a/include/drm/ttm/ttm_bo_driver.h
> > > b/include/drm/ttm/ttm_bo_driver.h
> > > index cbf3180cb612..cfeaff5d9706 100644
> > > --- a/include/drm/ttm/ttm_bo_driver.h
> > > +++ b/include/drm/ttm/ttm_bo_driver.h
> > > @@ -443,6 +443,9 @@ extern struct ttm_bo_global {
> > >* @driver: Pointer to a struct ttm_bo_driver struct setup by
> > > the
> > > driver.
> > >* @man: An array of mem_type_managers.
> > >* @vma_manager: Address space manager
> > > + * @vm_ops: Pointer to the struct vm_operations_struct used for
> > > this
> > > + * device's VM operations. The driver may override this before
> > > the
> > > first
> > > + * mmap() call.
> > >* lru_lock: Spinlock that protects the buffer+device lru lists
> > > and
> > >* ddestroy lists.
> > >* @dev_mapping: A pointer to the struct address_space
> > > representing the
> > > @@ -461,6 +464,7 @@ struct ttm_bo_device {
> > >struct ttm_bo_global *glob;
> > >struct ttm_bo_driver *driver;
> > >struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES];
> > > + const struct vm_operations_struct *vm_ops;
> > >
> > >/*
> > > * Protected by internal locks.
> > > @@ -489,6 +493,8 @@ struct ttm_bo_device {
> > >bool no_retry;
> > > };
> > >
> > > +extern const struct vm_operations_struct ttm_bo_vm_ops;
> > > +
> > > /**
> > >* struct ttm_lru_bulk_move_pos
> > >*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/imx: fix DP CSC handling
Hi Dave, Daniel, please consider merging these imx-drm fixes for v5.1. regards Philipp The following changes since commit dc4060a5dc2557e6b5aa813bf5b73677299d62d2: Linux 5.1-rc5 (2019-04-14 15:17:41 -0700) are available in the Git repository at: git://git.pengutronix.de/pza/linux tags/imx-drm-fixes-2019-04-25 for you to fetch changes up to 7bcde275eb1d0ac8793c77c7e666a886eb16633d: drm/imx: don't skip DP channel disable for background plane (2019-04-23 14:54:22 +0200) drm/imx: fix DP CSC handling - Fix the DP color space conversion matrix setup to avoid bugs where disabling the overlay plane while both primary and overlay plane are routed via the CSC unit would not reconfigure the CSC routing properly, leaving the display in a nonworking state, or the CSC setting from a previously set mode would be left behind, causing wrong colors when reenabling the display in certain configurations. Lucas Stach (2): gpu: ipu-v3: dp: fix CSC handling drm/imx: don't skip DP channel disable for background plane drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- drivers/gpu/ipu-v3/ipu-dp.c | 12 +--- 2 files changed, 10 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus
On 21.04.2019 10:25, Jonas Karlman wrote:
> When ddc-i2c-bus property is used, a NULL pointer dereference is reported:
>
> [ 31.041669] Unable to handle kernel NULL pointer dereference at virtual
> address 0008
> [ 31.041671] pgd = 4d3c16f6
> [ 31.041673] [0008] *pgd=
> [ 31.041678] Internal error: Oops: 5 [#1] SMP ARM
>
> [ 31.041711] Hardware name: Rockchip (Device Tree)
> [ 31.041718] PC is at i2c_transfer+0x8/0xe4
> [ 31.041721] LR is at drm_scdc_read+0x54/0x84
> [ 31.041723] pc : []lr : []psr: 280f0013
> [ 31.041725] sp : edffdad0 ip : 5ccb5511 fp : 0058
> [ 31.041727] r10: 0780 r9 : edf91608 r8 : c11b0f48
> [ 31.041728] r7 : 0438 r6 : r5 : r4 :
> [ 31.041730] r3 : edffdae7 r2 : 0002 r1 : edffdaec r0 :
>
> [ 31.041908] [] (i2c_transfer) from []
> (drm_scdc_read+0x54/0x84)
> [ 31.041913] [] (drm_scdc_read) from []
> (drm_scdc_set_scrambling+0x30/0xbc)
> [ 31.041919] [] (drm_scdc_set_scrambling) from []
> (dw_hdmi_update_power+0x1440/0x1610)
> [ 31.041926] [] (dw_hdmi_update_power) from []
> (dw_hdmi_bridge_enable+0x2c/0x70)
> [ 31.041932] [] (dw_hdmi_bridge_enable) from []
> (drm_bridge_enable+0x24/0x34)
> [ 31.041938] [] (drm_bridge_enable) from []
> (drm_atomic_helper_commit_modeset_enables+0x114/0x220)
> [ 31.041943] [] (drm_atomic_helper_commit_modeset_enables) from
> [] (rockchip_atomic_helper_commit_tail_rpm+0x28/0x64)
>
> hdmi->i2c may not be set when ddc-i2c-bus property is used in device tree.
> Fix this by using hdmi->ddc as the i2c adapter when calling drm_scdc_*().
> Also report that SCDC is not supported when there is no DDC bus.
>
> Fixes: 264fce6cc2c1 ("drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling
> support")
> Signed-off-by: Jonas Karlman
Pushed to drm-misc-fixes.
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct
Hi, Christian,
On Wed, 2019-04-24 at 16:20 +0200, Thomas Hellström wrote:
> On Wed, 2019-04-24 at 14:10 +, Koenig, Christian wrote:
> > Am 24.04.19 um 14:00 schrieb Thomas Hellstrom:
> > > Add a pointer to the struct vm_operations_struct in the
> > > bo_device,
> > > and
> > > assign that pointer to the default value currently used.
> > >
> > > The driver can then optionally modify that pointer and the new
> > > value
> > > can be used for each new vma created.
> > >
> > > Cc: "Christian König"
> > >
> > > Signed-off-by: Thomas Hellstrom
> > > Reviewed-by: Christian König
> >
> > Going to pick those two TTM patches up for amd-staging-drm-next.
>
> Will you be relying on either patch for related work? Otherwise it
> would be simpler for us to use vmwgfx-next for the whole series,
> targeting 5.3.
>
> Thomas
Is this OK with you?
Thanks,
Thomas
>
> > Christian.
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_bo.c| 1 +
> > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +++---
> > > include/drm/ttm/ttm_bo_driver.h | 6 ++
> > > 3 files changed, 10 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> > > b/drivers/gpu/drm/ttm/ttm_bo.c
> > > index 3f56647cdb35..1c85bec00472 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > > @@ -1656,6 +1656,7 @@ int ttm_bo_device_init(struct ttm_bo_device
> > > *bdev,
> > > mutex_lock(_global_mutex);
> > > list_add_tail(>device_list, >device_list);
> > > mutex_unlock(_global_mutex);
> > > + bdev->vm_ops = _bo_vm_ops;
> > >
> > > return 0;
> > > out_no_sys:
> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > index e86a29a1e51f..bfb25b81fed7 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > @@ -395,7 +395,7 @@ static int ttm_bo_vm_access(struct
> > > vm_area_struct *vma, unsigned long addr,
> > > return ret;
> > > }
> > >
> > > -static const struct vm_operations_struct ttm_bo_vm_ops = {
> > > +const struct vm_operations_struct ttm_bo_vm_ops = {
> > > .fault = ttm_bo_vm_fault,
> > > .open = ttm_bo_vm_open,
> > > .close = ttm_bo_vm_close,
> > > @@ -445,7 +445,7 @@ int ttm_bo_mmap(struct file *filp, struct
> > > vm_area_struct *vma,
> > > if (unlikely(ret != 0))
> > > goto out_unref;
> > >
> > > - vma->vm_ops = _bo_vm_ops;
> > > + vma->vm_ops = bdev->vm_ops;
> > >
> > > /*
> > >* Note: We're transferring the bo reference to
> > > @@ -477,7 +477,7 @@ int ttm_fbdev_mmap(struct vm_area_struct
> > > *vma,
> > > struct ttm_buffer_object *bo)
> > >
> > > ttm_bo_get(bo);
> > >
> > > - vma->vm_ops = _bo_vm_ops;
> > > + vma->vm_ops = bo->bdev->vm_ops;
> > > vma->vm_private_data = bo;
> > > vma->vm_flags |= VM_MIXEDMAP;
> > > vma->vm_flags |= VM_IO | VM_DONTEXPAND;
> > > diff --git a/include/drm/ttm/ttm_bo_driver.h
> > > b/include/drm/ttm/ttm_bo_driver.h
> > > index cbf3180cb612..cfeaff5d9706 100644
> > > --- a/include/drm/ttm/ttm_bo_driver.h
> > > +++ b/include/drm/ttm/ttm_bo_driver.h
> > > @@ -443,6 +443,9 @@ extern struct ttm_bo_global {
> > >* @driver: Pointer to a struct ttm_bo_driver struct setup by
> > > the
> > > driver.
> > >* @man: An array of mem_type_managers.
> > >* @vma_manager: Address space manager
> > > + * @vm_ops: Pointer to the struct vm_operations_struct used for
> > > this
> > > + * device's VM operations. The driver may override this before
> > > the
> > > first
> > > + * mmap() call.
> > >* lru_lock: Spinlock that protects the buffer+device lru lists
> > > and
> > >* ddestroy lists.
> > >* @dev_mapping: A pointer to the struct address_space
> > > representing the
> > > @@ -461,6 +464,7 @@ struct ttm_bo_device {
> > > struct ttm_bo_global *glob;
> > > struct ttm_bo_driver *driver;
> > > struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES];
> > > + const struct vm_operations_struct *vm_ops;
> > >
> > > /*
> > >* Protected by internal locks.
> > > @@ -489,6 +493,8 @@ struct ttm_bo_device {
> > > bool no_retry;
> > > };
> > >
> > > +extern const struct vm_operations_struct ttm_bo_vm_ops;
> > > +
> > > /**
> > >* struct ttm_lru_bulk_move_pos
> > >*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/1] drm/fb-helper: Avoid race with DRM userspace
drm_fb_helper_is_bound() is used to check if DRM userspace is in control.
This is done by looking at the fb on the primary plane. By the time
fb-helper gets around to committing, it's possible that the facts have
changed.
Avoid this race by holding the drm_device->master_mutex lock while
committing. When DRM userspace does its first open, it will now wait
until fb-helper is done. The helper will stay away if there's a master.
Locking rule: Always take the fb-helper lock first.
v2:
- Remove drm_fb_helper_is_bound() (Daniel Vetter)
- No need to check fb_helper->dev->master in
drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_auth.c | 20
drivers/gpu/drm/drm_fb_helper.c | 90 -
drivers/gpu/drm/drm_internal.h | 2 +
3 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1669c42c40ed..db199807b7dc 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -368,3 +368,23 @@ void drm_master_put(struct drm_master **master)
*master = NULL;
}
EXPORT_SYMBOL(drm_master_put);
+
+/* Used by drm_client and drm_fb_helper */
+bool drm_master_internal_acquire(struct drm_device *dev)
+{
+ mutex_lock(>master_mutex);
+ if (dev->master) {
+ mutex_unlock(>master_mutex);
+ return false;
+ }
+
+ return true;
+}
+EXPORT_SYMBOL(drm_master_internal_acquire);
+
+/* Used by drm_client and drm_fb_helper */
+void drm_master_internal_release(struct drm_device *dev)
+{
+ mutex_unlock(>master_mutex);
+}
+EXPORT_SYMBOL(drm_master_internal_release);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2339f0f8f5a8..578428461391 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -44,6 +44,7 @@
#include "drm_crtc_internal.h"
#include "drm_crtc_helper_internal.h"
+#include "drm_internal.h"
static bool drm_fbdev_emulation = true;
module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
@@ -509,7 +510,7 @@ static int restore_fbdev_mode_legacy(struct drm_fb_helper
*fb_helper)
return ret;
}
-static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
@@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
return restore_fbdev_mode_legacy(fb_helper);
}
+static int restore_fbdev_mode(struct drm_fb_helper *fb_helper)
+{
+ struct drm_device *dev = fb_helper->dev;
+ int ret;
+
+ if (!drm_master_internal_acquire(dev))
+ return -EBUSY;
+
+ ret = restore_fbdev_mode_force(fb_helper);
+
+ drm_master_internal_release(dev);
+
+ return ret;
+}
+
/**
* drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
* @fb_helper: driver-allocated fbdev helper, can be NULL
@@ -556,34 +572,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
-static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
-{
- struct drm_device *dev = fb_helper->dev;
- struct drm_crtc *crtc;
- int bound = 0, crtcs_bound = 0;
-
- /*
-* Sometimes user space wants everything disabled, so don't steal the
-* display if there's a master.
-*/
- if (READ_ONCE(dev->master))
- return false;
-
- drm_for_each_crtc(crtc, dev) {
- drm_modeset_lock(>mutex, NULL);
- if (crtc->primary->fb)
- crtcs_bound++;
- if (crtc->primary->fb == fb_helper->fb)
- bound++;
- drm_modeset_unlock(>mutex);
- }
-
- if (bound < crtcs_bound)
- return false;
-
- return true;
-}
-
#ifdef CONFIG_MAGIC_SYSRQ
/*
* restore fbcon display for all kms driver's using this helper, used for sysrq
@@ -604,7 +592,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
continue;
mutex_lock(>lock);
- ret = restore_fbdev_mode(helper);
+ ret = restore_fbdev_mode_force(helper);
if (ret)
error = true;
mutex_unlock(>lock);
@@ -663,20 +651,22 @@ static void dpms_legacy(struct drm_fb_helper *fb_helper,
int dpms_mode)
static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
{
struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
/*
* For each CRTC in this fb, turn the connectors on/off.
*/
mutex_lock(_helper->lock);
- if
[PATCH v4 0/1] drm/fb-helper: Move modesetting code to drm_client
The Intel CI [1] was not happy with the previous version and I don't know which part it didn't like. So I'll split up the series and feed it piece by piece until I know where the problem is. Noralf. [1] https://patchwork.freedesktop.org/series/58597/ Noralf Trønnes (1): drm/fb-helper: Avoid race with DRM userspace drivers/gpu/drm/drm_auth.c | 20 drivers/gpu/drm/drm_fb_helper.c | 90 - drivers/gpu/drm/drm_internal.h | 2 + 3 files changed, 67 insertions(+), 45 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/7] pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM
On Tue, 05 Mar 2019, claudiu.bez...@microchip.com wrote:
> From: Claudiu Beznea
>
> Add compatible string for SAM9X60 HLCDC's PWM.
>
> Signed-off-by: Claudiu Beznea
> Acked-by: Thierry Reding
> ---
> drivers/pwm/pwm-atmel-hlcdc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> index 54c6633d9b5d..331ca0233d9e 100644
> --- a/drivers/pwm/pwm-atmel-hlcdc.c
> +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> @@ -246,6 +246,9 @@ static const struct of_device_id atmel_hlcdc_dt_ids[] = {
> .compatible = "atmel,sama5d4-hlcdc",
> .data = _hlcdc_pwm_sama5d3_errata,
> },
> + {
> + .compatible = "microchip,sam9x60-hlcdc",
> + },
Please make this a single line entry, like the one below.
> { /* sentinel */ },
> };
> MODULE_DEVICE_TABLE(of, atmel_hlcdc_dt_ids);
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #83 from Tom B --- I have a similar problem with my Radeon VII. My testing/experiments are outlined here: https://bugs.freedesktop.org/show_bug.cgi?id=110510 sorry for the long post! However my bug seems slightly different albeit related. 1. The flicker only occurs on my HDMI monitor. It's a flicker and sometimes the screen will go black for a couple of seconds 2. If the HDMI monitor is the only monitor connected I can set the refresh rate to 59.94 instead of 60.00 and it is fine 3. If the HDMI monitor and a displayport monitor are both connected the flicker still occurs. However, trying to set the HDMI monitor to 59.94hz causes the system to freeze and I have to do a hard reset (it's fine if the HDMI monitor is the only monitor) 4. Setting power_dpm_force_performance_level to high alone does not fix it. But by running the higher power state I can set the HDMI monitor to 59.94hz without the system freezing In short: I need to use 59.94hz to stop the flickering and I need to use high power state to set the refresh rate without freezing the entire system. Although this is an acceptable workaround I would like to see a proper fix. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110313] [CI][SHARDS] igt@kms_lease@lease-uevent - fail - Failed assertion: igt_lease_change_detected(uevent_monitor, 1)
https://bugs.freedesktop.org/show_bug.cgi?id=110313 --- Comment #4 from Daniel Vetter --- (In reply to Arek Hiler from comment #3) > This seems like a test deficiency. We are polling on udev monitor FD in > anticipation of an events. According the the log linked in the previous > comments we get EAGAIN (11), but we do not retry. We already retry when we get EAGAIN, but then eventually give up. So the EAGAIN errno is kinda expected. The timeout right now is 1 second, which really should be enough to deliver an uevent. Maybe the box is totally overloaded or something like that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] vmwgfx-fixes-5.1
Dave, Daniel A single fix for a layer violation requested by Cristoph. The following changes since commit c2d311553855395764e2e5bf401d987ba65c2056: drm/vmwgfx: Don't double-free the mode stored in par->set_mode (2019-03-20 07:57:01 +0100) are available in the Git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-5.1 for you to fetch changes up to 81103355b1e23345dbcdeccad59962a424da4a34: drm/vmwgfx: Fix dma API layer violation (2019-04-25 09:05:03 +0200) Thomas Hellstrom (1): drm/vmwgfx: Fix dma API layer violation drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 33 + 1 file changed, 5 insertions(+), 28 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/docs: Clarify what userspace means for gl
On Thu, Apr 25, 2019 at 11:28:40AM +0800, zhoucm1 wrote: > > > On 2019年04月25日 03:22, Eric Anholt wrote: > > "Zhou, David(ChunMing)" writes: > > > > > Will linux be only mesa-linux? I thought linux is an open linux. > > > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm: > > > 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need? > > > reject? > > > 2. one hw feature that opengl/amdvlk developers work on that but no mesa > > > developers work on, cannot upstream as well? > > I believe these questions are already covered by > > > > "+Other userspace is only admissible if exposing a given feature through > > OpenGL > > or > > +OpenGL ES would result in a technically unsound design, incomplete driver > > or > > +an implementation which isn't useful in real world usage." > > > > If OpenGL needs the interface, then you need a Mesa implementation. > > It's time for you to work with the community to build that or get it > > built. Or, in AMD's case, work with the Mesa developers that you > > already employ. > > > > If OpenGL doesn't need it, but Vulkan needs it, then we don't have a > > clear policy in place, and this patch doesn't change that. I would > > personally say that AMDVLK doesn't qualify given that as far as I know > > there is not open review of proposed patches to the project as they're > > being developed. > Can I understand what you mean is, as soon as the stack is openly developed, > then which will be able to drive new UAPI? I think the only clear thing here is that the answer is complicated, and need to be decided on a case by case basis. That's what I tried to clarify with my patch, but I think there's not enough clearly defined common ground. So it'll stay complicated. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Use memset to initialize config_id
Clang warns:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:76:38: warning: suggest
braces around initialization of subobject [-Wmissing-braces]
union komeda_config_id config_id = {0,};
^
{}
1 warning generated.
One way to fix these warnings is to add additional braces like Clang
suggests; however, there has been a bit of push back from some
maintainers, who just prefer memset as it is unambiguous, doesn't
depend on a particular compiler version, and properly initializes all
subobjects [1][2]. Do that here so there are no more warnings.
[1]: https://lore.kernel.org/lkml/022e41c0-8465-dc7a-a45c-64187ecd9...@amd.com/
[2]:
https://lore.kernel.org/lkml/20181128.215241.702406654469517539.da...@davemloft.net/
Fixes: 4cc734cb79a8 ("drm/komeda: Add sysfs attribute: core_id and config_id")
Link: https://github.com/ClangBuiltLinux/linux/issues/457
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 9d6c31cca875..e605a518f59a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -73,9 +73,10 @@ config_id_show(struct device *dev, struct device_attribute
*attr, char *buf)
{
struct komeda_dev *mdev = dev_to_mdev(dev);
struct komeda_pipeline *pipe = mdev->pipelines[0];
- union komeda_config_id config_id = {0,};
+ union komeda_config_id config_id;
int i;
+ memset(_id, 0, sizeof(config_id));
config_id.max_line_sz = pipe->layers[0]->hsize_in.end;
config_id.n_pipelines = mdev->n_pipelines;
config_id.n_scalers = pipe->n_scalers;
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] r8169: use new helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/net/ethernet/realtek/r8169.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c index efaea1a0a..ae476fe8d 100644 --- a/drivers/net/ethernet/realtek/r8169.c +++ b/drivers/net/ethernet/realtek/r8169.c @@ -7020,8 +7020,7 @@ static int r8169_mdio_register(struct rtl8169_private *tp) new_bus->priv = tp; new_bus->parent = >dev; new_bus->irq[0] = PHY_IGNORE_INTERRUPT; - snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8169-%x", -PCI_DEVID(pdev->bus->number, pdev->devfn)); + snprintf(new_bus->id, MII_BUS_ID_SIZE, "r8169-%x", pci_dev_id(pdev)); new_bus->read = r8169_mdio_read_reg; new_bus->write = r8169_mdio_write_reg; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Support for 2D engines/blitters in V4L2 and DRM
Le mercredi 24 avril 2019 à 18:54 +0200, Michel Dänzer a écrit : > On 2019-04-24 5:44 p.m., Nicolas Dufresne wrote: > > Le mercredi 24 avril 2019 à 17:06 +0200, Daniel Vetter a écrit : > > > On Wed, Apr 24, 2019 at 4:41 PM Paul Kocialkowski > > > wrote: > > > > On Wed, 2019-04-24 at 16:39 +0200, Michel Dänzer wrote: > > > > > On 2019-04-24 2:01 p.m., Nicolas Dufresne wrote: > > > > > > Rendering a video stream is more complex then what you describe > > > > > > here. > > > > > > Whenever there is a unexpected delay (late delivery of a frame as an > > > > > > example) you may endup in situation where one frame is ready after > > > > > > the > > > > > > targeted vblank. If there is another frame that targets the > > > > > > following > > > > > > vblank that gets ready on-time, the previous frame should be > > > > > > replaced > > > > > > by the most recent one. > > > > > > > > > > > > With fences, what happens is that even if you received the next > > > > > > frame > > > > > > on time, naively replacing it is not possible, because we don't know > > > > > > when the fence for the next frame will be signalled. If you simply > > > > > > always replace the current frame, you may endup skipping a lot more > > > > > > vblank then what you expect, and that results in jumpy playback. > > > > > > > > > > So you want to be able to replace a queued flip with another one then. > > > > > That doesn't necessarily require allowing more than one flip to be > > > > > queued ahead of time. > > > > > > > > There might be other ways to do it, but this one has plenty of > > > > advantages. > > > > > > The point of kms (well one of the reasons) was to separate the > > > implementation of modesetting for specific hw from policy decisions > > > like which frames to drop and how to schedule them. Kernel gives > > > tools, userspace implements the actual protocols. > > > > > > There's definitely a bit a gap around scheduling flips for a specific > > > frame or allowing to cancel/overwrite an already scheduled flip, but > > > no one yet has come up with a clear proposal for new uapi + example > > > implementation + userspace implementation + big enough support from > > > other compositors that this is what they want too. > > Actually, the ATOMIC_AMEND patches propose a way to replace a scheduled > flip? > > > > > > > Note that this can also be done in userspace with explicit fencing (by > > > > > only selecting a frame and submitting it to the kernel after all > > > > > corresponding fences have signalled), at least to some degree, but the > > > > > kernel should be able to do it up to a later point in time and more > > > > > reliably, with less risk of missing a flip for a frame which becomes > > > > > ready just in time. > > > > > > > > Indeed, but it would be great if we could do that with implicit fencing > > > > as well. > > > > > > 1. extract implicit fences from dma-buf. This part is just an idea, > > > but easy to implement once we have someone who actually wants this. > > > All we need is a new ioctl on the dma-buf to export the fences from > > > the reservation_object as a sync_file (either the exclusive or the > > > shared ones, selected with a flag). > > > 2. do the exact same frame scheduling as with explicit fencing > > > 3. supply explicit fences in your atomic ioctl calls - these should > > > overrule any implicit fences (assuming correct kernel drivers, but we > > > have helpers so you can assume they all work correctly). > > > > > > By design this is possible, it's just that no one yet bothered enough > > > to make it happen. > > > -Daniel > > > > I'm not sure I understand the workflow of this one. I'm all in favour > > leaving the hard work to userspace. Note that I have assumed explicit > > fences from the start, I don't think implicit fence will ever exist in > > v4l2, but I might be wrong. What I understood is that there was a > > previous attempt in the past but it raised more issues then it actually > > solved. So that being said, how do handle exactly the follow use cases: > > > > - A frame was lost by capture driver, but it was schedule as being the > > next buffer to render (normally previous frame should remain). > > Userspace just doesn't call into the kernel to flip to the lost frame, > so the previous one remains. We are stuck in a loop you a me. Considering v4l2 to drm, where fences don't exist on v4l2, it makes very little sense to bring up fences if we are to wait on the fence in userspace. Unless of course you have other operations before end making a proper use of the fences. > > > - The scheduled frame is late for the next vblank (didn't signal on- > > time), a new one may be better for the next vlbank, but we will only > > know when it's fence is signaled. > > Userspace only selects a frame and submits it to the kernel after all > its fences have signalled. > > > Better in this context means the the presentation time of this frame is > > closer to the next vblank time.
Re: Support for 2D engines/blitters in V4L2 and DRM
Le mercredi 24 avril 2019 à 10:31 +0200, Michel Dänzer a écrit : > On 2019-04-19 10:38 a.m., Paul Kocialkowski wrote: > > On Thu, 2019-04-18 at 20:30 -0400, Nicolas Dufresne wrote: > > > Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit : > > > > > It would be cool if both could be used concurrently and not just > > > > > return > > > > > -EBUSY when the device is used with the other subsystem. > > > > > > > > We live in this world already :-) I think there's even patches (or > > > > merged > > > > already) to add fences to v4l, for Android. > > > > > > This work is currently suspended. It will require some feature on DRM > > > display to really make this useful, but there is also a lot of > > > challanges in V4L2. In GFX space, most of the use case are about > > > rendering as soon as possible. Though, in multimedia we have two > > > problems, we need to synchronize the frame rendering with the audio, > > > and output buffers may comes out of order due to how video CODECs are > > > made. > > > > Definitely, it feels like the DRM display side is currently a good fit > > for render use cases, but not so much for precise display cases where > > we want to try and display a buffer at a given vblank target instead of > > "as soon as possible". > > > > I have a userspace project where I've implemented a page flip queue, > > which only schedules the next flip when relevant and keeps ready > > buffers in the queue until then. This requires explicit vblank > > syncronisation (which DRM offsers, but pretty much all other display > > APIs, that are higher-level don't, so I'm just using a refresh-rate > > timer for them) and flip done notification. > > > > I haven't looked too much at how to flip with a target vblank with DRM > > directly but maybe the atomic API already has the bits in for that (but > > I haven't heard of such a thing as a buffer queue, so that makes me > > doubt it). > > Not directly. What's available is that if userspace waits for vblank n > and then submits a flip, the flip will complete in vblank n+1 (or a > later vblank, depending on when the flip is submitted and when the > fences the flip depends on signal). > > There is reluctance allowing more than one flip to be queued in the > kernel, as it would considerably increase complexity in the kernel. It > would probably only be considered if there was a compelling use-case > which was outright impossible otherwise. > > > > Well, I need to handle stuff like SDL in my userspace project, so I have > > to have all that queuing stuff in software anyway, but it would be good > > if each project didn't have to implement that. Worst case, it could be > > in libdrm too. > > Usually, this kind of queuing will be handled in a display server such > as Xorg or a Wayland compositor, not by the application such as a video > player itself, or any library in the latter's address space. I'm not > sure there's much potential for sharing code between display servers for > this. > > > > > In the first, we'd need a mechanism where we can schedule a render at a > > > specific time or vblank. We can of course already implement this in > > > software, but with fences, the scheduling would need to be done in the > > > driver. Then if the fence is signalled earlier, the driver should hold > > > on until the delay is met. If the fence got signalled late, we also > > > need to think of a workflow. As we can't schedule more then one render > > > in DRM at one time, I don't really see yet how to make that work. > > > > Indeed, that's also one of the main issues I've spotted. Before using > > an implicit fence, we basically have to make sure the frame is due for > > display at the next vblank. Otherwise, we need to refrain from using > > the fence and schedule the flip later, which is kind of counter- > > productive. > > Fences are about signalling that the contents of a frame are "done" and > ready to be presented. They're not about specifying which frame is to be > presented when. > > > > I feel like specifying a target vblank would be a good unit for that, > > The mechanism described above works for that. > > > since it's our native granularity after all (while a timestamp is not). > > Note that variable refresh rate (Adaptive Sync / FreeSync / G-Sync) > changes things in this regard. It makes the vblank length variable, and > if you wait for multiple vblanks between flips, you get the maximum > vblank length corresponding to the minimum refresh rate / timing > granularity. Thus, it would be useful to allow userspace to specify a > timestamp corresponding to the earliest time when the flip is to > complete. The kernel could then try to hit that as closely as possible. Rendering a video stream is more complex then what you describe here. Whenever there is a unexpected delay (late delivery of a frame as an example) you may endup in situation where one frame is ready after the targeted vblank. If there is another frame that targets the
[PATCH v2 5/9] drm/amdkfd: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c index 2cb09e088..769dbc7be 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -1272,8 +1272,7 @@ int kfd_topology_add_device(struct kfd_dev *gpu) dev->node_props.vendor_id = gpu->pdev->vendor; dev->node_props.device_id = gpu->pdev->device; - dev->node_props.location_id = PCI_DEVID(gpu->pdev->bus->number, - gpu->pdev->devfn); + dev->node_props.location_id = pci_dev_id(gpu->pdev); dev->node_props.max_engine_clk_fcompute = amdgpu_amdkfd_get_max_engine_clock_in_mhz(dev->gpu->kgd); dev->node_props.max_engine_clk_ccompute = -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst
On Tue, Apr 23, 2019 at 04:06:40PM -0600, Jonathan Corbet wrote: > Remember that most of our docs are 99% RST even though they were written > by people who had never even heard of RST. I really don't think it's a > big deal - a far smaller cognitive load than trying to keep up with any > given subsystem's variable-declaration-ordering rules, for example :) Tztztz, this thing seems to have hit a nerve with people. Which means, I will enforce that even more now so that I annoy submitters more! :-P See, I can do my own "RST" too. :-P Srsly: ok, good. Sounds like we're on the same page then. > I'm trying to do the same in Documentation/, with an attempt to be > sympathetic toward our readers, sort things by intended audience, > and create (someday) a coherent whole. I agree that moving docs is > a short-term annoyance, but I'm hoping that it brings a long-term > benefit. Ok, that's fair. I've been moving files too, in the past. > Minimal markup is the policy (it's even documented :). Automating stuff > that can be automated is an area that has definitely not received > enough attention; hopefully some things can be done there in the very > near future. Sounds nice, thanks Jon! -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst
Em Wed, 24 Apr 2019 16:54:10 +0200 Borislav Petkov escreveu: > On Wed, Apr 24, 2019 at 07:40:07AM -0300, Mauro Carvalho Chehab wrote: > > Personally, I don't care much with monospaced fonts on this table. After > > all, if I want to see it monospaced, I can simply click at the > > "View page source" at the browser, and it will display the file as a > > plain old monospaced text file. > > Goes to show why kernel people wouldn't want to look at that in > the browser. Long hex numbers are hard to read as it is - that's > why there's even the 4-digit separator in some docs, for example: > 0x__8100_. IMHO, even the 0x and _ would make it harder to read. This is a way more easy for my eyes: 8100 > Not having it monospaced makes the whole thing even less readable. Yeah, I see your point and agree with it. Just saying that, if all I want is to check if addresses that start with 80 belongs to the guard hole, or just to copy a value from a table into some C code, the font doesn't matter much, and, if I care, a simple click would show it in monospaced fonts. Looking from your PoV, something like: |8000 | -2GB | 9fff | 512 MB | kernel text mapping, mapped to physical address 0 | is very hard to be parsed by a human eye, even with monospaced fonts. In order to make it easier, I would replace it by: | 8000 | -2GB | 9fff | 512 MB | kernel text mapping, mapped to physical address 0 | > > That's why it is important for the markup not to get in the way of > people looking at those files in an editor. Fully agreed. the markups should make things easier and not harder for people to read its contents. Thanks, Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v8,1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel
Hi Thierry Reding：
*Could you please help to check whether there is any problem with the
sign-off identity**?*
*Thanks*
Jerry Han 于2019年4月25日周四 上午11:18写道：
> The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
> connected to DSI using four lanes.
>
> V8:
> - Modify communication address
>
> V7:
> - Add the information of the reviewer
>
> V6:
> - Add the information of the reviewer
>
> V5:
> - Added changelog
>
> V4:
> - None
>
> V3:
> - None
>
> V2:
> - Add compatible device "boe,himax8279d10p" (Sam)
> - Add the necessary property descriptions (Sam)
>
> Signed-off-by: Jerry Han
> Reviewed-by: Sam Ravnborg
> Reviewed-by: Derek Basehore
> Cc: Jitao Shi
> Cc: Rock wang
> ---
> .../bindings/display/panel/boe,himax8279d.txt | 24 +++
> 1 file changed, 24 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> new file mode 100644
> index ..3caea2172b1b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
> @@ -0,0 +1,24 @@
> +Boe Himax8279d 1200x1920 TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
> +- reg: DSI virtual channel of the peripheral
> +- enable-gpios: panel enable gpio
> +- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply
> voltage
> +- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply
> voltage
> +
> +Optional properties:
> +- backlight: phandle of the backlight device attached to the panel
> +
> +Example:
> +
> + _dsi {
> + panel {
> + compatible = "boe,himax8279d8p",
> "boe,himax8279d10p";
> + reg = <0>;
> + backlight = <>;
> + enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> + pp33-gpios = < 35 GPIO_ACTIVE_HIGH>;
> + pp18-gpios = < 36 GPIO_ACTIVE_HIGH>;
> + };
> + };
> --
> 2.17.1
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] iommu/amd: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index f467cc4b4..5cb201422 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -165,7 +165,7 @@ static inline u16 get_pci_device_id(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
- return PCI_DEVID(pdev->bus->number, pdev->devfn);
+ return pci_dev_id(pdev);
}
static inline int get_acpihid_device_id(struct device *dev,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 11/17] kunit: test: add test managed resource tests
On Thu, Apr 04, 2019 at 03:06:46PM -0700, Brendan Higgins wrote:
> From: Avinash Kondareddy
>
> Tests how tests interact with test managed resources in their lifetime.
>
> Signed-off-by: Avinash Kondareddy
> Signed-off-by: Brendan Higgins
> ---
> kunit/test-test.c | 122 ++
> 1 file changed, 122 insertions(+)
>
> diff --git a/kunit/test-test.c b/kunit/test-test.c
> index 4bd7a34d0a6cb..54add8ca418a0 100644
> --- a/kunit/test-test.c
> +++ b/kunit/test-test.c
> @@ -135,3 +135,125 @@ static struct kunit_module kunit_try_catch_test_module
> = {
> .test_cases = kunit_try_catch_test_cases,
> };
> module_test(kunit_try_catch_test_module);
> +
> +/*
> + * Context for testing test managed resources
> + * is_resource_initialized is used to test arbitrary resources
> + */
> +struct kunit_test_resource_context {
> + struct kunit test;
> + bool is_resource_initialized;
> +};
> +
> +static int fake_resource_init(struct kunit_resource *res, void *context)
> +{
> + struct kunit_test_resource_context *ctx = context;
> +
> + res->allocation = >is_resource_initialized;
> + ctx->is_resource_initialized = true;
> + return 0;
> +}
> +
> +static void fake_resource_free(struct kunit_resource *res)
> +{
> + bool *is_resource_initialized = res->allocation;
> +
> + *is_resource_initialized = false;
> +}
> +
> +static void kunit_resource_test_init_resources(struct kunit *test)
> +{
> + struct kunit_test_resource_context *ctx = test->priv;
> +
> + kunit_init_test(>test, "testing_test_init_test");
> +
> + KUNIT_EXPECT_TRUE(test, list_empty(>test.resources));
> +}
> +
> +static void kunit_resource_test_alloc_resource(struct kunit *test)
> +{
> + struct kunit_test_resource_context *ctx = test->priv;
> + struct kunit_resource *res;
> + kunit_resource_free_t free = fake_resource_free;
> +
> + res = kunit_alloc_resource(>test,
> +fake_resource_init,
> +fake_resource_free,
> +ctx);
> +
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, res);
KUNIT_EXPECT_NOT_ERR_OR_NULL(test, res);
Thanks!
Masa
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 56/79] docs: Documentation/*.txt: rename all ReST files to *.rst
Em Tue, 23 Apr 2019 23:38:16 +0200
Borislav Petkov escreveu:
> On Tue, Apr 23, 2019 at 05:05:02PM -0300, Mauro Carvalho Chehab wrote:
> > That's my view about how that specific file would be after
> > converted to ReST:
> >
> >
> > https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames
> >
> > I don't have any troubles reading/understanding it as a plain text
> > file,
>
> If that is all the changes it would need, then I guess that's ok. Btw,
> those rst-conversion patches don't really show what got changed. Dunno
> if git can even show that properly. I diffed the two files by hand to
> see what got changed, see end of mail.
Well, you can use git show -M01 and it will likely show what
changed. The thing is that plain diff is not very good showing
diffs on text files. I suspect that using some tool like wdiff
would give a better view of such changes.
> So I guess if table in rst means, one needs to draw rows and columns, I
> guess that's ok. It's not like I have to do it every day.
Yes, for complex tables, one needs to draw rows/columns. For simple
tables, all you need to do is something like:
== ===
- CONT PTEPMDCONT PMDPUD
== ===
4K: 64K 2M 32M 1G
16K: 2M32M 1G
64K: 2M 512M 16G
== ===
in order to teach Sphinx where each column starts/stops, and
(optionally) show the table titles in bold.
(that's from Documentation/arm64/hugetlbpage.rst conversion)
> But exactly this - *having* to do rst formatting would mean a lot of
> getting used to and people writing something which is not necessarily
> correct rst and someone else fixing up after them.
Yeah, one has to take the conversion effort, but once done, it should be
easy to keep it updated.
> > and its html output is also nice (although Sphinx 1.7.8 seems to
> > have some issues when parsing some cells - probably due to some bug):
> >
> > https://www.infradead.org/~mchehab/rst_conversion/x86/x86_64/mm.html
>
> I don't know how that looks in your browser but in mine those addresses
> are not in monospaced font and there's no properly reading them.
>
> And yap, the cells parsing fun I see too.
Font selection is one of the things would require some markup, as a
plain text file doesn't have font changes.
There are several ways to make it use a monospaced font.
The straight forward way would be to place everything that it is
monospaced inside ``double quotes``, with is the ReST way to mark
a literal block inside a text. IMHO, that would add too much
"noise" at the tables.
Another possibility would be to do:
.. raw:: html
td { font-family: monospace, monospace;
}
(the double monospace here is not a mistake - it is due to a known
bug^H^H^Hfeature on some browsers[1])
[1] https://stackoverflow.com/questions/38781089/font-family-monospace-monospace
IMO, the best alternative would be to add a new class to the css file,
and use it whenever we need a table with monospaced font, e. g.:
diff --git a/Documentation/sphinx-static/theme_overrides.css
b/Documentation/sphinx-static/theme_overrides.css
index e21e36cd6761..0948de6651f8 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -125,3 +125,7 @@ div[class^="highlight"] pre {
color: inherit;
}
}
+
+table.monospaced {
+ font-family: monospace, monospace;
+}
diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/x86/x86_64/mm.rst
index e8a92fa0f9b2..704bad5c5130 100644
--- a/Documentation/x86/x86_64/mm.rst
+++ b/Documentation/x86/x86_64/mm.rst
@@ -18,6 +18,8 @@ Notes:
notation than "16 EB", which few will recognize at first sight as 16
exabytes.
It also shows it nicely how incredibly large 64-bit address space is.
+.. cssclass:: monospaced
+
+-++--+-+---+
| Start addr| Offset | End addr | Size | VM area
description |
+=++==+=+===+
(patch on the top of this tree
https://git.linuxtv.org/mchehab/experimental.git/tree/Documentation/x86/x86_64/mm.rst?h=convert_rst_renames)
The ..cssclass:: markup on the above example will be applied just to
the table below it. So, with that, it is possible to have normal and
monospaced tables mixed (if you apply the above patch, you'll see
that just the first table will use monospaced fonts).
-
Personally, I don't care much with monospaced fonts on this table. After
all, if I want to see it monospaced, I can simply click at the
"View page source" at the browser, and it will display the file as a
plain
[PATCH v2 9/9] platform/chrome: chromeos_laptop: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code. Signed-off-by: Heiner Kallweit --- drivers/platform/chrome/chromeos_laptop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/chrome/chromeos_laptop.c b/drivers/platform/chrome/chromeos_laptop.c index 24326eecd..7abbb6167 100644 --- a/drivers/platform/chrome/chromeos_laptop.c +++ b/drivers/platform/chrome/chromeos_laptop.c @@ -125,7 +125,7 @@ static bool chromeos_laptop_match_adapter_devid(struct device *dev, u32 devid) return false; pdev = to_pci_dev(dev); - return devid == PCI_DEVID(pdev->bus->number, pdev->devfn); + return devid == pci_dev_id(pdev); } static void chromeos_laptop_check_adapter(struct i2c_adapter *adapter) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/9] PCI: use helper pci_dev_id
Use new helper pci_dev_id() to simplify the code.
Signed-off-by: Heiner Kallweit
---
drivers/pci/msi.c| 6 +++---
drivers/pci/search.c | 10 +++---
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 73986825d..e039b740f 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -1338,7 +1338,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev
*dev,
struct msi_desc *desc)
{
return (irq_hw_number_t)desc->msi_attrib.entry_nr |
- PCI_DEVID(dev->bus->number, dev->devfn) << 11 |
+ pci_dev_id(dev) << 11 |
(pci_domain_nr(dev->bus) & 0x) << 27;
}
@@ -1508,7 +1508,7 @@ static int get_msi_id_cb(struct pci_dev *pdev, u16 alias,
void *data)
u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev)
{
struct device_node *of_node;
- u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
+ u32 rid = pci_dev_id(pdev);
pci_for_each_dma_alias(pdev, get_msi_id_cb, );
@@ -1531,7 +1531,7 @@ u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain,
struct pci_dev *pdev)
struct irq_domain *pci_msi_get_device_domain(struct pci_dev *pdev)
{
struct irq_domain *dom;
- u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
+ u32 rid = pci_dev_id(pdev);
pci_for_each_dma_alias(pdev, get_msi_id_cb, );
dom = of_msi_map_get_device_domain(>dev, rid);
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 2b5f72086..5c7922612 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -33,7 +33,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
struct pci_bus *bus;
int ret;
- ret = fn(pdev, PCI_DEVID(pdev->bus->number, pdev->devfn), data);
+ ret = fn(pdev, pci_dev_id(pdev), data);
if (ret)
return ret;
@@ -88,9 +88,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
return ret;
continue;
case PCI_EXP_TYPE_PCIE_BRIDGE:
- ret = fn(tmp,
-PCI_DEVID(tmp->bus->number,
- tmp->devfn), data);
+ ret = fn(tmp, pci_dev_id(tmp), data);
if (ret)
return ret;
continue;
@@ -101,9 +99,7 @@ int pci_for_each_dma_alias(struct pci_dev *pdev,
PCI_DEVID(tmp->subordinate->number,
PCI_DEVFN(0, 0)), data);
else
- ret = fn(tmp,
-PCI_DEVID(tmp->bus->number,
- tmp->devfn), data);
+ ret = fn(tmp, pci_dev_id(tmp), data);
if (ret)
return ret;
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v8, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel
The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
connected to DSI using four lanes.
V8:
- Modify communication address
V7:
- Add the information of the reviewer
V6:
- Add the information of the reviewer
V5:
- Added changelog
V4:
- None
V3:
- None
V2:
- Add compatible device "boe,himax8279d10p" (Sam)
- Add the necessary property descriptions (Sam)
Signed-off-by: Jerry Han
Reviewed-by: Sam Ravnborg
Reviewed-by: Derek Basehore
Cc: Jitao Shi
Cc: Rock wang
---
.../bindings/display/panel/boe,himax8279d.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
new file mode 100644
index ..3caea2172b1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
@@ -0,0 +1,24 @@
+Boe Himax8279d 1200x1920 TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
+- reg: DSI virtual channel of the peripheral
+- enable-gpios: panel enable gpio
+- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
+- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+ _dsi {
+ panel {
+ compatible = "boe,himax8279d8p", "boe,himax8279d10p";
+ reg = <0>;
+ backlight = <>;
+ enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+ pp33-gpios = < 35 GPIO_ACTIVE_HIGH>;
+ pp18-gpios = < 36 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] backlight: lm3630a: add firmware node support
Add fwnode support to the lm3630a driver and optionally allow
configuring the label, default brightness level, and maximum brightness
level. The two outputs can be controlled by bank A and B independently
or bank A can control both outputs.
If the platform data was not configured, then the driver defaults to
enabling both banks. This patch changes the default value to disable
both banks before parsing the firmware node so that just a single bank
can be enabled if desired. There are no in-tree users of this driver.
Driver was tested on a LG Nexus 5 (hammerhead) phone.
Signed-off-by: Brian Masney
Reviewed-by: Dan Murphy
---
Changes since v5
- None
Changes since v4
- Added new function lm3630a_parse_bank()
- Renamed seen variable to seen_led_sources
- Use the bitmask returned from lm3630a_parse_led_sources() to compare
against the seen_led_sources rather than just the control bank. This
eliminated another if statement that was previously present that
checked to see if control bank A should control both sinks.
- #define LM3630A_BANK_0, LM3630A_BANK_1, LM3630A_SINK_0,
LM3630A_SINK_1, and LM3630A_NUM_SINKS and use where appropriate.
- Changed all occurances of
'if (bank == 0) { BANK_A_WORK } else { BANK_B_WORK }' to
'if (bank) { BANK_B_WORK } else { BANK_A_WORK }'
- Dropped unnecessary 'ret = 0' from lm3630a_parse_led_sources().
- Changed 'if (ret < 0)' to 'if (ret)' in lm3630a_parse_node().
- Dropped kerneldoc from lm3630a_parse_led_sources().
Changes since v3
- Add support for label
- Changed lm3630a_parse_node() to return -ENODEV if no nodes were found
- Remove LM3630A_LED{A,B}_DISABLE
- Add two additional newlines for code readability
- Remove extra newline
Changes since v2
- Separated out control banks and outputs via the reg and led-sources
properties.
- Use fwnode instead of of API
- Disable both banks by default before calling lm3630a_parse_node()
- Add lots of error handling
- Check for duplicate source / bank definitions
- Remove extra ;
- Make probe() method fail if fwnode parsing fails.
drivers/video/backlight/lm3630a_bl.c | 149 ++-
include/linux/platform_data/lm3630a_bl.h | 4 +
2 files changed, 148 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index ef2553f452ca..75d996490cf0 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -35,6 +35,14 @@
#define REG_MAX0x50
#define INT_DEBOUNCE_MSEC 10
+
+#define LM3630A_BANK_0 0
+#define LM3630A_BANK_1 1
+
+#define LM3630A_NUM_SINKS 2
+#define LM3630A_SINK_0 0
+#define LM3630A_SINK_1 1
+
struct lm3630a_chip {
struct device *dev;
struct delayed_work work;
@@ -329,15 +337,17 @@ static const struct backlight_ops lm3630a_bank_b_ops = {
static int lm3630a_backlight_register(struct lm3630a_chip *pchip)
{
- struct backlight_properties props;
struct lm3630a_platform_data *pdata = pchip->pdata;
+ struct backlight_properties props;
+ const char *label;
props.type = BACKLIGHT_RAW;
if (pdata->leda_ctrl != LM3630A_LEDA_DISABLE) {
props.brightness = pdata->leda_init_brt;
props.max_brightness = pdata->leda_max_brt;
+ label = pdata->leda_label ? pdata->leda_label : "lm3630a_leda";
pchip->bleda =
- devm_backlight_device_register(pchip->dev, "lm3630a_leda",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
_bank_a_ops, );
if (IS_ERR(pchip->bleda))
@@ -348,8 +358,9 @@ static int lm3630a_backlight_register(struct lm3630a_chip
*pchip)
(pdata->ledb_ctrl != LM3630A_LEDB_ON_A)) {
props.brightness = pdata->ledb_init_brt;
props.max_brightness = pdata->ledb_max_brt;
+ label = pdata->ledb_label ? pdata->ledb_label : "lm3630a_ledb";
pchip->bledb =
- devm_backlight_device_register(pchip->dev, "lm3630a_ledb",
+ devm_backlight_device_register(pchip->dev, label,
pchip->dev, pchip,
_bank_b_ops, );
if (IS_ERR(pchip->bledb))
@@ -364,6 +375,123 @@ static const struct regmap_config lm3630a_regmap = {
.max_register = REG_MAX,
};
+static int lm3630a_parse_led_sources(struct fwnode_handle *node,
+int default_led_sources)
+{
+ u32 sources[LM3630A_NUM_SINKS];
+ int ret, num_sources, i;
+
+ num_sources = fwnode_property_read_u32_array(node, "led-sources", NULL,
+0);
+ if (num_sources < 0)
+ return default_led_sources;
[PATCH v6 1/3] backlight: lm3630a: return 0 on success in update_status functions
lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.
Signed-off-by: Brian Masney
Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Acked-by: Pavel Machek
---
No changes since v2 when this patch was originally introduced.
drivers/video/backlight/lm3630a_bl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct
backlight_device *bl)
LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct
backlight_device *bl)
LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
- return bl->props.brightness;
+ return 0;
out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] PCI: add help pci_dev_id
In several places in the kernel we find PCI_DEVID used like this: PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper for it. v2: - apply the change to all affected places in the kernel Heiner Kallweit (9): PCI: add helper pci_dev_id PCI: use helper pci_dev_id r8169: use new helper pci_dev_id powerpc/powernv/npu: use helper pci_dev_id drm/amdkfd: use helper pci_dev_id iommu/amd: use helper pci_dev_id iommu/vt-d: use helper pci_dev_id stmmac: pci: use helper pci_dev_id platform/chrome: chromeos_laptop: use helper pci_dev_id arch/powerpc/platforms/powernv/npu-dma.c | 14 ++ drivers/gpu/drm/amd/amdkfd/kfd_topology.c| 3 +-- drivers/iommu/amd_iommu.c| 2 +- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/intel_irq_remapping.c | 2 +- drivers/net/ethernet/realtek/r8169.c | 3 +-- drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 2 +- drivers/pci/msi.c| 6 +++--- drivers/pci/search.c | 10 +++--- drivers/platform/chrome/chromeos_laptop.c| 2 +- include/linux/pci.h | 5 + 11 files changed, 24 insertions(+), 27 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 14/17] Documentation: kunit: add documentation for KUnit
Hi Brendan,
KUNIT_ASSERT_NOT_ERR_OR_NULL() should be replaced to
KUNIT_EXPECT_NOT_ERR_OR_NULL(), right?
On Thu, Apr 04, 2019 at 03:06:49PM -0700, Brendan Higgins wrote:
> Add documentation for KUnit, the Linux kernel unit testing framework.
> - Add intro and usage guide for KUnit
> - Add API reference
>
> Signed-off-by: Felix Guo
> Signed-off-by: Brendan Higgins
> ---
> diff --git a/Documentation/kunit/start.rst b/Documentation/kunit/start.rst
> new file mode 100644
> index 0..5cdba5091905e
> --- /dev/null
> +++ b/Documentation/kunit/start.rst
> +Assertions
> +~~
> +
> +KUnit also has the concept of an *assertion*. An assertion is just like an
> +expectation except the assertion immediately terminates the test case if it
> is
> +not satisfied.
> +
> +For example:
> +
> +.. code-block:: c
> +
> + static void mock_test_do_expect_default_return(struct kunit *test)
> + {
> + struct mock_test_context *ctx = test->priv;
> + struct mock *mock = ctx->mock;
> + int param0 = 5, param1 = -5;
> + const char *two_param_types[] = {"int", "int"};
> + const void *two_params[] = {, };
> + const void *ret;
> +
> + ret = mock->do_expect(mock,
> + "test_printk", test_printk,
> + two_param_types, two_params,
> + ARRAY_SIZE(two_params));
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ret);
KUNIT_EXPECT_NOT_ERR_OR_NULL(test, ret);
> + KUNIT_EXPECT_EQ(test, -4, *((int *) ret));
> + }
> +
> +In this example, the method under test should return a pointer to a value, so
> +if the pointer returned by the method is null or an errno, we don't want to
> +bother continuing the test since the following expectation could crash the
> test
> +case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test case if
+case. `KUNIT_EXPECT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test
case if
Thanks!
Masa
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
