Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi John, apparently the vgaarb was not the problem. Am 07.11.19 um 03:29 schrieb John Donnelly: > Hi, > > I am investigating an issue where we lose video activity when the display is > switched from from “text mode” to “graphic mode” > on a number of servers using this driver.Specifically starting the > GNOME desktop. When you say "text mode", do you mean VGA text mode or the graphical console that emulates text mode? When you enable graphics mode, does it set the correct resolution? A lot of work went into memory management recently. I could imagine that the driver sets the correct resolution, but then fails to display the correct framebuffer. If possible, could you try to update to the latest drm-tip and attach the output of /sys/kernel/debug/dri/0/vram-mm before and after switching to graphics mode. The file lists the allocated regions of the VRAM. > > This adapter is Server Engines Integrated Remote Video Acceleration > Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. > > I don’t see any specific errors in the gdm logs or message file other than > this: You can boot with drm.debug=0xff on the kernel command line to enable more warnings. > > > mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b00 > -> 0x9bff > mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c81 > -> 0x9c813fff > mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c00 > -> 0x9c7f Could you please attach the output of lspci -v for the VGA adapter? Best regards Thomas > > fb0: switching to mgag200drmfb from EFI VGA > mgag200 :04:00.0: vgaarb: deactivate vga console > fbcon: mgag200drmfb (fb0) is primary device > mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device > [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 > > The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; > The symptom first appears in 5.3.6. and onward. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: fix dropping obj reference twice
The reference count of obj will be decremented twice if error occurs
in dma_buf_fd(). Additionally, attempting to read the reference count of
obj after dropping reference may lead to a use after free bug. Here, we
drop obj's reference until it is not used.
Signed-off-by: Pan Bian
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 13044c027f27..4bfaefdf548d 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -498,8 +498,6 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned
int dmabuf_id)
goto out_free_gem;
}
- i915_gem_object_put(obj);
-
ret = dma_buf_fd(dmabuf, DRM_CLOEXEC | DRM_RDWR);
if (ret < 0) {
gvt_vgpu_err("create dma-buf fd failed ret:%d\n", ret);
@@ -524,6 +522,8 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu, unsigned
int dmabuf_id)
file_count(dmabuf->file),
kref_read(>base.refcount));
+ i915_gem_object_put(obj);
+
return dmabuf_fd;
out_free_dmabuf:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML
Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring: > On Sun, Nov 3, 2019 at 7:40 PM Andreas Färber > wrote: > > Instead of grouping alphabetically by third-party vendor, leading > > to > > one-element enums, sort by Mali model number, as done for Utgard. > > > > This already allows us to de-duplicate two "arm,mali-t760" sections > > and > > will make it easier to add new vendor compatibles. > > That was the intent. Not sure how I messed that up... > > This patch is problematic because there's changes in arm-soc juno/dt > branch and there's now a patch for exynos5420 (t628). I'd propose I > apply this such that we don't get a merge conflict with juno/dt and > we > finish resorting after rc1 (or when both branches are in Linus' > tree). This series has dependencies for the Realtek-side RFC patches and is not yet ready to merge, so you can take this prep PATCH through your tree for v5.6 probably, or feel free to rebase/rework as you see fit - I'd just appreciate being credited at least via Reported-by. :) Thanks, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
For the sysfs approach, I'm assuming the upstream vendors still need
to provide a pair of UMD and KMD, and this ioctl to label the BO is
kept as driver private ioctl. Then will each driver just define their
own set of "label"s and the KMD will only consume the corresponding
ones so that the sysfs nodes won't change at all? Report zero if
there's no allocation or re-use under a particular "label".
A separate thought is that do the GPU memory allocations deserve a
node under /proc/ for per process tracking? If the structure can
stay similar to what "maps" or "smaps" are, then we can bookkeep all
BOs with a label easily. For multi-gpu scenario, maybe having
something like "/proc//gpu_mem//maps" along with a global
table somewhere specifying the {gpu_id, device_name} pairs. Then the
global GPU allocation summary info still lives under
"/sys/devices//gpu_mem/". How difficult it is to define
such procfs node structure? Just curious.
Thanks for all the comments and replies!
Best regards,
Yiwei
On Wed, Nov 6, 2019 at 8:55 AM Rob Clark wrote:
>
> On Tue, Nov 5, 2019 at 1:47 AM Daniel Vetter wrote:
> >
> > On Mon, Nov 04, 2019 at 11:34:33AM -0800, Yiwei Zhang wrote:
> > > Hi folks,
> > >
> > > (Daniel, I just moved you to this thread)
> > >
> > > Below are the latest thoughts based on all the feedback and comments.
> > >
> > > First, I need to clarify on the gpu memory object type enumeration
> > > thing. We don't want to enforce those enumerations across the upstream
> > > and Android, and we should just leave those configurable and flexible.
> > >
> > > Second, to make this effort also useful to all the other memory
> > > management tools like PSS. At least an additional node is needed for
> > > the part of the gpu private allocation not mapped to the
> > > userspace(invisible to PSS). This is especially critical for the
> > > downstream Android so that low-memory-killer(lmkd) can be aware of the
> > > actual total memory for a process and will know how much gets freed up
> > > if it kills that process. This is an effort to de-mystify the "lost
> > > ram".
> > >
> > > Given above, the new node structure would look like below:
> > >
> > > Global nodes:
> > > /sys/devices//gpu_mem/global/total /* Total private allocation
> > > for coherency, this should also include the anonymous memory allocated
> > > in the kmd */
> > > /sys/devices//gpu_mem/global/total_unmapped /* Account for the
> > > private allocation not mapped to userspace(not visible for PSS), don't
> > > need to be coherent with the "total" node. lmkd or equivalent service
> > > looking at PSS will only look at this node in addition. */
> > > /sys/devices//gpu_mem/global/ /* One total value per
> > > type, this should also include the anonymous memory allocated in the
> > > kmd(or maybe another anonymous type for global nodes) */
> > > /sys/devices//gpu_mem/global/ /* One total value per type */
> > > ...
> > > /sys/devices//gpu_mem/global/ /* One total value per type */
> > >
> > > Per process nodes:
> > > /sys/devices//gpu_mem/proc//total /* Total private
> > > allocation for coherency */
> > > /sys/devices//gpu_mem/proc//total_unmapped /* Account for
> > > the private allocation not mapped to userspace(not visible for PSS),
> > > don't need to be coherent with the "total" node. lmkd or equivalent
> > > service looking at PSS will only look at this node in addition. */
> > > /sys/devices//gpu_mem/proc// /* One total value per
> > > type */
> > > /sys/devices//gpu_mem/proc// /* One total value per
> > > type */
> > > ...
> > > /sys/devices//gpu_mem/proc// /* One total value per
> > > type */
> > >
> > > The type1 to typeN for downstream Android will be the enumerations I
> > > mentioned in the original email which are: unknown, shader,...,
> > > transient. For the upstream, those can be the labeled BOs or any other
> > > customized types.
> > >
> > > Look forward to the comments and feedback!
> >
> > I don't think this will work well, at least for upstream:
> >
> > - The labels are currently free-form, baking them back into your structure
> > would mean we'd need to do lots of hot add/remove of sysfs directory
> > trees. Which sounds like a real bad idea :-/
>
> also, a bo's label can change over time if it is re-used for a
> different purpose.. not sure what the overhead is for add/remove
> sysfs, but I don't think I want that overhead in the bo_reuse path
>
> (maybe that matters less for vk, where we aren't using a userspace bo cache)
>
> BR,
> -R
>
> > - Buffer objects aren't attached to pids, but files. And files can be
> > shared. If we want to list this somewhere outside of debugfs, we need to
> > tie this into the files somehow (so proc), except the underlying files
> > are all anon inodes, so this gets really tricky I think to make work
> > well.
> >
> > Cheers, Daniel
> >
> > >
> > > Best regards,
> > > Yiwei
> > >
> > >
> > >
> > >
> > > On Fri, Nov 1, 2019 at 1:37 AM Pekka Paalanen wrote:
> > > >
> > > > On Thu, 31
Re: [PATCH V9 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On 11/5/19 11:05 PM, Jason Wang wrote: > diff --git a/samples/Kconfig b/samples/Kconfig > index c8dacb4dda80..13a2443e18e0 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY > mediated device. It is a simple framebuffer and supports > the region display interface (VFIO_GFX_PLANE_TYPE_REGION). > > +config SAMPLE_VIRTIO_MDEV_NET > + tristate "Build VIRTIO net example mediated device sample code -- > loadable modules only" > + depends on VIRTIO_MDEV && VHOST_RING && m > + help > + Build a networking sample device for use as a virtio > + mediated device. The device coopreates with virtio-mdev bus typo here: cooperates > + driver to present an virtio ethernet driver for > + kernel. It simply loopbacks all packets from its TX > + virtqueue to its RX virtqueue. > + > config SAMPLE_VFIO_MDEV_MDPY_FB > tristate "Build VFIO mdpy example guest fbdev driver -- loadable module > only" > depends on FB && m ciao. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2] modetest: Add support for setting mode having floating vertical refresh rate
For the scenario where user may require to modeset with a mode
supporting a fractional value for vertical refresh-rate,
appropriate mode can be selected by searching for mode
having matching fractional vertical refresh rate using
below equation.
vrefresh = (1000 * pixel clock) / (htotal * vtotal) Hz.
We do this way since driver doesn't return float value of vrefresh
as it use int for vrefresh in struct drm_mode_info, but we can derive
the actual value using pixel clock, horizontal total size and
vertical total size values.
So for e.g. if user want to select mode having 59.94 Hz as refresh rate
then with this patch it be can done as shown in below command,
given there is an appropriate mode is available :
modetest -M xlnx -s 39:1920x1080-59.94@BG24 -v
NOTE: Above command was tested on xilinx DRM driver with DP
monitor which was supporting mode having 59.94 Hz refresh rate.
Signed-off-by: Devarsh Thakkar
---
V2: Update commit message
---
tests/modetest/modetest.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index e66be66..9b3e410 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -795,7 +795,7 @@ struct pipe_arg {
uint32_t crtc_id;
char mode_str[64];
char format_str[5];
- unsigned int vrefresh;
+ float vrefresh;
unsigned int fourcc;
drmModeModeInfo *mode;
struct crtc *crtc;
@@ -822,11 +822,12 @@ struct plane_arg {
static drmModeModeInfo *
connector_find_mode(struct device *dev, uint32_t con_id, const char *mode_str,
-const unsigned int vrefresh)
+ const float vrefresh)
{
drmModeConnector *connector;
drmModeModeInfo *mode;
int i;
+ float mode_vrefresh;
connector = get_connector_by_id(dev, con_id);
if (!connector || !connector->count_modes)
@@ -839,9 +840,19 @@ connector_find_mode(struct device *dev, uint32_t con_id,
const char *mode_str,
* first mode that match with the name. Else, return
the mode that match
* the name and the specified vertical refresh
frequency.
*/
+ float temp;
+
+ mode_vrefresh = ((float)(mode->clock) * 1000.00)
+/ ((float)(mode->htotal)
+* (float)mode->vtotal);
+ /* Round off to 2 decimal places to match with user
+* provided value
+*/
+ temp = (int) (mode_vrefresh * 100 + 0.5);
+ mode_vrefresh = (float) temp / 100;
if (vrefresh == 0)
return mode;
- else if (mode->vrefresh == vrefresh)
+ else if (mode_vrefresh == vrefresh)
return mode;
}
}
@@ -1393,8 +1404,8 @@ static void atomic_set_mode(struct device *dev, struct
pipe_arg *pipes, unsigned
if (pipe->mode == NULL)
continue;
- printf("setting mode %s-%dHz on connectors ",
- pipe->mode_str, pipe->mode->vrefresh);
+ printf("setting mode %s-%.2fHz on connectors ",
+ pipe->mode_str, pipe->vrefresh);
for (j = 0; j < pipe->num_cons; ++j) {
printf("%s, ", pipe->cons[j]);
add_property(dev, pipe->con_ids[j], "CRTC_ID",
pipe->crtc->crtc->crtc_id);
@@ -1476,8 +1487,8 @@ static void set_mode(struct device *dev, struct pipe_arg
*pipes, unsigned int co
if (pipe->mode == NULL)
continue;
- printf("setting mode %s-%dHz@%s on connectors ",
- pipe->mode_str, pipe->mode->vrefresh, pipe->format_str);
+ printf("setting mode %s-%.2fHz@%s on connectors ",
+ pipe->mode_str, pipe->vrefresh, pipe->format_str);
for (j = 0; j < pipe->num_cons; ++j)
printf("%s, ", pipe->cons[j]);
printf("crtc %d\n", pipe->crtc->crtc->crtc_id);
@@ -1713,8 +1724,13 @@ static int parse_connector(struct pipe_arg *pipe, const
char *arg)
pipe->mode_str[len] = '\0';
if (*p == '-') {
- pipe->vrefresh = strtoul(p + 1, , 10);
+ float temp;
+
+ pipe->vrefresh = strtof(p + 1, );
p = endp;
+ /* Round off to 2 decimal places */
+ temp = (int) (pipe->vrefresh * 100 + 0.5);
+ pipe->vrefresh = (float) temp / 100;
}
if (*p == '@') {
--
2.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged
Re: WARNING in drm_mode_createblob_ioctl
On Wed, Nov 6, 2019 at 4:30 PM Daniel Vetter wrote:
>
> On Wed, Nov 6, 2019 at 4:20 PM syzbot
> wrote:
> >
> > syzbot has bisected this bug to:
> >
> > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
> > Author: Kees Cook
> > Date: Mon Nov 4 22:57:23 2019 +
> >
> > uaccess: disallow > INT_MAX copy sizes
>
> Ah cool, this explains it.
>
> fwiw I never managed to get the WARNING in the backtrace to lign up
> with any code. No idea what's been going on.
>
> I'll type a patch to paper over this.
> -Daniel
If I get:
git checkout 8ada228a
then include/linux/thread_info.h:150
points right to:
if (WARN_ON_ONCE(bytes > INT_MAX))
Is the size user-controllable here?
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce0
> > start commit: 51309b9d Add linux-next specific files for 20191105
> > git tree: linux-next
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=115fe6dce0
> > console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
> > dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0
> >
> > Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> > Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/CAKMK7uFQt%2B%3D7XMo9jvz77QvDWLAAU_V7-_qZ%3DiKe-GXG7cqeJg%40mail.gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/amdgpu: fix double reference dropping
The reference to object fence is dropped at the end of the loop.
However, it is dropped again outside the loop. The reference can be
dropped immediately after calling dma_fence_wait() in the loop and
thus the dropping operation outside the loop can be removed.
Signed-off-by: Pan Bian
---
v2: fix the bug in a more concise way
---
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
index 649e68c4479b..d1495e1c9289 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
@@ -33,7 +33,7 @@ static int amdgpu_benchmark_do_move(struct amdgpu_device
*adev, unsigned size,
{
unsigned long start_jiffies;
unsigned long end_jiffies;
- struct dma_fence *fence = NULL;
+ struct dma_fence *fence;
int i, r;
start_jiffies = jiffies;
@@ -44,16 +44,14 @@ static int amdgpu_benchmark_do_move(struct amdgpu_device
*adev, unsigned size,
if (r)
goto exit_do_move;
r = dma_fence_wait(fence, false);
+ dma_fence_put(fence);
if (r)
goto exit_do_move;
- dma_fence_put(fence);
}
end_jiffies = jiffies;
r = jiffies_to_msecs(end_jiffies - start_jiffies);
exit_do_move:
- if (fence)
- dma_fence_put(fence);
return r;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_mode_createblob_ioctl
syzbot has found a reproducer for the following crash on: HEAD commit:51309b9d Add linux-next specific files for 20191105 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=13f5c078e0 kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52 dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 8842 at include/linux/thread_info.h:150 check_copy_size include/linux/thread_info.h:150 [inline] WARNING: CPU: 0 PID: 8842 at include/linux/thread_info.h:150 copy_from_user include/linux/uaccess.h:143 [inline] WARNING: CPU: 0 PID: 8842 at include/linux/thread_info.h:150 drm_mode_createblob_ioctl+0x398/0x490 drivers/gpu/drm/drm_property.c:800 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 8842 Comm: syz-executor938 Not tainted 5.4.0-rc6-next-20191105 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 panic+0x2e3/0x75c kernel/panic.c:221 __warn.cold+0x2f/0x35 kernel/panic.c:582 report_bug+0x289/0x300 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:174 [inline] fixup_bug arch/x86/kernel/traps.c:169 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:check_copy_size include/linux/thread_info.h:150 [inline] RIP: 0010:copy_from_user include/linux/uaccess.h:143 [inline] RIP: 0010:drm_mode_createblob_ioctl+0x398/0x490 drivers/gpu/drm/drm_property.c:800 Code: c1 ea 03 80 3c 02 00 0f 85 ed 00 00 00 49 89 5d 00 e8 0c f2 c6 fd 4c 89 f7 e8 24 af aa 03 31 c0 e9 75 fd ff ff e8 f8 f1 c6 fd <0f> 0b e8 f1 f1 c6 fd 4d 85 e4 b8 f2 ff ff ff 0f 84 5b fd ff ff 89 RSP: 0018:8880a5e07aa8 EFLAGS: 00010293 RAX: 88809f3a0440 RBX: 8880a387c000 RCX: 83ac75e2 RDX: RSI: 83ac77a8 RDI: 0007 RBP: 8880a5e07ae8 R08: 88809f3a0440 R09: ed101470f910 R10: ed101470f90f R11: 8880a387c87f R12: c90005f5d000 R13: 8880a4d78000 R14: 96e170d0 R15: c90005f5d058 drm_ioctl_kernel+0x244/0x300 drivers/gpu/drm/drm_ioctl.c:786 drm_ioctl+0x54e/0xa60 drivers/gpu/drm/drm_ioctl.c:886 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x449659 Code: e8 fc b8 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab d6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f6951f91db8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 006dac38 RCX: 00449659 RDX: 2000 RSI: ffbd RDI: 0004 RBP: 006dac30 R08: 7f6951f92700 R09: R10: 7f6951f92700 R11: 0246 R12: 006dac3c R13: 7ffeae0e7e9f R14: 7f6951f929c0 R15: 20c49ba5e353f7cf Kernel Offset: disabled Rebooting in 86400 seconds.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Drm: mgag200. Video adapter issue with 5.4.0-rc3
Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver. This adapter is Server Engines integrated Remote Video Acceleration Subsystem (RVAS) is used primarily as remote console , iLO/DRAC environments. I was wondering if anyone could offer any suggestions where to look at . I don’t see any specific errors in the gdm logs or message file other than this: mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b00 -> 0x9bff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c81 -> 0x9c813fff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c00 -> 0x9c7f fb0: switching to mgag200drmfb from EFI VGA mgag200 :04:00.0: vgaarb: deactivate vga console fbcon: mgag200drmfb (fb0) is primary device mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 The systems worked fine 4.18 kernels ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] modetest: Add support for setting mode having floating vertical refresh rate
For the scenario where user may require to modeset with a mode
supporting a fractional value for vertical refresh-rate,
appropriate mode can be selected by searching for mode
having matching fractional vertical refresh rate using
below equation.
vrefresh = 1000 * (pixel clock) / (htotal * vtotal) Khz.
We do this way since driver doesn't return float value of vrefresh
as it use int for vrefresh in struct drm_mode_info, but we derive
the actual value using pixel clock, htotal and vtotal values.
So for e.g. if user want to select mode having 59.94 Hz as refresh rate
then with this patch it be can done as shown in below command,
given there is an appropriate mode is available :
modetest -M xlnx -s 39:1920x1080-59.94@BG24 -v
NOTE: Above command was tested on xilinx DRM driver with DP
monitor which was supporting mode having 59.94 Hz refresh rate.
Signed-off-by: Devarsh Thakkar
---
tests/modetest/modetest.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index e66be66..9b3e410 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -795,7 +795,7 @@ struct pipe_arg {
uint32_t crtc_id;
char mode_str[64];
char format_str[5];
- unsigned int vrefresh;
+ float vrefresh;
unsigned int fourcc;
drmModeModeInfo *mode;
struct crtc *crtc;
@@ -822,11 +822,12 @@ struct plane_arg {
static drmModeModeInfo *
connector_find_mode(struct device *dev, uint32_t con_id, const char *mode_str,
-const unsigned int vrefresh)
+ const float vrefresh)
{
drmModeConnector *connector;
drmModeModeInfo *mode;
int i;
+ float mode_vrefresh;
connector = get_connector_by_id(dev, con_id);
if (!connector || !connector->count_modes)
@@ -839,9 +840,19 @@ connector_find_mode(struct device *dev, uint32_t con_id,
const char *mode_str,
* first mode that match with the name. Else, return
the mode that match
* the name and the specified vertical refresh
frequency.
*/
+ float temp;
+
+ mode_vrefresh = ((float)(mode->clock) * 1000.00)
+/ ((float)(mode->htotal)
+* (float)mode->vtotal);
+ /* Round off to 2 decimal places to match with user
+* provided value
+*/
+ temp = (int) (mode_vrefresh * 100 + 0.5);
+ mode_vrefresh = (float) temp / 100;
if (vrefresh == 0)
return mode;
- else if (mode->vrefresh == vrefresh)
+ else if (mode_vrefresh == vrefresh)
return mode;
}
}
@@ -1393,8 +1404,8 @@ static void atomic_set_mode(struct device *dev, struct
pipe_arg *pipes, unsigned
if (pipe->mode == NULL)
continue;
- printf("setting mode %s-%dHz on connectors ",
- pipe->mode_str, pipe->mode->vrefresh);
+ printf("setting mode %s-%.2fHz on connectors ",
+ pipe->mode_str, pipe->vrefresh);
for (j = 0; j < pipe->num_cons; ++j) {
printf("%s, ", pipe->cons[j]);
add_property(dev, pipe->con_ids[j], "CRTC_ID",
pipe->crtc->crtc->crtc_id);
@@ -1476,8 +1487,8 @@ static void set_mode(struct device *dev, struct pipe_arg
*pipes, unsigned int co
if (pipe->mode == NULL)
continue;
- printf("setting mode %s-%dHz@%s on connectors ",
- pipe->mode_str, pipe->mode->vrefresh, pipe->format_str);
+ printf("setting mode %s-%.2fHz@%s on connectors ",
+ pipe->mode_str, pipe->vrefresh, pipe->format_str);
for (j = 0; j < pipe->num_cons; ++j)
printf("%s, ", pipe->cons[j]);
printf("crtc %d\n", pipe->crtc->crtc->crtc_id);
@@ -1713,8 +1724,13 @@ static int parse_connector(struct pipe_arg *pipe, const
char *arg)
pipe->mode_str[len] = '\0';
if (*p == '-') {
- pipe->vrefresh = strtoul(p + 1, , 10);
+ float temp;
+
+ pipe->vrefresh = strtof(p + 1, );
p = endp;
+ /* Round off to 2 decimal places */
+ temp = (int) (pipe->vrefresh * 100 + 0.5);
+ pipe->vrefresh = (float) temp / 100;
}
if (*p == '@') {
--
2.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the
[RFC PATCH 00/12] i2c: replace i2c_new_probed_device with an ERR_PTR variant
From: Wolfram Sang In the on-going mission to let i2c_new_* calls return an ERR_PTR instead of NULL, here is a series converting i2c_new_probed_device(). A new function called i2c_new_scanned_device() is introduced with the new retval, but for now, a compatibility helper is provided until all users are converted. The rest of the patches convert all current in-tree users. Note that these patches are RFC because I want feedback on the approach and hopefully collect acks on the driver conversions. If all goes well, I'll apply the first two patches for the next merge window. Then, once this dependency is upstream, I'll resend this series with all issues fixed and acks collected. Core changes tested on a Renesas Salvator-XS board (R-Car M3-N), driver patches build tested by me and buildbot. Wolfram Sang (12): i2c: replace i2c_new_probed_device with an ERR_PTR variant i2c: icy: convert to i2c_new_scanned_device macintosh: convert to i2c_new_scanned_device platform: chrome: convert to i2c_new_scanned_device video: fbdev: matrox: convert to i2c_new_scanned_device input: mouse: convert to i2c_new_scanned_device media: pci: cx23885: convert to i2c_new_scanned_device media: pci: cx88: convert to i2c_new_scanned_device media: pci: bt8xx: convert to i2c_new_scanned_device media: pci: cx18: convert to i2c_new_scanned_device media: pci: ivtv: convert to i2c_new_scanned_device media: v4l2-core: convert to i2c_new_scanned_device Documentation/i2c/instantiating-devices.rst | 10 - Documentation/i2c/writing-clients.rst | 8 +++ drivers/i2c/busses/i2c-icy.c| 8 +++ drivers/i2c/i2c-core-base.c | 25 - drivers/input/mouse/psmouse-smbus.c | 8 --- drivers/macintosh/therm_windtunnel.c| 4 ++-- drivers/media/pci/bt8xx/bttv-input.c| 6 ++--- drivers/media/pci/cx18/cx18-i2c.c | 2 +- drivers/media/pci/cx23885/cx23885-i2c.c | 4 ++-- drivers/media/pci/cx88/cx88-input.c | 2 +- drivers/media/pci/ivtv/ivtv-i2c.c | 6 ++--- drivers/media/pci/ivtv/ivtv-i2c.h | 2 +- drivers/media/v4l2-core/v4l2-i2c.c | 10 - drivers/platform/chrome/chromeos_laptop.c | 18 --- drivers/video/fbdev/matrox/i2c-matroxfb.c | 4 ++-- include/linux/i2c.h | 12 +++--- 16 files changed, 76 insertions(+), 53 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
>
> On Wed, Nov 6, 2019 at 1:13 AM Brian Masney wrote:
> >
> > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney wrote:
> > > > The 'pp done time out' errors go away if I revert the following three
> > > > commits:
> > > >
> > > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > > 2d99ced787e3 ("drm/msm: async commit support")
> > > >
> > > > I reverted the first one to fix a compiler error, and the second one so
> > > > that the last patch can be reverted without any merge conflicts.
> > > >
> > > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > > > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > > > buffer dance around the screen like its out of sync. I renamed
> > > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > > > declaration. Here's the relevant part of what I tried:
> > > >
> > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms
> > > > *kms, struct drm_atomic_state *st
> > > >
> > > > static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> > > > {
> > > > - /* TODO */
> > > > + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > > > + struct drm_crtc *crtc;
> > > > +
> > > > + for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > > + if (!crtc->state->active)
> > > > + continue;
> > > > +
> > > > + mdp5_crtc_flush_all(crtc);
> > > > + }
> > > > }
> > > >
> > > > Any tips would be appreciated.
> > >
> > >
> > > I think this is along the lines of what we need to enable async commit
> > > for mdp5 (but also removing the flush from the atomic-commit path)..
> > > the principle behind the async commit is to do all the atomic state
> > > commit normally, but defer writing the flush bits. This way, if you
> > > get another async update before the next vblank, you just apply it
> > > immediately instead of waiting for vblank.
> > >
> > > But I guess you are on a command mode panel, if I remember? Which is
> > > a case I didn't have a way to test. And I'm not entirely about how
> > > kms_funcs->vsync_time() should be implemented for cmd mode panels.
> >
> > Yes, this is a command-mode panel and there's no hardware frame counter
> > available. The key to getting the display working on this phone was this
> > patch:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> >
> > > That all said, I think we should first fix what is broken, before
> > > worrying about extending async commit support to mdp5.. which
> > > shouldn't hit the async==true path, due to not implementing
> > > kms_funcs->vsync_time().
> > >
> > > What I think is going on is that, in the cmd mode case,
> > > mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> > > which waits for a pp-done irq regardless of whether there is a flush
> > > in progress. Since there is no flush pending, the irq never comes.
> > > But the expectation is that kms_funcs->wait_flush() returns
> > > immediately if there is nothing to wait for.
> >
> > I don't think that's happening in this case. I added some pr_info()
> > statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> > Here's the first two sets of messages that appear in dmesg:
> >
> > [ 14.018907] msm fd90.mdss: pp done time out, lm=0
> > [ 14.018993] request_pp_done_pending: HERE
> > [ 14.074208] mdp5_crtc_pp_done_irq: HERE
> > [ 14.074368] Console: switching to colour frame buffer device 135x120
> > [ 14.138938] msm fd90.mdss: pp done time out, lm=0
> > [ 14.139021] request_pp_done_pending: HERE
> > [ 14.158097] mdp5_crtc_pp_done_irq: HERE
> >
> > The messages go on like this with the same pattern.
> >
> > I tried two different changes:
> >
> > 1) I moved the request_pp_done_pending() and corresponding if statement
> >from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
> >
> > 2) I increased the timeout in wait_for_completion_timeout() by several
> >increments; all the way to 5 seconds.
>
> increasing the timeout won't help, because the pp-done irq has already
> come at the point where we wait for it..
>
> maybe the easy thing is just add mdp5_crtc->needs_pp, set to true
> before requesting, and false when we get the irq.. and then
> mdp5_crtc_wait_for_pp_done() just returns if needs_pp==false..
On the otherhand, what about trying to make command mode panels
resemble video mode panels slightly? Video mode panels have a vsync
counter in hardware, which is missing from command mode - however it
seems like the driver/drm framework would prefer such a counter.
Would it be a
[PATCH 2/3] drm/rockchip: add ability to handle external dphys in mipi-dsi
While the common case is that the dsi controller uses an internal dphy,
accessed through the phy registers inside the dsi controller, there is
also the possibility to use a separate dphy from a different vendor.
One such case is the Rockchip px30 that uses a Innosilicon Mipi dphy,
so add the support for handling such a constellation, including the pll
also getting generated inside that external phy.
Signed-off-by: Heiko Stuebner
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 ++-
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 54 ++-
2 files changed, 57 insertions(+), 4 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
index ce4c1fc9116c..8b25156a9dcf 100644
---
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -8,8 +8,9 @@ Required properties:
"rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi".
- reg: Represent the physical address range of the controller.
- interrupts: Represent the controller's interrupt to the CPU(s).
-- clocks, clock-names: Phandles to the controller's pll reference
- clock(ref) and APB clock(pclk). For RK3399, a phy config clock
+- clocks, clock-names: Phandles to the controller's and APB clock(pclk)
+ and either a pll reference clock(ref) (internal dphy) or pll clock(pll)
+ (when connected to an external phy). For RK3399, a phy config clock
(phy_cfg) and a grf clock(grf) are required. As described in [1].
- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
- ports: contain a port node with endpoint definitions as defined in [2].
@@ -18,6 +19,8 @@ Required properties:
- video port 1 for either a panel or subsequent encoder
Optional properties:
+- phys: from general PHY binding: the phandle for the PHY device.
+- phy-names: Should be "dphy" if phys references an external phy.
- power-domains: a phandle to mipi dsi power domain node.
- resets: list of phandle + reset specifier pairs, as described in [3].
- reset-names: string reset name, must be "apb".
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index bc073ec5c183..99ec625e0448 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -223,6 +224,9 @@ struct dw_mipi_dsi_rockchip {
bool is_slave;
struct dw_mipi_dsi_rockchip *slave;
+ /* optional external dphy */
+ struct phy *phy;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -359,6 +363,9 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
struct dw_mipi_dsi_rockchip *dsi = priv_data;
int ret, i, vco;
+ if (dsi->phy)
+ return 0;
+
/*
* Get vco from frequency(lane_mbps)
* vco frequency table
@@ -467,6 +474,27 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+static void dw_mipi_dsi_phy_power_on(void *priv_data)
+{
+ struct dw_mipi_dsi_rockchip *dsi = priv_data;
+ int ret;
+
+ ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
+ if (ret) {
+ DRM_DEV_ERROR(dsi->dev, "failed to set phy mode: %d\n", ret);
+ return;
+ }
+
+ phy_power_on(dsi->phy);
+}
+
+static void dw_mipi_dsi_phy_power_off(void *priv_data)
+{
+ struct dw_mipi_dsi_rockchip *dsi = priv_data;
+
+ phy_power_off(dsi->phy);
+}
+
static int
dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
unsigned long mode_flags, u32 lanes, u32 format,
@@ -504,9 +532,21 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
"DPHY clock frequency is out of range\n");
}
- fin = clk_get_rate(dsi->pllref_clk);
fout = target_mbps * USEC_PER_SEC;
+ /* an external phy does have a controllable pll clk */
+ if (dsi->phy) {
+ fout = clk_round_rate(dsi->pllref_clk, fout);
+ clk_set_rate(dsi->pllref_clk, fout);
+
+ dsi->lane_mbps = target_mbps;
+ *lane_mbps = dsi->lane_mbps;
+
+ return 0;
+ }
+
+ fin = clk_get_rate(dsi->pllref_clk);
+
/* constraint: 5Mhz <= Fref / N <= 40MHz */
min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
max_prediv = fin / (5 * USEC_PER_SEC);
@@ -561,6 +601,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_rockchip_phy_ops = {
.init = dw_mipi_dsi_phy_init,
+ .power_on = dw_mipi_dsi_phy_power_on,
+
[RFC PATCH 05/12] video: fbdev: matrox: convert to i2c_new_scanned_device
Move from the deprecated i2c_new_probed_device() to the new
i2c_new_scanned_device(). Make use of the new ERRPTR if suitable.
Signed-off-by: Wolfram Sang
---
Build tested only. RFC, please comment and/or ack, but don't apply yet.
drivers/video/fbdev/matrox/i2c-matroxfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/matrox/i2c-matroxfb.c
b/drivers/video/fbdev/matrox/i2c-matroxfb.c
index 34e2659c3189..e2e4705e3fe0 100644
--- a/drivers/video/fbdev/matrox/i2c-matroxfb.c
+++ b/drivers/video/fbdev/matrox/i2c-matroxfb.c
@@ -191,8 +191,8 @@ static void* i2c_matroxfb_probe(struct matrox_fb_info*
minfo) {
0x1b, I2C_CLIENT_END
};
- i2c_new_probed_device(>maven.adapter,
- _info, addr_list, NULL);
+ i2c_new_scanned_device(>maven.adapter,
+ _info, addr_list, NULL);
}
}
return m2info;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/15] mm/mmu_notifier: define the header pre-processor parts even if disabled
On Tue, Nov 05, 2019 at 01:23:46PM -0800, John Hubbard wrote:
> On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Now that we have KERNEL_HEADER_TEST all headers are generally compile
> > tested, so relying on makefile tricks to avoid compiling code that depends
> > on CONFIG_MMU_NOTIFIER is more annoying.
> >
> > Instead follow the usual pattern and provide most of the header with only
> > the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This
> > ensures code compiles no matter what the config setting is.
> >
> > While here, struct mmu_notifier_mm is private to mmu_notifier.c, move it.
>
> and correct a minor spelling error in a comment. Good. :)
>
> >
> > Reviewed-by: Jérôme Glisse
> > Signed-off-by: Jason Gunthorpe
> > include/linux/mmu_notifier.h | 46 +---
> > mm/mmu_notifier.c| 13 ++
> > 2 files changed, 30 insertions(+), 29 deletions(-)
> >
>
> Because this is correct as-is, you can add:
>
> Reviewed-by: John Hubbard
>
Thanks
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 2b7485919ecf..107f9406a92d 100644
> +++ b/mm/mmu_notifier.c
> @@ -47,6 +47,16 @@ struct mmu_notifier_mm {
> struct hlist_head deferred_list;
> };
>
> +int mm_has_notifiers(struct mm_struct *mm)
> +{
> + return unlikely(mm->mmu_notifier_mm);
> +}
This inline is performance sensitive, it needs to stay inlined..
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/bridge/synopsys: dsi: move phy_ops callbacks around panel enablement
If implementation-specific phy_ops need to be defined they probably
should be enabled before trying to talk to the panel and disabled only
after the panel was disabled.
Right now they are enabled last and disabled first, so might make it
impossible to talk to some panels - example for this being the px30
with an external Innosilicon dphy that needs the phy to be enabled
to transfer commands to the panel.
So move the calls appropriately.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 675442bfc1bd..49f5600a1dea 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -797,9 +797,6 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
- if (phy_ops->power_off)
- phy_ops->power_off(dsi->plat_data->priv_data);
-
/*
* Switch to command mode before panel-bridge post_disable &
* panel unprepare.
@@ -816,6 +813,9 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
*/
dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
+ if (phy_ops->power_off)
+ phy_ops->power_off(dsi->plat_data->priv_data);
+
if (dsi->slave) {
dw_mipi_dsi_disable(dsi->slave);
clk_disable_unprepare(dsi->slave->pclk);
@@ -882,6 +882,9 @@ static void dw_mipi_dsi_mode_set(struct dw_mipi_dsi *dsi,
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
+
+ if (phy_ops->power_on)
+ phy_ops->power_on(dsi->plat_data->priv_data);
}
static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -898,15 +901,11 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
static void dw_mipi_dsi_bridge_enable(struct drm_bridge *bridge)
{
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
- const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
/* Switch to video mode for panel-bridge enable & panel enable */
dw_mipi_dsi_set_mode(dsi, MIPI_DSI_MODE_VIDEO);
if (dsi->slave)
dw_mipi_dsi_set_mode(dsi->slave, MIPI_DSI_MODE_VIDEO);
-
- if (phy_ops->power_on)
- phy_ops->power_on(dsi->plat_data->priv_data);
}
static enum drm_mode_status
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_mode_createblob_ioctl
syzbot has bisected this bug to:
commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
Author: Kees Cook
Date: Mon Nov 4 22:57:23 2019 +
uaccess: disallow > INT_MAX copy sizes
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce0
start commit: 51309b9d Add linux-next specific files for 20191105
git tree: linux-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=115fe6dce0
console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce0
kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
dashboard link: https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0
Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: fix potential double drop fence reference
The object fence is not set to NULL after its reference is dropped. As a
result, its reference may be dropped again if error occurs after that,
which may lead to a use after free bug. To avoid the issue, fence is
explicitly set to NULL after dropping its reference.
Signed-off-by: Pan Bian
---
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
index b66d29d5ffa2..b158230af8db 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
@@ -138,6 +138,7 @@ static void amdgpu_do_test_moves(struct amdgpu_device *adev)
}
dma_fence_put(fence);
+ fence = NULL;
r = amdgpu_bo_kmap(vram_obj, _map);
if (r) {
@@ -183,6 +184,7 @@ static void amdgpu_do_test_moves(struct amdgpu_device *adev)
}
dma_fence_put(fence);
+ fence = NULL;
r = amdgpu_bo_kmap(gtt_obj[i], _map);
if (r) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> On Tue, Nov 5, 2019 at 2:08 AM Brian Masney wrote:
> > The 'pp done time out' errors go away if I revert the following three
> > commits:
> >
> > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > d934a712c5e6 ("drm/msm: add atomic traces")
> > 2d99ced787e3 ("drm/msm: async commit support")
> >
> > I reverted the first one to fix a compiler error, and the second one so
> > that the last patch can be reverted without any merge conflicts.
> >
> > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > buffer dance around the screen like its out of sync. I renamed
> > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > declaration. Here's the relevant part of what I tried:
> >
> > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms *kms,
> > struct drm_atomic_state *st
> >
> > static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> > {
> > - /* TODO */
> > + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > + struct drm_crtc *crtc;
> > +
> > + for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > + if (!crtc->state->active)
> > + continue;
> > +
> > + mdp5_crtc_flush_all(crtc);
> > + }
> > }
> >
> > Any tips would be appreciated.
>
>
> I think this is along the lines of what we need to enable async commit
> for mdp5 (but also removing the flush from the atomic-commit path)..
> the principle behind the async commit is to do all the atomic state
> commit normally, but defer writing the flush bits. This way, if you
> get another async update before the next vblank, you just apply it
> immediately instead of waiting for vblank.
>
> But I guess you are on a command mode panel, if I remember? Which is
> a case I didn't have a way to test. And I'm not entirely about how
> kms_funcs->vsync_time() should be implemented for cmd mode panels.
Yes, this is a command-mode panel and there's no hardware frame counter
available. The key to getting the display working on this phone was this
patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> That all said, I think we should first fix what is broken, before
> worrying about extending async commit support to mdp5.. which
> shouldn't hit the async==true path, due to not implementing
> kms_funcs->vsync_time().
>
> What I think is going on is that, in the cmd mode case,
> mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> which waits for a pp-done irq regardless of whether there is a flush
> in progress. Since there is no flush pending, the irq never comes.
> But the expectation is that kms_funcs->wait_flush() returns
> immediately if there is nothing to wait for.
I don't think that's happening in this case. I added some pr_info()
statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
Here's the first two sets of messages that appear in dmesg:
[ 14.018907] msm fd90.mdss: pp done time out, lm=0
[ 14.018993] request_pp_done_pending: HERE
[ 14.074208] mdp5_crtc_pp_done_irq: HERE
[ 14.074368] Console: switching to colour frame buffer device 135x120
[ 14.138938] msm fd90.mdss: pp done time out, lm=0
[ 14.139021] request_pp_done_pending: HERE
[ 14.158097] mdp5_crtc_pp_done_irq: HERE
The messages go on like this with the same pattern.
I tried two different changes:
1) I moved the request_pp_done_pending() and corresponding if statement
from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
2) I increased the timeout in wait_for_completion_timeout() by several
increments; all the way to 5 seconds.
I haven't dug into the new code anymore.
Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/rockchip: dsi: add px30 support
Add the compatible and GRF definitions for the PX30 soc.
Signed-off-by: Heiko Stuebner
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 99ec625e0448..aeadeda0febc 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -140,6 +140,12 @@
#define DW_MIPI_NEEDS_PHY_CFG_CLK BIT(0)
#define DW_MIPI_NEEDS_GRF_CLK BIT(1)
+#define PX30_GRF_PD_VO_CON10x0438
+#define PX30_DSI_FORCETXSTOPMODE (0xf << 7)
+#define PX30_DSI_FORCERXMODE BIT(6)
+#define PX30_DSI_TURNDISABLE BIT(5)
+#define PX30_DSI_LCDC_SEL BIT(0)
+
#define RK3288_GRF_SOC_CON60x025c
#define RK3288_DSI0_LCDC_SEL BIT(6)
#define RK3288_DSI1_LCDC_SEL BIT(9)
@@ -1039,6 +1045,24 @@ static int dw_mipi_dsi_rockchip_remove(struct
platform_device *pdev)
return 0;
}
+static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
+ {
+ .reg = 0xff45,
+ .lcdsel_grf_reg = PX30_GRF_PD_VO_CON1,
+ .lcdsel_big = HIWORD_UPDATE(0, PX30_DSI_LCDC_SEL),
+ .lcdsel_lit = HIWORD_UPDATE(PX30_DSI_LCDC_SEL,
+ PX30_DSI_LCDC_SEL),
+
+ .lanecfg1_grf_reg = PX30_GRF_PD_VO_CON1,
+ .lanecfg1 = HIWORD_UPDATE(0, PX30_DSI_TURNDISABLE |
+PX30_DSI_FORCERXMODE |
+PX30_DSI_FORCETXSTOPMODE),
+
+ .max_data_lanes = 4,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
{
.reg = 0xff96,
@@ -1107,6 +1131,9 @@ static const struct rockchip_dw_dsi_chip_data
rk3399_chip_data[] = {
static const struct of_device_id dw_mipi_dsi_rockchip_dt_ids[] = {
{
+.compatible = "rockchip,px30-mipi-dsi",
+.data = _chip_data,
+ }, {
.compatible = "rockchip,rk3288-mipi-dsi",
.data = _chip_data,
}, {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND, v4, 2/7] dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks
From: AngeloGioacchino Del Regno These two clocks aren't present in all versions of the MDP5 HW: where present, they are needed to enable the Translation Buffer Unit(s). Signed-off-by: AngeloGioacchino Del Regno Acked-by: Rob Herring --- Documentation/devicetree/bindings/display/msm/mdp5.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt b/Documentation/devicetree/bindings/display/msm/mdp5.txt index 4e11338548aa..43d11279c925 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp5.txt +++ b/Documentation/devicetree/bindings/display/msm/mdp5.txt @@ -76,6 +76,8 @@ Required properties: Optional properties: - clock-names: the following clocks are optional: * "lut" + * "tbu" + * "tbu_rt" Example: -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in drm_mode_createblob_ioctl
On Wed, Nov 6, 2019 at 4:28 PM Daniel Vetter wrote:
>
> On Wed, Nov 6, 2019 at 4:23 PM Daniel Vetter wrote:
> >
> > On Wed, Nov 6, 2019 at 4:20 PM syzbot
> > wrote:
> > >
> > > syzbot has bisected this bug to:
> > >
> > > commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
> > > Author: Kees Cook
> > > Date: Mon Nov 4 22:57:23 2019 +
> > >
> > > uaccess: disallow > INT_MAX copy sizes
> >
> > Ah cool, this explains it.
> >
> > fwiw I never managed to get the WARNING in the backtrace to lign up
> > with any code. No idea what's been going on.
>
> Ok I think I have an idea, the above commit isn't in the linux-next I
> have here. Where is this from?
> -Daniel
You need to fetch tags to linux-next. syzbot started bisecting from
the commit where the crash happened, and it is now probably not the
current tag.
linux$ git show 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
commit 9e5a64c71b2f70ba530f8156046dd7dfb8a7a0ba
Author: Kees Cook
Date: Tue Nov 5 09:57:23 2019 +1100
uaccess: disallow > INT_MAX copy sizes
As we've done with VFS, string operations, etc, reject usercopy sizes
larger than INT_MAX, which would be nice to have for catching bugs related
to size calculation overflows[1].
This adds 10 bytes to x86_64 defconfig text and 1980 bytes to the data
section:
textdata bss dec hex filename
196911675134320 1646664 26472151193eed7 vmlinux.before
196911775136300 1646664 26474141193f69d vmlinux.after
[1] https://marc.info/?l=linux-s390=156631939010493=2
Link: http://lkml.kernel.org/r/201908251612.F9902D7A@keescook
Signed-off-by: Kees Cook
Suggested-by: Dan Carpenter
Cc: Alexander Viro
Signed-off-by: Andrew Morton
Signed-off-by: Stephen Rothwell
diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
index 659a4400517b2..e93e249a4e9bf 100644
--- a/include/linux/thread_info.h
+++ b/include/linux/thread_info.h
@@ -147,6 +147,8 @@ check_copy_size(const void *addr, size_t bytes,
bool is_source)
__bad_copy_to();
return false;
}
+ if (WARN_ON_ONCE(bytes > INT_MAX))
+ return false;
check_object_size(addr, bytes, is_source);
return true;
}
> > I'll type a patch to paper over this.
> > -Daniel
> >
> > >
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=125fe6dce0
> > > start commit: 51309b9d Add linux-next specific files for 20191105
> > > git tree: linux-next
> > > final crash:
> > > https://syzkaller.appspot.com/x/report.txt?x=115fe6dce0
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=165fe6dce0
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=a9b1a641c1f1fc52
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=fb77e97ebf0612ee6914
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1212dc3ae0
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=145f604ae0
> > >
> > > Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> > > Fixes: 9e5a64c71b2f ("uaccess: disallow > INT_MAX copy sizes")
> > >
> > > For information about bisection process see:
> > > https://goo.gl/tpsmEJ#bisection
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> 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
[PATCH] drm/amdgpu: fix double reference dropping
After dropping the reference of object fence in the loop, it should be set to NULL to protecting dropping its reference again outside the loop. Signed-off-by: Pan Bian --- drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c index 649e68c4479b..3174093f35f3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c @@ -47,6 +47,7 @@ static int amdgpu_benchmark_do_move(struct amdgpu_device *adev, unsigned size, if (r) goto exit_do_move; dma_fence_put(fence); + fence = NULL; } end_jiffies = jiffies; r = jiffies_to_msecs(end_jiffies - start_jiffies); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 00/12] i2c: replace i2c_new_probed_device with an ERR_PTR variant
On Wed, Nov 06, 2019 at 10:50:18AM +0100, Wolfram Sang wrote: > From: Wolfram Sang > > In the on-going mission to let i2c_new_* calls return an ERR_PTR instead > of NULL, here is a series converting i2c_new_probed_device(). A new > function called i2c_new_scanned_device() is introduced with the new > retval, but for now, a compatibility helper is provided until all users > are converted. The rest of the patches convert all current in-tree > users. > > Note that these patches are RFC because I want feedback on the approach > and hopefully collect acks on the driver conversions. If all goes well, > I'll apply the first two patches for the next merge window. Then, once > this dependency is upstream, I'll resend this series with all issues > fixed and acks collected. The patches to drivers/media/pci/* are all IR related which have touched on/read over the years. So, for those: Acked-by: Sean Young > > Core changes tested on a Renesas Salvator-XS board (R-Car M3-N), driver > patches build tested by me and buildbot. > > Wolfram Sang (12): > i2c: replace i2c_new_probed_device with an ERR_PTR variant > i2c: icy: convert to i2c_new_scanned_device > macintosh: convert to i2c_new_scanned_device > platform: chrome: convert to i2c_new_scanned_device > video: fbdev: matrox: convert to i2c_new_scanned_device > input: mouse: convert to i2c_new_scanned_device > media: pci: cx23885: convert to i2c_new_scanned_device > media: pci: cx88: convert to i2c_new_scanned_device > media: pci: bt8xx: convert to i2c_new_scanned_device > media: pci: cx18: convert to i2c_new_scanned_device > media: pci: ivtv: convert to i2c_new_scanned_device > media: v4l2-core: convert to i2c_new_scanned_device > > Documentation/i2c/instantiating-devices.rst | 10 - > Documentation/i2c/writing-clients.rst | 8 +++ > drivers/i2c/busses/i2c-icy.c| 8 +++ > drivers/i2c/i2c-core-base.c | 25 - > drivers/input/mouse/psmouse-smbus.c | 8 --- > drivers/macintosh/therm_windtunnel.c| 4 ++-- > drivers/media/pci/bt8xx/bttv-input.c| 6 ++--- > drivers/media/pci/cx18/cx18-i2c.c | 2 +- > drivers/media/pci/cx23885/cx23885-i2c.c | 4 ++-- > drivers/media/pci/cx88/cx88-input.c | 2 +- > drivers/media/pci/ivtv/ivtv-i2c.c | 6 ++--- > drivers/media/pci/ivtv/ivtv-i2c.h | 2 +- > drivers/media/v4l2-core/v4l2-i2c.c | 10 - > drivers/platform/chrome/chromeos_laptop.c | 18 --- > drivers/video/fbdev/matrox/i2c-matroxfb.c | 4 ++-- > include/linux/i2c.h | 12 +++--- > 16 files changed, 76 insertions(+), 53 deletions(-) > > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/ast: Enable atomic modesetting
Hi Am 07.11.19 um 07:55 schrieb Gerd Hoffmann: >>> Hmm. Pretty much a dummy encoder implementation. Maybe ast is simple >>> enough that the simple pipe helpers can do the trick? >> >> As Daniel said, simple pipe helpers don't support cursors. I >> investigated his comment on a encoder helpers and found that many >> drivers (including ast) only create an encoder structure without >> additional functionality. >> >> It's probably worth introducing a default implementation for the >> encoder, > > Either that, or make all the callbacks optional so a encoder without > additional functionality needs only a few lines of code. > >> but I'd like to do that in a separate patch set. Ok? > > Yep, that totally makes sense, given that it'll probably become a patch > series of its own (with driver cleanups included). Absolutely. I took a look at other driver's encoders and most of them are empty implementations; just like ast. Having a simple-encoder helper should make most of this go away. > > So, for this patch: > Acked-by: Gerd Hoffmann Thanks. Best regards Thomas > > cheers, > Gerd > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/ast: Enable atomic modesetting
> > Hmm. Pretty much a dummy encoder implementation. Maybe ast is simple > > enough that the simple pipe helpers can do the trick? > > As Daniel said, simple pipe helpers don't support cursors. I > investigated his comment on a encoder helpers and found that many > drivers (including ast) only create an encoder structure without > additional functionality. > > It's probably worth introducing a default implementation for the > encoder, Either that, or make all the callbacks optional so a encoder without additional functionality needs only a few lines of code. > but I'd like to do that in a separate patch set. Ok? Yep, that totally makes sense, given that it'll probably become a patch series of its own (with driver cleanups included). So, for this patch: Acked-by: Gerd Hoffmann cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #219 from Shmerl --- (In reply to L.S.S. from comment #218) > > I'm not an expert of apitrace, but the reporter provided a trace that would > 100% reproduce the lockup, and he was able to bisect the call that caused > the lockup which is the last call of that trace file. There could be multiple reasons for such hangs, so just please report one separately if you can reproduce others. -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #218 from L.S.S. --- It seems the page fault issue has been already reported here. I also found similar page faults in the log sometimes when the lockup occurred (I think it'll definitely show up if I leave the system as is for a prolonged amount of time). https://gitlab.freedesktop.org/mesa/mesa/issues/2053 I'm not an expert of apitrace, but the reporter provided a trace that would 100% reproduce the lockup, and he was able to bisect the call that caused the lockup which is the last call of that trace file. -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #217 from Shmerl --- (In reply to lptech1024 from comment #216) > >Hang occurred during a gaming cutscene. > >... > Nov 06 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring > gfx_0.0.0 timeout, signaled seq=2827901, emitted seq=2827903 > Nov 06 [SNIP] kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* > Waiting for fences timed out or interrupted! If you can reproduce it, please report this to radeonsi bug tracker (and attach an apitrace please). https://gitlab.freedesktop.org/mesa/mesa/issues Also, please add details on what game it is (and etc.) here: https://www.gamingonlinux.com/wiki/Mesa_Broken -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #216 from lptech1...@gmail.com --- GPU: PowerColor Red Devil Radeon RX 5700 XT using OC BIOS (default) Stock Fedora 31: Kernel 5.3.8, GNOME 3.34, Mesa 19.2.2, linux-firmware 20190923, LLVM 9.0.0 I experienced frequent hangs using X.org Gnome (Kernel 5.3.7, > Mesa 19.2.0), especially interacting with graphical file manager-related operations . Wayland Gnome is much more stable, although I experienced a hang today after being powered on for almost two hours (45 minutes idle, 75 minutes with high GPU load). Hang occurred during a gaming cutscene. All messages contained an identical timestamp: Nov 06 [SNIP] kernel: [drm] GPU recovery disabled. Nov 06 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process ShadowOfTheTomb pid 16893 thread WebViewRenderer pid 16939 Nov 06 [SNIP] kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=2827901, emitted seq=2827903 Nov 06 [SNIP] kernel: [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! -- 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 V8 0/6] mdev based hardware virtio offloading support
On 2019/11/7 上午5:13, Alex Williamson wrote:
On Wed, 6 Nov 2019 14:25:23 -0500
"Michael S. Tsirkin" wrote:
On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
On Wed, 6 Nov 2019 11:56:46 +0800
Jason Wang wrote:
On 2019/11/6 上午1:58, Alex Williamson wrote:
On Tue, 5 Nov 2019 17:32:34 +0800
Jason Wang wrote:
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.
Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.
A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.
Also a real ICF VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.
Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through introducing class id to the device and pairing it with
id_talbe claimed by the driver. On top, this seris also decouple
device specific parents ops out of the common ones.
Pktgen test was done with virito-net + mvnet loop back device.
Please review.
[1] https://lkml.org/lkml/2019/10/31/440
[2] https://lkml.org/lkml/2019/10/15/1226
Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes
Seems we're nearly there, all the remaining comments are relatively
superficial, though I would appreciate a v9 addressing them as well as
the checkpatch warnings:
https://patchwork.freedesktop.org/series/68977/
Will do.
Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
go through Michael's vhost tree?
I can include it if you wish. The mdev changes are isolated enough in
that patch that I wouldn't presume it, but clearly it would require
less merge coordination to drop it in my tree. Let me know. Thanks,
Alex
I'm fine with merging through your tree. If you do, feel free to
include
Acked-by: Michael S. Tsirkin
AFAICT, it looks like we're expecting at least one more version of
Tiwei's patch after V5, so it'd probably be best to provide the ack and
go-ahead on that next version so there's no confusion. Thanks,
Alex
Yes, it's probably need a V6. Will give ack there.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu, radeon drm-fixes-5.4
Hi Dave, Daniel, Fixes for 5.4. The following changes since commit a99d8080aaf358d5d23581244e5da23b35e340b9: Linux 5.4-rc6 (2019-11-03 14:07:26 -0800) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-fixes-5.4-2019-11-06 for you to fetch changes up to 2c409ba81be25516afe05ae27a4a15da01740b01: drm/radeon: fix si_enable_smc_cac() failed issue (2019-11-06 22:06:23 -0500) drm-fixes-5.4-2019-11-06: amdgpu: - Fix navi14 display issue root cause and revert workaround - GPU reset scheduler interaction fix - Fix fan boost on multi-GPU - Gfx10 and sdma5 fixes for navi - GFXOFF fix for renoir - Add navi14 PCI ID - GPUVM fix for arcturus radeon: - Port an SI power fix from amdgpu Alex Deucher (3): drm/amdgpu/arcturus: properly set BANK_SELECT and FRAGMENT_SIZE drm/amdgpu/renoir: move gfxoff handling into gfx9 module drm/radeon: fix si_enable_smc_cac() failed issue Evan Quan (1): drm/amdgpu: register gpu instance before fan boost feature enablment Kevin Wang (1): drm/amd/swSMU: fix smu workload bit map error Shirish S (1): drm/amdgpu: dont schedule jobs while in reset Tianci.Yin (1): drm/amdgpu: add navi14 PCI ID Zhan Liu (2): drm/amd/display: Add ENGINE_ID_DIGD condition check for Navi14 Revert "drm/amd/display: setting the DIG_MODE to the correct value." changzhu (2): drm/amdgpu: add dummy read by engines for some GCVM status registers in gfx10 drm/amdgpu: add warning for GRBM 1-cycle delay issue in gfx9 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 5 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 1 - drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 48 ++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 ++ drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c| 9 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 13 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 5 +++ drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +- drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +- drivers/gpu/drm/radeon/si_dpm.c| 1 + 16 files changed, 106 insertions(+), 24 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: rcar-du: Recognize "renesas,vsps" in addition to "vsps"
Hi Geert,
Thank you for the patch.
On Tue, Nov 05, 2019 at 07:35:03PM +0100, Geert Uytterhoeven wrote:
> The Renesas-specific "vsps" property lacks a vendor prefix.
> Add a "renesas," prefix to comply with DT best practises.
> Retain backward compatibility with old DTBs by falling back to "vsps"
> when needed.
>
> Fixes: 6d62ef3ac30be756 ("drm: rcar-du: Expose the VSP1 compositor through
> KMS planes")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
and taken in my tree (with a small change below).
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 186422ac552b2870..b14676f7a9f17501 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -544,6 +544,7 @@ static int rcar_du_properties_init(struct rcar_du_device
> *rcdu)
> static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
> {
> const struct device_node *np = rcdu->dev->of_node;
> + const char *vsps_prop_name = "renesas,vsps";
> struct of_phandle_args args;
> struct {
> struct device_node *np;
> @@ -559,15 +560,21 @@ static int rcar_du_vsps_init(struct rcar_du_device
> *rcdu)
>* entry contains a pointer to the VSP DT node and a bitmask of the
>* connected DU CRTCs.
>*/
> - cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
> + ret = of_property_count_u32_elems(np, vsps_prop_name);
> + if (ret < 0) {
> + /* Backward compatibility with old DTBs */
s/DTBs/DTBs./
> + vsps_prop_name = "vsps";
> + ret = of_property_count_u32_elems(np, vsps_prop_name);
> + }
> + cells = ret / rcdu->num_crtcs - 1;
> if (cells > 1)
> return -EINVAL;
>
> for (i = 0; i < rcdu->num_crtcs; ++i) {
> unsigned int j;
>
> - ret = of_parse_phandle_with_fixed_args(np, "vsps", cells, i,
> -);
> + ret = of_parse_phandle_with_fixed_args(np, vsps_prop_name,
> +cells, i, );
> if (ret < 0)
> goto error;
>
> @@ -589,8 +596,8 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
>
> /*
>* Store the VSP pointer and pipe index in the CRTC. If the
> - * second cell of the 'vsps' specifier isn't present, default
> - * to 0 to remain compatible with older DT bindings.
> + * second cell of the 'renesas,vsps' specifier isn't present,
> + * default to 0 to remain compatible with older DT bindings.
>*/
> rcdu->crtcs[i].vsp = >vsps[j];
> rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver.Specifically starting the GNOME desktop. This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. I don’t see any specific errors in the gdm logs or message file other than this: mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b00 -> 0x9bff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c81 -> 0x9c813fff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c00 -> 0x9c7f fb0: switching to mgag200drmfb from EFI VGA mgag200 :04:00.0: vgaarb: deactivate vga console fbcon: mgag200drmfb (fb0) is primary device mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: display: renesas: du: Add vendor prefix to vsps property
Hi Geert,
Thank you for the patch.
On Tue, Nov 05, 2019 at 07:35:02PM +0100, Geert Uytterhoeven wrote:
> The Renesas-specific "vsps" property lacks a vendor prefix.
> Add a "renesas," prefix to comply with DT best practises.
>
> Move "renesas,vsps" below "renesas,cmms" to preserve alphabetical sort
> order.
>
> Fixes: 06711e6385a4ab4c ("drm: rcar-du: Document the vsps property in the DT
> bindings")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
and taken in my tree.
> ---
> .../devicetree/bindings/display/renesas,du.txt | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> b/Documentation/devicetree/bindings/display/renesas,du.txt
> index f6fdaa67c257a046..eb4ae41fe41f83c7 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -41,15 +41,15 @@ Required Properties:
>supplied they must be named "dclkin.x" with "x" being the input clock
>numerical index.
>
> - - vsps: A list of phandle and channel index tuples to the VSPs that handle
> -the memory interfaces for the DU channels. The phandle identifies the VSP
> -instance that serves the DU channel, and the channel index identifies the
> -LIF instance in that VSP.
> -
>- renesas,cmms: A list of phandles to the CMM instances present in the SoC,
> one for each available DU channel. The property shall not be specified
> for
> SoCs that do not provide any CMM (such as V3M and V3H).
>
> + - renesas,vsps: A list of phandle and channel index tuples to the VSPs that
> +handle the memory interfaces for the DU channels. The phandle identifies
> the
> +VSP instance that serves the DU channel, and the channel index identifies
> +the LIF instance in that VSP.
> +
> Required nodes:
>
> The connections to the DU output video ports are modeled using the OF graph
> @@ -96,8 +96,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
>< CPG_MOD 722>,
>< CPG_MOD 721>;
> clock-names = "du.0", "du.1", "du.2", "du.3";
> - vsps = < 0>, < 0>, < 0>, < 1>;
> renesas,cmms = <>, <>, <>, <>;
> + renesas,vsps = < 0>, < 0>, < 0>, < 1>;
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] arm64: dts: renesas: rcar-gen3: Replace "vsps" by "renesas,vsps"
Hi Geert,
Thank you for the patch.
On Tue, Nov 05, 2019 at 07:35:04PM +0100, Geert Uytterhoeven wrote:
> The Renesas-specific "vsps" property lacks a vendor prefix.
> Add a "renesas," prefix to comply with DT best practises.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> This depends on '[PATCH 2/3] drm: rcar-du: Recognize "renesas,vsps" in
> addition to "vsps"'.
Reviewed-by: Laurent Pinchart
(once 2/3 will be upstream)
> ---
> arch/arm64/boot/dts/renesas/r8a774a1.dtsi| 2 +-
> arch/arm64/boot/dts/renesas/r8a774b1.dtsi| 2 +-
> arch/arm64/boot/dts/renesas/r8a774c0.dtsi| 3 ++-
> arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
> arch/arm64/boot/dts/renesas/r8a77965.dtsi| 2 +-
> arch/arm64/boot/dts/renesas/r8a77970.dtsi| 3 ++-
> arch/arm64/boot/dts/renesas/r8a77980.dtsi| 3 ++-
> arch/arm64/boot/dts/renesas/r8a77990.dtsi| 2 +-
> arch/arm64/boot/dts/renesas/r8a77995.dtsi| 2 +-
> 11 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> index 34a9f472fbb43072..0a48b53c3f9dcd69 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> @@ -2640,7 +2640,7 @@
> clock-names = "du.0", "du.1", "du.2";
> status = "disabled";
>
> - vsps = < 0>, < 0>, < 0>;
> + renesas,vsps = < 0>, < 0>, < 0>;
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
> index fe78387e4bb866ec..2ef0e136c84dcd25 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
> @@ -2486,7 +2486,7 @@
> clock-names = "du.0", "du.1", "du.3";
> status = "disabled";
>
> - vsps = < 0>, < 0>, < 1>;
> + renesas,vsps = < 0>, < 0>, < 1>;
>
> ports {
> #address-cells = <1>;
> diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> index c7bdc3606323fc97..40aceb6681474f0d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
> @@ -1813,7 +1813,8 @@
> clocks = < CPG_MOD 724>,
>< CPG_MOD 723>;
> clock-names = "du.0", "du.1";
> - vsps = < 0>, < 0>;
> + renesas,vsps = < 0>, < 0>;
> +
> status = "disabled";
>
> ports {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> index 14d8513d2a47336f..29b20e8aca5863e4 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
> @@ -30,7 +30,7 @@
> };
>
> {
> - vsps = < 0>, < 0>, < 0>, < 0>;
> + renesas,vsps = < 0>, < 0>, < 0>, < 0>;
> };
>
> {
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index fde6ec122d3b4006..c7b4ece0ab3ee03f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -3184,7 +3184,8 @@
> clock-names = "du.0", "du.1", "du.2", "du.3";
>
> renesas,cmms = <>, <>, <>, <>;
> - vsps = < 0>, < 0>, < 0>, < 1>;
> + renesas,vsps = < 0>, < 0>, < 0>,
> +< 1>;
>
> status = "disabled";
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index b9db882b0351155c..95fa1608add896bf 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -2824,7 +2824,7 @@
> clock-names = "du.0", "du.1", "du.2";
>
> renesas,cmms = <>, <>, <>;
> - vsps = < 0>, < 0>, < 0>;
> + renesas,vsps = < 0>, < 0>, < 0>;
>
> status = "disabled";
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> index bdbe197774d2f659..fb48dabb25adaf77 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -2500,7 +2500,7 @@
> clock-names = "du.0", "du.1", "du.3";
>
> renesas,cmms = <>, <>, <>;
> - vsps = < 0>, < 0>, < 1>;
> + renesas,vsps = < 0>, < 0>, < 1>;
>
> status =
Re: [PATCH v2 07/18] infiniband: set FOLL_PIN, FOLL_LONGTERM via pin_longterm_pages*()
On Mon, Nov 04, 2019 at 04:57:38PM -0400, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 12:48:13PM -0800, John Hubbard wrote:
> > On 11/4/19 12:33 PM, Jason Gunthorpe wrote:
> > ...
> > >> diff --git a/drivers/infiniband/core/umem.c
> > >> b/drivers/infiniband/core/umem.c
> > >> index 24244a2f68cc..c5a78d3e674b 100644
> > >> +++ b/drivers/infiniband/core/umem.c
> > >> @@ -272,11 +272,10 @@ struct ib_umem *ib_umem_get(struct ib_udata
> > >> *udata, unsigned long addr,
> > >>
> > >> while (npages) {
> > >> down_read(>mmap_sem);
> > >> -ret = get_user_pages(cur_base,
> > >> +ret = pin_longterm_pages(cur_base,
> > >> min_t(unsigned long, npages,
> > >> PAGE_SIZE / sizeof (struct
> > >> page *)),
> > >> - gup_flags | FOLL_LONGTERM,
> > >> - page_list, NULL);
> > >> + gup_flags, page_list, NULL);
> > >
> > > FWIW, this one should be converted to fast as well, I think we finally
> > > got rid of all the blockers for that?
> > >
> >
> > I'm not aware of any blockers on the gup.c end, anyway. The only broken
> > thing we
> > have there is "gup remote + FOLL_LONGTERM". But we can do "gup fast +
> > LONGTERM".
>
> I mean the use of the mmap_sem here is finally in a way where we can
> just delete the mmap_sem and use _fast
Yay! I agree if we can do this we should.
Thanks,
Ira
>
> ie, AFAIK there is no need for the mmap_sem to be held during
> ib_umem_add_sg_table()
>
> This should probably be a standalone patch however
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN
>
>
> ...
> >> +This document describes the following functions: ::
> >> +
> >> + pin_user_pages
> >> + pin_user_pages_fast
> >> + pin_user_pages_remote
> >> +
> >> + pin_longterm_pages
> >> + pin_longterm_pages_fast
> >> + pin_longterm_pages_remote
> >> +
> >> +Basic description of FOLL_PIN
> >> +=
> >> +
> >> +A new flag for get_user_pages ("gup") has been added: FOLL_PIN. FOLL_PIN
> >> has
> >
> > Consider reading this after, say, half a year ;-)
> >
>
> OK, OK. I knew when I wrote that that it was not going to stay new forever,
> but
> somehow failed to write the right thing anyway. :)
>
> Here's a revised set of paragraphs:
>
> Basic description of FOLL_PIN
> =
>
> FOLL_PIN and FOLL_LONGTERM are flags that can be passed to the
> get_user_pages*()
> ("gup") family of functions. FOLL_PIN has significant interactions and
> interdependencies with FOLL_LONGTERM, so both are covered here.
>
> Both FOLL_PIN and FOLL_LONGTERM are internal to gup, meaning that neither
> FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This
> allows
> the associated wrapper functions (pin_user_pages() and others) to set the
> correct combination of these flags, and to check for problems as well.
I like this revision as well.
Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mediatek drm next for 5.5 - 2
Hi Dave, Daniel: This round add new color format support and reflect function. Regards, CK The following changes since commit 631005b255aab5f846f7ca03606613f898d70207: drm/mediatek: add no_clk into ddp private data (2019-10-09 16:58:13 +0800) are available in the Git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git tags/mediatek-drm-next-5.5-2 for you to fetch changes up to df57711858d398896d678bd3cd7f43f1c1f5: drm/mediatek: Support 180 degree rotation (2019-11-06 16:00:45 +0800) Mediatek DRM next for Linux 5.5 - 2 Sean Paul (8): drm/mediatek: Add RGB[A] variants to published plane formats drm/mediatek: Refactor plane init drm/mediatek: Add helper to get component for a plane drm/mediatek: Add plumbing for layer_check hook drm/mediatek: Plumb supported rotation values from components to plane init drm/mediatek: Support reflect-y plane rotation drm/mediatek: Support reflect-x plane rotation drm/mediatek: Support 180 degree rotation drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 50 ++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 145 drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 22 + drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 - drivers/gpu/drm/mediatek/mtk_drm_plane.h| 4 +- 6 files changed, 205 insertions(+), 42 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
[...]
> > /**
> > * enum mmu_notifier_event - reason for the mmu notifier callback
> > @@ -32,6 +34,9 @@ struct mmu_notifier_range;
> > * access flags). User should soft dirty the page in the end callback to
> > make
> > * sure that anyone relying on soft dirtyness catch pages that might be
> > written
> > * through non CPU mappings.
> > + *
> > + * @MMU_NOTIFY_RELEASE: used during mmu_range_notifier invalidate to
> > signal that
> > + * the mm refcount is zero and the range is no longer accessible.
> > */
> > enum mmu_notifier_event {
> > MMU_NOTIFY_UNMAP = 0,
> > @@ -39,6 +44,7 @@ enum mmu_notifier_event {
> > MMU_NOTIFY_PROTECTION_VMA,
> > MMU_NOTIFY_PROTECTION_PAGE,
> > MMU_NOTIFY_SOFT_DIRTY,
> > + MMU_NOTIFY_RELEASE,
> > };
>
>
> OK, let the naming debates begin! ha. Anyway, after careful study of the
> overall
> patch, and some browsing of the larger patchset, it's clear that:
>
> * The new "MMU range notifier" that you've created is, approximately, a new
> object. It uses classic mmu notifiers inside, as an implementation detail, and
> it does *similar* things (notifications) as mmn's. But it's certainly not the
> same
> as mmn's, as shown later when you say the need to an entirely new ops struct,
> and
> data struct too.
>
> Therefore, you need a separate events enum as well. This is important. MMN's
> won't be issuing MMN_NOTIFY_RELEASE events, nor will MNR's be issuing the
> first
> four prexisting MMU_NOTIFY_* items. So it would be a design mistake to glom
> them
> together, unless you ultimately decided to merge these MMN and MNR objects
> (which
> I don't really see any intention of, and that's fine).
>
> So this should read:
>
> enum mmu_range_notifier_event {
> MMU_NOTIFY_RELEASE,
> };
>
> ...assuming that we stay with "mmu_range_notifier" as a core name for this
> whole thing.
>
> Also, it is best moved down to be next to the new MNR structs, so that all the
> MNR stuff is in one group.
>
> Extra credit: IMHO, this clearly deserves to all be in a new
> mmu_range_notifier.h
> header file, but I know that's extra work. Maybe later as a follow-up patch,
> if anyone has the time.
The range notifier should get the event too, it would be a waste, i think it is
an oversight here. The release event is fine so NAK to you separate event. Event
is really an helper for notifier i had a set of patch for nouveau to leverage
this i need to resucite them. So no need to split thing, i would just forward
the event ie add event to mmu_range_notifier_ops.invalidate() i failed to catch
that in v1 sorry.
[...]
> > +struct mmu_range_notifier_ops {
> > + bool (*invalidate)(struct mmu_range_notifier *mrn,
> > + const struct mmu_notifier_range *range,
> > + unsigned long cur_seq);
> > +};
> > +
> > +struct mmu_range_notifier {
> > + struct interval_tree_node interval_tree;
> > + const struct mmu_range_notifier_ops *ops;
> > + struct hlist_node deferred_item;
> > + unsigned long invalidate_seq;
> > + struct mm_struct *mm;
> > +};
> > +
>
> Again, now we have the new struct mmu_range_notifier, and the old
> struct mmu_notifier_range, and it's not good.
>
> Ideas:
>
> a) Live with it.
>
> b) (Discarded, too many callers): rename old one. Nope.
>
> c) Rename new one. Ideas:
>
> struct mmu_interval_notifier
> struct mmu_range_intersection
> ...other ideas?
I vote for interval_notifier we do want notifier in name but i am also
fine with current name.
[...]
> > + *
> > + * Note that the core mm creates nested invalidate_range_start()/end()
> > regions
> > + * within the same thread, and runs invalidate_range_start()/end() in
> > parallel
> > + * on multiple CPUs. This is designed to not reduce concurrency or block
> > + * progress on the mm side.
> > + *
> > + * As a secondary function, holding the full write side also serves to
> > prevent
> > + * writers for the itree, this is an optimization to avoid extra locking
> > + * during invalidate_range_start/end notifiers.
> > + *
> > + * The write side has two states, fully excluded:
> > + * - mm->active_invalidate_ranges != 0
> > + * - mnn->invalidate_seq & 1 == True
> > + * - some range on the mm_struct is being invalidated
> > + * - the itree is not allowed to change
> > + *
> > + * And partially excluded:
> > + * - mm->active_invalidate_ranges != 0
>
> I assume this implies mnn->invalidate_seq & 1 == False in this case? If so,
> let's say so. I'm probably getting that wrong, too.
Yes (mnn->invalidate_seq & 1) == 0
>
> > + * - some range on the mm_struct is being invalidated
> > + * - the itree is allowed to change
> > + *
> > + * The later state avoids some expensive work on inv_end in the common
> > case of
> > + * no mrn monitoring the VA.
> > + */
> > +static bool mn_itree_is_invalidating(struct
Re: [PATCH v2 7/7] drm/mediatek: Support 180 degree rotation
Hi, Sean:
On Wed, 2019-11-06 at 09:42 -0500, Sean Paul wrote:
> On Wed, Nov 6, 2019 at 4:07 AM CK Hu wrote:
> >
> > Hi, Sean:
> >
> > On Tue, 2019-11-05 at 16:10 -0500, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > Now that we support both reflections, we can expose 180 degree rotation
> > > and rely on the simplify routine to convert that into REFLECT_X |
> > > REFLECT_Y
> > >
> >
> > Patch 1 ~ 6 of this series looks good to me.
> > For this one, I think the rotation check in mtk_ovl_layer_check() should
> > be modified.
> >
>
> Thanks for the quick reviews, CK!
>
> In what way would you like the check to be modified? I'm guessing
> you're asking that I add it to the bitmask passed to the
> simplify_rotation function?
>
> If that's the case, we don't actually want to modify the
> simplify_rotation bitmask since that bitmask is supposed to be only
> the rotations that the hardware can achieve. So if you pass ROTATE_180
> into simplify_rotation, it will return REFLECT_X | REFLECT_Y, which is
> what we want. Does that make sense, or am I missing something?
drm_rotation_simplify() is really hard to understand. You're right, so
apply this series to mediatek-drm-next-5.5-2 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5-2
Regards,
CK
>
> Thanks,
>
> Sean
>
> > Regards,
> > CK
> >
> > > Signed-off-by: Sean Paul
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > index f4c4d3fedc5f..4a55bb6e2213 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > @@ -143,8 +143,8 @@ static unsigned int mtk_ovl_layer_nr(struct
> > > mtk_ddp_comp *comp)
> > >
> > > static unsigned int mtk_ovl_supported_rotations(struct mtk_ddp_comp
> > > *comp)
> > > {
> > > - return DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y |
> > > -DRM_MODE_REFLECT_X;
> > > + return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
> > > +DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
> > > }
> > >
> > > static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp, unsigned int
> > > idx,
> >
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: display: renesas: du: Add vendor prefix to vsps property
On Tue, 5 Nov 2019 19:35:02 +0100, Geert Uytterhoeven wrote:
> The Renesas-specific "vsps" property lacks a vendor prefix.
> Add a "renesas," prefix to comply with DT best practises.
>
> Move "renesas,vsps" below "renesas,cmms" to preserve alphabetical sort
> order.
>
> Fixes: 06711e6385a4ab4c ("drm: rcar-du: Document the vsps property in the DT
> bindings")
> Signed-off-by: Geert Uytterhoeven
> ---
> .../devicetree/bindings/display/renesas,du.txt | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #215 from Shmerl --- (In reply to Pierre-Eric Pelloux-Prayer from comment #141) > If anyone has a reliable way to trigger the issue, the most helpful thing to > do for now is an apitrace capture. Does the trace in comment #199 help to narrow it down? https://bugs.freedesktop.org/show_bug.cgi?id=111481#c199 -- 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 02/15] mm/mmu_notifier: add an interval tree notifier
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
...
> include/linux/mmu_notifier.h | 98 +++
> mm/Kconfig | 1 +
> mm/mmu_notifier.c| 533 +--
> 3 files changed, 607 insertions(+), 25 deletions(-)
>
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 12bd603d318ce7..51b92ba013ddce 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -6,10 +6,12 @@
> #include
> #include
> #include
> +#include
>
> struct mmu_notifier_mm;
> struct mmu_notifier;
> struct mmu_notifier_range;
> +struct mmu_range_notifier;
Hi Jason,
Nice design, I love the seq foundation! So far, I'm not able to spot anything
actually wrong with the implementation, sorry about that.
Generally my reaction is: given that the design is complex, try to mitigate
that with documentation and naming. So the comments are in these areas:
1. There is a rather severe naming overlap (not technically a naming conflict,
but still) with existing mmn work, which already has, for example:
struct mmu_notifier_range
...and you're adding:
struct mmu_range_notifier
...so I'll try to help sort that out.
2. I'm also seeing a couple of things that are really hard for the reader
verify are correct (abuse and battery of the low bit in .invalidate_seq,
for example, haha), so I have some recommendations there.
3. Documentation improvements, which easy to apply, with perhaps one exception.
(Here, because this a complicated area, documentation does make a difference,
so it's worth a little extra fuss.)
4. Other nits that don't matter too much, but just help polish things up
as usual.
>
> /**
> * enum mmu_notifier_event - reason for the mmu notifier callback
> @@ -32,6 +34,9 @@ struct mmu_notifier_range;
> * access flags). User should soft dirty the page in the end callback to make
> * sure that anyone relying on soft dirtyness catch pages that might be
> written
> * through non CPU mappings.
> + *
> + * @MMU_NOTIFY_RELEASE: used during mmu_range_notifier invalidate to signal
> that
> + * the mm refcount is zero and the range is no longer accessible.
> */
> enum mmu_notifier_event {
> MMU_NOTIFY_UNMAP = 0,
> @@ -39,6 +44,7 @@ enum mmu_notifier_event {
> MMU_NOTIFY_PROTECTION_VMA,
> MMU_NOTIFY_PROTECTION_PAGE,
> MMU_NOTIFY_SOFT_DIRTY,
> + MMU_NOTIFY_RELEASE,
> };
OK, let the naming debates begin! ha. Anyway, after careful study of the overall
patch, and some browsing of the larger patchset, it's clear that:
* The new "MMU range notifier" that you've created is, approximately, a new
object. It uses classic mmu notifiers inside, as an implementation detail, and
it does *similar* things (notifications) as mmn's. But it's certainly not the
same
as mmn's, as shown later when you say the need to an entirely new ops struct,
and
data struct too.
Therefore, you need a separate events enum as well. This is important. MMN's
won't be issuing MMN_NOTIFY_RELEASE events, nor will MNR's be issuing the first
four prexisting MMU_NOTIFY_* items. So it would be a design mistake to glom them
together, unless you ultimately decided to merge these MMN and MNR objects
(which
I don't really see any intention of, and that's fine).
So this should read:
enum mmu_range_notifier_event {
MMU_NOTIFY_RELEASE,
};
...assuming that we stay with "mmu_range_notifier" as a core name for this
whole thing.
Also, it is best moved down to be next to the new MNR structs, so that all the
MNR stuff is in one group.
Extra credit: IMHO, this clearly deserves to all be in a new
mmu_range_notifier.h
header file, but I know that's extra work. Maybe later as a follow-up patch,
if anyone has the time.
>
> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
> @@ -222,6 +228,26 @@ struct mmu_notifier {
> unsigned int users;
> };
>
That should also be moved down, next to the new structs.
A little bit above these next items, just above "struct mmu_notifier" (not
shown here,
it's outside the diff area), there is some documentation about classic MMNs. It
would
be nice if it were clearer that that documentation is not relevant to MNRs.
Actually,
this is another reason that a separate header file would be nice.
> +/**
> + * struct mmu_range_notifier_ops
> + * @invalidate: Upon return the caller must stop using any SPTEs within this
> + * range, this function can sleep. Return false if blocking was
> + * required but range is non-blocking
> + */
How about this (I'm not sure I fully understand the return value, though):
/**
* struct mmu_range_notifier_ops
* @invalidate: Upon return the caller must stop using any SPTEs within this
* range.
*
* This function is permitted to sleep.
*
* @Return: false if blocking was required, but @range is
* non-blocking.
*
*/
> +struct mmu_range_notifier_ops {
>
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Wed, Nov 06, 2019 at 12:50:21PM +1000, Dave Airlie wrote: > On Tue, 5 Nov 2019 at 07:00, Manasi Navare wrote: > > > > On Mon, Nov 04, 2019 at 07:48:26PM +1000, David Airlie wrote: > > > On Mon, Nov 4, 2019 at 7:18 PM Daniel Vetter wrote: > > > > > > > > On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote: > > > > > In case of tiled displays, if we hotplug just one connector, > > > > > fbcon currently just selects the preferred mode and if it is > > > > > tiled mode then that becomes a problem if rest of the tiles are > > > > > not present. > > > > > So in the fbdev driver on hotplug when we probe the client modeset, > > > > > we we dont find all the connectors for all tiles, then on a connector > > > > > with one tile, just fallback to the first available non tiled mode > > > > > to display over a single connector. > > > > > > > > > > Suggested-by: Ville Syrjälä > > > > > Suggested-by: Dave Airlie > > > > > Cc: Ville Syrjälä > > > > > Cc: Dave Airlie > > > > > Signed-off-by: Manasi Navare > > > > > > > > Hm, should we mayb have a slight timeout first to wait for the 2nd > > > > connector? Otherwise lots of flickering going on when plugging in one of > > > > these screens ... > > > > > > Not really, > > > > > > There are 3 scenarios with the multi-cable tiled monitors. and > > > non-resizeable fbdev. > > > > > > a) it's plugged in at boot. both cables are detected, fbdev gets a > > > full tiled mode. > > > > Yes this works as expected > > > > > b) it's not plugged in at boot, the user starts plugging it in, fbdev > > > was inited via the panel or another monitor. fbdev won't resize. > > > c) it's half plugged in at boot, then you get a non-tiled mode, and > > > fbdev can't resize to tiled anyways. > > > > In b and c, when its booted with only 1 cable connected and/or hotplugged > > only > > one cable after boot, I fallback to fisrt available non tiled mode, does > > that sound good? > > > > > > > > Also plugging in one of these multi-cable monitors piecemeal is going > > > to take multiple seconds for the user to do physical cable plugging. > > > > So still good with ignoring the second hotplug completely? > > However i donno where in the fb helper to stop passing the modeset down > > after the drm_fb_helper_hotplug_event() > > I don't think you can ignore it completely. I think you just have to > make the mode picking logic pick the right answer somehow. > > So you can tell if width/height are going to be lower than the tiled > mode size, and in that case just don't enable the secondary tile. > Ithink this tiled monitor is behaving in a way where if there are two ports connected, on the reciever end it tries to join the outputs and if there is no output or a different output other than tiled mode then it cant display anything so the moment i connect the second port, it expects the full tiled output but since no modes on second connector, it doesnt display anytjing goes into power save It almost makes me rethink our logic of falling back to the non tiled mode for the first hotplug since atleast this monitor displays the single tile across the whole monitor by stretching it out and then after connecting second connector it can ideally go back to a full tiled display Thoughts? Manasi > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dpu: Add UBWC support for RGB8888 formats
Hardware only natively supports BGR UBWC.
UBWC support for RGB can be had by pretending
that the buffer is BGR.
Signed-off-by: Fritz Koenig
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c| 18 ++
.../drm/msm/disp/dpu1/dpu_hw_catalog_format.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 24ab6249083a..528632690f1e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -489,12 +489,28 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
true, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ /* ARGB and ABGR purposely have the same color
+* ordering. The hardware only supports ABGR UBWC
+* natively.
+*/
+ INTERLEAVED_RGB_FMT_TILED(ARGB,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ true, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(XBGR,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
false, 4, DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+ INTERLEAVED_RGB_FMT_TILED(XRGB,
+ COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+ false, 4, DPU_FORMAT_FLAG_COMPRESSED,
+ DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
INTERLEAVED_RGB_FMT_TILED(ABGR2101010,
COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
@@ -550,7 +566,9 @@ static int _dpu_format_get_media_color_ubwc(const struct
dpu_format *fmt)
{
static const struct dpu_media_color_map dpu_media_ubwc_map[] = {
{DRM_FORMAT_ABGR, COLOR_FMT_RGBA_UBWC},
+ {DRM_FORMAT_ARGB, COLOR_FMT_RGBA_UBWC},
{DRM_FORMAT_XBGR, COLOR_FMT_RGBA_UBWC},
+ {DRM_FORMAT_XRGB, COLOR_FMT_RGBA_UBWC},
{DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
index bb6112c949ae..fbcb3c4bbfee 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h
@@ -6,7 +6,9 @@
static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_ABGR,
+ DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
+ DRM_FORMAT_XRGB,
DRM_FORMAT_BGR565,
};
--
2.24.0.432.g9d3f5f5b63-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V9 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On Wed, 6 Nov 2019 14:50:30 -0800 Randy Dunlap wrote: > On 11/5/19 11:05 PM, Jason Wang wrote: > > diff --git a/samples/Kconfig b/samples/Kconfig > > index c8dacb4dda80..13a2443e18e0 100644 > > --- a/samples/Kconfig > > +++ b/samples/Kconfig > > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY > > mediated device. It is a simple framebuffer and supports > > the region display interface (VFIO_GFX_PLANE_TYPE_REGION). > > > > +config SAMPLE_VIRTIO_MDEV_NET > > + tristate "Build VIRTIO net example mediated device sample code -- > > loadable modules only" > > + depends on VIRTIO_MDEV && VHOST_RING && m > > + help > > + Build a networking sample device for use as a virtio > > + mediated device. The device coopreates with virtio-mdev bus > > typo here: > cooperates > I can fix this on commit relative to V10 if there are no other issues raised: diff --git a/samples/Kconfig b/samples/Kconfig index 13a2443e18e0..b7116d97cbbe 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -136,7 +136,7 @@ config SAMPLE_VIRTIO_MDEV_NET depends on VIRTIO_MDEV && VHOST_RING && m help Build a networking sample device for use as a virtio - mediated device. The device coopreates with virtio-mdev bus + mediated device. The device cooperates with virtio-mdev bus driver to present an virtio ethernet driver for kernel. It simply loopbacks all packets from its TX virtqueue to its RX virtqueue. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2019-11-06: - Fix HPD poll to avoid kworker consuming a lot of cpu cycles. - Do not use TBT type for non Type-C ports. Thanks, Rodrigo. The following changes since commit a99d8080aaf358d5d23581244e5da23b35e340b9: Linux 5.4-rc6 (2019-11-03 14:07:26 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-11-06 for you to fetch changes up to ee2c5ef8a9d640ee1617ec97b84fe2f634284e51: drm/i915/dp: Do not switch aux to TBT mode for non-TC ports (2019-11-04 13:24:14 -0800) - Fix HPD poll to avoid kworker consuming a lot of cpu cycles. - Do not use TBT type for non Type-C ports. Imre Deak (1): drm/i915: Avoid HPD poll detect triggering a new detect cycle José Roberto de Souza (1): drm/i915/dp: Do not switch aux to TBT mode for non-TC ports drivers/gpu/drm/i915/display/intel_crt.c | 7 +++ drivers/gpu/drm/i915/display/intel_dp.c | 12 +++- drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++ 3 files changed, 24 insertions(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 0/6] mdev based hardware virtio offloading support
On Wed, 6 Nov 2019 14:25:23 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
> > On Wed, 6 Nov 2019 11:56:46 +0800
> > Jason Wang wrote:
> >
> > > On 2019/11/6 上午1:58, Alex Williamson wrote:
> > > > On Tue, 5 Nov 2019 17:32:34 +0800
> > > > Jason Wang wrote:
> > > >
> > > >> Hi all:
> > > >>
> > > >> There are hardwares that can do virtio datapath offloading while
> > > >> having its own control path. This path tries to implement a mdev based
> > > >> unified API to support using kernel virtio driver to drive those
> > > >> devices. This is done by introducing a new mdev transport for virtio
> > > >> (virtio_mdev) and register itself as a new kind of mdev driver. Then
> > > >> it provides a unified way for kernel virtio driver to talk with mdev
> > > >> device implementation.
> > > >>
> > > >> Though the series only contains kernel driver support, the goal is to
> > > >> make the transport generic enough to support userspace drivers. This
> > > >> means vhost-mdev[1] could be built on top as well by resuing the
> > > >> transport.
> > > >>
> > > >> A sample driver is also implemented which simulate a virito-net
> > > >> loopback ethernet device on top of vringh + workqueue. This could be
> > > >> used as a reference implementation for real hardware driver.
> > > >>
> > > >> Also a real ICF VF driver was also posted here[2] which is a good
> > > >> reference for vendors who is interested in their own virtio datapath
> > > >> offloading product.
> > > >>
> > > >> Consider mdev framework only support VFIO device and driver right now,
> > > >> this series also extend it to support other types. This is done
> > > >> through introducing class id to the device and pairing it with
> > > >> id_talbe claimed by the driver. On top, this seris also decouple
> > > >> device specific parents ops out of the common ones.
> > > >>
> > > >> Pktgen test was done with virito-net + mvnet loop back device.
> > > >>
> > > >> Please review.
> > > >>
> > > >> [1] https://lkml.org/lkml/2019/10/31/440
> > > >> [2] https://lkml.org/lkml/2019/10/15/1226
> > > >>
> > > >> Changes from V7:
> > > >> - drop {set|get}_mdev_features for virtio
> > > >> - typo and comment style fixes
> > > >
> > > > Seems we're nearly there, all the remaining comments are relatively
> > > > superficial, though I would appreciate a v9 addressing them as well as
> > > > the checkpatch warnings:
> > > >
> > > > https://patchwork.freedesktop.org/series/68977/
> > >
> > >
> > > Will do.
> > >
> > > Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
> > > go through Michael's vhost tree?
> >
> > I can include it if you wish. The mdev changes are isolated enough in
> > that patch that I wouldn't presume it, but clearly it would require
> > less merge coordination to drop it in my tree. Let me know. Thanks,
> >
> > Alex
>
> I'm fine with merging through your tree. If you do, feel free to
> include
>
> Acked-by: Michael S. Tsirkin
AFAICT, it looks like we're expecting at least one more version of
Tiwei's patch after V5, so it'd probably be best to provide the ack and
go-ahead on that next version so there's no confusion. Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Wed, Nov 06, 2019 at 12:47:16PM +1000, Dave Airlie wrote:
> On Fri, 1 Nov 2019 at 07:46, Manasi Navare wrote:
> >
> > In case of tiled displays, if we hotplug just one connector,
> > fbcon currently just selects the preferred mode and if it is
> > tiled mode then that becomes a problem if rest of the tiles are
> > not present.
> > So in the fbdev driver on hotplug when we probe the client modeset,
> > we we dont find all the connectors for all tiles, then on a connector
> > with one tile, just fallback to the first available non tiled mode
> > to display over a single connector.
> >
> > Suggested-by: Ville Syrjälä
> > Suggested-by: Dave Airlie
> > Cc: Ville Syrjälä
> > Cc: Dave Airlie
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_client_modeset.c | 29
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > b/drivers/gpu/drm/drm_client_modeset.c
> > index 895b73f23079..e28a723587db 100644
> > --- a/drivers/gpu/drm/drm_client_modeset.c
> > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > @@ -114,6 +114,20 @@ drm_client_find_modeset(struct drm_client_dev *client,
> > struct drm_crtc *crtc)
> > return NULL;
> > }
> >
> > +static struct drm_display_mode *
> > +drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
> > +{
> > + struct drm_display_mode *mode;
> > +
> > + list_for_each_entry(mode, >modes, head) {
> > + if (mode->hdisplay == connector->tile_h_size &&
> > + mode->vdisplay == connector->tile_v_size)
> > + continue;
> > + return mode;
> > + }
> > + return NULL;
> > +}
> > +
> > static struct drm_display_mode *
> > drm_connector_has_preferred_mode(struct drm_connector *connector, int
> > width, int height)
> > {
> > @@ -348,8 +362,17 @@ static bool drm_client_target_preferred(struct
> > drm_connector **connectors,
> > struct drm_connector *connector;
> > u64 conn_configured = 0;
> > int tile_pass = 0;
> > + int num_tiled_conns = 0;
> > int i;
> >
> > + for (i = 0; i < connector_count; i++) {
> > + connector = connectors[i];
> > + if (!connector->has_tile)
> > + continue;
> > +
> > + num_tiled_conns ++;
>
> Drop the space before the ++ here. Maybe just make this
>
> if (connectors[i]->has_tile)
> num_tiled_conns++;
Sure will modify like above and add your r-b afterwards.
Thank you so much for your review.
This only covers the hotplug case with 1 connector hotplugged and need to still
modify the fb dev code to ignore the second hotplug which I cant seem to figure
out how
to avoid the second hotplug from going through a modeset and retain the first
modeset on screen.
Also I will send a follow up patch to fallback to first non tiled mode in case
of connected boot.
But its okay for that to be separate patch than this right?
Regards
Manasi
>
> Reviewed-by: Dave Airlie
>
> Otherwise I think this seems fine, though it does beg the question in
> my mind of what happens if I get 2 8K monitors, and plug the first
> tile of one in, and the second tile of the other in.
>
> Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes
Hi Dave & Daniel, drm-misc-next-fixes is open and just a couple of patches this week. drm-misc-next-fixes-2019-11-06: -msm: Fix up a6xx debugbus register names (Sharat) -mst: Avoid u64 division (Sean) Cc: Sharat Masetty Cc: Sean Paul Cheers, Sean The following changes since commit cea35f5ad5ffac06ea29e0d7a7f748683e1f1b7d: drm/i915: Don't select BROKEN (2019-11-06 05:46:04 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2019-11-06 for you to fetch changes up to b149cbfeecaa2b2870d2c4f878382a024e6e4975: drm/mst: Fix up u64 division (2019-11-06 15:20:37 -0500) -msm: Fix up a6xx debugbus register names (Sharat) -mst: Avoid u64 division (Sean) Cc: Sharat Masetty Cc: Sean Paul Sean Paul (1): drm/mst: Fix up u64 division Sharat Masetty (1): drm: msm: a6xx: fix debug bus register configuration drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++-- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 24 2 files changed, 14 insertions(+), 14 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix up u64 division
On Wed, Nov 06, 2019 at 10:14:34PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 06, 2019 at 02:41:15PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Change rem_nsec to u32 since that's what do_div returns, this avoids the
> > u64 divide in the drm_print args.
> >
> > Changes in v2:
> > - Instead of doing do_div in drm_print, make rem_nsec u32 (Ville)
> >
> > Link to v1:
> > https://patchwork.freedesktop.org/patch/msgid/20191106173622.15573-1-s...@poorly.run
> >
> > Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
> > debugging")
> > Cc: Juston Li
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > Cc: Lyude Paul
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Sean Paul
>
> lgtm
> Reviewed-by: Ville Syrjälä
Thanks for the quick reviews, I've pushed this to drm-misc-next-fixes.
Sean
>
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 11adc4b6ccfe..ae5809a1f19a 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1507,12 +1507,12 @@ __dump_topology_ref_history(struct
> > drm_dp_mst_topology_ref_history *history,
> > ulong *entries;
> > uint nr_entries;
> > u64 ts_nsec = entry->ts_nsec;
> > - u64 rem_nsec = do_div(ts_nsec, 10);
> > + u32 rem_nsec = do_div(ts_nsec, 10);
> >
> > nr_entries = stack_depot_fetch(entry->backtrace, );
> > stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4);
> >
> > - drm_printf(, " %d %ss (last at %5llu.%06llu):\n%s",
> > + drm_printf(, " %d %ss (last at %5llu.%06u):\n%s",
> >entry->count,
> >topology_ref_type_to_str(entry->type),
> >ts_nsec, rem_nsec / 1000, buf);
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
> --
> Ville Syrjälä
> Intel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix up u64 division
On Wed, Nov 06, 2019 at 02:41:15PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Change rem_nsec to u32 since that's what do_div returns, this avoids the
> u64 divide in the drm_print args.
>
> Changes in v2:
> - Instead of doing do_div in drm_print, make rem_nsec u32 (Ville)
>
> Link to v1:
> https://patchwork.freedesktop.org/patch/msgid/20191106173622.15573-1-s...@poorly.run
>
> Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
> debugging")
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Lyude Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul
lgtm
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 11adc4b6ccfe..ae5809a1f19a 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1507,12 +1507,12 @@ __dump_topology_ref_history(struct
> drm_dp_mst_topology_ref_history *history,
> ulong *entries;
> uint nr_entries;
> u64 ts_nsec = entry->ts_nsec;
> - u64 rem_nsec = do_div(ts_nsec, 10);
> + u32 rem_nsec = do_div(ts_nsec, 10);
>
> nr_entries = stack_depot_fetch(entry->backtrace, );
> stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4);
>
> - drm_printf(, " %d %ss (last at %5llu.%06llu):\n%s",
> + drm_printf(, " %d %ss (last at %5llu.%06u):\n%s",
> entry->count,
> topology_ref_type_to_str(entry->type),
> ts_nsec, rem_nsec / 1000, buf);
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #214 from Marco Liedtke --- Created attachment 145904 --> https://bugs.freedesktop.org/attachment.cgi?id=145904=edit dmesg with gpu recovery enabled -- 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] drm/mst: Fix up u64 division
From: Sean Paul
Change rem_nsec to u32 since that's what do_div returns, this avoids the
u64 divide in the drm_print args.
Changes in v2:
- Instead of doing do_div in drm_print, make rem_nsec u32 (Ville)
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20191106173622.15573-1-s...@poorly.run
Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
debugging")
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Lyude Paul
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 11adc4b6ccfe..ae5809a1f19a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1507,12 +1507,12 @@ __dump_topology_ref_history(struct
drm_dp_mst_topology_ref_history *history,
ulong *entries;
uint nr_entries;
u64 ts_nsec = entry->ts_nsec;
- u64 rem_nsec = do_div(ts_nsec, 10);
+ u32 rem_nsec = do_div(ts_nsec, 10);
nr_entries = stack_depot_fetch(entry->backtrace, );
stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4);
- drm_printf(, " %d %ss (last at %5llu.%06llu):\n%s",
+ drm_printf(, " %d %ss (last at %5llu.%06u):\n%s",
entry->count,
topology_ref_type_to_str(entry->type),
ts_nsec, rem_nsec / 1000, buf);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #213 from Marco Liedtke --- (In reply to wychuchol from comment #212) > (In reply to Marco Liedtke from comment #211) > > > > I have already set AMD_DEBUG=nodam in /etc/environment and in ~/.profile. > > Last time i played World of Tanks via Wine and DXVK the same freeze occured, > > again the same error that xorg pid timed out... > > Don't know if you made a typo here but do you have AMD_DEBUG="nongg,nodma" > line in /etc/environment ? Bugs still occur for me but they're far less > frequent. > Also since you're running ryzen 3000 try to get kernel 5.4. It won't solve > your problems but there's a massive performance buff for zen2 in 5.4. Hi, i have noch kernel 5.4 rc6 installed and the problem didnt change. I have written AMD_DEBUG=nodma and NOT AMD_DEBUG="nodma" in /etc/environment. Now i have added the amdgpu.gpu_recovery=1 attribute in grub. So now there is a long output from dmesg while nothing done then clicking "login" in bugzilla with firefox. see attachment dmesg_with_gpu_recovery enabled I hope this helps a bit... -- 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 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #131 from Wilko Bartels --- (In reply to haro41 from comment #130) > > > > > > echo "manual" > > > > /sys/class/drm/card0/device/power_dpm_force_performance_level > > > echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk > > > > > > > do you have any suggestion to automate this? so far i can strictly run these > > commands after su. not even sudo works with scripts running these commands. > > or systemd files. > > Currently i use my patch (see above) to workaround the crashes. > If you prefer not to touch your kernel, you could create a systemd service: > > # cat /etc/systemd/system/amd-pp.service: > > [Unit] > Description=AMD PP adjust service > [Service] > User=root > Group=root > GuessMainPID=no > ExecStart=/srv/amdgpu-pp.sh > [Install] > WantedBy=multi-user.target > --- > # cat /srv/amdgpu-pp.sh: > > #!/bin/bash > echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level > echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk > --- > #systemctl enable amd-pp.service > #systemctl start amd-pp.service > --- > > ... assuming you have 'amdgpu.ppfeaturemask=0x' set ... Thank you. I already tried exactly that. And the unit unable to autostart (permission denied). Only manual systemctl start works. Dont know why. I would try to patch the kernel instead if i had any clue how to do the steps. -- 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 V8 0/6] mdev based hardware virtio offloading support
On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
> On Wed, 6 Nov 2019 11:56:46 +0800
> Jason Wang wrote:
>
> > On 2019/11/6 上午1:58, Alex Williamson wrote:
> > > On Tue, 5 Nov 2019 17:32:34 +0800
> > > Jason Wang wrote:
> > >
> > >> Hi all:
> > >>
> > >> There are hardwares that can do virtio datapath offloading while
> > >> having its own control path. This path tries to implement a mdev based
> > >> unified API to support using kernel virtio driver to drive those
> > >> devices. This is done by introducing a new mdev transport for virtio
> > >> (virtio_mdev) and register itself as a new kind of mdev driver. Then
> > >> it provides a unified way for kernel virtio driver to talk with mdev
> > >> device implementation.
> > >>
> > >> Though the series only contains kernel driver support, the goal is to
> > >> make the transport generic enough to support userspace drivers. This
> > >> means vhost-mdev[1] could be built on top as well by resuing the
> > >> transport.
> > >>
> > >> A sample driver is also implemented which simulate a virito-net
> > >> loopback ethernet device on top of vringh + workqueue. This could be
> > >> used as a reference implementation for real hardware driver.
> > >>
> > >> Also a real ICF VF driver was also posted here[2] which is a good
> > >> reference for vendors who is interested in their own virtio datapath
> > >> offloading product.
> > >>
> > >> Consider mdev framework only support VFIO device and driver right now,
> > >> this series also extend it to support other types. This is done
> > >> through introducing class id to the device and pairing it with
> > >> id_talbe claimed by the driver. On top, this seris also decouple
> > >> device specific parents ops out of the common ones.
> > >>
> > >> Pktgen test was done with virito-net + mvnet loop back device.
> > >>
> > >> Please review.
> > >>
> > >> [1] https://lkml.org/lkml/2019/10/31/440
> > >> [2] https://lkml.org/lkml/2019/10/15/1226
> > >>
> > >> Changes from V7:
> > >> - drop {set|get}_mdev_features for virtio
> > >> - typo and comment style fixes
> > >
> > > Seems we're nearly there, all the remaining comments are relatively
> > > superficial, though I would appreciate a v9 addressing them as well as
> > > the checkpatch warnings:
> > >
> > > https://patchwork.freedesktop.org/series/68977/
> >
> >
> > Will do.
> >
> > Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
> > go through Michael's vhost tree?
>
> I can include it if you wish. The mdev changes are isolated enough in
> that patch that I wouldn't presume it, but clearly it would require
> less merge coordination to drop it in my tree. Let me know. Thanks,
>
> Alex
I'm fine with merging through your tree. If you do, feel free to
include
Acked-by: Michael S. Tsirkin
--
MST
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 0/6] mdev based hardware virtio offloading support
On Wed, 6 Nov 2019 11:56:46 +0800
Jason Wang wrote:
> On 2019/11/6 上午1:58, Alex Williamson wrote:
> > On Tue, 5 Nov 2019 17:32:34 +0800
> > Jason Wang wrote:
> >
> >> Hi all:
> >>
> >> There are hardwares that can do virtio datapath offloading while
> >> having its own control path. This path tries to implement a mdev based
> >> unified API to support using kernel virtio driver to drive those
> >> devices. This is done by introducing a new mdev transport for virtio
> >> (virtio_mdev) and register itself as a new kind of mdev driver. Then
> >> it provides a unified way for kernel virtio driver to talk with mdev
> >> device implementation.
> >>
> >> Though the series only contains kernel driver support, the goal is to
> >> make the transport generic enough to support userspace drivers. This
> >> means vhost-mdev[1] could be built on top as well by resuing the
> >> transport.
> >>
> >> A sample driver is also implemented which simulate a virito-net
> >> loopback ethernet device on top of vringh + workqueue. This could be
> >> used as a reference implementation for real hardware driver.
> >>
> >> Also a real ICF VF driver was also posted here[2] which is a good
> >> reference for vendors who is interested in their own virtio datapath
> >> offloading product.
> >>
> >> Consider mdev framework only support VFIO device and driver right now,
> >> this series also extend it to support other types. This is done
> >> through introducing class id to the device and pairing it with
> >> id_talbe claimed by the driver. On top, this seris also decouple
> >> device specific parents ops out of the common ones.
> >>
> >> Pktgen test was done with virito-net + mvnet loop back device.
> >>
> >> Please review.
> >>
> >> [1] https://lkml.org/lkml/2019/10/31/440
> >> [2] https://lkml.org/lkml/2019/10/15/1226
> >>
> >> Changes from V7:
> >> - drop {set|get}_mdev_features for virtio
> >> - typo and comment style fixes
> >
> > Seems we're nearly there, all the remaining comments are relatively
> > superficial, though I would appreciate a v9 addressing them as well as
> > the checkpatch warnings:
> >
> > https://patchwork.freedesktop.org/series/68977/
>
>
> Will do.
>
> Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
> go through Michael's vhost tree?
I can include it if you wish. The mdev changes are isolated enough in
that patch that I wouldn't presume it, but clearly it would require
less merge coordination to drop it in my tree. Let me know. Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2 v2] drm/atomic: fix self-refresh helpers crtc state dereference
On Mon, Nov 04, 2019 at 09:37:36AM -0800, Rob Clark wrote:
> From: Rob Clark
>
> drm_self_refresh_helper_update_avg_times() was incorrectly accessing the
> new incoming state after drm_atomic_helper_commit_hw_done(). But this
> state might have already been superceeded by an !nonblock atomic update
> resulting in dereferencing an already free'd crtc_state.
>
> TODO I *think* this will more or less do the right thing.. althought I'm
> not 100% sure if, for example, we enter psr in a nonblock commit, and
> then leave psr in a !nonblock commit that overtakes the completion of
> the nonblock commit. Not sure if this sort of scenario can happen in
> practice. But not crashing is better than crashing, so I guess we
> should either take this patch or rever the self-refresh helpers until
> Sean can figure out a better solution.
>
> Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid
> thrashing")
> Cc: Sean Paul
> Signed-off-by: Rob Clark
Thanks for tracking this down, Rob. I gave it a spin on my rk3399 kevin and it
behaved as expected.
I've pushed this patch to drm-misc-fixes in hopes it'll catch 5.4
Sean
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 14 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 15 +--
> include/drm/drm_self_refresh_helper.h | 3 ++-
> 3 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3ef2ac52ce94..648494c813e5 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1581,8 +1581,11 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> const struct drm_mode_config_helper_funcs *funcs;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc *crtc;
> ktime_t start;
> s64 commit_time_ms;
> + unsigned i, new_self_refresh_mask = 0;
>
> funcs = dev->mode_config.helper_private;
>
> @@ -1602,6 +1605,14 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
>
> drm_atomic_helper_wait_for_dependencies(old_state);
>
> + /*
> + * We cannot safely access new_crtc_state after
> drm_atomic_helper_commit_hw_done()
> + * so figure out which crtc's have self-refresh active beforehand:
> + */
> + for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i)
> + if (new_crtc_state->self_refresh_active)
> + new_self_refresh_mask |= BIT(i);
> +
> if (funcs && funcs->atomic_commit_tail)
> funcs->atomic_commit_tail(old_state);
> else
> @@ -1610,7 +1621,8 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> commit_time_ms = ktime_ms_delta(ktime_get(), start);
> if (commit_time_ms > 0)
> drm_self_refresh_helper_update_avg_times(old_state,
> - (unsigned long)commit_time_ms);
> + (unsigned long)commit_time_ms,
> + new_self_refresh_mask);
>
> drm_atomic_helper_commit_cleanup_done(old_state);
>
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 68f4765a5896..011b8d5f7dd6 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -133,6 +133,8 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> * drm_self_refresh_helper_update_avg_times - Updates a crtc's SR time
> averages
> * @state: the state which has just been applied to hardware
> * @commit_time_ms: the amount of time in ms that this commit took to
> complete
> + * @new_self_refresh_mask: bitmask of crtc's that have self_refresh_active in
> + *new state
> *
> * Called after _mode_config_funcs.atomic_commit_tail, this function will
> * update the average entry/exit self refresh times on self refresh
> transitions.
> @@ -140,22 +142,23 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> * entering self refresh mode after activity.
> */
> void drm_self_refresh_helper_update_avg_times(struct drm_atomic_state *state,
> - unsigned int commit_time_ms)
> + unsigned int commit_time_ms,
> + unsigned int
> new_self_refresh_mask)
> {
> struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_crtc_state *old_crtc_state;
> int i;
>
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> - new_crtc_state, i) {
> + for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
> + bool new_self_refresh_active =
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #130 from har...@gmx.de --- > > > > echo "manual" > > > /sys/class/drm/card0/device/power_dpm_force_performance_level > > echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk > > > > do you have any suggestion to automate this? so far i can strictly run these > commands after su. not even sudo works with scripts running these commands. > or systemd files. Currently i use my patch (see above) to workaround the crashes. If you prefer not to touch your kernel, you could create a systemd service: # cat /etc/systemd/system/amd-pp.service: [Unit] Description=AMD PP adjust service [Service] User=root Group=root GuessMainPID=no ExecStart=/srv/amdgpu-pp.sh [Install] WantedBy=multi-user.target --- # cat /srv/amdgpu-pp.sh: #!/bin/bash echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk --- #systemctl enable amd-pp.service #systemctl start amd-pp.service --- ... assuming you have 'amdgpu.ppfeaturemask=0x' set ... -- 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] drm/mst: Fix up u64 division
On Wed, Nov 06, 2019 at 12:36:15PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Use do_div to divide rem_nsec instead of /.
>
> Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
> debugging")
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Lyude Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 11adc4b6ccfe..d2da5f113f16 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1512,10 +1512,10 @@ __dump_topology_ref_history(struct
> drm_dp_mst_topology_ref_history *history,
> nr_entries = stack_depot_fetch(entry->backtrace, );
> stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4);
>
> - drm_printf(, " %d %ss (last at %5llu.%06llu):\n%s",
> + drm_printf(, " %d %ss (last at %5llu.%06u):\n%s",
> entry->count,
> topology_ref_type_to_str(entry->type),
> -ts_nsec, rem_nsec / 1000, buf);
> +ts_nsec, do_div(rem_nsec, 1000), buf);
Or just change rem_nsec to u32 since that's what do_div() gives you.
> }
>
> /* Now free the history, since this is the only time we expose it */
> --
> Sean Paul, Software Engineer, Google / Chromium OS
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On 11/6/19 12:18 PM, Andrew F. Davis wrote:
> On 11/6/19 12:03 PM, John Stultz wrote:
>> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>>
>>> On 11/5/19 11:22 PM, John Stultz wrote:
+unsigned int dma_heap_ioctl_cmds[] = {
+ DMA_HEAP_IOC_ALLOC,
+};
+
+static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
+unsigned long arg)
+{
+ char stack_kdata[128];
+ char *kdata = stack_kdata;
+ unsigned int kcmd;
+ unsigned int in_size, out_size, drv_size, ksize;
+ int nr = _IOC_NR(ucmd);
+ int ret = 0;
+
+ if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds))
+ return -EINVAL;
+
+ /* Get the kernel ioctl cmd that matches */
+ kcmd = dma_heap_ioctl_cmds[nr];
>>>
>>>
>>> Why do we need this indirection here and all the complexity below? I
>>> know DRM ioctl does something like this but it has a massive table,
>>> legacy ioctls, driver defined ioctls, etc..
>>>
>>> I don't expect we will ever need complex handling like this, could we
>>> switch back to the more simple handler from v13?
>>
>> I agree it does add complexity, but I'm not sure I see how to avoid
>> some of this. The logic trying to handle that the user may pass a cmd
>> that has the same _IOC_NR() as DMA_HEAP_IOC_ALLOC but not the same
>> size. So the simple "switch(cmd) { case DMA_HEAP_IOC_ALLOC:" we had
>> before won't work (as the cmd will be a different value).
>>
>
>
> DMA_HEAP_IOC_ALLOC encodes everything we need, if the size is different
> then the switch case will not match. It handled everything we have.
>
>
>> Thus why I thought the cleanest approach would be to use the
>> dma_heap_ioctl_cmds array to convert from whatever the user cmd is to
>> the matching kernel cmd value.
>>
>
>
> There are no kernel or user commands, just commands, they will match or
> they are not valid. If someday we some need a variable sized ioctl then
> we can deal with that then.
>
Had a little discussion about this on IRC #dri-devel (check logs for
today if you want to follow along). Conclusion being the way it is done
here should be fine to help support forward compatibility. If optional
extensions to the structure are made that grow the size of data passed
in then we can ignore that and zero out the returned data without harm.
It is up to the flags field to mark incompatible changes that should
error out from kernel.
Andrew
> Andrew
>
>
>> Do you have an alternative suggestion that I'm overlooking?
>>
>> thanks
>> -john
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Limit to INT_MAX in create_blob ioctl
On Wed, 6 Nov 2019 09:24:18 -0800 Kees Cook wrote: > > Since this is -mm can I have a stable sha1 or something for > > referencing? Or do you want to include this in the -mm patch bomb for > > the merge window? > > Traditionally these things live in akpm's tree when they are fixes for > patches in there. I have no idea how the Fixes tags work in that case, > though... I queued it immediately ahead of uaccess-disallow-int_max-copy-sizes.patch so all should be good, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Limit to INT_MAX in create_blob ioctl
On Wed, Nov 6, 2019 at 6:24 PM Kees Cook wrote:
>
> On Wed, Nov 06, 2019 at 05:47:55PM +0100, Daniel Vetter wrote:
> > The hardened usercpy code is too paranoid ever since:
> >
> > commit 6a30afa8c1fbde5f10f9c584c2992aa3c7f7a8fe
> > Author: Kees Cook
> > Date: Wed Nov 6 16:07:01 2019 +1100
> >
> > uaccess: disallow > INT_MAX copy sizes
> >
> > Code itself should have been fine as-is.
>
> I had to go read the syzbot report to understand what was actually being
> fixed here. Can you be a bit more verbose in this commit log? It sounds
> like huge usercopy sizes were allowed by drm (though I guess they would
> fail gracefully in some other way?) but after 6a30afa8c1fb, the copy
> would yell about sizes where INT_MAX < size < ULONG_MAX - sizeof(...) ?
The WARNING seems to have been the only bad effect. I guess in
practice the real big stuff fails at memory allocation time, but
shouldn't overflow. Or maybe I still don't get how this C thing works.
Anyway I figured the cited patch is good enough, userptr copies >
INT_MAX aren't allowed anymore, so we need to adjust our overflow
checks.
-Daniel
> What was the prior failure mode that made the existing ULONG_MAX check
> safe? Your patch looks fine, though:
>
> Reviewed-by: Kees Cook
>
> > Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> > Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
> > Cc: Kees Cook
> > Cc: Alexander Viro
> > Cc: Andrew Morton
> > Cc: Stephen Rothwell
> > Signed-off-by: Daniel Vetter
> > --
> > Kees/Andrew,
> >
> > Since this is -mm can I have a stable sha1 or something for
> > referencing? Or do you want to include this in the -mm patch bomb for
> > the merge window?
>
> Traditionally these things live in akpm's tree when they are fixes for
> patches in there. I have no idea how the Fixes tags work in that case,
> though...
>
> -Kees
>
> > -Daniel
> > ---
> > drivers/gpu/drm/drm_property.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> > index 892ce636ef72..6ee04803c362 100644
> > --- a/drivers/gpu/drm/drm_property.c
> > +++ b/drivers/gpu/drm/drm_property.c
> > @@ -561,7 +561,7 @@ drm_property_create_blob(struct drm_device *dev, size_t
> > length,
> > struct drm_property_blob *blob;
> > int ret;
> >
> > - if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
> > + if (!length || length > INT_MAX - sizeof(struct drm_property_blob))
> > return ERR_PTR(-EINVAL);
> >
> > blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
> > --
> > 2.24.0.rc2
> >
>
> --
> Kees Cook
--
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: drm/komeda: Use devm_platform_ioremap_resource() in komeda_dev_create()
On Wednesday, 9 October 2019 09:57:11 GMT james qian wang (Arm Technology
China) wrote:
> On Sat, Sep 21, 2019 at 07:50:46PM +0200, Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Sat, 21 Sep 2019 19:43:51 +0200
> >
> > Simplify this function implementation by using a known wrapper function.
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring
>
> Thank you for the patch.
>
> Looks good to me.
> Reviewed-by: James Qian Wang (Arm Technology China)
Applied to drm-misc-next - 50ec5b563bed04b0b262822b755f6aa336f1f40a
>
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 9 +
> > 1 file changed, 1 insertion(+), 8 deletions(-)
> >
> > --
> > 2.23.0
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > index ca64a129c594..a387d923962e 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> > @@ -172,19 +172,12 @@ struct komeda_dev *komeda_dev_create(struct device
> > *dev)
> > struct platform_device *pdev = to_platform_device(dev);
> > const struct komeda_product_data *product;
> > struct komeda_dev *mdev;
> > - struct resource *io_res;
> > int err = 0;
> >
> > product = of_device_get_match_data(dev);
> > if (!product)
> > return ERR_PTR(-ENODEV);
> >
> > - io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - if (!io_res) {
> > - DRM_ERROR("No registers defined.\n");
> > - return ERR_PTR(-ENODEV);
> > - }
> > -
> > mdev = devm_kzalloc(dev, sizeof(*mdev), GFP_KERNEL);
> > if (!mdev)
> > return ERR_PTR(-ENOMEM);
> > @@ -192,7 +185,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
> > mutex_init(>lock);
> >
> > mdev->dev = dev;
> > - mdev->reg_base = devm_ioremap_resource(dev, io_res);
> > + mdev->reg_base = devm_platform_ioremap_resource(pdev, 0);
> > if (IS_ERR(mdev->reg_base)) {
> > DRM_ERROR("Map register space failed.\n");
> > err = PTR_ERR(mdev->reg_base);
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amdgpu: Avoid accidental thread thread reactivation.
Problem:
During GPU reset we call the GPU scheduler to suspend it's
thread, those two functions in amdgpu also suspend and resume
the sceduler for their needs but this can collide with GPU
reset in progress and accidently restart a suspended thread
before time.
Fix:
Serialize with GPU reset.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 693f17e..8e6726e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -859,6 +859,9 @@ static int amdgpu_debugfs_test_ib(struct seq_file *m, void
*data)
struct amdgpu_device *adev = dev->dev_private;
int r = 0, i;
+ /* Avoid accidently unparking the sched thread during GPU reset */
+ mutex_lock(>lock_reset);
+
/* hold on the scheduler */
for (i = 0; i < AMDGPU_MAX_RINGS; i++) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -884,6 +887,8 @@ static int amdgpu_debugfs_test_ib(struct seq_file *m, void
*data)
kthread_unpark(ring->sched.thread);
}
+ mutex_unlock(>lock_reset);
+
return 0;
}
@@ -1036,6 +1041,9 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
if (!fences)
return -ENOMEM;
+ /* Avoid accidently unparking the sched thread during GPU reset */
+ mutex_lock(>lock_reset);
+
/* stop the scheduler */
kthread_park(ring->sched.thread);
@@ -1075,6 +1083,8 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
/* restart the scheduler */
kthread_unpark(ring->sched.thread);
+ mutex_unlock(>lock_reset);
+
ttm_bo_unlock_delayed_workqueue(>mman.bdev, resched);
kfree(fences);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/sched: Use completion to wait for entity idle
Removes thread park/unpark hack from drm_sched_entity_fini and
by this fixes reactivation of scheduler thread while the thread
is supposed to be stopped.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 12
drivers/gpu/drm/scheduler/sched_main.c | 6 ++
include/drm/gpu_scheduler.h | 2 ++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
b/drivers/gpu/drm/scheduler/sched_entity.c
index 1a51531..461a7a8 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -68,6 +69,8 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
if (!entity->rq_list)
return -ENOMEM;
+ init_completion(>entity_idle);
+
for (i = 0; i < num_rq_list; ++i)
entity->rq_list[i] = rq_list[i];
@@ -286,11 +289,12 @@ void drm_sched_entity_fini(struct drm_sched_entity
*entity)
*/
if (spsc_queue_count(>job_queue)) {
if (sched) {
- /* Park the kernel for a moment to make sure it isn't
processing
-* our enity.
+ /*
+* Wait for thread to idle to make sure it isn't
processing
+* this entity.
*/
- kthread_park(sched->thread);
- kthread_unpark(sched->thread);
+ wait_for_completion(>entity_idle);
+
}
if (entity->dependency) {
dma_fence_remove_callback(entity->dependency,
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dba4390..38bbad7 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
@@ -134,6 +135,7 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
list_for_each_entry_continue(entity, >entities, list) {
if (drm_sched_entity_is_ready(entity)) {
rq->current_entity = entity;
+ reinit_completion(>entity_idle);
spin_unlock(>lock);
return entity;
}
@@ -144,6 +146,7 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
if (drm_sched_entity_is_ready(entity)) {
rq->current_entity = entity;
+ reinit_completion(>entity_idle);
spin_unlock(>lock);
return entity;
}
@@ -721,6 +724,9 @@ static int drm_sched_main(void *param)
continue;
sched_job = drm_sched_entity_pop_job(entity);
+
+ complete(>entity_idle);
+
if (!sched_job)
continue;
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 57b4121..6619d2a 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -71,6 +71,7 @@ enum drm_sched_priority {
* @last_scheduled: points to the finished fence of the last scheduled job.
* @last_user: last group leader pushing a job into the entity.
* @stopped: Marks the enity as removed from rq and destined for termination.
+ * @entity_idle: Signals when enityt is not in use
*
* Entities will emit jobs in order to their corresponding hardware
* ring, and the scheduler will alternate between entities based on
@@ -94,6 +95,7 @@ struct drm_sched_entity {
struct dma_fence*last_scheduled;
struct task_struct *last_user;
boolstopped;
+ struct completion entity_idle;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/sched: Avoid job cleanup if sched thread is parked.
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 38bbad7..80ddbdf 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -647,9 +647,13 @@ static void drm_sched_cleanup_jobs(struct
drm_gpu_scheduler *sched)
{
unsigned long flags;
- /* Don't destroy jobs while the timeout worker is running */
- if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
- !cancel_delayed_work(>work_tdr))
+ /*
+* Don't destroy jobs while the timeout worker is running OR thread
+* is being parked and hence assumed to not touch ring_mirror_list
+*/
+ if ((sched->timeout != MAX_SCHEDULE_TIMEOUT &&
+ !cancel_delayed_work(>work_tdr)) ||
+ __kthread_should_park(sched->thread))
return;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] Revert "drm/amdgpu: dont schedule jobs while in reset"
This reverts commit 3cdf9bd0089723c468d5f6240e54d1afa52e9a04.
We will do a proper fix in next patch.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 2cdaf3b..6614d8a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -604,11 +604,8 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
continue;
}
- for (i = 0; i < num_entities; i++) {
- mutex_lock(>adev->lock_reset);
+ for (i = 0; i < num_entities; i++)
drm_sched_entity_fini(>entities[0][i].entity);
- mutex_unlock(>adev->lock_reset);
- }
}
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shmem: Add docbook comments for drm_gem_shmem_object madvise fields
On Fri, Nov 01, 2019 at 10:37:54AM -0500, Rob Herring wrote:
> Add missing docbook comments to madvise fields in struct
> drm_gem_shmem_object which fixes these warnings:
>
> include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member
> 'madv' not described in 'drm_gem_shmem_object'
> include/drm/drm_gem_shmem_helper.h:87: warning: Function parameter or member
> 'madv_list' not described in 'drm_gem_shmem_object'
>
> Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers")
> Reported-by: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
Reviewed-by: Sean Paul
> Signed-off-by: Rob Herring
> ---
> include/drm/drm_gem_shmem_helper.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index e2e9947b4770..901eafb09209 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -44,7 +44,20 @@ struct drm_gem_shmem_object {
>*/
> unsigned int pages_use_count;
>
> + /**
> + * @madv: State for madvise
> + *
> + * 0 is active/inuse.
> + * A negative value is the object is purged.
> + * Positive values are driver specific and not used by the helpers.
> + */
> int madv;
> +
> + /**
> + * @madv_list: List entry for madvise tracking
> + *
> + * Typically used by drivers to track purgeable objects
> + */
> struct list_head madv_list;
>
> /**
> --
> 2.20.1
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm: msm: a6xx: fix debug bus register configuration
On Wed, Nov 06, 2019 at 05:19:23PM +0530, Sharat Masetty wrote:
> Fix the cx debugbus related register configuration, to collect accurate
> bus data during gpu snapshot. This helps with complete snapshot dump
> and also complete proper GPU recovery.
>
> Signed-off-by: Sharat Masetty
Applied to drm-misc-next-fixes
Thanks,
Sean
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> index 483e100..c5764b4 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> @@ -353,26 +353,26 @@ static void a6xx_get_debugbus(struct msm_gpu *gpu,
> cxdbg = ioremap(res->start, resource_size(res));
>
> if (cxdbg) {
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLT,
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT,
> A6XX_DBGC_CFG_DBGBUS_CNTLT_SEGT(0xf));
>
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLM,
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM,
> A6XX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(0xf));
>
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_3, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3, 0);
>
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_0,
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0,
> 0x76543210);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_1,
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1,
> 0xFEDCBA98);
>
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> }
>
> nr_debugbus_blocks = ARRAY_SIZE(a6xx_debugbus_blocks) +
> --
> 1.9.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
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/mst: Fix up u64 division
From: Sean Paul
Use do_div to divide rem_nsec instead of /.
Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
debugging")
Cc: Juston Li
Cc: Imre Deak
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Lyude Paul
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 11adc4b6ccfe..d2da5f113f16 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1512,10 +1512,10 @@ __dump_topology_ref_history(struct
drm_dp_mst_topology_ref_history *history,
nr_entries = stack_depot_fetch(entry->backtrace, );
stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 4);
- drm_printf(, " %d %ss (last at %5llu.%06llu):\n%s",
+ drm_printf(, " %d %ss (last at %5llu.%06u):\n%s",
entry->count,
topology_ref_type_to_str(entry->type),
- ts_nsec, rem_nsec / 1000, buf);
+ ts_nsec, do_div(rem_nsec, 1000), buf);
}
/* Now free the history, since this is the only time we expose it */
--
Sean Paul, Software Engineer, Google / Chromium OS
___
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 #129 from Wilko Bartels --- (In reply to haro41 from comment #122) > In my experience, this issue is related to mclk switching and it affects the > lowest mclk level only. > > So you guy's can save a lot of power, if you, insteed of switching to > highest gfxlevel or to disable vsync, just disable the lowest mclk level by: > > echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level > echo "1 2 3" > /sys/class/drm/card0/device/pp_dpm_mclk > > If you are building your kernel locally, look in this thread for a driver > code modification that works, without disabling the lowest mclk level (saves > a few watt on idle). do you have any suggestion to automate this? so far i can strictly run these commands after su. not even sudo works with scripts running these commands. or systemd files. -- 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] drm: Limit to INT_MAX in create_blob ioctl
On Wed, Nov 06, 2019 at 05:47:55PM +0100, Daniel Vetter wrote:
> The hardened usercpy code is too paranoid ever since:
>
> commit 6a30afa8c1fbde5f10f9c584c2992aa3c7f7a8fe
> Author: Kees Cook
> Date: Wed Nov 6 16:07:01 2019 +1100
>
> uaccess: disallow > INT_MAX copy sizes
>
> Code itself should have been fine as-is.
I had to go read the syzbot report to understand what was actually being
fixed here. Can you be a bit more verbose in this commit log? It sounds
like huge usercopy sizes were allowed by drm (though I guess they would
fail gracefully in some other way?) but after 6a30afa8c1fb, the copy
would yell about sizes where INT_MAX < size < ULONG_MAX - sizeof(...) ?
What was the prior failure mode that made the existing ULONG_MAX check
safe? Your patch looks fine, though:
Reviewed-by: Kees Cook
> Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
> Cc: Kees Cook
> Cc: Alexander Viro
> Cc: Andrew Morton
> Cc: Stephen Rothwell
> Signed-off-by: Daniel Vetter
> --
> Kees/Andrew,
>
> Since this is -mm can I have a stable sha1 or something for
> referencing? Or do you want to include this in the -mm patch bomb for
> the merge window?
Traditionally these things live in akpm's tree when they are fixes for
patches in there. I have no idea how the Fixes tags work in that case,
though...
-Kees
> -Daniel
> ---
> drivers/gpu/drm/drm_property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 892ce636ef72..6ee04803c362 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -561,7 +561,7 @@ drm_property_create_blob(struct drm_device *dev, size_t
> length,
> struct drm_property_blob *blob;
> int ret;
>
> - if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
> + if (!length || length > INT_MAX - sizeof(struct drm_property_blob))
> return ERR_PTR(-EINVAL);
>
> blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
> --
> 2.24.0.rc2
>
--
Kees Cook
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: fix double reference dropping
On Wed, Nov 6, 2019 at 7:48 AM Koenig, Christian
wrote:
>
> Am 06.11.19 um 12:35 schrieb Pan Bian:
> > The reference to object fence is dropped at the end of the loop.
> > However, it is dropped again outside the loop. The reference can be
> > dropped immediately after calling dma_fence_wait() in the loop and
> > thus the dropping operation outside the loop can be removed.
> >
> > Signed-off-by: Pan Bian
>
> Reviewed-by: Christian König
>
Applied. thanks!
Alex
> > ---
> > v2: fix the bug in a more concise way
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
> > index 649e68c4479b..d1495e1c9289 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
> > @@ -33,7 +33,7 @@ static int amdgpu_benchmark_do_move(struct amdgpu_device
> > *adev, unsigned size,
> > {
> > unsigned long start_jiffies;
> > unsigned long end_jiffies;
> > - struct dma_fence *fence = NULL;
> > + struct dma_fence *fence;
> > int i, r;
> >
> > start_jiffies = jiffies;
> > @@ -44,16 +44,14 @@ static int amdgpu_benchmark_do_move(struct
> > amdgpu_device *adev, unsigned size,
> > if (r)
> > goto exit_do_move;
> > r = dma_fence_wait(fence, false);
> > + dma_fence_put(fence);
> > if (r)
> > goto exit_do_move;
> > - dma_fence_put(fence);
> > }
> > end_jiffies = jiffies;
> > r = jiffies_to_msecs(end_jiffies - start_jiffies);
> >
> > exit_do_move:
> > - if (fence)
> > - dma_fence_put(fence);
> > return r;
> > }
> >
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH] drm: msm: a6xx: fix debug bus register configuration
On Wed, Nov 06, 2019 at 08:18:59AM -0800, Rob Clark wrote:
> On Wed, Nov 6, 2019 at 3:49 AM Sharat Masetty wrote:
> >
> > Fix the cx debugbus related register configuration, to collect accurate
> > bus data during gpu snapshot. This helps with complete snapshot dump
> > and also complete proper GPU recovery.
> >
> > Signed-off-by: Sharat Masetty
This commit summary is far too polite. The word boneheaded should have appeared
several times. Thanks for this patch.
> (adding fixes tag for benefit of stable kernels)
>
> Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Thanks, I was going to suggest this as well.
> Reviewed-by: Rob Clark
Reviewed-by: Jordan Crouse
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 24
> > 1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > index 483e100..c5764b4 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
> > @@ -353,26 +353,26 @@ static void a6xx_get_debugbus(struct msm_gpu *gpu,
> > cxdbg = ioremap(res->start, resource_size(res));
> >
> > if (cxdbg) {
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLT,
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT,
> > A6XX_DBGC_CFG_DBGBUS_CNTLT_SEGT(0xf));
> >
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_CNTLM,
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM,
> > A6XX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(0xf));
> >
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_IVTL_3, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3, 0);
> >
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_0,
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0,
> > 0x76543210);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_BYTEL_1,
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1,
> > 0xFEDCBA98);
> >
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> > - cxdbg_write(cxdbg, REG_A6XX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2, 0);
> > + cxdbg_write(cxdbg, REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3, 0);
> > }
> >
> > nr_debugbus_blocks = ARRAY_SIZE(a6xx_debugbus_blocks) +
> > --
> > 1.9.1
> >
> > ___
> > Freedreno mailing list
> > freedr...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/freedreno
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: fix struct init in renoir_print_clk_levels
On Tue, Nov 5, 2019 at 6:10 PM Raul E Rangel wrote:
>
> drivers/gpu/drm/amd/powerplay/renoir_ppt.c:186:2: error: missing braces
> around initializer [-Werror=missing-braces]
> SmuMetrics_t metrics = {0};
> ^
>
> Fixes: 8b8031703bd7 ("drm/amd/powerplay: implement sysfs for getting dpm
> clock")
>
> Signed-off-by: Raul E Rangel
Applied. thanks!
Alex
> ---
>
> drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> index e62bfba51562..e5283dafc414 100644
> --- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> +++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
> @@ -183,11 +183,13 @@ static int renoir_print_clk_levels(struct smu_context
> *smu,
> int i, size = 0, ret = 0;
> uint32_t cur_value = 0, value = 0, count = 0, min = 0, max = 0;
> DpmClocks_t *clk_table = smu->smu_table.clocks_table;
> - SmuMetrics_t metrics = {0};
> + SmuMetrics_t metrics;
>
> if (!clk_table || clk_type >= SMU_CLK_COUNT)
> return -EINVAL;
>
> + memset(, 0, sizeof(metrics));
> +
> ret = smu_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
>(void *), false);
> if (ret)
> --
> 2.24.0.rc1.363.gb1bccd3e3d-goog
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: fix potential double drop fence reference
On Wed, Nov 6, 2019 at 4:39 AM Koenig, Christian
wrote:
>
> Am 06.11.19 um 10:14 schrieb Pan Bian:
> > The object fence is not set to NULL after its reference is dropped. As a
> > result, its reference may be dropped again if error occurs after that,
> > which may lead to a use after free bug. To avoid the issue, fence is
> > explicitly set to NULL after dropping its reference.
> >
> > Signed-off-by: Pan Bian
>
> Acked-by: Christian König
Applied. thanks!
Alex
>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
> > index b66d29d5ffa2..b158230af8db 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_test.c
> > @@ -138,6 +138,7 @@ static void amdgpu_do_test_moves(struct amdgpu_device
> > *adev)
> > }
> >
> > dma_fence_put(fence);
> > + fence = NULL;
> >
> > r = amdgpu_bo_kmap(vram_obj, _map);
> > if (r) {
> > @@ -183,6 +184,7 @@ static void amdgpu_do_test_moves(struct amdgpu_device
> > *adev)
> > }
> >
> > dma_fence_put(fence);
> > + fence = NULL;
> >
> > r = amdgpu_bo_kmap(gtt_obj[i], _map);
> > if (r) {
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On 11/6/19 12:03 PM, John Stultz wrote:
> On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>>
>> On 11/5/19 11:22 PM, John Stultz wrote:
>>> +unsigned int dma_heap_ioctl_cmds[] = {
>>> + DMA_HEAP_IOC_ALLOC,
>>> +};
>>> +
>>> +static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
>>> +unsigned long arg)
>>> +{
>>> + char stack_kdata[128];
>>> + char *kdata = stack_kdata;
>>> + unsigned int kcmd;
>>> + unsigned int in_size, out_size, drv_size, ksize;
>>> + int nr = _IOC_NR(ucmd);
>>> + int ret = 0;
>>> +
>>> + if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds))
>>> + return -EINVAL;
>>> +
>>> + /* Get the kernel ioctl cmd that matches */
>>> + kcmd = dma_heap_ioctl_cmds[nr];
>>
>>
>> Why do we need this indirection here and all the complexity below? I
>> know DRM ioctl does something like this but it has a massive table,
>> legacy ioctls, driver defined ioctls, etc..
>>
>> I don't expect we will ever need complex handling like this, could we
>> switch back to the more simple handler from v13?
>
> I agree it does add complexity, but I'm not sure I see how to avoid
> some of this. The logic trying to handle that the user may pass a cmd
> that has the same _IOC_NR() as DMA_HEAP_IOC_ALLOC but not the same
> size. So the simple "switch(cmd) { case DMA_HEAP_IOC_ALLOC:" we had
> before won't work (as the cmd will be a different value).
>
DMA_HEAP_IOC_ALLOC encodes everything we need, if the size is different
then the switch case will not match. It handled everything we have.
> Thus why I thought the cleanest approach would be to use the
> dma_heap_ioctl_cmds array to convert from whatever the user cmd is to
> the matching kernel cmd value.
>
There are no kernel or user commands, just commands, they will match or
they are not valid. If someday we some need a variable sized ioctl then
we can deal with that then.
Andrew
> Do you have an alternative suggestion that I'm overlooking?
>
> thanks
> -john
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/amdgpu: remove set but not used variable 'mc_shared_chmap'
On Mon, Nov 4, 2019 at 8:54 AM yu kuai wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function
> ‘gfx_v8_0_gpu_early_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1713:6: warning: variable
> ‘mc_shared_chmap’ set but not used [-Wunused-but-set-variable]
>
> Fixes: 0bde3a95eaa9 ("drm/amdgpu: split gfx8 gpu init into sw and hw parts")
> Signed-off-by: yu kuai
Looks like gfx_v7_0.c and gfx_v6_0.c could have the same treatment.
Care to send patches?
Applied the series. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index e4c645d..80b7958 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1710,7 +1710,7 @@ static int gfx_v8_0_do_edc_gpr_workarounds(struct
> amdgpu_device *adev)
> static int gfx_v8_0_gpu_early_init(struct amdgpu_device *adev)
> {
> u32 gb_addr_config;
> - u32 mc_shared_chmap, mc_arb_ramcfg;
> + u32 mc_arb_ramcfg;
> u32 dimm00_addr_map, dimm01_addr_map, dimm10_addr_map,
> dimm11_addr_map;
> u32 tmp;
> int ret;
> @@ -1850,7 +1850,6 @@ static int gfx_v8_0_gpu_early_init(struct amdgpu_device
> *adev)
> break;
> }
>
> - mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
> adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
> mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
>
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Limit to INT_MAX in create_blob ioctl
On Wed, Nov 06, 2019 at 05:47:55PM +0100, Daniel Vetter wrote:
> The hardened usercpy code is too paranoid ever since:
>
> commit 6a30afa8c1fbde5f10f9c584c2992aa3c7f7a8fe
> Author: Kees Cook
> Date: Wed Nov 6 16:07:01 2019 +1100
>
> uaccess: disallow > INT_MAX copy sizes
>
> Code itself should have been fine as-is.
>
> Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
> Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
> Cc: Kees Cook
> Cc: Alexander Viro
> Cc: Andrew Morton
> Cc: Stephen Rothwell
> Signed-off-by: Daniel Vetter
> --
> Kees/Andrew,
>
> Since this is -mm can I have a stable sha1 or something for
> referencing? Or do you want to include this in the -mm patch bomb for
> the merge window?
> -Daniel
> ---
> drivers/gpu/drm/drm_property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 892ce636ef72..6ee04803c362 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -561,7 +561,7 @@ drm_property_create_blob(struct drm_device *dev, size_t
> length,
> struct drm_property_blob *blob;
> int ret;
>
> - if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
> + if (!length || length > INT_MAX - sizeof(struct drm_property_blob))
> return ERR_PTR(-EINVAL);
INT_MAX should be more than enough.
Reviewed-by: Ville Syrjälä
>
> blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
> --
> 2.24.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
On Wed, Nov 6, 2019 at 5:52 AM Andrew F. Davis wrote:
>
> On 11/5/19 11:22 PM, John Stultz wrote:
> > +unsigned int dma_heap_ioctl_cmds[] = {
> > + DMA_HEAP_IOC_ALLOC,
> > +};
> > +
> > +static long dma_heap_ioctl(struct file *file, unsigned int ucmd,
> > +unsigned long arg)
> > +{
> > + char stack_kdata[128];
> > + char *kdata = stack_kdata;
> > + unsigned int kcmd;
> > + unsigned int in_size, out_size, drv_size, ksize;
> > + int nr = _IOC_NR(ucmd);
> > + int ret = 0;
> > +
> > + if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds))
> > + return -EINVAL;
> > +
> > + /* Get the kernel ioctl cmd that matches */
> > + kcmd = dma_heap_ioctl_cmds[nr];
>
>
> Why do we need this indirection here and all the complexity below? I
> know DRM ioctl does something like this but it has a massive table,
> legacy ioctls, driver defined ioctls, etc..
>
> I don't expect we will ever need complex handling like this, could we
> switch back to the more simple handler from v13?
I agree it does add complexity, but I'm not sure I see how to avoid
some of this. The logic trying to handle that the user may pass a cmd
that has the same _IOC_NR() as DMA_HEAP_IOC_ALLOC but not the same
size. So the simple "switch(cmd) { case DMA_HEAP_IOC_ALLOC:" we had
before won't work (as the cmd will be a different value).
Thus why I thought the cleanest approach would be to use the
dma_heap_ioctl_cmds array to convert from whatever the user cmd is to
the matching kernel cmd value.
Do you have an alternative suggestion that I'm overlooking?
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/mcde: Handle pending vblank while disabling display
Disabling the display using MCDE currently results in a warning
together with a delay caused by some timeouts:
mcde a035.mcde: MCDE display is disabled
[ cut here ]
WARNING: CPU: 0 PID: 20 at drivers/gpu/drm/drm_atomic_helper.c:2258
drm_atomic_helper_commit_hw_done+0xe0/0xe4
Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
Workqueue: events drm_mode_rmfb_work_fn
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0x98)
[] (dump_stack) from [] (__warn+0xb8/0xd4)
[] (__warn) from [] (warn_slowpath_fmt+0x64/0xc4)
[] (warn_slowpath_fmt) from []
(drm_atomic_helper_commit_hw_done+0xe0/0xe4)
[] (drm_atomic_helper_commit_hw_done) from []
(drm_atomic_helper_commit_tail_rpm+0x44/0x6c)
[] (drm_atomic_helper_commit_tail_rpm) from []
(commit_tail+0x50/0x10c)
[] (commit_tail) from []
(drm_atomic_helper_commit+0xbc/0x128)
[] (drm_atomic_helper_commit) from []
(drm_framebuffer_remove+0x390/0x428)
[] (drm_framebuffer_remove) from []
(drm_mode_rmfb_work_fn+0x38/0x48)
[] (drm_mode_rmfb_work_fn) from []
(process_one_work+0x1f0/0x43c)
[] (process_one_work) from []
(worker_thread+0x254/0x55c)
[] (worker_thread) from [] (kthread+0x124/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xeb14dfb0 to 0xeb14dff8)
dfa0:
dfc0:
dfe0: 0013
---[ end trace 314909bcd4c7d50c ]---
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:crtc-0]
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:DSI-1]
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0]
flip_done timed out
The reason for this is that there is a vblank event pending, but we
never handle it after disabling the vblank interrupts.
Check if there is an vblank event pending when disabling the display,
and clear it by sending a fake vblank event in that case.
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index a3375a974caf..e59907e68854 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -949,12 +949,22 @@ static void mcde_display_disable(struct
drm_simple_display_pipe *pipe)
struct drm_crtc *crtc = >crtc;
struct drm_device *drm = crtc->dev;
struct mcde *mcde = drm->dev_private;
+ struct drm_pending_vblank_event *event;
drm_crtc_vblank_off(crtc);
/* Disable FIFO A flow */
mcde_disable_fifo(mcde, MCDE_FIFO_A, true);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+
+ spin_lock_irq(>dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, event);
+ spin_unlock_irq(>dev->event_lock);
+ }
+
dev_info(drm->dev, "MCDE display is disabled\n");
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/mcde: dsi: Make video mode errors more verbose
Triggering an error conditions in DSI video mode only results in a very generic "some video mode error status" error message at the moment. Make this more clear by adding separate error messages for each bit. Signed-off-by: Stephan Gerhold --- drivers/gpu/drm/mcde/mcde_dsi.c | 22 +- drivers/gpu/drm/mcde/mcde_dsi_regs.h | 10 ++ 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c index ffd2e0b64628..c7956c92b51b 100644 --- a/drivers/gpu/drm/mcde/mcde_dsi.c +++ b/drivers/gpu/drm/mcde/mcde_dsi.c @@ -124,7 +124,27 @@ bool mcde_dsi_irq(struct mipi_dsi_device *mdsi) val = readl(d->regs + DSI_VID_MODE_STS_FLAG); if (val) - dev_err(d->dev, "some video mode error status\n"); + dev_dbg(d->dev, "DSI_VID_MODE_STS_FLAG = %08x\n", val); + if (val & DSI_VID_MODE_STS_VSG_RUNNING) + dev_dbg(d->dev, "VID mode VSG running\n"); + if (val & DSI_VID_MODE_STS_ERR_MISSING_DATA) + dev_err(d->dev, "VID mode missing data\n"); + if (val & DSI_VID_MODE_STS_ERR_MISSING_HSYNC) + dev_err(d->dev, "VID mode missing HSYNC\n"); + if (val & DSI_VID_MODE_STS_ERR_MISSING_VSYNC) + dev_err(d->dev, "VID mode missing VSYNC\n"); + if (val & DSI_VID_MODE_STS_REG_ERR_SMALL_LENGTH) + dev_err(d->dev, "VID mode less bytes than expected between two HSYNC\n"); + if (val & DSI_VID_MODE_STS_REG_ERR_SMALL_HEIGHT) + dev_err(d->dev, "VID mode less lines than expected between two VSYNC\n"); + if (val & (DSI_VID_MODE_STS_ERR_BURSTWRITE | + DSI_VID_MODE_STS_ERR_LINEWRITE | + DSI_VID_MODE_STS_ERR_LONGREAD)) + dev_err(d->dev, "VID mode read/write error\n"); + if (val & DSI_VID_MODE_STS_ERR_VRS_WRONG_LENGTH) + dev_err(d->dev, "VID mode received packets differ from expected size\n"); + if (val & DSI_VID_MODE_STS_VSG_RECOVERY) + dev_err(d->dev, "VID mode VSG in recovery mode\n"); writel(val, d->regs + DSI_VID_MODE_STS_CLR); return te_received; diff --git a/drivers/gpu/drm/mcde/mcde_dsi_regs.h b/drivers/gpu/drm/mcde/mcde_dsi_regs.h index c9253321a3be..b03a336c235f 100644 --- a/drivers/gpu/drm/mcde/mcde_dsi_regs.h +++ b/drivers/gpu/drm/mcde/mcde_dsi_regs.h @@ -248,6 +248,16 @@ #define DSI_VID_MODE_STS 0x00BC #define DSI_VID_MODE_STS_VSG_RUNNING BIT(0) +#define DSI_VID_MODE_STS_ERR_MISSING_DATA BIT(1) +#define DSI_VID_MODE_STS_ERR_MISSING_HSYNC BIT(2) +#define DSI_VID_MODE_STS_ERR_MISSING_VSYNC BIT(3) +#define DSI_VID_MODE_STS_REG_ERR_SMALL_LENGTH BIT(4) +#define DSI_VID_MODE_STS_REG_ERR_SMALL_HEIGHT BIT(5) +#define DSI_VID_MODE_STS_ERR_BURSTWRITE BIT(6) +#define DSI_VID_MODE_STS_ERR_LINEWRITE BIT(7) +#define DSI_VID_MODE_STS_ERR_LONGREAD BIT(8) +#define DSI_VID_MODE_STS_ERR_VRS_WRONG_LENGTH BIT(9) +#define DSI_VID_MODE_STS_VSG_RECOVERY BIT(10) #define DSI_VID_VCA_SETTING1 0x00C0 #define DSI_VID_VCA_SETTING1_MAX_BURST_LIMIT_SHIFT 0 -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm/mcde: DSI video mode fixes
This is a collection of fixes to make DSI video mode work better using the MCDE driver. With these changes, MCDE appears to work properly for the video mode panel I have been testing with. Note: The patch that fixes the DSI link register setup for video mode [1] is still necessary; but we still need to finish it and actually make it initialize a panel correctly. This series contains only patches for the other parts in MCDE. I have tested it by disabling most of the register setup in the DSI driver, which makes it re-use the properly working DSI register set by the bootloader. [1]: https://lists.freedesktop.org/archives/dri-devel/2019-October/238175.html Stephan Gerhold (7): drm/mcde: Provide vblank handling unconditionally drm/mcde: Fix frame sync setup for video mode panels drm/mcde: dsi: Make video mode errors more verbose drm/mcde: dsi: Delay start of video stream generator drm/mcde: dsi: Fix duplicated DSI connector drm/mcde: dsi: Enable clocks in pre_enable() instead of mode_set() drm/mcde: Handle pending vblank while disabling display drivers/gpu/drm/mcde/mcde_display.c | 57 + drivers/gpu/drm/mcde/mcde_drm.h | 1 + drivers/gpu/drm/mcde/mcde_drv.c | 18 +-- drivers/gpu/drm/mcde/mcde_dsi.c | 167 +-- drivers/gpu/drm/mcde/mcde_dsi_regs.h | 10 ++ 5 files changed, 126 insertions(+), 127 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/mcde: dsi: Fix duplicated DSI connector
Using a (single) DSI display with MCDE currently results in
two "connected" connectors:
Connector: DSI-1
id : 34
encoder id : 0
conn : connected
size : 0x0 (mm)
count_modes: 0
count_props: 5
props : 1 2 5 6 4
count_encoders : 1
encoders : 33
Connector: DSI-2
id : 35
encoder id : 33
conn : connected
size : 53x89 (mm)
count_modes: 1
count_props: 5
props : 1 2 5 6 4
count_encoders : 1
encoders : 33
Mode: "480x800" 480x800 60
Although both show up as connected, the first one does not have
any size and no available modes. This confuses userspace tools
(e.g. kmscube) who look for available modes for the first connector.
The reason for the duplicated connector is that mcde_dsi.c and the
DRM panel bridge helper both set up a DSI connector, with more or less
the same code. The connector set up by the DRM panel bridge is the
one that is correctly set up in the example above.
Therefore we can just remove the connector setup from mcde_dsi.c
and let the DRM core handle all the hard work.
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_dsi.c | 52 +
1 file changed, 1 insertion(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 4710f23b2966..df963e078c35 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -39,7 +39,6 @@ struct mcde_dsi {
struct device *dev;
struct mcde *mcde;
struct drm_bridge bridge;
- struct drm_connector connector;
struct drm_panel *panel;
struct drm_bridge *bridge_out;
struct mipi_dsi_host dsi_host;
@@ -64,11 +63,6 @@ static inline struct mcde_dsi *host_to_mcde_dsi(struct
mipi_dsi_host *h)
return container_of(h, struct mcde_dsi, dsi_host);
}
-static inline struct mcde_dsi *connector_to_mcde_dsi(struct drm_connector *c)
-{
- return container_of(c, struct mcde_dsi, connector);
-}
-
bool mcde_dsi_irq(struct mipi_dsi_device *mdsi)
{
struct mcde_dsi *d;
@@ -843,67 +837,23 @@ static void mcde_dsi_bridge_disable(struct drm_bridge
*bridge)
clk_disable_unprepare(d->lp_clk);
}
-/*
- * This connector needs no special handling, just use the default
- * helpers for everything. It's pretty dummy.
- */
-static const struct drm_connector_funcs mcde_dsi_connector_funcs = {
- .reset = drm_atomic_helper_connector_reset,
- .fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = drm_connector_cleanup,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static int mcde_dsi_get_modes(struct drm_connector *connector)
-{
- struct mcde_dsi *d = connector_to_mcde_dsi(connector);
-
- /* Just pass the question to the panel */
- if (d->panel)
- return drm_panel_get_modes(d->panel);
-
- /* TODO: deal with bridges */
-
- return 0;
-}
-
-static const struct drm_connector_helper_funcs
-mcde_dsi_connector_helper_funcs = {
- .get_modes = mcde_dsi_get_modes,
-};
-
static int mcde_dsi_bridge_attach(struct drm_bridge *bridge)
{
struct mcde_dsi *d = bridge_to_mcde_dsi(bridge);
struct drm_device *drm = bridge->dev;
int ret;
- drm_connector_helper_add(>connector,
-_dsi_connector_helper_funcs);
-
if (!drm_core_check_feature(drm, DRIVER_ATOMIC)) {
dev_err(d->dev, "we need atomic updates\n");
return -ENOTSUPP;
}
- ret = drm_connector_init(drm, >connector,
-_dsi_connector_funcs,
-DRM_MODE_CONNECTOR_DSI);
- if (ret) {
- dev_err(d->dev, "failed to initialize DSI bridge connector\n");
- return ret;
- }
- d->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
- /* The encoder in the bridge attached to the DSI bridge */
- drm_connector_attach_encoder(>connector, bridge->encoder);
- /* Then we attach the DSI bridge to the output (panel etc) bridge */
+ /* Attach the DSI bridge to the output (panel etc) bridge */
ret = drm_bridge_attach(bridge->encoder, d->bridge_out, bridge);
if (ret) {
dev_err(d->dev, "failed to attach the DSI bridge\n");
return ret;
}
- d->connector.status = connector_status_connected;
return 0;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/mcde: dsi: Enable clocks in pre_enable() instead of mode_set()
The DSI initialization sequence incorrectly assumes that the mode_set()
function of the DRM bridge is always called when (re-)enabling the display.
This is not necessarily the case.
Keeping the device idle in the framebuffer console for a while results
in the display being turned off using the disable() function. However,
as soon as any key is pressed only (pre_)enable() are called.
mode_set() is skipped because the mode has not been changed.
In this case, the DSI HS/LP clocks are never turned back on,
preventing the display from working.
Fix this by moving a part of the initialization sequence from
mode_set() to pre_enable(). Keep most of the video mode setup in
mode_set() since most of the registers are only dependent on the mode
that is set for the panel - there is no need to write them again each
time we re-enable the display.
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_dsi.c | 67 ++---
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index df963e078c35..03896a1f339a 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -562,21 +562,6 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
DSI_VID_VCA_SETTING2_EXACT_BURST_LIMIT_SHIFT;
writel(val, d->regs + DSI_VID_VCA_SETTING2);
- /* Put IF1 into video mode */
- val = readl(d->regs + DSI_MCTL_MAIN_DATA_CTL);
- val |= DSI_MCTL_MAIN_DATA_CTL_IF1_MODE;
- writel(val, d->regs + DSI_MCTL_MAIN_DATA_CTL);
-
- /* Disable command mode on IF1 */
- val = readl(d->regs + DSI_CMD_MODE_CTL);
- val &= ~DSI_CMD_MODE_CTL_IF1_LP_EN;
- writel(val, d->regs + DSI_CMD_MODE_CTL);
-
- /* Enable some error interrupts */
- val = readl(d->regs + DSI_VID_MODE_STS_CTL);
- val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_VSYNC;
- val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_DATA;
- writel(val, d->regs + DSI_VID_MODE_STS_CTL);
}
static void mcde_dsi_start(struct mcde_dsi *d)
@@ -700,26 +685,13 @@ static void mcde_dsi_bridge_enable(struct drm_bridge
*bridge)
dev_info(d->dev, "enable DSI master\n");
};
-static void mcde_dsi_bridge_mode_set(struct drm_bridge *bridge,
-const struct drm_display_mode *mode,
-const struct drm_display_mode *adj)
+static void mcde_dsi_bridge_pre_enable(struct drm_bridge *bridge)
{
struct mcde_dsi *d = bridge_to_mcde_dsi(bridge);
- unsigned long pixel_clock_hz = mode->clock * 1000;
unsigned long hs_freq, lp_freq;
u32 val;
int ret;
- if (!d->mdsi) {
- dev_err(d->dev, "no DSI device attached to encoder!\n");
- return;
- }
-
- dev_info(d->dev, "set DSI master to %dx%d %lu Hz %s mode\n",
-mode->hdisplay, mode->vdisplay, pixel_clock_hz,
-(d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO) ? "VIDEO" : "CMD"
- );
-
/* Copy maximum clock frequencies */
if (d->mdsi->lp_rate)
lp_freq = d->mdsi->lp_rate;
@@ -758,7 +730,21 @@ static void mcde_dsi_bridge_mode_set(struct drm_bridge
*bridge,
d->hs_freq);
if (d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
- mcde_dsi_setup_video_mode(d, mode);
+ /* Put IF1 into video mode */
+ val = readl(d->regs + DSI_MCTL_MAIN_DATA_CTL);
+ val |= DSI_MCTL_MAIN_DATA_CTL_IF1_MODE;
+ writel(val, d->regs + DSI_MCTL_MAIN_DATA_CTL);
+
+ /* Disable command mode on IF1 */
+ val = readl(d->regs + DSI_CMD_MODE_CTL);
+ val &= ~DSI_CMD_MODE_CTL_IF1_LP_EN;
+ writel(val, d->regs + DSI_CMD_MODE_CTL);
+
+ /* Enable some error interrupts */
+ val = readl(d->regs + DSI_VID_MODE_STS_CTL);
+ val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_VSYNC;
+ val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_DATA;
+ writel(val, d->regs + DSI_VID_MODE_STS_CTL);
} else {
/* Command mode, clear IF1 ID */
val = readl(d->regs + DSI_CMD_MODE_CTL);
@@ -772,6 +758,26 @@ static void mcde_dsi_bridge_mode_set(struct drm_bridge
*bridge,
}
}
+static void mcde_dsi_bridge_mode_set(struct drm_bridge *bridge,
+const struct drm_display_mode *mode,
+const struct drm_display_mode *adj)
+{
+ struct mcde_dsi *d = bridge_to_mcde_dsi(bridge);
+
+ if (!d->mdsi) {
+ dev_err(d->dev, "no DSI device attached to encoder!\n");
+ return;
+ }
+
+ dev_info(d->dev, "set DSI master to %dx%d %u Hz %s mode\n",
+mode->hdisplay, mode->vdisplay, mode->clock * 1000,
+(d->mdsi->mode_flags &
[PATCH 1/7] drm/mcde: Provide vblank handling unconditionally
At the moment, vblank handling is only enabled together with
TE synchronization. However, the vblank IRQ is also working with
on displays without TE synchronization (e.g. DSI video mode panels).
It seems like the vblank IRQ is actually generated by the
MCDE hardware for the channel.
Therefore, the vblank handling should be working correctly in
all the cases and we can enable it unconditionally.
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_display.c | 15 +--
drivers/gpu/drm/mcde/mcde_drv.c | 16
2 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 751454ae3cd1..65522481b367 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -934,10 +934,10 @@ static void mcde_display_enable(struct
drm_simple_display_pipe *pipe,
val = readl(mcde->regs + MCDE_CRC);
val |= MCDE_CRC_SYCEN0;
writel(val, mcde->regs + MCDE_CRC);
-
- drm_crtc_vblank_on(crtc);
}
+ drm_crtc_vblank_on(crtc);
+
dev_info(drm->dev, "MCDE display is enabled\n");
}
@@ -947,8 +947,7 @@ static void mcde_display_disable(struct
drm_simple_display_pipe *pipe)
struct drm_device *drm = crtc->dev;
struct mcde *mcde = drm->dev_private;
- if (mcde->te_sync)
- drm_crtc_vblank_off(crtc);
+ drm_crtc_vblank_off(crtc);
/* Disable FIFO A flow */
mcde_disable_fifo(mcde, MCDE_FIFO_A, true);
@@ -1097,6 +1096,8 @@ static struct drm_simple_display_pipe_funcs
mcde_display_funcs = {
.enable = mcde_display_enable,
.disable = mcde_display_disable,
.update = mcde_display_update,
+ .enable_vblank = mcde_display_enable_vblank,
+ .disable_vblank = mcde_display_disable_vblank,
.prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
};
@@ -1123,12 +1124,6 @@ int mcde_display_init(struct drm_device *drm)
DRM_FORMAT_YUV422,
};
- /* Provide vblank only when we have TE enabled */
- if (mcde->te_sync) {
- mcde_display_funcs.enable_vblank = mcde_display_enable_vblank;
- mcde_display_funcs.disable_vblank = mcde_display_disable_vblank;
- }
-
ret = drm_simple_display_pipe_init(drm, >pipe,
_display_funcs,
formats, ARRAY_SIZE(formats),
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 5649887d2b90..0ccd3b0308c2 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -179,18 +179,10 @@ static int mcde_modeset_init(struct drm_device *drm)
mode_config->min_height = 1;
mode_config->max_height = 1080;
- /*
-* Currently we only support vblank handling on the DSI bridge, using
-* TE synchronization. If TE sync is not set up, it is still possible
-* to push out a single update on demand, but this is hard for DRM to
-* exploit.
-*/
- if (mcde->te_sync) {
- ret = drm_vblank_init(drm, 1);
- if (ret) {
- dev_err(drm->dev, "failed to init vblank\n");
- goto out_config;
- }
+ ret = drm_vblank_init(drm, 1);
+ if (ret) {
+ dev_err(drm->dev, "failed to init vblank\n");
+ goto out_config;
}
ret = mcde_display_init(drm);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/mcde: Fix frame sync setup for video mode panels
The MCDE driver differentiates only between "te_sync"
(for hardware TE0 sync) and software sync
(i.e. manually triggered updates) at the moment.
However, none of these options work correctly for video mode panels.
Therefore, we need to make some changes to make them work correctly:
- Select hardware sync coming from the (DSI) formatter.
- Keep the FIFO permanently enabled (otherwise MCDE will stop
feeding data to the panel).
- Skip manual software sync (this is not necessary in video mode).
Automatically detect if the connected panel is using video mode
and enable the necessary changes in that case.
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_display.c | 32 -
drivers/gpu/drm/mcde/mcde_drm.h | 1 +
drivers/gpu/drm/mcde/mcde_drv.c | 2 --
drivers/gpu/drm/mcde/mcde_dsi.c | 13 ++--
4 files changed, 30 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_display.c
b/drivers/gpu/drm/mcde/mcde_display.c
index 65522481b367..a3375a974caf 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -498,24 +498,20 @@ static void mcde_configure_channel(struct mcde *mcde,
enum mcde_channel ch,
}
/* Set up channel 0 sync (based on chnl_update_registers()) */
- if (mcde->te_sync) {
- /*
-* Turn on hardware TE0 synchronization
-*/
+ if (mcde->video_mode || mcde->te_sync)
val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_HARDWARE
<< MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
- val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0
- << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
- } else {
- /*
-* Set up sync source to software, out sync formatter
-* Code mostly from mcde_hw.c chnl_update_registers()
-*/
+ else
val = MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SOFTWARE
<< MCDE_CHNLXSYNCHMOD_SRC_SYNCH_SHIFT;
+
+ if (mcde->te_sync)
+ val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_TE0
+ << MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
+ else
val |= MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_FORMATTER
<< MCDE_CHNLXSYNCHMOD_OUT_SYNCH_SRC_SHIFT;
- }
+
writel(val, mcde->regs + sync);
/* Set up pixels per line and lines per frame */
@@ -938,6 +934,13 @@ static void mcde_display_enable(struct
drm_simple_display_pipe *pipe,
drm_crtc_vblank_on(crtc);
+ if (mcde->video_mode)
+ /*
+* Keep FIFO permanently enabled in video mode,
+* otherwise MCDE will stop feeding data to the panel.
+*/
+ mcde_enable_fifo(mcde, MCDE_FIFO_A);
+
dev_info(drm->dev, "MCDE display is enabled\n");
}
@@ -1047,8 +1050,9 @@ static void mcde_display_update(struct
drm_simple_display_pipe *pipe,
*/
if (fb) {
mcde_set_extsrc(mcde, drm_fb_cma_get_gem_addr(fb, pstate, 0));
- /* Send a single frame using software sync */
- mcde_display_send_one_frame(mcde);
+ if (!mcde->video_mode)
+ /* Send a single frame using software sync */
+ mcde_display_send_one_frame(mcde);
dev_info_once(mcde->dev, "sent first display update\n");
} else {
/*
diff --git a/drivers/gpu/drm/mcde/mcde_drm.h b/drivers/gpu/drm/mcde/mcde_drm.h
index dab4db021231..80edd6628979 100644
--- a/drivers/gpu/drm/mcde/mcde_drm.h
+++ b/drivers/gpu/drm/mcde/mcde_drm.h
@@ -19,6 +19,7 @@ struct mcde {
struct mipi_dsi_device *mdsi;
s16 stride;
bool te_sync;
+ bool video_mode;
bool oneshot_mode;
unsigned int flow_active;
spinlock_t flow_lock; /* Locks the channel flow control */
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index 0ccd3b0308c2..9008ddcfc528 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -331,8 +331,6 @@ static int mcde_probe(struct platform_device *pdev)
drm->dev_private = mcde;
platform_set_drvdata(pdev, drm);
- /* Enable use of the TE signal and interrupt */
- mcde->te_sync = true;
/* Enable continuous updates: this is what Linux' framebuffer expects */
mcde->oneshot_mode = false;
drm->dev_private = mcde;
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index d6214d3c8b33..ffd2e0b64628 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -130,6 +130,15 @@ bool mcde_dsi_irq(struct mipi_dsi_device *mdsi)
return te_received;
}
+static void mcde_dsi_attach_to_mcde(struct mcde_dsi *d)
+{
+ d->mcde->mdsi = d->mdsi;
+
+ d->mcde->video_mode =
[PATCH 4/7] drm/mcde: dsi: Delay start of video stream generator
The initialization order for DSI video mode is important - if we
enable the video stream generator (VSG) before the MCDE DSI formatter
starts sending pixel data, it will immediately run into an error and
disable itself again.
Avoid this problem by delaying the activation of the VSG
until the MCDE DSI formatter is properly set up and running
(i.e. when mcde_dsi_bridge_enable() is called).
Signed-off-by: Stephan Gerhold
---
drivers/gpu/drm/mcde/mcde_dsi.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index c7956c92b51b..4710f23b2966 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -583,11 +583,6 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_VSYNC;
val |= DSI_VID_MODE_STS_CTL_ERR_MISSING_DATA;
writel(val, d->regs + DSI_VID_MODE_STS_CTL);
-
- /* Enable video mode */
- val = readl(d->regs + DSI_MCTL_MAIN_DATA_CTL);
- val |= DSI_MCTL_MAIN_DATA_CTL_VID_EN;
- writel(val, d->regs + DSI_MCTL_MAIN_DATA_CTL);
}
static void mcde_dsi_start(struct mcde_dsi *d)
@@ -699,6 +694,14 @@ static void mcde_dsi_start(struct mcde_dsi *d)
static void mcde_dsi_bridge_enable(struct drm_bridge *bridge)
{
struct mcde_dsi *d = bridge_to_mcde_dsi(bridge);
+ u32 val;
+
+ if (d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
+ /* Enable video mode */
+ val = readl(d->regs + DSI_MCTL_MAIN_DATA_CTL);
+ val |= DSI_MCTL_MAIN_DATA_CTL_VID_EN;
+ writel(val, d->regs + DSI_MCTL_MAIN_DATA_CTL);
+ }
dev_info(d->dev, "enable DSI master\n");
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo wrote:
>
> On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> >
> > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney wrote:
> > >
> > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > wrote:
> > > > > The 'pp done time out' errors go away if I revert the following three
> > > > > commits:
> > > > >
> > > > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > > > 2d99ced787e3 ("drm/msm: async commit support")
> > > > >
> > > > > I reverted the first one to fix a compiler error, and the second one
> > > > > so
> > > > > that the last patch can be reverted without any merge conflicts.
> > > > >
> > > > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > > > > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > > > > buffer dance around the screen like its out of sync. I renamed
> > > > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > > > > declaration. Here's the relevant part of what I tried:
> > > > >
> > > > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms
> > > > > *kms, struct drm_atomic_state *st
> > > > >
> > > > > static void mdp5_flush_commit(struct msm_kms *kms, unsigned
> > > > > crtc_mask)
> > > > > {
> > > > > - /* TODO */
> > > > > + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > > > > + struct drm_crtc *crtc;
> > > > > +
> > > > > + for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > > > + if (!crtc->state->active)
> > > > > + continue;
> > > > > +
> > > > > + mdp5_crtc_flush_all(crtc);
> > > > > + }
> > > > > }
> > > > >
> > > > > Any tips would be appreciated.
> > > >
> > > >
> > > > I think this is along the lines of what we need to enable async commit
> > > > for mdp5 (but also removing the flush from the atomic-commit path)..
> > > > the principle behind the async commit is to do all the atomic state
> > > > commit normally, but defer writing the flush bits. This way, if you
> > > > get another async update before the next vblank, you just apply it
> > > > immediately instead of waiting for vblank.
> > > >
> > > > But I guess you are on a command mode panel, if I remember? Which is
> > > > a case I didn't have a way to test. And I'm not entirely about how
> > > > kms_funcs->vsync_time() should be implemented for cmd mode panels.
> > >
> > > Yes, this is a command-mode panel and there's no hardware frame counter
> > > available. The key to getting the display working on this phone was this
> > > patch:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > >
> > > > That all said, I think we should first fix what is broken, before
> > > > worrying about extending async commit support to mdp5.. which
> > > > shouldn't hit the async==true path, due to not implementing
> > > > kms_funcs->vsync_time().
> > > >
> > > > What I think is going on is that, in the cmd mode case,
> > > > mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> > > > which waits for a pp-done irq regardless of whether there is a flush
> > > > in progress. Since there is no flush pending, the irq never comes.
> > > > But the expectation is that kms_funcs->wait_flush() returns
> > > > immediately if there is nothing to wait for.
> > >
> > > I don't think that's happening in this case. I added some pr_info()
> > > statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> > > Here's the first two sets of messages that appear in dmesg:
> > >
> > > [ 14.018907] msm fd90.mdss: pp done time out, lm=0
> > > [ 14.018993] request_pp_done_pending: HERE
> > > [ 14.074208] mdp5_crtc_pp_done_irq: HERE
> > > [ 14.074368] Console: switching to colour frame buffer device 135x120
> > > [ 14.138938] msm fd90.mdss: pp done time out, lm=0
> > > [ 14.139021] request_pp_done_pending: HERE
> > > [ 14.158097] mdp5_crtc_pp_done_irq: HERE
> > >
> > > The messages go on like this with the same pattern.
> > >
> > > I tried two different changes:
> > >
> > > 1) I moved the request_pp_done_pending() and corresponding if statement
> > >from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
> > >
> > > 2) I increased the timeout in wait_for_completion_timeout() by several
> > >increments; all the way to 5 seconds.
> >
> > increasing the timeout won't help, because the pp-done irq has already
> > come at the point where we wait for it..
> >
> > maybe the easy thing is just add mdp5_crtc->needs_pp, set to true
> > before requesting, and false when we get the irq.. and then
> > mdp5_crtc_wait_for_pp_done() just returns if needs_pp==false..
>
>
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
On Tue, Nov 5, 2019 at 1:47 AM Daniel Vetter wrote: > > On Mon, Nov 04, 2019 at 11:34:33AM -0800, Yiwei Zhang wrote: > > Hi folks, > > > > (Daniel, I just moved you to this thread) > > > > Below are the latest thoughts based on all the feedback and comments. > > > > First, I need to clarify on the gpu memory object type enumeration > > thing. We don't want to enforce those enumerations across the upstream > > and Android, and we should just leave those configurable and flexible. > > > > Second, to make this effort also useful to all the other memory > > management tools like PSS. At least an additional node is needed for > > the part of the gpu private allocation not mapped to the > > userspace(invisible to PSS). This is especially critical for the > > downstream Android so that low-memory-killer(lmkd) can be aware of the > > actual total memory for a process and will know how much gets freed up > > if it kills that process. This is an effort to de-mystify the "lost > > ram". > > > > Given above, the new node structure would look like below: > > > > Global nodes: > > /sys/devices//gpu_mem/global/total /* Total private allocation > > for coherency, this should also include the anonymous memory allocated > > in the kmd */ > > /sys/devices//gpu_mem/global/total_unmapped /* Account for the > > private allocation not mapped to userspace(not visible for PSS), don't > > need to be coherent with the "total" node. lmkd or equivalent service > > looking at PSS will only look at this node in addition. */ > > /sys/devices//gpu_mem/global/ /* One total value per > > type, this should also include the anonymous memory allocated in the > > kmd(or maybe another anonymous type for global nodes) */ > > /sys/devices//gpu_mem/global/ /* One total value per type */ > > ... > > /sys/devices//gpu_mem/global/ /* One total value per type */ > > > > Per process nodes: > > /sys/devices//gpu_mem/proc//total /* Total private > > allocation for coherency */ > > /sys/devices//gpu_mem/proc//total_unmapped /* Account for > > the private allocation not mapped to userspace(not visible for PSS), > > don't need to be coherent with the "total" node. lmkd or equivalent > > service looking at PSS will only look at this node in addition. */ > > /sys/devices//gpu_mem/proc// /* One total value per type > > */ > > /sys/devices//gpu_mem/proc// /* One total value per type > > */ > > ... > > /sys/devices//gpu_mem/proc// /* One total value per type > > */ > > > > The type1 to typeN for downstream Android will be the enumerations I > > mentioned in the original email which are: unknown, shader,..., > > transient. For the upstream, those can be the labeled BOs or any other > > customized types. > > > > Look forward to the comments and feedback! > > I don't think this will work well, at least for upstream: > > - The labels are currently free-form, baking them back into your structure > would mean we'd need to do lots of hot add/remove of sysfs directory > trees. Which sounds like a real bad idea :-/ also, a bo's label can change over time if it is re-used for a different purpose.. not sure what the overhead is for add/remove sysfs, but I don't think I want that overhead in the bo_reuse path (maybe that matters less for vk, where we aren't using a userspace bo cache) BR, -R > - Buffer objects aren't attached to pids, but files. And files can be > shared. If we want to list this somewhere outside of debugfs, we need to > tie this into the files somehow (so proc), except the underlying files > are all anon inodes, so this gets really tricky I think to make work > well. > > Cheers, Daniel > > > > > Best regards, > > Yiwei > > > > > > > > > > On Fri, Nov 1, 2019 at 1:37 AM Pekka Paalanen wrote: > > > > > > On Thu, 31 Oct 2019 13:57:00 -0400 > > > Kenny Ho wrote: > > > > > > > Hi Yiwei, > > > > > > > > This is the latest series: > > > > https://patchwork.kernel.org/cover/11120371/ > > > > > > > > (I still need to reply some of the feedback.) > > > > > > > > Regards, > > > > Kenny > > > > > > > > On Thu, Oct 31, 2019 at 12:59 PM Yiwei Zhang wrote: > > > > > > > > > > Hi Kenny, > > > > > > > > > > Thanks for the info. Do you mind forwarding the existing discussion > > > > > to me or have me cc'ed in that thread? > > > > > > > > > > Best, > > > > > Yiwei > > > > > > > > > > On Wed, Oct 30, 2019 at 10:23 PM Kenny Ho wrote: > > > > >> > > > > >> Hi Yiwei, > > > > >> > > > > >> I am not sure if you are aware, there is an ongoing RFC on adding drm > > > > >> support in cgroup for the purpose of resource tracking. One of the > > > > >> resource is GPU memory. It's not exactly the same as what you are > > > > >> proposing (it doesn't track API usage, but it tracks the type of GPU > > > > >> memory from kmd perspective) but perhaps it would be of interest to > > > > >> you. There are no consensus on it at this point. > > > > > > Hi Yiwei, > > > > > > I'd like to point out an effort to have drivers label BOs for debugging > > > purposes: > >
[PATCH] drm: Limit to INT_MAX in create_blob ioctl
The hardened usercpy code is too paranoid ever since:
commit 6a30afa8c1fbde5f10f9c584c2992aa3c7f7a8fe
Author: Kees Cook
Date: Wed Nov 6 16:07:01 2019 +1100
uaccess: disallow > INT_MAX copy sizes
Code itself should have been fine as-is.
Reported-by: syzbot+fb77e97ebf0612ee6...@syzkaller.appspotmail.com
Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes")
Cc: Kees Cook
Cc: Alexander Viro
Cc: Andrew Morton
Cc: Stephen Rothwell
Signed-off-by: Daniel Vetter
--
Kees/Andrew,
Since this is -mm can I have a stable sha1 or something for
referencing? Or do you want to include this in the -mm patch bomb for
the merge window?
-Daniel
---
drivers/gpu/drm/drm_property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 892ce636ef72..6ee04803c362 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -561,7 +561,7 @@ drm_property_create_blob(struct drm_device *dev, size_t
length,
struct drm_property_blob *blob;
int ret;
- if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob))
+ if (!length || length > INT_MAX - sizeof(struct drm_property_blob))
return ERR_PTR(-EINVAL);
blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL);
--
2.24.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm: imx: Add i.MX 6 MIPI DSI host driver
This adds support for the Synopsis DesignWare MIPI DSI v1.01 host
controller which is embedded in i.MX 6 SoCs.
Based on following patches, but updated/extended to work with existing
support found in the kernel:
- drm: imx: Support Synopsys DesignWare MIPI DSI host controller
Signed-off-by: Liu Ying
- ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
Signed-off-by: Liu Ying
Reviewed-by: Neil Armstrong
Reviewed-by: Emil Velikov
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 146 ++-
drivers/gpu/drm/imx/Kconfig | 7 +
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 378 ++
4 files changed, 523 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index a0637328fbc1..d88363cc2681 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -31,6 +31,8 @@
#include
#define HWVER_131 0x31333100 /* IP version 1.31 */
+#define HWVER_130 0x31333000 /* IP version 1.30 */
+#define HWVER_101 0x31303000 /* IP version 1.01 */
#define DSI_VERSION0x00
#define VERSIONGENMASK(31, 8)
@@ -99,6 +101,25 @@
#define DSI_EDPI_CMD_SIZE 0x64
#define DSI_CMD_MODE_CFG 0x68
+
+#define DSI_DPI_CFG0x0c
+#define DSI_TMR_LINE_CFG 0x28
+#define DSI_VTIMING_CFG0x2c
+#define DSI_PHY_TMR_CFG_V101 0x30
+#define DSI_PHY_IF_CFG_V1010x58
+#define DSI_PHY_IF_CTRL0x5c
+#define DSI_PHY_RSTZ_V101 0x54
+#define DSI_PHY_STATUS_V1010x60
+#define DSI_PHY_TST_CTRL0_V101 0x64
+#define DSI_GEN_HDR_V101 0x34
+#define DSI_GEN_PLD_DATA_V101 0x38
+#define DSI_CMD_MODE_CFG_V101 0x24
+#define DSI_CMD_PKT_STATUS_V1010x3c
+#define DSI_VID_PKT_CFG0x20
+#define DSI_VID_MODE_CFG_V101 0x1c
+#define DSI_TO_CNT_CFG_V1010x40
+#define DSI_PCKHDL_CFG_V1010x18
+
#define MAX_RD_PKT_SIZE_LP BIT(24)
#define DCS_LW_TX_LP BIT(19)
#define DCS_SR_0P_TX_LPBIT(18)
@@ -126,6 +147,33 @@
GEN_SW_1P_TX_LP | \
GEN_SW_0P_TX_LP)
+#define EN_TEAR_FX_V101BIT(14)
+#define DCS_LW_TX_LP_V101 BIT(12)
+#define GEN_LW_TX_LP_V101 BIT(11)
+#define MAX_RD_PKT_SIZE_LP_V101BIT(10)
+#define DCS_SW_2P_TX_LP_V101 BIT(9)
+#define DCS_SW_1P_TX_LP_V101 BIT(8)
+#define DCS_SW_0P_TX_LP_V101 BIT(7)
+#define GEN_SR_2P_TX_LP_V101 BIT(6)
+#define GEN_SR_1P_TX_LP_V101 BIT(5)
+#define GEN_SR_0P_TX_LP_V101 BIT(4)
+#define GEN_SW_2P_TX_LP_V101 BIT(3)
+#define GEN_SW_1P_TX_LP_V101 BIT(2)
+#define GEN_SW_0P_TX_LP_V101 BIT(1)
+
+#define CMD_MODE_ALL_LP_V101 (DCS_LW_TX_LP_V101 | \
+GEN_LW_TX_LP_V101 | \
+MAX_RD_PKT_SIZE_LP_V101 | \
+DCS_SW_2P_TX_LP_V101 | \
+DCS_SW_1P_TX_LP_V101 | \
+DCS_SW_0P_TX_LP_V101 | \
+GEN_SR_2P_TX_LP_V101 | \
+GEN_SR_1P_TX_LP_V101 | \
+GEN_SR_0P_TX_LP_V101 | \
+GEN_SW_2P_TX_LP_V101 | \
+GEN_SW_1P_TX_LP_V101 | \
+GEN_SW_0P_TX_LP_V101)
+
#define DSI_GEN_HDR0x6c
#define DSI_GEN_PLD_DATA 0x70
@@ -164,6 +212,11 @@
#define DSI_INT_MSK0 0xc4
#define DSI_INT_MSK1 0xc8
+#define DSI_ERROR_ST0_V101 0x44
+#define DSI_ERROR_ST1_V101 0x48
+#define DSI_ERROR_MSK0_V1010x4c
+#define DSI_ERROR_MSK1_V1010x50
+
#define DSI_PHY_TMR_RD_CFG 0xf4
#define PHY_STATUS_TIMEOUT_US 1
@@ -357,6 +410,49 @@ static struct dw_mipi_dsi_variant
dw_mipi_dsi_v130_v131_layout = {
.cfg_gen_payload = REG_FIELD(DSI_GEN_PLD_DATA, 0, 31),
};
+static struct dw_mipi_dsi_variant dw_mipi_dsi_v101_layout = {
+ .cfg_dpi_vid = REG_FIELD(DSI_DPI_CFG, 0, 1),
+ .cfg_dpi_color_coding =
[PATCH v2 2/4] drm: bridge: dw_mipi_dsi: abstract register access using reg_fields
Register existence, address/offsets, field layouts, reserved bits and so on differ between MIPI-DSI versions and between SoC vendor boards. Despite these differences the hw IP and protocols are mostly the same so the generic driver can be made to compensate these differences. The current Rockchip and STM drivers hardcoded a lot of their common definitions in the bridge code because they're based on DSI v1.30 and 1.31 which are relatively close, but in order to support older/future versions with more diverging layouts like the v1.01 present on imx6, we abstract some of the register accesses via the regmap field APIs. The bridge detects the DSI core version and initializes the required regmap register layout, so platform drivers will continue to use the regmap as before. Other DSI versions / register layouts can easily be added in the future by only changing the bridge code. An additional benefit of using the reg_field API is that much of the bit-shifting and masking boilerplate is removed because it's now handled automatically by the regmap subsystem. Not all register accesses have been converted: only the minimum diff between the three host controller versions supported by the current vendor platform drivers (rockchip, stm and now imx), more can be added in the future as needed. Suggested-by: Boris Brezillon Reviewed-by: Neil Armstrong Reviewed-by: Emil Velikov Signed-off-by: Adrian Ratiu --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 504 -- 1 file changed, 346 insertions(+), 158 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 6cb57807f3f9..a0637328fbc1 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -47,7 +47,6 @@ #define DPI_VCID(vcid) ((vcid) & 0x3) #define DSI_DPI_COLOR_CODING 0x10 -#define LOOSELY18_EN BIT(8) #define DPI_COLOR_CODING_16BIT_1 0x0 #define DPI_COLOR_CODING_16BIT_2 0x1 #define DPI_COLOR_CODING_16BIT_3 0x2 @@ -56,11 +55,6 @@ #define DPI_COLOR_CODING_24BIT 0x5 #define DSI_DPI_CFG_POL0x14 -#define COLORM_ACTIVE_LOW BIT(4) -#define SHUTD_ACTIVE_LOW BIT(3) -#define HSYNC_ACTIVE_LOW BIT(2) -#define VSYNC_ACTIVE_LOW BIT(1) -#define DATAEN_ACTIVE_LOW BIT(0) #define DSI_DPI_LP_CMD_TIM 0x18 #define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) @@ -81,27 +75,19 @@ #define DSI_GEN_VCID 0x30 #define DSI_MODE_CFG 0x34 -#define ENABLE_VIDEO_MODE 0 -#define ENABLE_CMD_MODEBIT(0) #define DSI_VID_MODE_CFG 0x38 -#define ENABLE_LOW_POWER (0x3f << 8) -#define ENABLE_LOW_POWER_MASK (0x3f << 8) +#define ENABLE_LOW_POWER 0x3f + #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0 #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1 #define VID_MODE_TYPE_BURST0x2 -#define VID_MODE_TYPE_MASK 0x3 -#define VID_MODE_VPG_ENABLEBIT(16) -#define VID_MODE_VPG_HORIZONTALBIT(24) #define DSI_VID_PKT_SIZE 0x3c -#define VID_PKT_SIZE(p)((p) & 0x3fff) #define DSI_VID_NUM_CHUNKS 0x40 -#define VID_NUM_CHUNKS(c) ((c) & 0x1fff) #define DSI_VID_NULL_SIZE 0x44 -#define VID_NULL_SIZE(b) ((b) & 0x1fff) #define DSI_VID_HSA_TIME 0x48 #define DSI_VID_HBP_TIME 0x4c @@ -125,7 +111,6 @@ #define GEN_SW_2P_TX_LPBIT(10) #define GEN_SW_1P_TX_LPBIT(9) #define GEN_SW_0P_TX_LPBIT(8) -#define ACK_RQST_ENBIT(1) #define TEAR_FX_EN BIT(0) #define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \ @@ -154,8 +139,6 @@ #define GEN_CMD_EMPTY BIT(0) #define DSI_TO_CNT_CFG 0x78 -#define HSTX_TO_CNT(p) (((p) & 0x) << 16) -#define LPRX_TO_CNT(p) ((p) & 0x) #define DSI_HS_RD_TO_CNT 0x7c #define DSI_LP_RD_TO_CNT 0x80 @@ -164,52 +147,17 @@ #define DSI_BTA_TO_CNT 0x8c #define DSI_LPCLK_CTRL 0x94 -#define AUTO_CLKLANE_CTRL BIT(1) -#define PHY_TXREQUESTCLKHS BIT(0) - #define DSI_PHY_TMR_LPCLK_CFG 0x98 -#define PHY_CLKHS2LP_TIME(lbcc)(((lbcc) & 0x3ff) << 16) -#define PHY_CLKLP2HS_TIME(lbcc)((lbcc) & 0x3ff) - #define DSI_PHY_TMR_CFG0x9c -#define PHY_HS2LP_TIME(lbcc) (((lbcc) & 0xff) << 24) -#define PHY_LP2HS_TIME(lbcc) (((lbcc) & 0xff) << 16) -#define MAX_RD_TIME(lbcc) ((lbcc) &
[PATCH v2 0/4] Genericize DW MIPI DSI bridge and add i.MX 6 driver
Having a generic Synopsis DesignWare MIPI-DSI host controller bridge driver is a very good idea, however the current implementation has hardcoded quite a lot of the register layouts used by the two supported SoC vendors, STM and Rockchip, which use IP cores v1.30 and v1.31. This makes it hard to support other SoC vendors like the FSL/NXP i.MX 6 which use older v1.01 cores or future versions because, based on history, layout changes should also be expected in new DSI versions / SoCs. This patch series converts the bridge and platform drivers to access registers via generic regmap APIs then, adds support for the host controller found on i.MX 6. I only have i.MX hardware with MIPI-DSI panel and relevant documentation available for testing so I'll really appreciate it if someone could test the series on Rockchip and STM... eyeballing register fields could only get me so far, so sorry in advance for any breakage! Many thanks to Boris Brezillon for suggesting the regmap solution and to Liu Ying for doing the initial i.MX platform driver implementation. This series applies on top of latest linux-next tree, next-20191106. v1 -> v2: * Moved the register definitions & regmap initialization into the bridge module as suggested by Emil. Platform drivers can get the regmap via their plat_data after calling the bridge probe() without worrying at all about layouts, which are handled by the bridge now. Adrian Ratiu (4): drm: bridge: dw_mipi_dsi: access registers via a regmap drm: bridge: dw_mipi_dsi: abstract register access using reg_fields drm: imx: Add i.MX 6 MIPI DSI host driver dt-bindings: display: add IMX MIPI DSI host controller doc .../bindings/display/imx/mipi-dsi.txt | 56 ++ drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 699 +- drivers/gpu/drm/imx/Kconfig | 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 378 ++ .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 17 +- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 34 +- include/drm/bridge/dw_mipi_dsi.h | 2 +- 8 files changed, 987 insertions(+), 207 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm: bridge: dw_mipi_dsi: access registers via a regmap
Convert the common bridge code and the two rockchip & stm drivers
which currently use it to the regmap API in anticipation for further
changes to make it more generic and add older DSI host controller
support as found on i.mx6 based devices.
The regmap becomes an internal state of the bridge. No functional
changes other than requiring the platform drivers to use the
pre-configured regmap supplied by the bridge after its probe() call
instead of ioremp'ing the registers themselves.
In subsequent commits the bridge will become able to detect the
DSI host core version and init the regmap with different register
layouts. The platform drivers will continue to use the regmap without
modifications or worrying about the specific layout in use (in other
words the layout is abstracted away via the regmap).
Suggested-by: Boris Brezillon
Reviewed-by: Neil Armstrong
Reviewed-by: Emil Velikov
Signed-off-by: Adrian Ratiu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 215 ++
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 17 +-
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 34 ++-
include/drm/bridge/dw_mipi_dsi.h | 2 +-
4 files changed, 145 insertions(+), 123 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b6e793bb653c..6cb57807f3f9 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -226,7 +227,7 @@ struct dw_mipi_dsi {
struct mipi_dsi_host dsi_host;
struct drm_bridge *panel_bridge;
struct device *dev;
- void __iomem *base;
+ struct regmap *regs;
struct clk *pclk;
@@ -249,6 +250,13 @@ struct dw_mipi_dsi {
const struct dw_mipi_dsi_plat_data *plat_data;
};
+static const struct regmap_config dw_mipi_dsi_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .name = "dw-mipi-dsi",
+};
+
/*
* Check if either a link to a master or slave is present
*/
@@ -280,16 +288,6 @@ static inline struct dw_mipi_dsi *bridge_to_dsi(struct
drm_bridge *bridge)
return container_of(bridge, struct dw_mipi_dsi, bridge);
}
-static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
-{
- writel(val, dsi->base + reg);
-}
-
-static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
-{
- return readl(dsi->base + reg);
-}
-
static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
@@ -366,29 +364,29 @@ static void dw_mipi_message_config(struct dw_mipi_dsi
*dsi,
if (lpm)
val |= CMD_MODE_ALL_LP;
- dsi_write(dsi, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
- dsi_write(dsi, DSI_CMD_MODE_CFG, val);
+ regmap_write(dsi->regs, DSI_LPCLK_CTRL, lpm ? 0 : PHY_TXREQUESTCLKHS);
+ regmap_write(dsi->regs, DSI_CMD_MODE_CFG, val);
}
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 hdr_val)
{
int ret;
- u32 val, mask;
+ u32 val = 0, mask;
- ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_CMD_FULL), 1000,
-CMD_PKT_STATUS_TIMEOUT_US);
+ ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+ val, !(val & GEN_CMD_FULL), 1000,
+ CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
}
- dsi_write(dsi, DSI_GEN_HDR, hdr_val);
+ regmap_write(dsi->regs, DSI_GEN_HDR, hdr_val);
mask = GEN_CMD_EMPTY | GEN_PLD_W_EMPTY;
- ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
-val, (val & mask) == mask,
-1000, CMD_PKT_STATUS_TIMEOUT_US);
+ ret = regmap_read_poll_timeout(dsi->regs, DSI_CMD_PKT_STATUS,
+ val, (val & mask) == mask,
+ 1000, CMD_PKT_STATUS_TIMEOUT_US);
if (ret) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -403,24 +401,26 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
__le32 word;
- u32 val;
+ u32 val = 0;
while (len) {
if (len < pld_data_bytes) {
word = 0;
memcpy(, tx_buf, len);
- dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
+ regmap_write(dsi->regs, DSI_GEN_PLD_DATA,
+
[PATCH v2 4/4] dt-bindings: display: add IMX MIPI DSI host controller doc
Reviewed-by: Neil Armstrong
Reviewed-by: Emil Velikov
Signed-off-by: Sjoerd Simons
Signed-off-by: Martyn Welch
Signed-off-by: Adrian Ratiu
---
.../bindings/display/imx/mipi-dsi.txt | 56 +++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
diff --git a/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
new file mode 100644
index ..3f05c32ef963
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
@@ -0,0 +1,56 @@
+Freescale i.MX6 DW MIPI DSI Host Controller
+===
+
+The DSI host controller is a Synopsys DesignWare MIPI DSI v1.01 IP
+with a companion PHY IP.
+
+These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
+Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
+the following device-specific properties.
+
+Required properties:
+
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+- compatible: "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi".
+- reg: See dw_mipi_dsi.txt.
+- interrupts: The controller's CPU interrupt.
+- clocks, clock-names: Phandles to the controller's pll reference
+ clock(ref) and APB clock(pclk), as described in [1].
+- ports: a port node with endpoint definitions as defined in [2].
+- gpr: Should be <>.
+ Phandle to the iomuxc-gpr region containing the multiplexer
+ control register.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ mipi_dsi: mipi@21e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_IPG>;
+ clock-names = "ref", "pclk";
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
