[radeon-alex:amd-mainline-hybrid-4.12 1596/2092] drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h:517:80: sparse: dubious one-bit signed bitfield
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-hybrid-4.12
head: 0439a4b45dfef1c775f45f29831bfbcee37a582f
commit: 86a60e76532a64856c762cd98ee612a6cadf3fd2 [1596/2092] Change fence
references to dma_fence
reproduce:
# apt-get install sparse
git checkout 86a60e76532a64856c762cd98ee612a6cadf3fd2
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
vim +517 drivers/gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h
7ac4346d Felix Kuehling 2017-03-14 492
7ac4346d Felix Kuehling 2017-03-14 493 struct pm4_mec_release_mem {
7ac4346d Felix Kuehling 2017-03-14 494 union {
7ac4346d Felix Kuehling 2017-03-14 495 union
PM4_MES_TYPE_3_HEADER header; /*header */
7ac4346d Felix Kuehling 2017-03-14 496 unsigned int ordinal1;
7ac4346d Felix Kuehling 2017-03-14 497 };
7ac4346d Felix Kuehling 2017-03-14 498
7ac4346d Felix Kuehling 2017-03-14 499 union {
7ac4346d Felix Kuehling 2017-03-14 500 struct {
7ac4346d Felix Kuehling 2017-03-14 501 unsigned int
event_type:6;
7ac4346d Felix Kuehling 2017-03-14 502 unsigned int
reserved1:2;
7ac4346d Felix Kuehling 2017-03-14 503 enum
mec_release_mem_event_index_enum event_index:4;
7ac4346d Felix Kuehling 2017-03-14 504 unsigned int
tcl1_vol_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 505 unsigned int
tc_vol_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 506 unsigned int
reserved2:1;
7ac4346d Felix Kuehling 2017-03-14 507 unsigned int
tc_wb_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 508 unsigned int
tcl1_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 509 unsigned int
tc_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 510 uint32_t
reserved3:1;
7ac4346d Felix Kuehling 2017-03-14 511 uint32_t
tc_nc_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 512 uint32_t
tc_wc_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 513 uint32_t
tc_md_action_ena:1;
7ac4346d Felix Kuehling 2017-03-14 514 uint32_t
reserved4:3;
7ac4346d Felix Kuehling 2017-03-14 515 enum
mec_release_mem_cache_policy_enum cache_policy:2;
7ac4346d Felix Kuehling 2017-03-14 516 uint32_t
reserved5:2;
7ac4346d Felix Kuehling 2017-03-14 @517 enum
mec_release_mem_pq_exe_status_enum pq_exe_status:1;
7ac4346d Felix Kuehling 2017-03-14 518 uint32_t
reserved6:2;
7ac4346d Felix Kuehling 2017-03-14 519 } bitfields2;
7ac4346d Felix Kuehling 2017-03-14 520 unsigned int ordinal2;
7ac4346d Felix Kuehling 2017-03-14 521 };
7ac4346d Felix Kuehling 2017-03-14 522
7ac4346d Felix Kuehling 2017-03-14 523 union {
7ac4346d Felix Kuehling 2017-03-14 524 struct {
7ac4346d Felix Kuehling 2017-03-14 525 uint32_t
reserved7:16;
7ac4346d Felix Kuehling 2017-03-14 526 enum
mec_release_mem_dst_sel_enum dst_sel:2;
7ac4346d Felix Kuehling 2017-03-14 527 uint32_t
reserved8:6;
7ac4346d Felix Kuehling 2017-03-14 528 enum
mec_release_mem_int_sel_enum int_sel:3;
7ac4346d Felix Kuehling 2017-03-14 529 uint32_t
reserved9:2;
7ac4346d Felix Kuehling 2017-03-14 530 enum
mec_release_mem_data_sel_enum data_sel:3;
7ac4346d Felix Kuehling 2017-03-14 531 } bitfields3;
7ac4346d Felix Kuehling 2017-03-14 532 unsigned int ordinal3;
7ac4346d Felix Kuehling 2017-03-14 533 };
7ac4346d Felix Kuehling 2017-03-14 534
7ac4346d Felix Kuehling 2017-03-14 535 union {
7ac4346d Felix Kuehling 2017-03-14 536 struct {
7ac4346d Felix Kuehling 2017-03-14 537 uint32_t
reserved10:2;
7ac4346d Felix Kuehling 2017-03-14 538 unsigned int
address_lo_32b:30;
7ac4346d Felix Kuehling 2017-03-14 539 } bitfields4;
7ac4346d Felix Kuehling 2017-03-14 540 struct {
7ac4346d Felix Kuehling 2017-03-14 541 uint32_t
reserved11:3;
7ac4346d Felix Kuehling 2017-03-14 542 uint32_t
address_lo_64b:29;
7ac4346d Felix Kuehling 2017-03-14 543 } bitfields4b;
7ac4346d Felix Kuehling 2017-03-14 544 uint32_t reserved12;
7ac4346d Felix Kuehling 2017-03-14 545 unsigned int ordinal4;
7ac4346d Felix Kuehling 2017-03-14 546 };
7ac4346d Felix Kuehling 2017-03-14 547
7ac4346d Felix Kueh
Re: [PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts
Hi Krzysztof,
The driver has been merged into exynos-drm-misc.
Could you please check this patch(3/3).
Best regards,
Hoegeun
On 07/13/2017 11:20 AM, Hoegeun Kwon wrote:
The display-timing and delay are included in the panel driver. So it
should be removed in dts.
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 443e0c9..6b70c8d 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -242,28 +242,6 @@
vci-supply = <&ldo20_reg>;
reset-gpios = <&gpe0 1 GPIO_ACTIVE_LOW>;
te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
- power-on-delay= <30>;
- power-off-delay= <120>;
- reset-delay = <5>;
- init-delay = <100>;
- flip-horizontal;
- flip-vertical;
- panel-width-mm = <29>;
- panel-height-mm = <29>;
-
- display-timings {
- timing-0 {
- clock-frequency = <460>;
- hactive = <320>;
- vactive = <320>;
- hfront-porch = <1>;
- hback-porch = <1>;
- hsync-len = <1>;
- vfront-porch = <150>;
- vback-porch = <1>;
- vsync-len = <2>;
- };
- };
port {
dsi_in: endpoint {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm-hisilicon-next
Hi Dave, One fix for next. Sorry for late pull request. If it can't catch this round, will resend on next round. Best, Xinliang The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 10:38:14 +1000) are available in the git repository at: g...@github.com:xin3liang/linux.git tags/drm-hisilicon-next-2017-08-29 for you to fetch changes up to 834fe0f6023a4fad68612dbbe93866c4df32142e: drm/hisilicon: Ensure LDI regs are properly configured. (2017-08-29 10:17:18 +0800) hisilicon-drm-next Peter Griffin (1): drm/hisilicon: Ensure LDI regs are properly configured. drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++ 1 file changed, 3 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers
https://bugs.freedesktop.org/show_bug.cgi?id=99195 --- Comment #13 from Michel Dänzer --- (In reply to johnrory.odwyer from comment #12) > Often when I turn back on the system it just goes straight away to a black > screen. It doesn't even go the the Dell boot menu that gives the bios options > etc. The card would seem to be alive. Sometimes in this situation I get a > beeping sound from the hardware. That sounds like a hardware / BIOS issue. That's before the Linux kernel is even loaded. -- 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
[radeon-alex:amd-mainline-hybrid-4.12 1229/2092] drivers/gpu/drm/radeon/radeon_kfd.c:1431:2: note: in expansion of macro 'pr_debug'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-hybrid-4.12
head: 0439a4b45dfef1c775f45f29831bfbcee37a582f
commit: d35e5029162c64ba73eb0ae70366f1df9a6eb5eb [1229/2092] radeon_kfd.c copied
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout d35e5029162c64ba73eb0ae70366f1df9a6eb5eb
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/gpu/drm/radeon/radeon_kfd.c: In function
'get_pdd_from_buffer_object':
drivers/gpu/drm/radeon/radeon_kfd.c:219:22: error: 'struct radeon_bo' has no
member named 'pdd'; did you mean 'pid'?
return mem->data2.bo->pdd;
^~
drivers/gpu/drm/radeon/radeon_kfd.c: In function 'open_graphic_handle':
drivers/gpu/drm/radeon/radeon_kfd.c:532:34: error: passing argument 1 of
'drm_gem_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
^~~~
In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
include/drm/drm_gem.h:319:24: note: expected 'struct drm_file *' but
argument is of type 'struct drm_device *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
drivers/gpu/drm/radeon/radeon_kfd.c:532:46: warning: passing argument 2 of
'drm_gem_object_lookup' makes integer from pointer without a cast
[-Wint-conversion]
gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
^~~~
In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
include/drm/drm_gem.h:319:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'void *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
drivers/gpu/drm/radeon/radeon_kfd.c:532:12: error: too many arguments to
function 'drm_gem_object_lookup'
gem_obj = drm_gem_object_lookup(rdev->ddev, filp->private_data, handle);
^
In file included from drivers/gpu/drm/radeon/radeon.h:77:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
include/drm/drm_gem.h:319:24: note: declared here
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
drivers/gpu/drm/radeon/radeon_kfd.c: In function 'map_bo_to_gpuvm':
drivers/gpu/drm/radeon/radeon_kfd.c:1276:9: error: too many arguments to
function 'ttm_bo_wait'
ret = ttm_bo_wait(&bo->tbo, true, false, false);
^~~
In file included from drivers/gpu/drm/radeon/radeon.h:71:0,
from drivers/gpu/drm/radeon/radeon_kfd.c:27:
include/drm/ttm/ttm_bo_api.h:292:12: note: declared here
extern int ttm_bo_wait(struct ttm_buffer_object *bo,
^~~
drivers/gpu/drm/radeon/radeon_kfd.c: In function 'write_config_static_mem':
drivers/gpu/drm/radeon/radeon_kfd.c:1373:26: error:
'SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT' undeclared (first use in this
function)
reg = swizzle_enable << SH_STATIC_MEM_CONFIG__SWIZZLE_ENABLE__SHIFT |
^~~
drivers/gpu/drm/radeon/radeon_kfd.c:1373:26: note: each undeclared
identifier is reported only once for each function it appears in
drivers/gpu/drm/radeon/radeon_kfd.c:1374:19: error:
'SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT' undeclared (first use in this
function)
element_size << SH_STATIC_MEM_CONFIG__ELEMENT_SIZE__SHIFT |
^
drivers/gpu/drm/radeon/radeon_kfd.c:1375:19: error:
'SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT' undeclared (first use in this
function)
index_stride << SH_STATIC_MEM_CONFIG__INDEX_STRIDE__SHIFT |
^
drivers/gpu/drm/radeon/radeon_kfd.c:1376:19: error:
'SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT' undeclared (first use in this
function)
index_stride << SH_STATIC_MEM_CONFIG__PRIVATE_MTYPE__SHIFT;
^~
In file included from drivers/gpu/drm/radeon/radeon_kfd.c:27:0:
drivers/gpu/drm/radeon/radeon_kfd.c: In function 'alloc_memory_of_scratch':
drivers/gpu/drm/radeon/radeon_kfd.c:1387:9: error:
'SH_HIDDEN_PRIVATE_BASE_VMID' undeclared (first use in this function)
WREG32(SH_HIDDEN_PRIVATE_BASE_VMID, va);
^
drivers/gpu/drm/radeon/radeon.h:2528:44: note: in definition of macro
'WREG32'
#define WREG32(reg, v)
RE: [PATCH v3 04/22] drm/arc: Use drm_gem_fb_create()
Hi Noralf, > -Original Message- > From: Noralf Trønnes [mailto:nor...@tronnes.org] > Sent: Sunday, August 13, 2017 4:32 PM > To: dri-devel@lists.freedesktop.org > Cc: daniel.vet...@ffwll.ch; alexey.brod...@synopsys.com; > alison.w...@freescale.com; benjamin.gaign...@linaro.org; > boris.brezil...@free-electrons.com; brian.star...@arm.com; > puck.c...@hisilicon.com; e...@anholt.net; jsa...@ti.com; > laurent.pinch...@ideasonboard.com; liviu.du...@arm.com; ma...@denx.de; > maxime.rip...@free-electrons.com; > narmstr...@baylibre.com; philippe.co...@st.com; p.za...@pengutronix.de; > zourongr...@gmail.com; shawn...@kernel.org; > ste...@agner.ch; tomi.valkei...@ti.com; vincent.abr...@st.com; > z.liuxinli...@hisilicon.com; kong.kongxin...@hisilicon.com; > yannick.fer...@st.com; Noralf Trønnes > Subject: [PATCH v3 04/22] drm/arc: Use drm_gem_fb_create() > > drm_fb_cma_create() is just a wrapper around drm_gem_fb_create() now, > so use the function directly. Acked-by: Alexey Brodkin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM Format Modifiers in v4l2
Le jeudi 24 août 2017 à 13:26 +0100, Brian Starkey a écrit : > > What I mean was: an application can use the modifier to give buffers from > > one device to another without needing to understand it. > > > > But a generic video capture application that processes the video itself > > cannot be expected to know about the modifiers. It's a custom HW specific > > format that you only use between two HW devices or with software written > > for that hardware. > > > > Yes, makes sense. > > > > > > > However, in DRM the API lets you get the supported formats for each > > > modifier as-well-as the modifier list itself. I'm not sure how exactly > > > to provide that in a control. > > > > We have support for a 'menu' of 64 bit integers: > > V4L2_CTRL_TYPE_INTEGER_MENU. > > You use VIDIOC_QUERYMENU to enumerate the available modifiers. > > > > So enumerating these modifiers would work out-of-the-box. > > Right. So I guess the supported set of formats could be somehow > enumerated in the menu item string. In DRM the pairs are (modifier + > bitmask) where bits represent formats in the supported formats list > (commit db1689aa61bd in drm-next). Printing a hex representation of > the bitmask would be functional but I concede not very pretty. The problem is that the list of modifiers depends on the format selected. Having to call S_FMT to obtain this list is quite inefficient. Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think an other one made it the same way recently, something from Mediatek if I remember. Though, unlike the Intel one, the same modifier does not have various result depending on the hardware revision. regards, Nicolas signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm/tinydrm: Support device unplug
Hi Noralf, On Mon, Aug 28, 2017 at 07:17:42PM +0200, Noralf Trønnes wrote: > This adds device unplug support to drm_fb_helper, drm_fb_cma_helper > (fbdev) and tinydrm. > > My motivation for doing this is to make tinydrm useable with USB > devices. This discussion gave insight into the problem: > [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge. > https://lists.freedesktop.org/archives/dri-devel/2017-August/149376.html Looks a lot less scary than I thought, but I think needs a bit more polish. I think it'd be also great if you could co-evolve the udl driver to get this right, since it looks like right now it'll just oops when you unplug when userspace is using the fbdev emulation. That way we'd be at least somewhat consistent with unpluggable drivers, and since it's only 1 other it should be doable. Unplugging is already hard, having 2 drivers do stuff differently (when we only have 2 with unplug support) pretty much guarnatees we'll never get this right. But maybe good to first develop this using your own driver only. Cheers, Daniel > > Noralf. > > Noralf Trønnes (6): > drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend() > drm/fb-helper: Support device unplug > drm/fb-cma-helper: Support device unplug > drm/tinydrm: Embed drm_device in tinydrm_device > drm/tinydrm/mi0283qt: Let the display pipe handle power > drm/tinydrm: Support device unplug > > drivers/gpu/drm/drm_fb_cma_helper.c | 139 +-- > drivers/gpu/drm/drm_fb_helper.c | 207 > +++- > drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 109 ++- > drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- > drivers/gpu/drm/tinydrm/mi0283qt.c | 77 +++ > drivers/gpu/drm/tinydrm/mipi-dbi.c | 27 ++-- > drivers/gpu/drm/tinydrm/repaper.c | 19 ++- > drivers/gpu/drm/tinydrm/st7586.c| 25 ++-- > include/drm/drm_fb_cma_helper.h | 1 + > include/drm/drm_fb_helper.h | 35 + > include/drm/tinydrm/tinydrm.h | 14 +- > 11 files changed, 460 insertions(+), 195 deletions(-) > > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/tinydrm: Support device unplug
On Mon, Aug 28, 2017 at 07:17:48PM +0200, Noralf Trønnes wrote:
> Support device unplugging to make tinydrm suitable for USB devices.
>
> Cc: David Lechner
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 69
> -
> drivers/gpu/drm/tinydrm/mi0283qt.c | 4 ++
> drivers/gpu/drm/tinydrm/mipi-dbi.c | 5 ++-
> drivers/gpu/drm/tinydrm/repaper.c | 9 +++-
> drivers/gpu/drm/tinydrm/st7586.c| 9 +++-
> include/drm/tinydrm/tinydrm.h | 5 +++
> 6 files changed, 87 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> index f11f4cd..3ccbcc5 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> @@ -32,6 +32,29 @@
> * The driver allocates &tinydrm_device, initializes it using
> * devm_tinydrm_init(), sets up the pipeline using
> tinydrm_display_pipe_init()
> * and registers the DRM device using devm_tinydrm_register().
> + *
> + * Device unplug
> + * -
> + *
> + * tinydrm supports device unplugging when there's still open DRM or fbdev
> file
> + * handles.
> + *
> + * There are 2 ways for driver-device unbinding to happen:
> + *
> + * - The driver module is unloaded causing the driver to be unregistered.
> + * This can't happen as long as there's open file handles because a
> reference
> + * is taken on the module.
Aside: you can do that, but then it works like a hw unplug, through the
unbind property in sysfs.
> + *
> + * - The device is removed (USB, Device Tree overlay).
> + * This can happen at any time.
> + *
> + * The driver needs to protect device resources from access after the device
> is
> + * gone. This is done checking drm_dev_is_unplugged(), typically in
> + * &drm_framebuffer_funcs.dirty, &drm_simple_display_pipe_funcs.enable and
> + * \.disable. Resources that doesn't face userspace and is only used with the
> + * device can be setup using devm\_ functions, but &tinydrm_device must be
> + * allocated using plain kzalloc() since it's lifetime can exceed that of the
> + * device. tinydrm_release() will free the structure.
So here's a bit a dragon: There's no prevention of is_unplugged racing
against a drm_dev_unplug(). There's been various attempts to fixing this,
but they're all somewhat ugly.
Either way, that's a bug in the drm core :-)
> */
>
> /**
> @@ -138,6 +161,29 @@ static const struct drm_mode_config_funcs
> tinydrm_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> +/**
> + * tinydrm_release - DRM driver release helper
> + * @drm: DRM device
> + *
> + * This function cleans up and finalizes &drm_device and frees
> &tinydrm_device.
> + *
> + * Drivers must use this as their &drm_driver->release callback.
> + */
> +void tinydrm_release(struct drm_device *drm)
> +{
> + struct tinydrm_device *tdev = drm_to_tinydrm(drm);
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + drm_mode_config_cleanup(drm);
> + drm_dev_fini(drm);
> +
> + mutex_destroy(&tdev->dirty_lock);
> + kfree(tdev->fbdev_cma);
> + kfree(tdev);
> +}
> +EXPORT_SYMBOL(tinydrm_release);
> +
> static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> const struct drm_framebuffer_funcs *fb_funcs,
> struct drm_driver *driver)
> @@ -160,8 +206,6 @@ static int tinydrm_init(struct device *parent, struct
> tinydrm_device *tdev,
>
> static void tinydrm_fini(struct tinydrm_device *tdev)
> {
> - drm_mode_config_cleanup(&tdev->drm);
> - mutex_destroy(&tdev->dirty_lock);
> drm_dev_unref(&tdev->drm);
> }
>
> @@ -178,8 +222,8 @@ static void devm_tinydrm_release(void *data)
> * @driver: DRM driver
> *
> * This function initializes @tdev, the underlying DRM device and it's
> - * mode_config. Resources will be automatically freed on driver detach
> (devres)
> - * using drm_mode_config_cleanup() and drm_dev_unref().
> + * mode_config. drm_dev_unref() is called on driver detach (devres) and when
> + * all refs are dropped, tinydrm_release() is called.
> *
> * Returns:
> * Zero on success, negative error code on failure.
> @@ -226,14 +270,17 @@ static int tinydrm_register(struct tinydrm_device *tdev)
>
> static void tinydrm_unregister(struct tinydrm_device *tdev)
> {
> - struct drm_fbdev_cma *fbdev_cma = tdev->fbdev_cma;
> -
> drm_atomic_helper_shutdown(&tdev->drm);
> - /* don't restore fbdev in lastclose, keep pipeline disabled */
> - tdev->fbdev_cma = NULL;
> - drm_dev_unregister(&tdev->drm);
> - if (fbdev_cma)
> - drm_fbdev_cma_fini(fbdev_cma);
> +
> + /* Get a ref that will be put in tinydrm_fini() */
> + drm_dev_ref(&tdev->drm);
Why do we need that private ref? Grabbing references in unregister code
looks like a recipe for leaks ...
> +
> + d
Re: [PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device
On Mon, Aug 28, 2017 at 07:17:46PM +0200, Noralf Trønnes wrote:
> Might as well embed drm_device since tinydrm_device (embeds pipe struct
> and fbdev pointer) needs to stick around after driver-device unbind to
> handle open fd's after device removal.
>
> Cc: David Lechner
> Signed-off-by: Noralf Trønnes
I think you should be able to merge this right away, and it's definitely a
nice cleanup.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 44
> -
> drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
> drivers/gpu/drm/tinydrm/mi0283qt.c | 8 +++---
> drivers/gpu/drm/tinydrm/mipi-dbi.c | 12
> drivers/gpu/drm/tinydrm/repaper.c | 10 +++
> drivers/gpu/drm/tinydrm/st7586.c| 16 +--
> include/drm/tinydrm/tinydrm.h | 9 +-
> 7 files changed, 50 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> index 551709e..f11f4cd 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
> @@ -44,7 +44,7 @@
> */
> void tinydrm_lastclose(struct drm_device *drm)
> {
> - struct tinydrm_device *tdev = drm->dev_private;
> + struct tinydrm_device *tdev = drm_to_tinydrm(drm);
>
> DRM_DEBUG_KMS("\n");
> drm_fbdev_cma_restore_mode(tdev->fbdev_cma);
> @@ -126,7 +126,7 @@ static struct drm_framebuffer *
> tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - struct tinydrm_device *tdev = drm->dev_private;
> + struct tinydrm_device *tdev = drm_to_tinydrm(drm);
>
> return drm_fb_cma_create_with_funcs(drm, file_priv, mode_cmd,
> tdev->fb_funcs);
> @@ -142,23 +142,16 @@ static int tinydrm_init(struct device *parent, struct
> tinydrm_device *tdev,
> const struct drm_framebuffer_funcs *fb_funcs,
> struct drm_driver *driver)
> {
> - struct drm_device *drm;
> + struct drm_device *drm = &tdev->drm;
> + int ret;
>
> mutex_init(&tdev->dirty_lock);
> tdev->fb_funcs = fb_funcs;
>
> - /*
> - * We don't embed drm_device, because that prevent us from using
> - * devm_kzalloc() to allocate tinydrm_device in the driver since
> - * drm_dev_unref() frees the structure. The devm_ functions provide
> - * for easy error handling.
> - */
> - drm = drm_dev_alloc(driver, parent);
> - if (IS_ERR(drm))
> - return PTR_ERR(drm);
> -
> - tdev->drm = drm;
> - drm->dev_private = tdev;
> + ret = drm_dev_init(drm, driver, parent);
> + if (ret)
> + return ret;
> +
> drm_mode_config_init(drm);
> drm->mode_config.funcs = &tinydrm_mode_config_funcs;
>
> @@ -167,10 +160,9 @@ static int tinydrm_init(struct device *parent, struct
> tinydrm_device *tdev,
>
> static void tinydrm_fini(struct tinydrm_device *tdev)
> {
> - drm_mode_config_cleanup(tdev->drm);
> + drm_mode_config_cleanup(&tdev->drm);
> mutex_destroy(&tdev->dirty_lock);
> - tdev->drm->dev_private = NULL;
> - drm_dev_unref(tdev->drm);
> + drm_dev_unref(&tdev->drm);
> }
>
> static void devm_tinydrm_release(void *data)
> @@ -212,12 +204,12 @@ EXPORT_SYMBOL(devm_tinydrm_init);
>
> static int tinydrm_register(struct tinydrm_device *tdev)
> {
> - struct drm_device *drm = tdev->drm;
> + struct drm_device *drm = &tdev->drm;
> int bpp = drm->mode_config.preferred_depth;
> struct drm_fbdev_cma *fbdev;
> int ret;
>
> - ret = drm_dev_register(tdev->drm, 0);
> + ret = drm_dev_register(drm, 0);
> if (ret)
> return ret;
>
> @@ -236,10 +228,10 @@ static void tinydrm_unregister(struct tinydrm_device
> *tdev)
> {
> struct drm_fbdev_cma *fbdev_cma = tdev->fbdev_cma;
>
> - drm_atomic_helper_shutdown(tdev->drm);
> + drm_atomic_helper_shutdown(&tdev->drm);
> /* don't restore fbdev in lastclose, keep pipeline disabled */
> tdev->fbdev_cma = NULL;
> - drm_dev_unregister(tdev->drm);
> + drm_dev_unregister(&tdev->drm);
> if (fbdev_cma)
> drm_fbdev_cma_fini(fbdev_cma);
> }
> @@ -262,7 +254,7 @@ static void devm_tinydrm_register_release(void *data)
> */
> int devm_tinydrm_register(struct tinydrm_device *tdev)
> {
> - struct device *dev = tdev->drm->dev;
> + struct device *dev = tdev->drm.dev;
> int ret;
>
> ret = tinydrm_register(tdev);
> @@ -287,7 +279,7 @@ EXPORT_SYMBOL(devm_tinydrm_register);
> */
> void tinydrm_shutdown(struct tinydrm_device *tdev)
> {
> - drm_atomic_helper_shutdown(tdev->drm);
> + drm_atomic_helper_shutdown(&tdev->drm);
> }
> EXPORT_SYMBOL(tinydrm_shutdown);
>
> @@ -312,7 +304,7 @@ int tinydrm_suspend(struct tinydr
Re: [PATCH 3/6] drm/fb-cma-helper: Support device unplug
On Mon, Aug 28, 2017 at 07:17:45PM +0200, Noralf Trønnes wrote:
> Add drm_fbdev_cma_dev_unplug() and use the drm_fb_helper device unplug
> support. Pin driver module on fb_open().
>
> Cc: Laurent Pinchart
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 139
> +---
> include/drm/drm_fb_cma_helper.h | 1 +
> 2 files changed, 68 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index f2ee883..2b044be 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -25,8 +25,6 @@
> #include
> #include
>
> -#define DEFAULT_FBDEFIO_DELAY_MS 50
> -
> struct drm_fbdev_cma {
> struct drm_fb_helperfb_helper;
> const struct drm_framebuffer_funcs *fb_funcs;
> @@ -238,6 +236,34 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void
> *arg)
> EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
> #endif
>
> +static int drm_fbdev_cma_fb_open(struct fb_info *info, int user)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> +
> + /*
> + * The fb_ops definition resides in this library, meaning fb_open()
> + * will take a ref on the library instead of the driver. Make sure the
> + * driver module is pinned. Skip fbcon (user==0) since it can detach
> + * itself on unregister_framebuffer().
> + */
> + if (user && !try_module_get(dev->driver->fops->owner))
> + return -ENODEV;
I thought we've fixed this by redoing the fb_ops as a macro? Maybe tinydrm
isn't fixed yet, but then we need to fix up tinydrm. This here otoh kinda
smells a bit like a hack ...
If we need it, then I'd vote to put it into the fbdev helpers, not the cma
specific parts.
> +
> + return 0;
> +}
> +
> +static int drm_fbdev_cma_fb_release(struct fb_info *info, int user)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> +
> + if (user)
> + module_put(dev->driver->fops->owner);
> +
> + return 0;
> +}
> +
> static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> {
> return dma_mmap_writecombine(info->device, vma, info->screen_base,
> @@ -247,10 +273,13 @@ static int drm_fb_cma_mmap(struct fb_info *info, struct
> vm_area_struct *vma)
> static struct fb_ops drm_fbdev_cma_ops = {
> .owner = THIS_MODULE,
> DRM_FB_HELPER_DEFAULT_OPS,
> + .fb_open= drm_fbdev_cma_fb_open,
> + .fb_release = drm_fbdev_cma_fb_release,
> .fb_fillrect= drm_fb_helper_sys_fillrect,
> .fb_copyarea= drm_fb_helper_sys_copyarea,
> .fb_imageblit = drm_fb_helper_sys_imageblit,
> .fb_mmap= drm_fb_cma_mmap,
> + .fb_destroy = drm_fb_helper_fb_destroy,
> };
>
> static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> @@ -262,52 +291,26 @@ static int drm_fbdev_cma_deferred_io_mmap(struct
> fb_info *info,
> return 0;
> }
>
> -static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
> +static int drm_fbdev_cma_defio_init(struct drm_fb_helper *helper,
> struct drm_gem_cma_object *cma_obj)
> {
> - struct fb_deferred_io *fbdefio;
> - struct fb_ops *fbops;
> + struct fb_info *fbi = helper->fbdev;
> + int ret;
>
> - /*
> - * Per device structures are needed because:
> - * fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
> - * fbdefio: individual delays
> - */
> - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
> - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
> - if (!fbdefio || !fbops) {
> - kfree(fbdefio);
> - kfree(fbops);
> - return -ENOMEM;
> - }
> + ret = drm_fb_helper_defio_init(helper);
> + if (ret)
> + return ret;
>
> /* can't be offset from vaddr since dirty() uses cma_obj */
> fbi->screen_buffer = cma_obj->vaddr;
> /* fb_deferred_io_fault() needs a physical address */
> fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
>
> - *fbops = *fbi->fbops;
> - fbi->fbops = fbops;
> -
> - fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
> - fbdefio->deferred_io = drm_fb_helper_deferred_io;
> - fbi->fbdefio = fbdefio;
> - fb_deferred_io_init(fbi);
> fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
>
> return 0;
> }
>
> -static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
> -{
> - if (!fbi->fbdefio)
> - return;
> -
> - fb_deferred_io_cleanup(fbi);
> - kfree(fbi->fbdefio);
> - kfree(fbi->fbops);
> -}
> -
Above changes look like unrelated cleanup? Should be a separate patch I
think.
> static int
> drm_fbdev_cma_create(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size *siz
Re: [PATCH 2/6] drm/fb-helper: Support device unplug
On Mon, Aug 28, 2017 at 07:17:44PM +0200, Noralf Trønnes wrote:
> Support device unplug by introducing a new initialization function:
> drm_fb_helper_simple_init() which together with
> drm_fb_helper_dev_unplug() and drm_fb_helper_fb_destroy() handles open
> fbdev fd's after device unplug. There's also a
> drm_fb_helper_simple_fini() for drivers who's device won't be removed.
>
> It turns out that fbdev has the necessary ref counting, so
> unregister_framebuffer() together with fb_ops->destroy handles unplug
> with open fd's. The ref counting doesn't apply to the fb_info structure
> itself, but to use of the fbdev framebuffer.
>
> Analysis of entry points after unregister_framebuffer():
> - fbcon has been unbound (through notifier)
> - sysfs files removed
>
> First we look at possible operations on open fbdev file handles:
>
> static const struct file_operations fb_fops = {
> .read = fb_read,
> .write =fb_write,
> .unlocked_ioctl = fb_ioctl,
> .compat_ioctl = fb_compat_ioctl,
> .mmap = fb_mmap,
> .open = fb_open,
> .release = fb_release,
> .get_unmapped_area = get_fb_unmapped_area,
> .fsync =fb_deferred_io_fsync,
> };
>
> Not possible after unregister:
> fb_open() -> fb_ops.fb_open
>
> Protected by file_fb_info() (-ENODEV):
> fb_read() -> fb_ops.fb_read : drm_fb_helper_sys_read()
> fb_write() -> fb_ops.fb_write : drm_fb_helper_sys_write()
> fb_ioctl() -> fb_ops.fb_ioctl : drm_fb_helper_ioctl()
> fb_compat_ioctl() -> fb_ops.fb_compat_ioctl
> fb_mmap() -> fb_ops.fb_mmap
>
> Safe:
> fb_release() -> fb_ops.fb_release
> get_fb_unmapped_area() : info->screen_base
> fb_deferred_io_fsync() : if (info->fbdefio) &info->deferred_work
>
> Active mmap's will need the backing buffer to be present.
> If deferred IO is used, mmap writes will via a worker generate calls to
> drm_fb_helper_deferred_io() which in turn via a worker calls into
> drm_fb_helper_dirty_work().
>
> Secondly we look at the remaining struct fb_ops operations:
>
> Called by fbcon:
> - fb_ops.fb_fillrect : drm_fb_helper_{sys,cfb}_fillrect()
> - fb_ops.fb_copyarea : drm_fb_helper_{sys,cfb}_copyarea()
> - fb_ops.fb_imageblit : drm_fb_helper_{sys,cfb}_imageblit()
>
> Called in fb_set_var() which is called from ioctl, sysfs and fbcon:
> - fb_ops.fb_check_var : drm_fb_helper_check_var()
> - fb_ops.fb_set_par : drm_fb_helper_set_par()
> drm_fb_helper_set_par() is also called from drm_fb_helper_hotplug_event().
>
> Called in fb_set_cmap() which is called from fb_set_var(), ioctl
> and fbcon:
> - fb_ops.fb_setcolreg
> - fb_ops.fb_setcmap : drm_fb_helper_setcmap()
>
> Called in fb_blank() which is called from ioctl and fbcon:
> - fb_ops.fb_blank : drm_fb_helper_blank()
>
> Called in fb_pan_display() which is called from fb_set_var(), ioctl,
> sysfs and fbcon:
> - fb_ops.fb_pan_display : drm_fb_helper_pan_display()
>
> Called by fbcon:
> - fb_ops.fb_cursor
>
> Called in fb_read(), fb_write(), and fb_get_buffer_offset() which is
> called by fbcon:
> - fb_ops.fb_sync
>
> Called by fb_set_var():
> - fb_ops.fb_get_caps
>
> Called by fbcon:
> - fb_ops.fb_debug_enter : drm_fb_helper_debug_enter()
> - fb_ops.fb_debug_leave : drm_fb_helper_debug_leave()
>
> Destroy is safe
> - fb_ops.fb_destroy
>
> Finally we look at other call paths:
>
> drm_fb_helper_set_suspend{_unlocked}() and
> drm_fb_helper_resume_worker():
> Calls into fb_set_suspend(), but that's fine since it just uses the
> fbdev notifier.
>
> drm_fb_helper_restore_fbdev_mode_unlocked():
> Called from drm_driver.last_close, possibly after drm_fb_helper_fini().
>
> drm_fb_helper_force_kernel_mode():
> Triggered by sysrq, possibly after unplug, but before
> drm_fb_helper_fini().
>
> drm_fb_helper_hotplug_event():
> Called by drm_kms_helper_hotplug_event(). I don't know if this can be
> called after drm_dev_unregister(), so add a check to be safe.
>
> Based on this analysis the following functions get a
> drm_dev_is_unplugged() check:
> - drm_fb_helper_restore_fbdev_mode_unlocked()
> - drm_fb_helper_force_kernel_mode()
> - drm_fb_helper_hotplug_event()
> - drm_fb_helper_dirty_work()
>
> Signed-off-by: Noralf Trønnes
You're mixing in the new simple fbdev helper helpers as a bonus, that's
two things in one patch and makes it harder to review what's really going
on.
My gut feeling is that when we need a helper for the helper the original
helper needs to be improved, but I think that's much easier to decide when
it's a separate patch. Splitting things out would definitely make this
patch much smaller and easier to understand and review.
The only reason for the simple helpers that I could find is the
drm_dev_ref/unref, we should be able to do that in one of the existing
callbacks.
> ---
> drivers/gpu/drm/drm_fb_helper.c | 204
> +++-
> include/drm/drm_fb_helper.h | 35 +++
> 2 files changed, 237 insertions(+), 2 deletions(-)
>
> diff --git a/d
[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #7 from FFAB --- Created attachment 133857 --> https://bugs.freedesktop.org/attachment.cgi?id=133857&action=edit kernel 4.13-rc7 kernel parameter iommu=soft -- 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 1/6] drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend()
On Mon, Aug 28, 2017 at 07:17:43PM +0200, Noralf Trønnes wrote:
> drm_fb_helper_resume_worker() uses fb_helper->fbdev to call
> fb_set_suspend() which dereferences the pointer.
> Move sync-canceling of the resume worker in drm_fb_helper_fini() before
> setting fb_helper->fbdev to NULL.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 1b8f013..2e33467 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -910,6 +910,8 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> if (!drm_fbdev_emulation || !fb_helper)
> return;
>
> + cancel_work_sync(&fb_helper->resume_work);
> +
> info = fb_helper->fbdev;
> if (info) {
> if (info->cmap.len)
> @@ -918,7 +920,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> }
> fb_helper->fbdev = NULL;
>
> - cancel_work_sync(&fb_helper->resume_work);
> cancel_work_sync(&fb_helper->dirty_work);
Hm, I would have moved both up, just for safety. Either way:
Reviewed-by: Daniel Vetter
>
> mutex_lock(&kernel_fb_helper_lock);
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #6 from FFAB --- Created attachment 133856 --> https://bugs.freedesktop.org/attachment.cgi?id=133856&action=edit no workaround parameter Upstream kernel test - kernel 4.13-rc7 Installation, on which upstream kernel was installed: ubuntu 16.04.3, kernel4.10.0-32, updated 2017-08-28 1. booting without any workaround parameters 2. booting with kernel parameter iommu=soft boot-time 45sec (message sound), black screen remote-login (ssh) o.k. -- 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
[PULL] drm-misc-next-fixes
Hi Dave, Only one change in -misc-next-fixes as well. Simply a rename to use consistent types across ioctl structs. drm-misc-next-fixes-2017-08-28: UAPI Changes: - Rename u32 to __u32 in struct drm_format_modifier_blob (Lionel) Cc: Lionel Landwerlin Cheers, Sean The following changes since commit 0e8841ec7ee5b1ffe416c3be7743985b1896ec00: Merge airlied/drm-next into drm-misc-next (2017-08-18 10:52:44 -0400) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-08-28 for you to fetch changes up to f44d85389e17b2e960620c1c6d89bda978a11f2b: drm: rename u32 in __u32 in uapi (2017-08-25 10:07:30 +0100) UAPI Changes: - Rename u32 to __u32 in struct drm_format_modifier_blob (Lionel) Cc: Lionel Landwerlin Lionel Landwerlin (1): drm: rename u32 in __u32 in uapi include/uapi/drm/drm_mode.h | 14 +++--- 1 file changed, 7 insertions(+), 7 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
[PULL] drm-misc-fixes
Hi Dave, Apologies for the late pull req. This is a regression fix to a patch committed in Feb which prevents writes to an incorrect register. Andrzej: once this lands in Linus' tree, please send it over to stable@ so they can add it to the stable releases of the affected trees. drm-misc-fixes-2017-08-28: Driver Changes: - bridge/sii8620: Fix out-of-bounds write to incorrect register Cc: Maciej Purski Cc: Andrzej Hajda Cheers, Sean The following changes since commit fe4600a548f2763dec91b3b27a1245c370ceee2a: drm: Release driver tracking before making the object available again (2017-08-22 16:03:43 +0300) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-08-28 for you to fetch changes up to 79964dbaf662229253b281c42e82e2675a9d3b80: drm/bridge/sii8620: Fix memory corruption (2017-08-24 19:06:32 +0200) Driver Changes: - bridge/sii8620: Fix out-of-bounds write to incorrect register Cc: Maciej Purski Cc: Andrzej Hajda Maciej Purski (1): drm/bridge/sii8620: Fix memory corruption drivers/gpu/drm/bridge/sil-sii8620.c | 4 ++-- 1 file changed, 2 insertions(+), 2 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
[PATCH 1/2] drm/syncobj: Add a reset ioctl (v3)
This just resets the dma_fence to NULL so it looks like it's never been
signaled. This will be useful once we add the new wait API for allowing
wait on "submit and signal" behavior.
v2:
- Take an array of sync objects (Dave Airlie)
v3:
- Throw -EINVAL if pad != 0
Signed-off-by: Jason Ekstrand
Reviewed-by: Christian König (v1)
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 33 +
include/uapi/drm/drm.h | 7 +++
4 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 534e5ac..83f1615 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -169,3 +169,5 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b4f4434..16c5d51 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -659,6 +659,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 15e74ca..40d2ad2 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -885,3 +885,36 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
return ret;
}
+
+int
+drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+ struct drm_syncobj_array *args = data;
+ struct drm_syncobj **syncobjs;
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < args->count_handles; i++)
+ drm_syncobj_replace_fence(syncobjs[i], NULL);
+
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return 0;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 4c74659..b037fdf 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -731,6 +731,12 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_array {
+ __u64 handles;
+ __u32 count_handles;
+ __u32 pad;
+};
+
#if defined(__cplusplus)
}
#endif
@@ -854,6 +860,7 @@ extern "C" {
#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct
drm_syncobj_handle)
#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct
drm_syncobj_handle)
#define DRM_IOCTL_SYNCOBJ_WAIT DRM_IOWR(0xC3, struct drm_syncobj_wait)
+#define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, struct
drm_syncobj_array)
/**
* Device specific ioctls should only be in their respective headers
--
2.5.0.400.gff86faf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/syncobj: Add a signal ioctl (v3)
This IOCTL provides a mechanism for userspace to trigger a sync object
directly. There are other ways that userspace can trigger a syncobj
such as submitting a dummy batch somewhere or hanging on to a triggered
sync_file and doing an import. This just provides an easy way to
manually trigger the sync object without weird hacks.
The motivation for this IOCTL is Vulkan fences. Vulkan lets you create
a fence already in the signaled state so that you can wait on it
immediatly without stalling. We could also handle this with a new
create flag to ask the driver to create a syncobj that is already
signaled but the IOCTL seemed a bit cleaner and more generic.
v2:
- Take an array of sync objects (Dave Airlie)
v3:
- Throw -EINVAL if pad != 0
Signed-off-by: Jason Ekstrand
signal
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 2 ++
drivers/gpu/drm/drm_syncobj.c | 36
include/uapi/drm/drm.h | 1 +
4 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 83f1615..fbc3f30 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -171,3 +171,5 @@ int drm_syncobj_wait_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 16c5d51..a9ae6dd 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -661,6 +661,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 40d2ad2..0422b8c 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -918,3 +918,39 @@ drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
return 0;
}
+
+int
+drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private)
+{
+ struct drm_syncobj_array *args = data;
+ struct drm_syncobj **syncobjs;
+ uint32_t i;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ return -ENODEV;
+
+ if (args->pad != 0)
+ return -EINVAL;
+
+ if (args->count_handles == 0)
+ return -EINVAL;
+
+ ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+&syncobjs);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < args->count_handles; i++) {
+ ret = drm_syncobj_assign_null_handle(syncobjs[i]);
+ if (ret < 0)
+ break;
+ }
+
+ drm_syncobj_array_free(syncobjs, args->count_handles);
+
+ return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b037fdf..97677cd 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -861,6 +861,7 @@ extern "C" {
#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct
drm_syncobj_handle)
#define DRM_IOCTL_SYNCOBJ_WAIT DRM_IOWR(0xC3, struct drm_syncobj_wait)
#define DRM_IOCTL_SYNCOBJ_RESETDRM_IOWR(0xC4, struct
drm_syncobj_array)
+#define DRM_IOCTL_SYNCOBJ_SIGNAL DRM_IOWR(0xC5, struct drm_syncobj_array)
/**
* Device specific ioctls should only be in their respective headers
--
2.5.0.400.gff86faf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Git PULL] vmwgfx-next
Hi Dave, The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f: Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-next (2017-08-23 05:32:26 +1000) are available in the git repository at: git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-next for you to fetch changes up to d78acfe934e3b9f533f72ee3dde0982935fc2b32: drm/vmwgfx: Bump the version for fence FD support (2017-08-28 17:53:32 +0200) Sinclair Yeh (4): drm/vmwgfx: Prepare to support fence fd drm/vmwgfx: Add support for imported Fence File Descriptor drm/vmwgfx: Add export fence to file descriptor support drm/vmwgfx: Bump the version for fence FD support Thomas Hellstrom (5): drm/vmwgfx: Don't use drm_irq_[un]install drm/vmwgfx: Move irq bottom half processing to threads drm/vmwgfx: Restart command buffers after errors drm/vmwgfx: Support the NOP_ERROR command drm/vmwgfx: Fix incorrect command header offset at restart drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 242 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 39 ++ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 148 + drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 104 +- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 4 + drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 111 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- include/uapi/drm/vmwgfx_drm.h | 11 ++- 9 files changed, 511 insertions(+), 161 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_atomic_helper_shutdown() doesn't drop ref on active fb
On Mon, Aug 28, 2017 at 10:54 PM, Daniel Vetter wrote: > I don't see your code, but from the logs it sound like you're > replacing a call for this with the shutdown helper. That will ofcourse > the references the fb helper holds. You need both calls to clean up > everything in all cases. Oops, that got mangled, I meant to write: Drop fb_destroy will fail to clean up the references the fb helper holds. -Daniel -- 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_atomic_helper_shutdown() doesn't drop ref on active fb
On Mon, Aug 28, 2017 at 7:25 PM, Noralf Trønnes wrote: > Hi, > > If I use drm_atomic_helper_shutdown() when there's no framebuffer > active, it works fine, but if there is, it fails to drop a reference and > drm_mode_config_cleanup() complains that there are framebuffers left. > > The difference between using drm_atomic_helper_shutdown() and not using > it, is a fb put after the pipe is disabled (fb id = 33). > > Using drm_atomic_helper_shutdown() on device-driver unbind: > > [ 121.543588] [drm:drm_atomic_commit] committing d6c9bd80 > [ 121.543648] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [ENCODER:30:None-30] > [ 121.543671] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [CRTC:29:crtc-0] > [ 121.543719] [drm:mipi_dbi_pipe_disable [mipi_dbi]] > [ 121.543802] [drm:tinydrm_disable_backlight [tinydrm]] Backlight state: > 0x0 -> 0x2 > [ 121.543878] [drm:drm_atomic_state_default_clear] Clearing atomic state > d6c9bd80 > [ 121.543903] [drm:drm_mode_object_put] OBJ ID: 27 (5) > [ 121.543920] [drm:drm_mode_object_put] OBJ ID: 27 (4) > [ 121.543936] [drm:drm_mode_object_put] OBJ ID: 35 (1) > [ 121.543982] [drm:drm_mode_object_put] OBJ ID: 33 (3) > [ 121.543999] [drm:__drm_atomic_state_free] Freeing atomic state d6c9bd80 > > Not using drm_atomic_helper_shutdown() and just let it tear down when > the last file handle is closed: > > [ 72.021160] [drm:drm_atomic_commit] committing d6a48b40 > [ 72.021235] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [ENCODER:30:None-30] > [ 72.021257] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [CRTC:29:crtc-0] > [ 72.021307] [drm:mipi_dbi_pipe_disable [mipi_dbi]] > [ 72.021381] [drm:drm_mode_object_put] OBJ ID: 33 (3) > [ 72.021401] [drm:drm_atomic_state_default_clear] Clearing atomic state > d6a48b40 > [ 72.021416] [drm:drm_mode_object_put] OBJ ID: 27 (3) > [ 72.021431] [drm:drm_mode_object_put] OBJ ID: 27 (2) > [ 72.021461] [drm:drm_mode_object_put] OBJ ID: 35 (1) > [ 72.021489] [drm:drm_mode_object_put] OBJ ID: 33 (2) > [ 72.021504] [drm:__drm_atomic_state_free] Freeing atomic state d6a48b40 > > > More details: > > Calling drm_atomic_helper_shutdown(): > > [ 121.543048] [drm:drm_atomic_state_init] Allocated atomic state d6c9bd80 > [ 121.543106] [drm:drm_mode_object_get] OBJ ID: 35 (1) > [ 121.543127] [drm:drm_atomic_get_crtc_state] Added [CRTC:29:crtc-0] > d6db8400 state to d6c9bd80 > [ 121.543142] [drm:drm_mode_object_put] OBJ ID: 35 (2) > [ 121.543158] [drm:drm_atomic_set_mode_prop_for_crtc] Set [NOMODE] for CRTC > state d6db8400 > [ 121.543180] [drm:drm_mode_object_get] OBJ ID: 33 (3) > [ 121.543198] [drm:drm_atomic_get_plane_state] Added [PLANE:28:plane-0] > d6e5b180 state to d6c9bd80 > [ 121.543234] [drm:drm_atomic_add_affected_connectors] Adding all current > connectors for [CRTC:29:crtc-0] to d6c9bd80 > [ 121.543262] [drm:drm_mode_object_get] OBJ ID: 27 (5) > [ 121.543276] [drm:drm_mode_object_get] OBJ ID: 27 (6) > [ 121.543294] [drm:drm_atomic_get_connector_state] Added > [CONNECTOR:27:Virtual-1] d6e5b580 state to d6c9bd80 > [ 121.543307] [drm:drm_mode_object_put] OBJ ID: 27 (7) > [ 121.543337] [drm:drm_mode_object_put] OBJ ID: 27 (6) > [ 121.543352] [drm:drm_atomic_set_crtc_for_connector] Link connector state > d6e5b580 to [NOCRTC] > [ 121.543367] [drm:drm_atomic_set_crtc_for_plane] Link plane state d6e5b180 > to [NOCRTC] > [ 121.543379] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state > d6e5b180 > [ 121.543392] [drm:drm_mode_object_put] OBJ ID: 33 (4) > [ 121.543405] [drm:drm_atomic_check_only] checking d6c9bd80 > [ 121.543426] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] mode > changed > [ 121.543438] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] enable > changed > [ 121.543466] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] active > changed > [ 121.543483] [drm:drm_atomic_helper_check_modeset] Updating routing for > [CONNECTOR:27:Virtual-1] > [ 121.543495] [drm:drm_atomic_helper_check_modeset] Disabling > [CONNECTOR:27:Virtual-1] > [ 121.543512] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] needs > all connectors, enable: n, active: n > [ 121.543531] [drm:drm_atomic_add_affected_connectors] Adding all current > connectors for [CRTC:29:crtc-0] to d6c9bd80 > [ 121.543546] [drm:drm_mode_object_put] OBJ ID: 27 (6) > [ 121.543588] [drm:drm_atomic_commit] committing d6c9bd80 > [ 121.543648] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [ENCODER:30:None-30] > [ 121.543671] [drm:drm_atomic_helper_commit_modeset_disables] disabling > [CRTC:29:crtc-0] > [ 121.543719] [drm:mipi_dbi_pipe_disable [mipi_dbi]] > [ 121.543802] [drm:tinydrm_disable_backlight [tinydrm]] Backlight state: > 0x0 -> 0x2 > [ 121.543878] [drm:drm_atomic_state_default_clear] Clearing atomic state > d6c9bd80 > [ 121.543903] [drm:drm_mode_object_put] OBJ ID: 27 (5) > [ 121.543920] [drm:drm_mode_object_put] OBJ ID: 27 (4) > [
Re: DRM Format Modifiers in v4l2
On Mon, Aug 28, 2017 at 8:07 PM, Nicolas Dufresne wrote: > Le jeudi 24 août 2017 à 13:26 +0100, Brian Starkey a écrit : >> > What I mean was: an application can use the modifier to give buffers from >> > one device to another without needing to understand it. >> > >> > But a generic video capture application that processes the video itself >> > cannot be expected to know about the modifiers. It's a custom HW specific >> > format that you only use between two HW devices or with software written >> > for that hardware. >> > >> >> Yes, makes sense. >> >> > > >> > > However, in DRM the API lets you get the supported formats for each >> > > modifier as-well-as the modifier list itself. I'm not sure how exactly >> > > to provide that in a control. >> > >> > We have support for a 'menu' of 64 bit integers: >> > V4L2_CTRL_TYPE_INTEGER_MENU. >> > You use VIDIOC_QUERYMENU to enumerate the available modifiers. >> > >> > So enumerating these modifiers would work out-of-the-box. >> >> Right. So I guess the supported set of formats could be somehow >> enumerated in the menu item string. In DRM the pairs are (modifier + >> bitmask) where bits represent formats in the supported formats list >> (commit db1689aa61bd in drm-next). Printing a hex representation of >> the bitmask would be functional but I concede not very pretty. > > The problem is that the list of modifiers depends on the format > selected. Having to call S_FMT to obtain this list is quite > inefficient. > > Also, be aware that DRM_FORMAT_MOD_SAMSUNG_64_32_TILE modifier has been > implemented in V4L2 with a direct format (V4L2_PIX_FMT_NV12MT). I think > an other one made it the same way recently, something from Mediatek if > I remember. Though, unlike the Intel one, the same modifier does not > have various result depending on the hardware revision. Note on the intel modifers: On most recent platforms (iirc gen9) the modifier is well defined and always describes the same byte layout. We simply didn't want to rewrite our entire software stack for all the old gunk platforms, hence the language. I guess we could/should describe the layout in detail, but atm we're the only ones using it. On your topic of v4l2 encoding the drm fourcc+modifier combo into a special v4l fourcc: That's exactly the mismatch I was thinking of. There's other examples of v4l2 fourcc being more specific than their drm counters (e.g. specific way the different planes are laid out). -Daniel -- 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: Why shmem?
On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes wrote: > Hi, > > Currently I'm using the cma library with tinydrm because it was so > simple to use even though I have to work around the fact that reads are > uncached. A bigger problem that I have become aware of, is that it > restricts the dma buffers it can import since they have to be continous. > > So I looked to udl and it uses shmem. Fine, let's make a shmem gem > library similar to the cma library. > > Now I have done so and have started to think about the DOC: section, > explaining what the library does. And I'm stuck, what's the benefit of > using shmem compared to just using alloc_page()? Gives you swapping (and eventually maybe even migration) since there's a real filesystem behind it. Atm this only works if you register a shrinker callback, which for display drivers is a bit overkill. See i915 or msm for examples (or ttm, if you want an entire fancy framework), and git grep shrinker -- drivers/gpu. -Daniel -- 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: Why shmem?
Noralf Trønnes writes: > Hi, > > Currently I'm using the cma library with tinydrm because it was so > simple to use even though I have to work around the fact that reads are > uncached. A bigger problem that I have become aware of, is that it > restricts the dma buffers it can import since they have to be continous. > > So I looked to udl and it uses shmem. Fine, let's make a shmem gem > library similar to the cma library. > > Now I have done so and have started to think about the DOC: section, > explaining what the library does. And I'm stuck, what's the benefit of > using shmem compared to just using alloc_page()? Using shmem means that, when the buffer isn't pinned for DMA usage by the device, the pages can be swapped out. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Git PULL] vmwgfx-next
On Tue, Aug 29, 2017 at 06:35:38AM +1000, Dave Airlie wrote: > On 29 August 2017 at 06:22, Sinclair Yeh wrote: > > Hi Dave, > > > > The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f: > > Just a reminder, -next branches need to be sent before rc6 if you want > them in the next kernel. Sorry about this. We were finalizing a few patches. > > I'll take a look at this branch later since it's pretty late in the > day, but I'm merging some other stuff that was stuck so I'll see if > this has much impact. Ok, if it doesn't work, then we'll just get onto the next train. thanks, Sinclair ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Git PULL] vmwgfx-next
On 29 August 2017 at 06:22, Sinclair Yeh wrote: > Hi Dave, > > The following changes since commit 7c0059dd832cc686bf0febefdcf8295cdd93007f: Just a reminder, -next branches need to be sent before rc6 if you want them in the next kernel. I'll take a look at this branch later since it's pretty late in the day, but I'm merging some other stuff that was stuck so I'll see if this has much impact. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm: Why shmem?
Hi, Currently I'm using the cma library with tinydrm because it was so simple to use even though I have to work around the fact that reads are uncached. A bigger problem that I have become aware of, is that it restricts the dma buffers it can import since they have to be continous. So I looked to udl and it uses shmem. Fine, let's make a shmem gem library similar to the cma library. Now I have done so and have started to think about the DOC: section, explaining what the library does. And I'm stuck, what's the benefit of using shmem compared to just using alloc_page()? Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #5 from Takashi Iwai (ti...@suse.de) --- It doesn't matter what zypper says. Simply check initrd content via lsinitrd. If the target firmware file is found there, it's OK. If not, that's the problem. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #4 from Walther Pelser (w.pel...@web.de) --- Correction: Taken from: var/log/zypper/history -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #3 from Walther Pelser (w.pel...@web.de) --- Created attachment 258139 --> https://bugzilla.kernel.org/attachment.cgi?id=258139&action=edit dracut logs during kernel installation -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 --- Comment #2 from Walther Pelser (w.pel...@web.de) --- (In reply to Takashi Iwai from comment #1) > Did you rebuild initrd after updating kernel-firmware containing > /lib/firmware/radeon/RV710_pfb.bin? kernel-firmware was installed at Di 15 Aug 2017 16:16:40 CEST. In the meantime there were a lot of updates of dracut, udev etc. Today, installed 4.13.rc6-2.1.g43edc52-vanilla in order to get a new entry of dracut in zypper/log I will add a new attachment taken var/log/zypper/log with 3 entries of dracut in var/log/zypper/log. Maybe this could answer your question properly. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm_atomic_helper_shutdown() doesn't drop ref on active fb
Hi, If I use drm_atomic_helper_shutdown() when there's no framebuffer active, it works fine, but if there is, it fails to drop a reference and drm_mode_config_cleanup() complains that there are framebuffers left. The difference between using drm_atomic_helper_shutdown() and not using it, is a fb put after the pipe is disabled (fb id = 33). Using drm_atomic_helper_shutdown() on device-driver unbind: [ 121.543588] [drm:drm_atomic_commit] committing d6c9bd80 [ 121.543648] [drm:drm_atomic_helper_commit_modeset_disables] disabling [ENCODER:30:None-30] [ 121.543671] [drm:drm_atomic_helper_commit_modeset_disables] disabling [CRTC:29:crtc-0] [ 121.543719] [drm:mipi_dbi_pipe_disable [mipi_dbi]] [ 121.543802] [drm:tinydrm_disable_backlight [tinydrm]] Backlight state: 0x0 -> 0x2 [ 121.543878] [drm:drm_atomic_state_default_clear] Clearing atomic state d6c9bd80 [ 121.543903] [drm:drm_mode_object_put] OBJ ID: 27 (5) [ 121.543920] [drm:drm_mode_object_put] OBJ ID: 27 (4) [ 121.543936] [drm:drm_mode_object_put] OBJ ID: 35 (1) [ 121.543982] [drm:drm_mode_object_put] OBJ ID: 33 (3) [ 121.543999] [drm:__drm_atomic_state_free] Freeing atomic state d6c9bd80 Not using drm_atomic_helper_shutdown() and just let it tear down when the last file handle is closed: [ 72.021160] [drm:drm_atomic_commit] committing d6a48b40 [ 72.021235] [drm:drm_atomic_helper_commit_modeset_disables] disabling [ENCODER:30:None-30] [ 72.021257] [drm:drm_atomic_helper_commit_modeset_disables] disabling [CRTC:29:crtc-0] [ 72.021307] [drm:mipi_dbi_pipe_disable [mipi_dbi]] [ 72.021381] [drm:drm_mode_object_put] OBJ ID: 33 (3) [ 72.021401] [drm:drm_atomic_state_default_clear] Clearing atomic state d6a48b40 [ 72.021416] [drm:drm_mode_object_put] OBJ ID: 27 (3) [ 72.021431] [drm:drm_mode_object_put] OBJ ID: 27 (2) [ 72.021461] [drm:drm_mode_object_put] OBJ ID: 35 (1) [ 72.021489] [drm:drm_mode_object_put] OBJ ID: 33 (2) [ 72.021504] [drm:__drm_atomic_state_free] Freeing atomic state d6a48b40 More details: Calling drm_atomic_helper_shutdown(): [ 121.543048] [drm:drm_atomic_state_init] Allocated atomic state d6c9bd80 [ 121.543106] [drm:drm_mode_object_get] OBJ ID: 35 (1) [ 121.543127] [drm:drm_atomic_get_crtc_state] Added [CRTC:29:crtc-0] d6db8400 state to d6c9bd80 [ 121.543142] [drm:drm_mode_object_put] OBJ ID: 35 (2) [ 121.543158] [drm:drm_atomic_set_mode_prop_for_crtc] Set [NOMODE] for CRTC state d6db8400 [ 121.543180] [drm:drm_mode_object_get] OBJ ID: 33 (3) [ 121.543198] [drm:drm_atomic_get_plane_state] Added [PLANE:28:plane-0] d6e5b180 state to d6c9bd80 [ 121.543234] [drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:29:crtc-0] to d6c9bd80 [ 121.543262] [drm:drm_mode_object_get] OBJ ID: 27 (5) [ 121.543276] [drm:drm_mode_object_get] OBJ ID: 27 (6) [ 121.543294] [drm:drm_atomic_get_connector_state] Added [CONNECTOR:27:Virtual-1] d6e5b580 state to d6c9bd80 [ 121.543307] [drm:drm_mode_object_put] OBJ ID: 27 (7) [ 121.543337] [drm:drm_mode_object_put] OBJ ID: 27 (6) [ 121.543352] [drm:drm_atomic_set_crtc_for_connector] Link connector state d6e5b580 to [NOCRTC] [ 121.543367] [drm:drm_atomic_set_crtc_for_plane] Link plane state d6e5b180 to [NOCRTC] [ 121.543379] [drm:drm_atomic_set_fb_for_plane] Set [NOFB] for plane state d6e5b180 [ 121.543392] [drm:drm_mode_object_put] OBJ ID: 33 (4) [ 121.543405] [drm:drm_atomic_check_only] checking d6c9bd80 [ 121.543426] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] mode changed [ 121.543438] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] enable changed [ 121.543466] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] active changed [ 121.543483] [drm:drm_atomic_helper_check_modeset] Updating routing for [CONNECTOR:27:Virtual-1] [ 121.543495] [drm:drm_atomic_helper_check_modeset] Disabling [CONNECTOR:27:Virtual-1] [ 121.543512] [drm:drm_atomic_helper_check_modeset] [CRTC:29:crtc-0] needs all connectors, enable: n, active: n [ 121.543531] [drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:29:crtc-0] to d6c9bd80 [ 121.543546] [drm:drm_mode_object_put] OBJ ID: 27 (6) [ 121.543588] [drm:drm_atomic_commit] committing d6c9bd80 [ 121.543648] [drm:drm_atomic_helper_commit_modeset_disables] disabling [ENCODER:30:None-30] [ 121.543671] [drm:drm_atomic_helper_commit_modeset_disables] disabling [CRTC:29:crtc-0] [ 121.543719] [drm:mipi_dbi_pipe_disable [mipi_dbi]] [ 121.543802] [drm:tinydrm_disable_backlight [tinydrm]] Backlight state: 0x0 -> 0x2 [ 121.543878] [drm:drm_atomic_state_default_clear] Clearing atomic state d6c9bd80 [ 121.543903] [drm:drm_mode_object_put] OBJ ID: 27 (5) [ 121.543920] [drm:drm_mode_object_put] OBJ ID: 27 (4) [ 121.543936] [drm:drm_mode_object_put] OBJ ID: 35 (1) [ 121.543982] [drm:drm_mode_object_put] OBJ ID: 33 (3) [ 121.543999] [drm:__drm_atomic_state_free] Freeing atomic state d6c9bd80 Not using drm_atomic_helper_
[PATCH 5/6] drm/tinydrm/mi0283qt: Let the display pipe handle power
It's better to leave power handling and controller init to the
modesetting machinery using the simple pipe .enable and .disable
callbacks. Remove the probe done message since drm_dev_register()
already puts out one.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 69 --
drivers/gpu/drm/tinydrm/mipi-dbi.c | 10 +++---
2 files changed, 20 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 77d40c9..2465489 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -20,9 +20,11 @@
#include
#include
-static int mi0283qt_init(struct mipi_dbi *mipi)
+static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
{
- struct tinydrm_device *tdev = &mipi->tinydrm;
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
struct device *dev = tdev->drm.dev;
u8 addr_mode;
int ret;
@@ -31,20 +33,19 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
ret = regulator_enable(mipi->regulator);
if (ret) {
- dev_err(dev, "Failed to enable regulator %d\n", ret);
- return ret;
+ dev_err(dev, "Failed to enable regulator (%d)\n", ret);
+ return;
}
- /* Avoid flicker by skipping setup if the bootloader has done it */
if (mipi_dbi_display_is_on(mipi))
- return 0;
+ goto out_enable;
mipi_dbi_hw_reset(mipi);
ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
if (ret) {
- dev_err(dev, "Error sending command %d\n", ret);
+ dev_err(dev, "Error sending command (%d)\n", ret);
regulator_disable(mipi->regulator);
- return ret;
+ return;
}
msleep(20);
@@ -110,19 +111,12 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
msleep(100);
- return 0;
-}
-
-static void mi0283qt_fini(void *data)
-{
- struct mipi_dbi *mipi = data;
-
- DRM_DEBUG_KMS("\n");
- regulator_disable(mipi->regulator);
+out_enable:
+ mipi_dbi_pipe_enable(pipe, crtc_state);
}
static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
- .enable = mipi_dbi_pipe_enable,
+ .enable = mi0283qt_enable,
.disable = mipi_dbi_pipe_disable,
.update = tinydrm_display_pipe_update,
.prepare_fb = tinydrm_display_pipe_prepare_fb,
@@ -163,7 +157,6 @@ MODULE_DEVICE_TABLE(spi, mi0283qt_id);
static int mi0283qt_probe(struct spi_device *spi)
{
struct device *dev = &spi->dev;
- struct tinydrm_device *tdev;
struct mipi_dbi *mipi;
struct gpio_desc *dc;
u32 rotation = 0;
@@ -204,31 +197,9 @@ static int mi0283qt_probe(struct spi_device *spi)
if (ret)
return ret;
- ret = mi0283qt_init(mipi);
- if (ret)
- return ret;
-
- /* use devres to fini after drm unregister (drv->remove is before) */
- ret = devm_add_action(dev, mi0283qt_fini, mipi);
- if (ret) {
- mi0283qt_fini(mipi);
- return ret;
- }
-
- tdev = &mipi->tinydrm;
-
- ret = devm_tinydrm_register(tdev);
- if (ret)
- return ret;
-
spi_set_drvdata(spi, mipi);
- DRM_DEBUG_DRIVER("Initialized %s:%s @%uMHz on minor %d\n",
-tdev->drm.driver->name, dev_name(dev),
-spi->max_speed_hz / 100,
-tdev->drm.primary->index);
-
- return 0;
+ return devm_tinydrm_register(&mipi->tinydrm);
}
static void mi0283qt_shutdown(struct spi_device *spi)
@@ -241,25 +212,13 @@ static void mi0283qt_shutdown(struct spi_device *spi)
static int __maybe_unused mi0283qt_pm_suspend(struct device *dev)
{
struct mipi_dbi *mipi = dev_get_drvdata(dev);
- int ret;
-
- ret = tinydrm_suspend(&mipi->tinydrm);
- if (ret)
- return ret;
- mi0283qt_fini(mipi);
-
- return 0;
+ return tinydrm_suspend(&mipi->tinydrm);
}
static int __maybe_unused mi0283qt_pm_resume(struct device *dev)
{
struct mipi_dbi *mipi = dev_get_drvdata(dev);
- int ret;
-
- ret = mi0283qt_init(mipi);
- if (ret)
- return ret;
return tinydrm_resume(&mipi->tinydrm);
}
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index c22e352..f5b9b772 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -263,8 +263,9 @@ static const struct drm_framebuffer_funcs mipi_dbi_fb_funcs
= {
* @pipe: Display pipe
* @crtc_state: CRTC state
*
- * This function enables
[PATCH 3/6] drm/fb-cma-helper: Support device unplug
Add drm_fbdev_cma_dev_unplug() and use the drm_fb_helper device unplug
support. Pin driver module on fb_open().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_cma_helper.c | 139 +---
include/drm/drm_fb_cma_helper.h | 1 +
2 files changed, 68 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f2ee883..2b044be 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -25,8 +25,6 @@
#include
#include
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
const struct drm_framebuffer_funcs *fb_funcs;
@@ -238,6 +236,34 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
#endif
+static int drm_fbdev_cma_fb_open(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+
+ /*
+* The fb_ops definition resides in this library, meaning fb_open()
+* will take a ref on the library instead of the driver. Make sure the
+* driver module is pinned. Skip fbcon (user==0) since it can detach
+* itself on unregister_framebuffer().
+*/
+ if (user && !try_module_get(dev->driver->fops->owner))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int drm_fbdev_cma_fb_release(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+
+ if (user)
+ module_put(dev->driver->fops->owner);
+
+ return 0;
+}
+
static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
return dma_mmap_writecombine(info->device, vma, info->screen_base,
@@ -247,10 +273,13 @@ static int drm_fb_cma_mmap(struct fb_info *info, struct
vm_area_struct *vma)
static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
+ .fb_open= drm_fbdev_cma_fb_open,
+ .fb_release = drm_fbdev_cma_fb_release,
.fb_fillrect= drm_fb_helper_sys_fillrect,
.fb_copyarea= drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
.fb_mmap= drm_fb_cma_mmap,
+ .fb_destroy = drm_fb_helper_fb_destroy,
};
static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
@@ -262,52 +291,26 @@ static int drm_fbdev_cma_deferred_io_mmap(struct fb_info
*info,
return 0;
}
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
+static int drm_fbdev_cma_defio_init(struct drm_fb_helper *helper,
struct drm_gem_cma_object *cma_obj)
{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
+ struct fb_info *fbi = helper->fbdev;
+ int ret;
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
+ ret = drm_fb_helper_defio_init(helper);
+ if (ret)
+ return ret;
/* can't be offset from vaddr since dirty() uses cma_obj */
fbi->screen_buffer = cma_obj->vaddr;
/* fb_deferred_io_fault() needs a physical address */
fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdefio = fbdefio;
- fb_deferred_io_init(fbi);
fbi->fbops->fb_mmap = drm_fbdev_cma_deferred_io_mmap;
return 0;
}
-static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
-{
- if (!fbi->fbdefio)
- return;
-
- fb_deferred_io_cleanup(fbi);
- kfree(fbi->fbdefio);
- kfree(fbi->fbops);
-}
-
static int
drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
@@ -365,7 +368,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
fbi->fix.smem_len = size;
if (fbdev_cma->fb_funcs->dirty) {
- ret = drm_fbdev_cma_defio_init(fbi, obj);
+ ret = drm_fbdev_cma_defio_init(helper, obj);
if (ret)
goto err_cma_destroy;
}
@@ -399,7 +402,6 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct
drm_device *dev,
const struct drm_framebuffer_funcs *funcs)
{
struct drm_fbdev_cma *fbdev_cma;
- stru
[PATCH 1/6] drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend()
drm_fb_helper_resume_worker() uses fb_helper->fbdev to call
fb_set_suspend() which dereferences the pointer.
Move sync-canceling of the resume worker in drm_fb_helper_fini() before
setting fb_helper->fbdev to NULL.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1b8f013..2e33467 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -910,6 +910,8 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation || !fb_helper)
return;
+ cancel_work_sync(&fb_helper->resume_work);
+
info = fb_helper->fbdev;
if (info) {
if (info->cmap.len)
@@ -918,7 +920,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
fb_helper->fbdev = NULL;
- cancel_work_sync(&fb_helper->resume_work);
cancel_work_sync(&fb_helper->dirty_work);
mutex_lock(&kernel_fb_helper_lock);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/fb-helper: Support device unplug
Support device unplug by introducing a new initialization function:
drm_fb_helper_simple_init() which together with
drm_fb_helper_dev_unplug() and drm_fb_helper_fb_destroy() handles open
fbdev fd's after device unplug. There's also a
drm_fb_helper_simple_fini() for drivers who's device won't be removed.
It turns out that fbdev has the necessary ref counting, so
unregister_framebuffer() together with fb_ops->destroy handles unplug
with open fd's. The ref counting doesn't apply to the fb_info structure
itself, but to use of the fbdev framebuffer.
Analysis of entry points after unregister_framebuffer():
- fbcon has been unbound (through notifier)
- sysfs files removed
First we look at possible operations on open fbdev file handles:
static const struct file_operations fb_fops = {
.read = fb_read,
.write =fb_write,
.unlocked_ioctl = fb_ioctl,
.compat_ioctl = fb_compat_ioctl,
.mmap = fb_mmap,
.open = fb_open,
.release = fb_release,
.get_unmapped_area = get_fb_unmapped_area,
.fsync =fb_deferred_io_fsync,
};
Not possible after unregister:
fb_open() -> fb_ops.fb_open
Protected by file_fb_info() (-ENODEV):
fb_read() -> fb_ops.fb_read : drm_fb_helper_sys_read()
fb_write() -> fb_ops.fb_write : drm_fb_helper_sys_write()
fb_ioctl() -> fb_ops.fb_ioctl : drm_fb_helper_ioctl()
fb_compat_ioctl() -> fb_ops.fb_compat_ioctl
fb_mmap() -> fb_ops.fb_mmap
Safe:
fb_release() -> fb_ops.fb_release
get_fb_unmapped_area() : info->screen_base
fb_deferred_io_fsync() : if (info->fbdefio) &info->deferred_work
Active mmap's will need the backing buffer to be present.
If deferred IO is used, mmap writes will via a worker generate calls to
drm_fb_helper_deferred_io() which in turn via a worker calls into
drm_fb_helper_dirty_work().
Secondly we look at the remaining struct fb_ops operations:
Called by fbcon:
- fb_ops.fb_fillrect : drm_fb_helper_{sys,cfb}_fillrect()
- fb_ops.fb_copyarea : drm_fb_helper_{sys,cfb}_copyarea()
- fb_ops.fb_imageblit : drm_fb_helper_{sys,cfb}_imageblit()
Called in fb_set_var() which is called from ioctl, sysfs and fbcon:
- fb_ops.fb_check_var : drm_fb_helper_check_var()
- fb_ops.fb_set_par : drm_fb_helper_set_par()
drm_fb_helper_set_par() is also called from drm_fb_helper_hotplug_event().
Called in fb_set_cmap() which is called from fb_set_var(), ioctl
and fbcon:
- fb_ops.fb_setcolreg
- fb_ops.fb_setcmap : drm_fb_helper_setcmap()
Called in fb_blank() which is called from ioctl and fbcon:
- fb_ops.fb_blank : drm_fb_helper_blank()
Called in fb_pan_display() which is called from fb_set_var(), ioctl,
sysfs and fbcon:
- fb_ops.fb_pan_display : drm_fb_helper_pan_display()
Called by fbcon:
- fb_ops.fb_cursor
Called in fb_read(), fb_write(), and fb_get_buffer_offset() which is
called by fbcon:
- fb_ops.fb_sync
Called by fb_set_var():
- fb_ops.fb_get_caps
Called by fbcon:
- fb_ops.fb_debug_enter : drm_fb_helper_debug_enter()
- fb_ops.fb_debug_leave : drm_fb_helper_debug_leave()
Destroy is safe
- fb_ops.fb_destroy
Finally we look at other call paths:
drm_fb_helper_set_suspend{_unlocked}() and
drm_fb_helper_resume_worker():
Calls into fb_set_suspend(), but that's fine since it just uses the
fbdev notifier.
drm_fb_helper_restore_fbdev_mode_unlocked():
Called from drm_driver.last_close, possibly after drm_fb_helper_fini().
drm_fb_helper_force_kernel_mode():
Triggered by sysrq, possibly after unplug, but before
drm_fb_helper_fini().
drm_fb_helper_hotplug_event():
Called by drm_kms_helper_hotplug_event(). I don't know if this can be
called after drm_dev_unregister(), so add a check to be safe.
Based on this analysis the following functions get a
drm_dev_is_unplugged() check:
- drm_fb_helper_restore_fbdev_mode_unlocked()
- drm_fb_helper_force_kernel_mode()
- drm_fb_helper_hotplug_event()
- drm_fb_helper_dirty_work()
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 204 +++-
include/drm/drm_fb_helper.h | 35 +++
2 files changed, 237 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2e33467..fc898db 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -105,6 +105,158 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* mmap page writes.
*/
+/**
+ * drm_fb_helper_simple_init - Simple fbdev emulation initialization
+ * @dev: drm device
+ * @fb_helper: driver-allocated fbdev helper structure to initialize
+ * @bpp_sel: bpp value to use for the framebuffer configuration
+ * @max_conn_count: max connector count
+ * @funcs: pointer to structure of functions associate with this helper
+ *
+ * Simple fbdev emulation initialization which calls the following functions:
+ * drm_fb_helper_prepare(), drm_fb_helper_init(),
+ * drm_fb_helper_single_add_all_connectors() and
+ * drm_fb_helper_initial_config().
+ *
+ * This function takes a ref on
[PATCH 6/6] drm/tinydrm: Support device unplug
Support device unplugging to make tinydrm suitable for USB devices.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 69 -
drivers/gpu/drm/tinydrm/mi0283qt.c | 4 ++
drivers/gpu/drm/tinydrm/mipi-dbi.c | 5 ++-
drivers/gpu/drm/tinydrm/repaper.c | 9 +++-
drivers/gpu/drm/tinydrm/st7586.c| 9 +++-
include/drm/tinydrm/tinydrm.h | 5 +++
6 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index f11f4cd..3ccbcc5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -32,6 +32,29 @@
* The driver allocates &tinydrm_device, initializes it using
* devm_tinydrm_init(), sets up the pipeline using tinydrm_display_pipe_init()
* and registers the DRM device using devm_tinydrm_register().
+ *
+ * Device unplug
+ * -
+ *
+ * tinydrm supports device unplugging when there's still open DRM or fbdev file
+ * handles.
+ *
+ * There are 2 ways for driver-device unbinding to happen:
+ *
+ * - The driver module is unloaded causing the driver to be unregistered.
+ * This can't happen as long as there's open file handles because a reference
+ * is taken on the module.
+ *
+ * - The device is removed (USB, Device Tree overlay).
+ * This can happen at any time.
+ *
+ * The driver needs to protect device resources from access after the device is
+ * gone. This is done checking drm_dev_is_unplugged(), typically in
+ * &drm_framebuffer_funcs.dirty, &drm_simple_display_pipe_funcs.enable and
+ * \.disable. Resources that doesn't face userspace and is only used with the
+ * device can be setup using devm\_ functions, but &tinydrm_device must be
+ * allocated using plain kzalloc() since it's lifetime can exceed that of the
+ * device. tinydrm_release() will free the structure.
*/
/**
@@ -138,6 +161,29 @@ static const struct drm_mode_config_funcs
tinydrm_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
+/**
+ * tinydrm_release - DRM driver release helper
+ * @drm: DRM device
+ *
+ * This function cleans up and finalizes &drm_device and frees &tinydrm_device.
+ *
+ * Drivers must use this as their &drm_driver->release callback.
+ */
+void tinydrm_release(struct drm_device *drm)
+{
+ struct tinydrm_device *tdev = drm_to_tinydrm(drm);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ drm_mode_config_cleanup(drm);
+ drm_dev_fini(drm);
+
+ mutex_destroy(&tdev->dirty_lock);
+ kfree(tdev->fbdev_cma);
+ kfree(tdev);
+}
+EXPORT_SYMBOL(tinydrm_release);
+
static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
@@ -160,8 +206,6 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
static void tinydrm_fini(struct tinydrm_device *tdev)
{
- drm_mode_config_cleanup(&tdev->drm);
- mutex_destroy(&tdev->dirty_lock);
drm_dev_unref(&tdev->drm);
}
@@ -178,8 +222,8 @@ static void devm_tinydrm_release(void *data)
* @driver: DRM driver
*
* This function initializes @tdev, the underlying DRM device and it's
- * mode_config. Resources will be automatically freed on driver detach (devres)
- * using drm_mode_config_cleanup() and drm_dev_unref().
+ * mode_config. drm_dev_unref() is called on driver detach (devres) and when
+ * all refs are dropped, tinydrm_release() is called.
*
* Returns:
* Zero on success, negative error code on failure.
@@ -226,14 +270,17 @@ static int tinydrm_register(struct tinydrm_device *tdev)
static void tinydrm_unregister(struct tinydrm_device *tdev)
{
- struct drm_fbdev_cma *fbdev_cma = tdev->fbdev_cma;
-
drm_atomic_helper_shutdown(&tdev->drm);
- /* don't restore fbdev in lastclose, keep pipeline disabled */
- tdev->fbdev_cma = NULL;
- drm_dev_unregister(&tdev->drm);
- if (fbdev_cma)
- drm_fbdev_cma_fini(fbdev_cma);
+
+ /* Get a ref that will be put in tinydrm_fini() */
+ drm_dev_ref(&tdev->drm);
+
+ drm_fbdev_cma_dev_unplug(tdev->fbdev_cma);
+ drm_dev_unplug(&tdev->drm);
+
+ /* Make sure framebuffer flushing is done */
+ mutex_lock(&tdev->dirty_lock);
+ mutex_unlock(&tdev->dirty_lock);
}
static void devm_tinydrm_register_release(void *data)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 2465489..84ab8d1 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -31,6 +31,9 @@ static void mi0283qt_enable(struct drm_simple_display_pipe
*pipe,
DRM_DEBUG_KMS("\n");
+ if (drm_dev_is_unplugged(&tdev->drm))
+ return;
+
ret = regulator_enable(mipi->regulat
[PATCH 4/6] drm/tinydrm: Embed drm_device in tinydrm_device
Might as well embed drm_device since tinydrm_device (embeds pipe struct
and fbdev pointer) needs to stick around after driver-device unbind to
handle open fd's after device removal.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 44 -
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
drivers/gpu/drm/tinydrm/mi0283qt.c | 8 +++---
drivers/gpu/drm/tinydrm/mipi-dbi.c | 12
drivers/gpu/drm/tinydrm/repaper.c | 10 +++
drivers/gpu/drm/tinydrm/st7586.c| 16 +--
include/drm/tinydrm/tinydrm.h | 9 +-
7 files changed, 50 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 551709e..f11f4cd 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -44,7 +44,7 @@
*/
void tinydrm_lastclose(struct drm_device *drm)
{
- struct tinydrm_device *tdev = drm->dev_private;
+ struct tinydrm_device *tdev = drm_to_tinydrm(drm);
DRM_DEBUG_KMS("\n");
drm_fbdev_cma_restore_mode(tdev->fbdev_cma);
@@ -126,7 +126,7 @@ static struct drm_framebuffer *
tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- struct tinydrm_device *tdev = drm->dev_private;
+ struct tinydrm_device *tdev = drm_to_tinydrm(drm);
return drm_fb_cma_create_with_funcs(drm, file_priv, mode_cmd,
tdev->fb_funcs);
@@ -142,23 +142,16 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
{
- struct drm_device *drm;
+ struct drm_device *drm = &tdev->drm;
+ int ret;
mutex_init(&tdev->dirty_lock);
tdev->fb_funcs = fb_funcs;
- /*
-* We don't embed drm_device, because that prevent us from using
-* devm_kzalloc() to allocate tinydrm_device in the driver since
-* drm_dev_unref() frees the structure. The devm_ functions provide
-* for easy error handling.
-*/
- drm = drm_dev_alloc(driver, parent);
- if (IS_ERR(drm))
- return PTR_ERR(drm);
-
- tdev->drm = drm;
- drm->dev_private = tdev;
+ ret = drm_dev_init(drm, driver, parent);
+ if (ret)
+ return ret;
+
drm_mode_config_init(drm);
drm->mode_config.funcs = &tinydrm_mode_config_funcs;
@@ -167,10 +160,9 @@ static int tinydrm_init(struct device *parent, struct
tinydrm_device *tdev,
static void tinydrm_fini(struct tinydrm_device *tdev)
{
- drm_mode_config_cleanup(tdev->drm);
+ drm_mode_config_cleanup(&tdev->drm);
mutex_destroy(&tdev->dirty_lock);
- tdev->drm->dev_private = NULL;
- drm_dev_unref(tdev->drm);
+ drm_dev_unref(&tdev->drm);
}
static void devm_tinydrm_release(void *data)
@@ -212,12 +204,12 @@ EXPORT_SYMBOL(devm_tinydrm_init);
static int tinydrm_register(struct tinydrm_device *tdev)
{
- struct drm_device *drm = tdev->drm;
+ struct drm_device *drm = &tdev->drm;
int bpp = drm->mode_config.preferred_depth;
struct drm_fbdev_cma *fbdev;
int ret;
- ret = drm_dev_register(tdev->drm, 0);
+ ret = drm_dev_register(drm, 0);
if (ret)
return ret;
@@ -236,10 +228,10 @@ static void tinydrm_unregister(struct tinydrm_device
*tdev)
{
struct drm_fbdev_cma *fbdev_cma = tdev->fbdev_cma;
- drm_atomic_helper_shutdown(tdev->drm);
+ drm_atomic_helper_shutdown(&tdev->drm);
/* don't restore fbdev in lastclose, keep pipeline disabled */
tdev->fbdev_cma = NULL;
- drm_dev_unregister(tdev->drm);
+ drm_dev_unregister(&tdev->drm);
if (fbdev_cma)
drm_fbdev_cma_fini(fbdev_cma);
}
@@ -262,7 +254,7 @@ static void devm_tinydrm_register_release(void *data)
*/
int devm_tinydrm_register(struct tinydrm_device *tdev)
{
- struct device *dev = tdev->drm->dev;
+ struct device *dev = tdev->drm.dev;
int ret;
ret = tinydrm_register(tdev);
@@ -287,7 +279,7 @@ EXPORT_SYMBOL(devm_tinydrm_register);
*/
void tinydrm_shutdown(struct tinydrm_device *tdev)
{
- drm_atomic_helper_shutdown(tdev->drm);
+ drm_atomic_helper_shutdown(&tdev->drm);
}
EXPORT_SYMBOL(tinydrm_shutdown);
@@ -312,7 +304,7 @@ int tinydrm_suspend(struct tinydrm_device *tdev)
}
drm_fbdev_cma_set_suspend_unlocked(tdev->fbdev_cma, 1);
- state = drm_atomic_helper_suspend(tdev->drm);
+ state = drm_atomic_helper_suspend(&tdev->drm);
if (IS_ERR(state)) {
drm_fbdev_cma_set_suspend_unlocked(tdev->fbdev_cma, 0);
retur
[PATCH 0/6] drm/tinydrm: Support device unplug
This adds device unplug support to drm_fb_helper, drm_fb_cma_helper (fbdev) and tinydrm. My motivation for doing this is to make tinydrm useable with USB devices. This discussion gave insight into the problem: [PATCH v5 2/6] drm/bridge: Add a devm_ allocator for panel bridge. https://lists.freedesktop.org/archives/dri-devel/2017-August/149376.html Noralf. Noralf Trønnes (6): drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend() drm/fb-helper: Support device unplug drm/fb-cma-helper: Support device unplug drm/tinydrm: Embed drm_device in tinydrm_device drm/tinydrm/mi0283qt: Let the display pipe handle power drm/tinydrm: Support device unplug drivers/gpu/drm/drm_fb_cma_helper.c | 139 +-- drivers/gpu/drm/drm_fb_helper.c | 207 +++- drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 109 ++- drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- drivers/gpu/drm/tinydrm/mi0283qt.c | 77 +++ drivers/gpu/drm/tinydrm/mipi-dbi.c | 27 ++-- drivers/gpu/drm/tinydrm/repaper.c | 19 ++- drivers/gpu/drm/tinydrm/st7586.c| 25 ++-- include/drm/drm_fb_cma_helper.h | 1 + include/drm/drm_fb_helper.h | 35 + include/drm/tinydrm/tinydrm.h | 14 +- 11 files changed, 460 insertions(+), 195 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 Takashi Iwai (ti...@suse.de) changed: What|Removed |Added CC||ti...@suse.de --- Comment #1 from Takashi Iwai (ti...@suse.de) --- Did you rebuild initrd after updating kernel-firmware containing /lib/firmware/radeon/RV710_pfb.bin? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196791] New: load for radeon/RV71O_pfd.bin failed with error -2
https://bugzilla.kernel.org/show_bug.cgi?id=196791 Bug ID: 196791 Summary: load for radeon/RV71O_pfd.bin failed with error -2 Product: Drivers Version: 2.5 Kernel Version: 4.13.rc6 f Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: w.pel...@web.de Regression: No Created attachment 258137 --> https://bugzilla.kernel.org/attachment.cgi?id=258137&action=edit part of journal log OS is openSUSE tumbleweed with radeon 4350. After Installation of kernel 4.13.rc6-2.1.g43edc52 (obs://build.opensuse.org/Kernel) booting problem with radeon 4350. Graphic Card could not be installed, booting only with default(?) graphic mode. See attachment. Building my own kernel from mainline: 4.13-rc7 2017-08-28 [tarball] has the same error. RV710_pfp.bin was always present in: /lib/firmware/4.13.0-rc7/radeon/ and /lib/firmware/radeon/ Why kernel fails to load it? kernel 4.13.0-rc2-1.gb545b87 (obs://build.opensuse.org/Kernel) was booting (Jul 30.) without this error. Actual kernel 4.12.8-1.2 is running without problems. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 83023] A problem related to Radeon DPM causes a corrupted console and black X display.
https://bugs.freedesktop.org/show_bug.cgi?id=83023 --- Comment #6 from Alex Deucher --- (In reply to Pablo Estigarribia from comment #5) > I had to disable dpm on amdgpu too due to very similar bug on rx550 > https://bugs.freedesktop.org/show_bug.cgi?id=101976 Different hardware and different drivers. Not related even though the symptoms may be similar. -- 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 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers
https://bugs.freedesktop.org/show_bug.cgi?id=99195 --- Comment #12 from johnrory.odw...@gmail.com --- I have been meaning to update this bug report for a long time but I have been having difficulty getting back to a stable system with the right combination of kernel, mesa & xorg-x11-drv-ati. Downgrading mesa makes no difference. I suspect the problem is something in the kernel This bug is severe for me, leaving my system almost unusuable. GPU lockup can happen anywhere from turning on the laptop to just before I get to gdm to log in. If I manage to log in the session might only last a few minutes. A long lasting session is a rarity A hard reboot is necessary. Often when I turn back on the system it just goes straight away to a black screen. It doesn't even go the the Dell boot menu that gives the bios options etc. The card would seem to be alive. Sometimes in this situation I get a beeping sound from the hardware. However right now I seem to have hit a sweetspot with the following: kernel-4.12.8-300.fc26 mesa-17.1.7-1.fc26 xorg-x11-drv-ati-7.9.0-1.fc26 I get long sessions lasting possibly hours without lockup. I still do have some problems: 1: Even after a long session without a lockup if I shutdown the laptop normally and try to boot it a few hours later it just goes straight away to a black screen. It doesn't even go the the Dell boot menu that gives the bios options etc. 2:There are still the odd random lockup giving all the problems above Should I change tack & report a bug relating to the kernel instead? -- 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 5/10] drm/syncobj: Add a callback mechanism for replace_fence (v3)
It is useful in certain circumstances to know when the fence is replaced
in a syncobj. Specifically, it may be useful to know when the fence
goes from NULL to something valid. This does make syncobj_replace_fence
a little more expensive because it has to take a lock but, in the common
case where there is no callback list, it spends a very short amount of
time inside the lock.
v2:
- Don't lock in drm_syncobj_fence_get. We only really need to lock
around fence_replace to make the callback work.
v3:
- Fix the cb_list comment to make kbuild happy
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/drm_syncobj.c | 60 +--
include/drm/drm_syncobj.h | 39
2 files changed, 97 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4e8563c..bade497 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -80,6 +80,46 @@ struct drm_syncobj *drm_syncobj_find(struct drm_file
*file_private,
}
EXPORT_SYMBOL(drm_syncobj_find);
+static void drm_syncobj_add_callback_locked(struct drm_syncobj *syncobj,
+ struct drm_syncobj_cb *cb,
+ drm_syncobj_func_t func)
+{
+ cb->func = func;
+ list_add_tail(&cb->node, &syncobj->cb_list);
+}
+
+/**
+ * drm_syncobj_add_callback - adds a callback to syncobj::cb_list
+ * @syncobj: Sync object to which to add the callback
+ * @cb: Callback to add
+ * @func: Func to use when initializing the drm_syncobj_cb struct
+ *
+ * This adds a callback to be called next time the fence is replaced
+ */
+void drm_syncobj_add_callback(struct drm_syncobj *syncobj,
+ struct drm_syncobj_cb *cb,
+ drm_syncobj_func_t func)
+{
+ spin_lock(&syncobj->lock);
+ drm_syncobj_add_callback_locked(syncobj, cb, func);
+ spin_unlock(&syncobj->lock);
+}
+EXPORT_SYMBOL(drm_syncobj_add_callback);
+
+/**
+ * drm_syncobj_add_callback - removes a callback to syncobj::cb_list
+ * @syncobj: Sync object from which to remove the callback
+ * @cb: Callback to remove
+ */
+void drm_syncobj_remove_callback(struct drm_syncobj *syncobj,
+struct drm_syncobj_cb *cb)
+{
+ spin_lock(&syncobj->lock);
+ list_del_init(&cb->node);
+ spin_unlock(&syncobj->lock);
+}
+EXPORT_SYMBOL(drm_syncobj_remove_callback);
+
/**
* drm_syncobj_replace_fence - replace fence in a sync object.
* @syncobj: Sync object to replace fence in
@@ -91,10 +131,24 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *fence)
{
struct dma_fence *old_fence;
+ struct drm_syncobj_cb *cur, *tmp;
if (fence)
dma_fence_get(fence);
- old_fence = xchg(&syncobj->fence, fence);
+
+ spin_lock(&syncobj->lock);
+
+ old_fence = syncobj->fence;
+ syncobj->fence = fence;
+
+ if (fence != old_fence) {
+ list_for_each_entry_safe(cur, tmp, &syncobj->cb_list, node) {
+ list_del_init(&cur->node);
+ cur->func(syncobj, cur);
+ }
+ }
+
+ spin_unlock(&syncobj->lock);
dma_fence_put(old_fence);
}
@@ -130,7 +184,7 @@ void drm_syncobj_free(struct kref *kref)
struct drm_syncobj *syncobj = container_of(kref,
struct drm_syncobj,
refcount);
- dma_fence_put(syncobj->fence);
+ drm_syncobj_replace_fence(syncobj, NULL);
kfree(syncobj);
}
EXPORT_SYMBOL(drm_syncobj_free);
@@ -146,6 +200,8 @@ static int drm_syncobj_create(struct drm_file *file_private,
return -ENOMEM;
kref_init(&syncobj->refcount);
+ INIT_LIST_HEAD(&syncobj->cb_list);
+ spin_lock_init(&syncobj->lock);
idr_preload(GFP_KERNEL);
spin_lock(&file_private->syncobj_table_lock);
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index ce94d14..c00fee5 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -28,6 +28,8 @@
#include "linux/dma-fence.h"
+struct drm_syncobj_cb;
+
/**
* struct drm_syncobj - sync object.
*
@@ -43,15 +45,47 @@ struct drm_syncobj {
/**
* @fence:
* NULL or a pointer to the fence bound to this object.
+*
+* This field should not be used directly. Use drm_syncobj_fence_get
+* and drm_syncobj_replace_fence instead.
*/
struct dma_fence *fence;
/**
+* @cb_list:
+* List of callbacks to call when the fence gets replaced
+*/
+ struct list_head cb_list;
+ /**
+* @lock:
+* locks cb_list and write-locks fence.
+*/
+ spinlock_t lock;
+ /**
* @file:
Re: [PATCH] drm/syncobj: Fix the cb_list comment
Never mind this one. I'm squashing this into the relavant patch and
sending a v2 of that one patch
On Mon, Aug 28, 2017 at 7:33 AM, Jason Ekstrand
wrote:
> Signed-off-by: Jason Ekstrand
> ---
> include/drm/drm_syncobj.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index aef7c10..c00fee5 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -51,7 +51,7 @@ struct drm_syncobj {
> */
> struct dma_fence *fence;
> /**
> -* @list:
> +* @cb_list:
> * List of callbacks to call when the fence gets replaced
> */
> struct list_head cb_list;
> --
> 2.5.0.400.gff86faf
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/syncobj: Fix the cb_list comment
Signed-off-by: Jason Ekstrand
---
include/drm/drm_syncobj.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index aef7c10..c00fee5 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -51,7 +51,7 @@ struct drm_syncobj {
*/
struct dma_fence *fence;
/**
-* @list:
+* @cb_list:
* List of callbacks to call when the fence gets replaced
*/
struct list_head cb_list;
--
2.5.0.400.gff86faf
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)
https://bugs.freedesktop.org/show_bug.cgi?id=102358 --- Comment #17 from har...@gmx.de --- @Michel, i did just now, but WarThunder freeze behavoir didn't really change. xorg.conf: Section "Device" Identifier "AMD" Driver "modesetting" EndSection DRI 3 is used per default too (X.Org X Server 1.19.3). BTW: i have tested with my older pitcairn (HD7870), trying amdgpu and radeon kernel driver. The behavoir is the same as with tonga in both cases. -- 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 74203] Window corruption on dual-GPU (integrated+discrete) Radeon setup in GNOME 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=74203 --- Comment #7 from Michel Dänzer --- Does this still happen with current versions of the kernel, Mesa and xf86-video-ati? -- 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 libdrm 1/1] i915 perf framework changes for supporting DAPC
Cc: Lionel Landwerlin
Signed-off-by: Sourab Gupta
Signed-off-by: Sagar Arun Kamble
---
include/drm/i915_drm.h | 87 ++
1 file changed, 80 insertions(+), 7 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 5ebe046..d70f75f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -897,6 +897,11 @@ struct drm_i915_gem_execbuffer2 {
#define i915_execbuffer2_get_context_id(eb2) \
((eb2).rsvd1 & I915_EXEC_CONTEXT_ID_MASK)
+/* upper 32 bits of rsvd1 field contain tag */
+#define I915_EXEC_TAG_MASK (0xUL)
+#define i915_execbuffer2_get_tag(eb2) \
+ ((eb2).rsvd1 & I915_EXEC_TAG_MASK >> 32)
+
struct drm_i915_gem_pin {
/** Handle of the buffer to be pinned. */
__u32 handle;
@@ -1293,17 +1298,34 @@ struct drm_i915_gem_context_param {
};
enum drm_i915_oa_format {
- I915_OA_FORMAT_A13 = 1,
- I915_OA_FORMAT_A29,
- I915_OA_FORMAT_A13_B8_C8,
- I915_OA_FORMAT_B4_C8,
- I915_OA_FORMAT_A45_B8_C8,
- I915_OA_FORMAT_B4_C8_A16,
- I915_OA_FORMAT_C4_B8,
+ I915_OA_FORMAT_A13 = 1, /* HSW only */
+ I915_OA_FORMAT_A29, /* HSW only */
+ I915_OA_FORMAT_A13_B8_C8, /* HSW only */
+ I915_OA_FORMAT_B4_C8, /* HSW only */
+ I915_OA_FORMAT_A45_B8_C8, /* HSW only */
+ I915_OA_FORMAT_B4_C8_A16, /* HSW only */
+ I915_OA_FORMAT_C4_B8, /* HSW+ */
+
+ /* Gen8+ */
+ I915_OA_FORMAT_A12,
+ I915_OA_FORMAT_A12_B8_C8,
+ I915_OA_FORMAT_A32u40_A4u32_B8_C8,
I915_OA_FORMAT_MAX /* non-ABI */
};
+enum drm_i915_perf_sample_oa_source {
+ I915_PERF_SAMPLE_OA_SOURCE_OABUFFER,
+ I915_PERF_SAMPLE_OA_SOURCE_RCS,
+ I915_PERF_SAMPLE_OA_SOURCE_MAX /* non-ABI */
+};
+
+#define I915_PERF_MMIO_NUM_MAX 8
+struct drm_i915_perf_mmio_list {
+ __u32 num_mmio;
+ __u32 mmio_list[I915_PERF_MMIO_NUM_MAX];
+};
+
enum drm_i915_perf_property_id {
/**
* Open the stream for a specific context handle (as used with
@@ -1338,6 +1360,51 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_OA_EXPONENT,
+ /**
+* The value of this property set to 1 requests inclusion of sample
+* source field to be given to userspace. The sample source field
+* specifies the origin of OA report.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_OA_SOURCE,
+
+ /**
+* The value of this property specifies the GPU engine for which
+* the samples need to be collected. Specifying this property also
+* implies the command stream based sample collection.
+*/
+ DRM_I915_PERF_PROP_ENGINE,
+
+ /**
+* The value of this property set to 1 requests inclusion of context ID
+* in the perf sample data.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_CTX_ID,
+
+ /**
+* The value of this property set to 1 requests inclusion of pid in the
+* perf sample data.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_PID,
+
+ /**
+* The value of this property set to 1 requests inclusion of tag in the
+* perf sample data.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_TAG,
+
+ /**
+* The value of this property set to 1 requests inclusion of timestamp
+* in the perf sample data.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_TS,
+
+ /**
+* This property requests inclusion of mmio register values in the perf
+* sample data. The value of this property specifies the address of user
+* struct having the register addresses.
+*/
+ DRM_I915_PERF_PROP_SAMPLE_MMIO,
+
DRM_I915_PERF_PROP_MAX /* non-ABI */
};
@@ -1403,6 +1470,12 @@ enum drm_i915_perf_record_type {
* struct {
* struct drm_i915_perf_record_header header;
*
+* { u64 source; } && DRM_I915_PERF_PROP_SAMPLE_OA_SOURCE
+* { u64 ctx_id; } && DRM_I915_PERF_PROP_SAMPLE_CTX_ID
+* { u64 pid; } && DRM_I915_PERF_PROP_SAMPLE_PID
+* { u64 tag; } && DRM_I915_PERF_PROP_SAMPLE_TAG
+* { u64 timestamp; } && DRM_I915_PERF_PROP_SAMPLE_TS
+* { u32 mmio[]; } && DRM_I915_PERF_PROP_SAMPLE_MMIO
* { u32 oa_report[]; } && DRM_I915_PERF_PROP_SAMPLE_OA
* };
*/
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196789] WARNING: generic_reg_update_ex+0x112/0x180 [amdgpu on Vega 10]
https://bugzilla.kernel.org/show_bug.cgi?id=196789 --- Comment #2 from Vedran Miletić (ved...@miletic.net) --- Unfortunately, doesn't seem to be the case here. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.
Hi Daniel,
On 28 August 2017 at 16:51, Daniel Vetter wrote:
> On Mon, Aug 28, 2017 at 04:44:30PM +0800, Xinliang Liu wrote:
>> Hi,
>>
>> On 15 August 2017 at 22:14, Peter Griffin wrote:
>>
>> > This patch fixes the following soft lockup:
>> > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>> >
>> > On weston idle-timeout the IP is powered down and reset
>> > asserted. On weston resume we get a massive vblank
>> > IRQ storm due to the LDI registers having lost some state.
>> >
>> > This state loss is caused by ade_crtc_atomic_begin() not
>> > calling ade_ldi_set_mode(). With this patch applied
>> > resuming from Weston idle-timeout works well.
>> >
>> > Signed-off-by: Peter Griffin
>> > Tested-by: John Stultz
>> >
>>
>> Thanks Peter,
>> This patch looks good to me.
>> Reviewed-by: Xinliang Liu
>>
>> @Sean, could you please help to apply to drm-misc if others has no more
>> comments, thanks.
>
> hisilicon isn't maintained in drm-misc, and you're the maintainer. This is
> not how it works. So either
> a) pick up the patch and send out a pull request to Dave Airlie
> b) move hisilicon over to drm-misc and become a drm-misc maintainer
> yourself. This needs a MAINTAINERS update to point the git tree at
> drm-misc.
>
> drm-misc maintainers don't maintain everyone else's driver as a service,
> that simply doesn't scale.
Sorry for my misunderstanding and thanks for pointing out that how
drm-misc works.
So I will pick up the patch and send a pull request.
Thanks,
Xinliang
>
> Thanks, Daniel
>
>>
>> Thanks,
>> Xinliang
>>
>>
>> > Cc: sta...@vger.kernel.org
>> > ---
>> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > index c96c228..72c6357 100644
>> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
>> > @@ -519,9 +519,12 @@ static void ade_crtc_atomic_begin(struct drm_crtc
>> > *crtc,
>> > {
>> > struct ade_crtc *acrtc = to_ade_crtc(crtc);
>> > struct ade_hw_ctx *ctx = acrtc->ctx;
>> > + struct drm_display_mode *mode = &crtc->state->mode;
>> > + struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
>> >
>> > if (!ctx->power_on)
>> > (void)ade_power_up(ctx);
>> > + ade_ldi_set_mode(acrtc, mode, adj_mode);
>> > }
>> >
>> > static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
>> > --
>> > 2.7.4
>> >
>> > ___
>> > 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
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102423] kwin segfaults when Alt+Tabbing with windows thumbnails on AMDGPU
https://bugs.freedesktop.org/show_bug.cgi?id=102423 --- Comment #2 from leguen.yann...@gmail.com --- How can I provide such debugging symbols? -- 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: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.
On Mon, Aug 28, 2017 at 04:44:30PM +0800, Xinliang Liu wrote:
> Hi,
>
> On 15 August 2017 at 22:14, Peter Griffin wrote:
>
> > This patch fixes the following soft lockup:
> > BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
> >
> > On weston idle-timeout the IP is powered down and reset
> > asserted. On weston resume we get a massive vblank
> > IRQ storm due to the LDI registers having lost some state.
> >
> > This state loss is caused by ade_crtc_atomic_begin() not
> > calling ade_ldi_set_mode(). With this patch applied
> > resuming from Weston idle-timeout works well.
> >
> > Signed-off-by: Peter Griffin
> > Tested-by: John Stultz
> >
>
> Thanks Peter,
> This patch looks good to me.
> Reviewed-by: Xinliang Liu
>
> @Sean, could you please help to apply to drm-misc if others has no more
> comments, thanks.
hisilicon isn't maintained in drm-misc, and you're the maintainer. This is
not how it works. So either
a) pick up the patch and send out a pull request to Dave Airlie
b) move hisilicon over to drm-misc and become a drm-misc maintainer
yourself. This needs a MAINTAINERS update to point the git tree at
drm-misc.
drm-misc maintainers don't maintain everyone else's driver as a service,
that simply doesn't scale.
Thanks, Daniel
>
> Thanks,
> Xinliang
>
>
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > index c96c228..72c6357 100644
> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > @@ -519,9 +519,12 @@ static void ade_crtc_atomic_begin(struct drm_crtc
> > *crtc,
> > {
> > struct ade_crtc *acrtc = to_ade_crtc(crtc);
> > struct ade_hw_ctx *ctx = acrtc->ctx;
> > + struct drm_display_mode *mode = &crtc->state->mode;
> > + struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
> >
> > if (!ctx->power_on)
> > (void)ade_power_up(ctx);
> > + ade_ldi_set_mode(acrtc, mode, adj_mode);
> > }
> >
> > static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
> > --
> > 2.7.4
> >
> > ___
> > 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH] drm/hisilicon: Ensure LDI regs are properly configured.
Hi,
On 15 August 2017 at 22:14, Peter Griffin wrote:
> This patch fixes the following soft lockup:
> BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
>
> On weston idle-timeout the IP is powered down and reset
> asserted. On weston resume we get a massive vblank
> IRQ storm due to the LDI registers having lost some state.
>
> This state loss is caused by ade_crtc_atomic_begin() not
> calling ade_ldi_set_mode(). With this patch applied
> resuming from Weston idle-timeout works well.
>
> Signed-off-by: Peter Griffin
> Tested-by: John Stultz
>
Thanks Peter,
This patch looks good to me.
Reviewed-by: Xinliang Liu
@Sean, could you please help to apply to drm-misc if others has no more
comments, thanks.
Thanks,
Xinliang
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index c96c228..72c6357 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -519,9 +519,12 @@ static void ade_crtc_atomic_begin(struct drm_crtc
> *crtc,
> {
> struct ade_crtc *acrtc = to_ade_crtc(crtc);
> struct ade_hw_ctx *ctx = acrtc->ctx;
> + struct drm_display_mode *mode = &crtc->state->mode;
> + struct drm_display_mode *adj_mode = &crtc->state->adjusted_mode;
>
> if (!ctx->power_on)
> (void)ade_power_up(ctx);
> + ade_ldi_set_mode(acrtc, mode, adj_mode);
> }
>
> static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
> --
> 2.7.4
>
> ___
> 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
[Bug 101691] gfx corruption on windowed 3d-apps running on dGPU
https://bugs.freedesktop.org/show_bug.cgi?id=101691 --- Comment #37 from Michel Dänzer --- I wonder if it could be related to the caching attributes of the system memory pages being shared between the GPUs. AFAICT the amdgpu driver should end up treating them as non-cacheable, and correspondingly program the AMD GPU not to participate in cache coherency protocol for them. How does the i915 driver treat the pages of imported buffer objects? -- 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/tve200: Pass NULL format_modifier to drm_simple_display_pipe_init
On Fri, Aug 25, 2017 at 01:16:12PM -0700, Rodrigo Vivi wrote:
> This Fixes build on branches where we already have format-modifier.
>
> Reference:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/151044.html
> Fixes: e6fc3b68558e ("drm: Plumb modifiers through plane init")
tve200 was merged after this patch, the correct Fixes line would be:
Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
Linus, can you pls make sure that tve200 is enabled int the
drm-rerere/*arm*defconfig files, to avoid this in the future? They're the
recommended set to compile-test drm-misc (yes we should somehow bot-ify
this, but oh well).
Thanks, Daniel
> Cc: Linus Walleij
> Cc: Janet Morgan
> Cc: Ben Widawsky
> Cc: Daniel Stone (v2)
> Cc: Liviu Dudau
> Cc: Daniel Stone
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/tve200/tve200_display.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/tve200/tve200_display.c
> b/drivers/gpu/drm/tve200/tve200_display.c
> index 37fb31f3..3f4b97bf2a13 100644
> --- a/drivers/gpu/drm/tve200/tve200_display.c
> +++ b/drivers/gpu/drm/tve200/tve200_display.c
> @@ -336,6 +336,7 @@ int tve200_display_init(struct drm_device *drm)
> ret = drm_simple_display_pipe_init(drm, &priv->pipe,
> &tve200_display_funcs,
> formats, ARRAY_SIZE(formats),
> +NULL,
> &priv->connector.connector);
> if (ret)
> return ret;
> --
> 2.13.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate
On 23 August 2017 at 02:42, John Stultz wrote:
> Currently the hikey dsi logic cannot generate accurate byte
> clocks values for all pixel clock values. Thus if a mode clock
> is selected that cannot match the calculated byte clock, the
> device will boot with a blank screen.
>
> This patch uses the new mode_valid callback (many thanks to
> Jose Abreu for upstreaming it!) to ensure we don't select
> modes we cannot generate.
>
> Also, since the ade crtc code will adjust the mode in mode_set,
> this patch also adds a mode_fixup callback which we use to make
> sure we are validating the mode clock that will eventually be
> used.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Rob Clark
> Cc: Xinliang Liu
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: Jose Abreu
> Cc: Archit Taneja
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Sean Paul
>
Thanks John,
This patch looks good to me.
Reviewed-by: Xinliang Liu
Thanks,
Xinliang
> Signed-off-by: John Stultz
> ---
> v2: Reworked to calculate if modeclock matches the phy's
> byteclock, rather then using a whitelist of known modes.
>
> v3: Reworked to check across all possible crtcs (even though for
> us there is only one), and use mode_fixup instead of a custom
> function, as suggested by Jose and Daniel.
>
> v4: Fixes and improved error handling as suggested by Jose.
>
> v5: Small typo fix noted by Sean
> ---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 67
> +
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 14 ++
> 2 files changed, 81 insertions(+)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index f77dcfa..b4c7af3 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -603,6 +603,72 @@ static void dsi_encoder_enable(struct drm_encoder
> *encoder)
> dsi->enable = true;
> }
>
> +static enum drm_mode_status dsi_encoder_phy_mode_valid(
> + struct drm_encoder *encoder,
> + const struct drm_display_mode
> *mode)
> +{
> + struct dw_dsi *dsi = encoder_to_dsi(encoder);
> + struct mipi_phy_params phy;
> + u32 bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> + u32 req_kHz, act_kHz, lane_byte_clk_kHz;
> +
> + /* Calculate the lane byte clk using the adjusted mode clk */
> + memset(&phy, 0, sizeof(phy));
> + req_kHz = mode->clock * bpp / dsi->lanes;
> + act_kHz = dsi_calc_phy_rate(req_kHz, &phy);
> + lane_byte_clk_kHz = act_kHz / 8;
> +
> + DRM_DEBUG_DRIVER("Checking mode %ix%i-%i@%i clock: %i...",
> + mode->hdisplay, mode->vdisplay, bpp,
> + drm_mode_vrefresh(mode), mode->clock);
> +
> + /*
> +* Make sure the adjusted mode clock and the lane byte clk
> +* have a common denominator base frequency
> +*/
> + if (mode->clock/dsi->lanes == lane_byte_clk_kHz/3) {
> + DRM_DEBUG_DRIVER("OK!\n");
> + return MODE_OK;
> + }
> +
> + DRM_DEBUG_DRIVER("BAD!\n");
> + return MODE_BAD;
> +}
> +
> +static enum drm_mode_status dsi_encoder_mode_valid(struct drm_encoder
> *encoder,
> + const struct drm_display_mode
> *mode)
> +
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
> + struct drm_crtc *crtc = NULL;
> + struct drm_display_mode adj_mode;
> + enum drm_mode_status ret;
> +
> + /*
> +* The crtc might adjust the mode, so go through the
> +* possible crtcs (technically just one) and call
> +* mode_fixup to figure out the adjusted mode before we
> +* validate it.
> +*/
> + drm_for_each_crtc(crtc, encoder->dev) {
> + /*
> +* reset adj_mode to the mode value each time,
> +* so we don't adjust the mode twice
> +*/
> + drm_mode_copy(&adj_mode, mode);
> +
> + crtc_funcs = crtc->helper_private;
> + if (crtc_funcs && crtc_funcs->mode_fixup)
> + if (!crtc_funcs->mode_fixup(crtc, mode, &adj_mode))
> + return MODE_BAD;
> +
> + ret = dsi_encoder_phy_mode_valid(encoder, &adj_mode);
> + if (ret != MODE_OK)
> + return ret;
> + }
> + return MODE_OK;
> +}
> +
> static void dsi_encoder_mode_set(struct drm_encoder *encoder,
> struct drm_display_mode *mode,
> struct drm_display_mode *adj_mode)
> @@ -622,6 +688,7 @@ static int dsi_encoder_atomic_check(struct
> drm_encoder *encoder,
>
> static const struct drm_encoder_helper_funcs dw_encoder_helper_funcs = {
>
