This patch adds support for Kaohsiung Opto-Electronics Inc.
10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface.
The panel has dual LVDS channels.
My panel is manufactured by US Micro Products(USMP). There is a tag at
the back of the panel, which indicates the panel type is 'TX26D202VM0BWA'
and it's made by KOE in Taiwan.
The panel spec from USMP can be found at:
https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf
The below panel spec from KOE is basically the same to the one from USMP.
However, the panel type 'TX26D202VM0BAA' is a little bit different.
It looks that the two types of panel are compatible with each other.
http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1590991880-24273-1-git-send-email-victor.liu@nxp.com
Add compatible to panel-simple for Kaohsiung Opto-Electronics Inc.
10.1" WUXGA(1920x1200) TX26D202VM0BWA TFT LCD panel with LVDS interface.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1590991843-24231-1-git-send-email-victor.liu@nxp.com
None of the DSI panels set the connector_type in their panel_desc
descriptor. As they are all guaranteed to be DSI panels, that's an easy
fix, set the connector type to DRM_MODE_CONNECTOR_DSI.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200602171240.2785-1-laurent.pinchart+renesas@ideasonboard.com
Fixes: 0cdea4455a ("drm/mm: optimize rb_hole_addr rbtree search")
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
Reported-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/367726/
This is already taken care of by drm_atomic_helper_shutdown(), and
in that case only for the CRTC which are actually on.
Only tricky bit here is that we kill the interrupt handling before we
shut down crtc, so need to reorder that.
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200602095140.36678-3-daniel.vetter@ffwll.ch
This is already done as part of the drm_atomic_helper_shutdown(),
and in that case only for the crtc which are actually on.
v2: I overlooked that malidp also needs to have it's interrupt shut
down reordered.
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200602095505.37509-1-daniel.vetter@ffwll.ch
Currently this seems to work by converting the sgt into a pages array,
and then treating it like a native object. Do the right thing and
redirect mmap to the exporter.
With this nothing is calling get_pages anymore on imported dma-buf,
and we can start to remove the use of the ->pages array for that case.
v2: Rebase
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-8-daniel.vetter@ffwll.ch
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for importers.
v2: Change the control flow less compared to what's there (Thomas)
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514202256.490926-1-daniel.vetter@ffwll.ch
There's no direct harm, because for the shmem helpers these are noops
on imported buffers. The trouble is in the locks these take - I want
to change dma_buf_vmap locking, and so need to make sure that we only
ever take certain locks on one side of the dma-buf interface: Either
for exporters, or for importers.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-6-daniel.vetter@ffwll.ch
drm_gem_shmem_get_sg_table is meant to implement
obj->funcs->get_sg_table, for prime exporting. The one we want is
drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
just native objects.
v2: Rebase, this stuff moved around in
commit 2f2aa13724
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: Fri Feb 7 08:46:38 2020 +0100
drm/virtio: move virtio_gpu_mem_entry initialization to new function
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-5-daniel.vetter@ffwll.ch
- Move the shmem helper section to the drm-mm.rst file, next to the
vram helpers. Makes a lot more sense there with the now wider scope.
Also, that's where the all the other backing storage stuff resides.
It's just the framebuffer helpers that should be in the kms helper
section.
- Try to clarify which functiosn are for implementing
drm_gem_object_funcs, and which for drivers to call directly. At
least one driver screwed that up a bit.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-4-daniel.vetter@ffwll.ch
No real functional change, since this just converts an annoying Oops
into a more harmless WARNING backtrace. It's still a driver bug.
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Tested-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200511093554.211493-3-daniel.vetter@ffwll.ch
I honestly don't exactly understand what's going on here, but the
current code is wrong for sure: It calls dma_buf_vunmap without ever
calling dma_buf_vmap.
What I'm not sure about is whether the WARN_ON is correct:
- msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
a pretty neat layering violation of how you shouldn't peek behind
the curtain of the dma-buf exporter, but par for course. Note that
all the nice new helpers don't (and we should probably have a bit a
warning about this in the kerneldoc).
- but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a
vmap() around any object with ->pages set (so including imported
dma-buf).
- I'm not seeing any guarantees that userspace can't use an imported
dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
guarantees that an imported dma-buf won't end up with a ->vaddr set.
But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
calling dma_buf_vunmap is the wrong thing to do.
v2: Rob said in review that we do indeed have a gap in get_vaddr() that
needs to be plugged. But the users I've found aren't legit users on
imported dma-buf, so we can just reject that.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200514201117.465146-1-daniel.vetter@ffwll.ch
'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()'
not 'dma_free_wc()'.
The correct dma_free_ function is already used in the error handling path
of the probe function.
Fixes: 77e196752b ("[ARM] pxafb: allow video memory size to be configurable")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Jani Nikula <jani.nikula@intel.com>
cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429084505.108897-1-christophe.jaillet@wanadoo.fr
A call of the function do_take_over_console() can fail here.
The corresponding system resources were not released then.
Thus add a call of iounmap() and release_mem_region()
together with the check of a failure predicate. and also
add release_mem_region() on device removal.
Fixes: e86bb8acc0 ("[PATCH] VT binding: Make newport_con support binding")
Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423164251.3349-1-zhengdejin5@gmail.com
the sfb->fb->screen_base is not save the value get by iounmap() when
the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
is not right.
Fixes: 1461d66728 ("staging: sm7xxfb: merge sm712fb with fbdev")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422160719.27763-1-zhengdejin5@gmail.com
Fix the following coccicheck warning:
drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING:
Comparison to bool
drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING:
Comparison of 0/1 to bool variable
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Andrew F. Davis <afd@ti.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422071903.637-1-yanaijie@huawei.com
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200522041506.39638-3-jhubbard@nvidia.com
Dealing with the return value of get_user_pages*() variants has a few
classic pitfalls, and this driver found one of them: the return value
might be zero, positive, or -errno. And if positive, it might be fewer
pages than were requested. And if fewer pages than requested, then
the caller should return (via put_page()) the pages that *were*
pinned.
This driver was doing that *except* that it had a problem with the
-errno case, which was being stored in an unsigned int, and which
would case an interesting mess if it ever happened: nr_pages would be
interpreted as a spectacularly huge unsigned value, rather than a
small negative value. Also, it was unnecessarily overriding a
potentially informative -errno, with -EINVAL, in some cases.
Instead: clamp the nr_pages to zero or positive, so that the error
handling works. And return the -errno value from get_user_pages*(),
unchanged, if we get one. And explain this with comments, seeing as
how it is error-prone.
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200522041506.39638-2-jhubbard@nvidia.com
Replace all the WARN_* variants with their drm_WARN counterparts.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200523071224.1716837-3-sam@ravnborg.org
Replace all DRM_* logging functions with their drm_ counterparts.
checkpatch emits a few "quoted string split across lines",
which is left as is. The strings was already split in the original code
base and it would not increase readability to fix them.
v2:
- added braces to if statement (Thomas)
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200523071224.1716837-2-sam@ravnborg.org
For historical reasons it's called dev->num_crtcs, which is rather
confusing ever since kms was added. But now we have a nice helper, so
let's use it for better readability!
Only code change is in atomic helpers: vblank support means that
dev->irq_enabled must be set too. Another one of these quirky things
... But since it's implied we can simplify that check.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200527111134.1571781-1-daniel.vetter@ffwll.ch
gma500 only uses mode->private_flags to convey the sdvo pixel
multiplier from the encoder .mode_fixup() hook to the encoder
.mode_set() hook. Those always seems get called as a pair so
let's just stuff the pixel multiplier into the encoder itself
as there are no state objects we could use in this non-atomic
driver.
Paves the way for nuking mode->private_flag.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
CC: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-15-ville.syrjala@linux.intel.com
htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it.
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-12-ville.syrjala@linux.intel.com
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below the two cacheline mark even on 64bit.
v2: Rebase due to DRM_MODE_TYPE_USERDEF comment change
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-11-ville.syrjala@linux.intel.com
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-10-ville.syrjala@linux.intel.com
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-9-ville.syrjala@linux.intel.com
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-6-ville.syrjala@linux.intel.com
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-3-ville.syrjala@linux.intel.com
The variable ret is being initialized with a value that is
never read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200524222715.27305-1-colin.king@canonical.com
On some architectures like ppc64le and aarch64, compiling with
-Wformat=1 will throw the following warnings:
In file included from drivers/gpu/drm/drm_vblank.c:33:
drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count':
drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects
argument of type 'long long unsigned int', but argument 4 has type
'long int' [-Wformat=]
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/drm/drm_print.h:407:22: note: in definition of macro
'DRM_DEBUG_VBL'
drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__)
^~~
drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here
" current=%llu, diff=%u, hw=%u hw_last=%u\n",
~~~^
%lu
So, fix that with a typecast.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Co-developed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[fixed too long line]
Link: https://patchwork.freedesktop.org/patch/msgid/20200521204647.2578479-1-lyude@redhat.com
It's the default.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200511091142.208787-1-daniel.vetter@ffwll.ch
Do it uncontionally, there's a separate peek function with
dma_fence_is_signalled() which can be called from atomic context.
v2: Consensus calls for an unconditional might_sleep (Chris,
Christian)
Full audit:
- dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps
- dma-resv.c: Timeout always at least 1
- st-dma-fence.c: Save to sleep in testcases
- amdgpu_cs.c: Both callers are for variants of the wait ioctl
- amdgpu_device.c: Two callers in vram recover code, both right next
to mutex_lock.
- amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve
- remaining functions in amdgpu: All for test_ib implementations for
various engines, caller for that looks all safe (debugfs, driver
load, reset)
- etnaviv: another wait ioctl
- habanalabs: another wait ioctl
- nouveau_fence.c: hardcoded 15*HZ ... glorious
- nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but
this one does have a WARN_ON :-/ At least this one is only a
fallback path for when kmalloc fails. Maybe this should be put onto
some worker list instead, instead of a work per unamp ...
- i915/selftests: Hardecoded HZ / 4 or HZ / 8
- i915/gt/selftests: Going up the callchain looks safe looking at
nearby callers
- i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock
- i915/gem_i915_gem_wait.c: The i915-version which is called instead
for i915 fences already has a might_sleep() annotation, so all good
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
Cc: Oded Gabbay <oded.gabbay@gmail.com>
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-sig@lists.linaro.org
Cc: linux-rdma@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200519132756.682888-1-daniel.vetter@ffwll.ch
The question of "what process is this pid" keeps on popping up, so lets
print the process name alongside the pid.
Cc: Mauro Rossi <issor.oruam@gmail.com>
Cc: Bob Beckett <bob.beckett@collabora.com>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518083315.129948-1-emil.l.velikov@gmail.com
