[Bug 196379] Laptop loses performance at random bootups.
https://bugzilla.kernel.org/show_bug.cgi?id=196379 --- Comment #2 from Jani Nikula (jani.nik...@intel.com) --- If you think this is a graphics bug, please file it at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel Otherwise please assign it to some other component than video 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
[Bug 101837] libdrm fails to get bus id
https://bugs.freedesktop.org/show_bug.cgi?id=101837 --- Comment #4 from Lauri Kasanen --- The DRM node must be opened (and kept open for the lifetime of the app) to make the VRAM queries, or to make the register queries on kernels that prohibit direct access (e.g. Ubuntu). -- 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 v12 6/6] drm/i915: Introduce GEM proxy
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, July 19, 2017 7:20 PM
> To: Zhang, Tina ; intel-...@lists.freedesktop.org;
> intel-
> gvt-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; zhen...@linux.intel.com; Lv, Zhiyuan
> ; Wang, Zhi A ;
> alex.william...@redhat.com; kra...@redhat.com; dan...@ffwll.ch;
> kwankh...@nvidia.com; Tian, Kevin
> Cc: Zhang, Tina
> Subject: Re: [PATCH v12 6/6] drm/i915: Introduce GEM proxy
>
> s/GEM proxy/a GEM proxy object/
>
> Quoting Tina Zhang (2017-07-19 11:59:05)
>
> Rationale goes here.
Thanks for the comments. The idea behind the GEM proxy is that we want to
propose a kind of GEM which content is produced by the guest VM and used by
host. So, to host, this kind of GEM should be read only (both for CPU and GPU),
and host cannot use ioctls to change or modify the GEM.
I will add more comments in the next version. Thanks.
>
> > Signed-off-by: Tina Zhang
> > ---
> > drivers/gpu/drm/i915/i915_gem.c| 26 +-
> > drivers/gpu/drm/i915/i915_gem_object.h | 9 +
> > drivers/gpu/drm/i915/i915_gem_tiling.c | 5 +
> > 3 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c index 1b2dfa8..ebacc04 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1612,6 +1612,12 @@ i915_gem_set_domain_ioctl(struct drm_device
> *dev, void *data,
> > if (!obj)
> > return -ENOENT;
> >
> > + /* proxy gem object does not support setting domain */
>
> Yes, this is what the code is doing. The comment tells us why.
>
> /*
> * Proxy objects do not control access to the backing storage, ergo
> * they cannot be used as a means to manipulate the cache domain
> * tracking for that backing storage. The proxy object is always
> * considered to be outside of any cache domain.
> */
>
> However, set-domain does have some other side-effects that includes waiting
> which should still be performed, i.e. this check should be after the lockless
> wait.
Is it the requirement of this ioctl? Other ioctls here in this patch, won't
need it?
>
> > + if (i915_gem_object_is_proxy(obj)) {
> > + err = -EPERM;
> > + goto out;
> > + }
> > +
> > /* Try to flush the object off the GPU without holding the lock.
> > * We will repeat the flush holding the lock in the normal manner
> > * to catch cases where we are gazumped.
> > @@ -1680,6 +1686,12 @@ i915_gem_sw_finish_ioctl(struct drm_device
> *dev, void *data,
> > if (!obj)
> > return -ENOENT;
> >
>
> A comment could explain that since proxy objects are barred from CPU access,
> we do not need to ban sw_finish as it is a nop.
Agree.
>
> > + /* proxy gem obj does not support this operation */
> > + if (i915_gem_object_is_proxy(obj)) {
> > + i915_gem_object_put(obj);
> > + return -EPERM;
> > + }
> > +
> > /* Pinned buffers may be scanout, so flush the cache */
> > i915_gem_object_flush_if_display(obj);
> > i915_gem_object_put(obj);
> > @@ -1730,7 +1742,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> void *data,
> > */
> > if (!obj->base.filp) {
> > i915_gem_object_put(obj);
> > - return -EINVAL;
> > + return -EPERM;
> > }
> >
> > addr = vm_mmap(obj->base.filp, 0, args->size, @@ -3764,6
> > +3776,12 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void
> *data,
> > if (!obj)
> > return -ENOENT;
> >
> > + /* proxy gem obj does not support setting caching mode */
>
> More rationale. Also is the proxied object (its target) also banned from
> changing
> the PTE bits or do we inherit all such changes automatically?
From v2, cache_level isn't be set during the GEM generation, i.e.
cache_level=0. And the PTE bits which is set by guest, won't be modified by
host.
>
> > + if (i915_gem_object_is_proxy(obj)) {
> > + ret = -EPERM;
> > + goto out;
> > + }
> > +
> > if (obj->cache_level == level)
> > goto out;
> >
> > @@ -4210,6 +4228,12 @@ i915_gem_madvise_ioctl(struct drm_device
> *dev, void *data,
> > if (!obj)
> > return -ENOENT;
> >
> > + /* proxy gem obj does not support changing backding storage */
>
> This one could be generalised to I915_GEM_OBJECT_IS_SHRINKABLE?
I suppose no. The backend pages should always be the guest framebuffer. And
when to release it is up to user mode. If the kernel part senses the guest
framebuffer is changed, it will generate a new GEM/dma-buf with the new
framebuffer backend, to user mode.
>
> > + if (i915_gem_object_is_proxy(obj)) {
> > + er
[git pull] drm fixes for 4.13-rc2
Hi Linus, A bunch of fixes for rc2, two imx regressions, vc4 fix, dma-buf fix, some displayport mst fixes, and an amdkfd fix. Nothing too crazy, I assume we just haven't see much rc1 testing yet. Dave. The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877: Linux v4.13-rc1 (2017-07-15 15:22:10 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc2 for you to fetch changes up to 5896ec77d70d33dd38a455b0aa5f3154aeecea09: Merge tag 'imx-drm-fixes-2017-07-18' of git://git.pengutronix.de/git/pza/linux into drm-fixes (2017-07-21 14:04:44 +1000) imx, misc and amdkfd fixes Boris Brezillon (1): drm/vc4: Fix VBLANK handling in crtc->enable() path Chris Wilson (1): dma-buf/fence: Avoid use of uninitialised timestamp Dave Airlie (3): Merge tag 'drm-amdkfd-fixes-2017-07-18' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes Merge tag 'drm-misc-fixes-2017-07-20' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'imx-drm-fixes-2017-07-18' of git://git.pengutronix.de/git/pza/linux into drm-fixes Imre Deak (3): drm/mst: Fix error handling during MST sideband message reception drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req() drm/mst: Avoid processing partially received up/down message transactions Jay Cornwall (4): drm/amdgpu: Fix KFD oversubscription by tracking queues correctly drm/amdkfd: Remove unused references to shared_resources.num_mec drm/radeon: Remove initialization of shared_resources.num_mec drm/amdgpu: Remove unused field kgd2kfd_shared_resources.num_mec Laurentiu Palcu (1): drm/imx: fix typo in ipu_plane_formats[] Philipp Zabel (1): drm/imx: parallel-display: Accept drm_of_find_panel_or_bridge failure Sean Paul (1): Merge branch 'drm-misc-next-fixes' into drm-misc-fixes drivers/dma-buf/dma-fence.c| 17 ++ drivers/dma-buf/sync_debug.c | 2 +- drivers/dma-buf/sync_file.c| 8 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 4 -- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 --- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 1 - drivers/gpu/drm/amd/include/kgd_kfd_interface.h| 3 - drivers/gpu/drm/drm_dp_mst_topology.c | 41 +++--- drivers/gpu/drm/imx/ipuv3-plane.c | 2 +- drivers/gpu/drm/imx/parallel-display.c | 2 +- drivers/gpu/drm/radeon/radeon_kfd.c| 1 - drivers/gpu/drm/vc4/vc4_crtc.c | 66 ++ include/linux/dma-fence.h | 2 + 14 files changed, 95 insertions(+), 64 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob
On 17-07-14 22:10:15, Ville Syrjälä wrote: On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote: On 17-06-29 22:49:44, Ville Syrjälä wrote: [snip] > >... but here it's ALIGN(formats_offset+formats_size). I think we should >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to >make sure the header size always stays a multiple of 8 bytes. > >That's mainly because the design of the structure seems geared towards >expanding the header in the future (as in why else would you have the >offsets?). > I guess I don't quite understand what you're asking for. The first thing is determining a size, the second is finding an offset into the blob. If I remember my thinking correctly, then what I was trying to say was ALIGN(multiple_of_4, 8) + ALIGN(multiple_of_4, 8) != ALIGN(multiple_of_4 + multiple_of_4, 8) but the code was assuming that it's true, or that at least one of those things is a multiple of 8 already. Going with this and calling it sufficient. diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 0da6707a8cf7..5c14beee52ff 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -96,6 +96,7 @@ static int create_in_format_blob(struct drm_device *dev, struct drm_plane *plane /* Modifiers offset is a pointer to a struct with a 64 bit field so it * should be naturally aligned to 8B. */ + BUILD_BUG_ON(sizeof(struct drm_format_modifier_blob) % 8); blob_size += ALIGN(formats_size, 8); blob_size += modifiers_size; I don't mind changing this, but tell me what you want. BUILD_BUG_ON sounds good to me regardless. [snip] -- Ben Widawsky, Intel Open Source Technology Center -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101732] TURKS GPU - radeon 0000:01:00.0: failed to get a new IB (-35)
https://bugs.freedesktop.org/show_bug.cgi?id=101732 --- Comment #1 from Fede --- More Details which might be relevant and might have missed the first time around: Other packages: linux-firmware 20170422.ade8332-1 kernel 4.11.9-1 Xorg driver: xf86-video-ati 1:7.9.0-1 Have also seen the following when booting the radeon kernel module is loaded: Jul 21 09:51:06 hostname kernel: [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, giving up!!! Jul 21 09:51:06 hostname kernel: radeon :01:00.0: failed initializing UVD (-1). Jul 21 09:51:06 hostname kernel: [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out. Jul 21 09:51:06 hostname kernel: [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110). Jul 21 09:51:06 hostname kernel: [drm:radeon_device_init [radeon]] *ERROR* ib ring test failed (-110). Current situation: GDM with Wayland shows only white noise on the screen. Switching to Xorg shows the desktop as expected however it seems it is not using the radeon driver. As glxinfo puts it: OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 4.0, 256 bits) -- 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 101731] System freeze with AMDGPU when playing The Witcher 3
https://bugs.freedesktop.org/show_bug.cgi?id=101731 --- Comment #18 from Shmerl --- Actually, I just experienced the freeze bug again. I guess it's somehow random, and it's not truly gone :( -- 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
linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
9cc5bb18bd0a ("drm/i915: Fix bad comparison in skl_compute_plane_wm")
from the drm-intel-fixes tree and commit:
eac2cb81fb87 ("drm/i915: cleanup fixed-point wrappers naming")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/intel_pm.c
index 40b224b44d1b,ee2a349cfe68..
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@@ -4463,11 -4459,11 +4459,11 @@@ static int skl_compute_plane_wm(const s
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
- else if ((ddb_allocation && ddb_allocation /
- fixed16_to_u32_round_up(plane_blocks_per_line)) >= 1)
+ else if (ddb_allocation >=
-fixed_16_16_to_u32_round_up(plane_blocks_per_line))
- selected_result = min_fixed_16_16(method1, method2);
++ fixed16_to_u32_round_up(plane_blocks_per_line))
+ selected_result = min_fixed16(method1, method2);
else if (latency >= linetime_us)
- selected_result = min_fixed_16_16(method1, method2);
+ selected_result = min_fixed16(method1, method2);
else
selected_result = method1;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
The following conflict now exists between the drm and drm-intel trees.
On Thu, 20 Jul 2017 11:23:33 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_drv.c
>
> between commit:
>
> 99c539bef538 ("drm/i915: unregister interfaces first in unload")
>
> from the drm-intel tree and commit:
>
> baf54385af78 ("drm/i915: Drop drm_vblank_cleanup")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/i915_drv.c
> index f406aec8a499,04d9bd84ee43..
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@@ -1386,8 -1367,8 +1384,6 @@@ void i915_driver_unload(struct drm_devi
>
> intel_gvt_cleanup(dev_priv);
>
> - drm_vblank_cleanup(dev);
> -i915_driver_unregister(dev_priv);
> --
> intel_modeset_cleanup(dev);
>
> /*
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Dave,
The following is now applicable to the drm and staging.current trees ...
On Wed, 19 Jul 2017 11:46:57 +1000 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid'
> specified in initializer
> .set_busid = drm_pci_set_busid,
> ^
> drivers/staging/vboxvideo/vbox_drv.c:235:15: error: 'drm_pci_set_busid'
> undeclared here (not in a function)
> .set_busid = drm_pci_set_busid,
>^
> drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_init':
> drivers/staging/vboxvideo/vbox_drv.c:273:9: error: implicit declaration of
> function 'drm_pci_init' [-Werror=implicit-function-declaration]
> return drm_pci_init(&driver, &vbox_pci_driver);
> ^
> drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_exit':
> drivers/staging/vboxvideo/vbox_drv.c:278:2: error: implicit declaration of
> function 'drm_pci_exit' [-Werror=implicit-function-declaration]
> drm_pci_exit(&driver, &vbox_pci_driver);
> ^
>
> Caused by commits
>
> 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook")
> 10631d724def ("drm/pci: Deprecate drm_pci_init/exit completely")
>
> interacting with commit
>
> dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging")
>
> from the staging.current tree.
>
> I have applied the following merge fix patch - please check that it
> is correct.
>
> From: Stephen Rothwell
> Date: Wed, 19 Jul 2017 11:41:01 +1000
> Subject: [PATCH] drm: fixes for staging due to API changes in the drm core
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/staging/vboxvideo/vbox_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/vboxvideo/vbox_drv.c
> b/drivers/staging/vboxvideo/vbox_drv.c
> index 92ae1560a16d..6d0600c37c0c 100644
> --- a/drivers/staging/vboxvideo/vbox_drv.c
> +++ b/drivers/staging/vboxvideo/vbox_drv.c
> @@ -232,7 +232,6 @@ static struct drm_driver driver = {
> .lastclose = vbox_driver_lastclose,
> .master_set = vbox_master_set,
> .master_drop = vbox_master_drop,
> - .set_busid = drm_pci_set_busid,
>
> .fops = &vbox_fops,
> .irq_handler = vbox_irq_handler,
> @@ -270,12 +269,12 @@ static int __init vbox_init(void)
> if (vbox_modeset == 0)
> return -EINVAL;
>
> - return drm_pci_init(&driver, &vbox_pci_driver);
> + return pci_register_driver(&vbox_pci_driver);
> }
>
> static void __exit vbox_exit(void)
> {
> - drm_pci_exit(&driver, &vbox_pci_driver);
> + pci_unregister_driver(&vbox_pci_driver);
> }
>
> module_init(vbox_init);
> --
> 2.13.2
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Hi Dave,
The conflict below now exists between the drm-misc-fixes tree and the
drm tree.
On Tue, 18 Jul 2017 11:39:46 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/vc4/vc4_crtc.c
>
> between commit:
>
> 1ed134e6526b ("drm/vc4: Fix VBLANK handling in crtc->enable() path")
>
> from the drm-misc-fixes tree and commit:
>
> 0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper
> function")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/vc4/vc4_crtc.c
> index a12cc7ea99b6,9e0c1500375c..
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@@ -518,37 -519,23 +519,51 @@@ static void vc4_crtc_atomic_disable(str
> WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
> (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
>SCALER_DISPSTATX_EMPTY);
> +
> + /*
> + * Make sure we issue a vblank event after disabling the CRTC if
> + * someone was waiting it.
> + */
> + if (crtc->state->event) {
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dev->event_lock, flags);
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> + spin_unlock_irqrestore(&dev->event_lock, flags);
> + }
> }
>
> +static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
> +{
> +struct drm_device *dev = crtc->dev;
> +struct vc4_dev *vc4 = to_vc4_dev(dev);
> +struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> +
> +if (crtc->state->event) {
> +unsigned long flags;
> +
> +crtc->state->event->pipe = drm_crtc_index(crtc);
> +
> +WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> +
> +spin_lock_irqsave(&dev->event_lock, flags);
> +vc4_crtc->event = crtc->state->event;
> +crtc->state->event = NULL;
> +
> +HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> + vc4_state->mm.start);
> +
> +spin_unlock_irqrestore(&dev->event_lock, flags);
> +} else {
> +HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> + vc4_state->mm.start);
> +}
> +}
> +
> - static void vc4_crtc_enable(struct drm_crtc *crtc)
> + static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> +struct drm_crtc_state *old_state)
> {
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> @@@ -575,20 -556,22 +590,19 @@@
> /* Turn on the pixel valve, which will emit the vstart signal. */
> CRTC_WRITE(PV_V_CONTROL,
> CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
> -
> -/* Enable vblank irq handling after crtc is started. */
> -drm_crtc_vblank_on(crtc);
> }
>
> - static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode
> *mode)
> {
> /* Do not allow doublescan modes from user space */
> - if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> + if (mode->flags & DRM_MODE_FLAG_DBLSCAN) {
> DRM_DEBUG_KMS("[CRTC:%d] Doublescan mode rejected.\n",
> crtc->base.id);
> - return false;
> + return MODE_NO_DBLESCAN;
> }
>
> - return true;
> + return MODE_OK;
> }
>
> static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
> @@@ -650,15 -634,25 +664,15 @@@ static void vc4_crtc_atomic_flush(struc
>
> WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
>
> -if (crtc->state->event) {
> -unsigned long flags;
> -
> -crtc->state->event->pipe = drm_crtc_index(crtc);
> -
> -WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> -
> -spin_lock_irqsave(&dev->event_lock, flags);
> -vc4_crtc->event = crtc->state->event;
> -crtc->state->event = NULL;
> -
> -HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> - vc4_state->mm.start);
> -
> -spin_unlock_irqrestore(&dev->event_lock, flags);
>
Re: [Nouveau] [PATCH] drm: disable vblank only if it got previously enabled
On Thu, Jul 20, 2017 at 11:58 PM, Tobias Klausmann wrote: > Mh ok, > > paper over in nouveau_display_fini until Ben comes up with a better idea > then?! No paper needed, just don't call drm_vblank_off for the atomic case. Not sure why that patch isn't landed yet, it should be simple. -Daniel > > Greetings, > > Tobias > > > On 7/20/17 10:13 AM, Daniel Vetter wrote: >> On Wed, Jul 19, 2017 at 04:10:50PM -0400, Ilia Mirkin wrote: >>> I believe the solution is to not call drm_crtc_vblank_off for atomic >>> modesetting in nouveau_display_fini. I think Ben's working on it. >> Yes, the goal of vblank_on/off was very much to not paper over driver bugs >> with clever tricks like these. If the driver cant keep track of its >> vblank, something has gone wrong, and the core should _not_ fix it up. >> Otherwise we're back to the old style vblank horror show. >> >> Thanks, Daniel >> >>> On Wed, Jul 19, 2017 at 1:25 PM, Tobias Klausmann >>> wrote: mimic the behavior of vblank_disable_fn(), another caller of drm_vblank_disable_and_save(). This avoids oopsing, while trying to disable vblank on a not connected display: [ 12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm] [ 12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 hid_multitouch nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp vfat coretemp fat kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel ath10k_pci snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec crypto_simd ath glue_helper cryptd snd_hda_core mac80211 snd_hwdep snd_pcm pcspkr r8169 cfg80211 mii snd_timer acer_wmi snd sparse_keymap wmi_bmof idma64 hci_uart virt_dma mei_me soundcore i2c_i801 mei btbcm shpchp intel_lpss_pci intel_pch_thermal [ 12.768130] serdev btqca ucsi_acpi btintel typec_ucsi thermal typec bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill intel_lpss_acpi pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 mxm_wmi ttm i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect sysimgblt xhci_hcd fb_sys_fops usbcore drm i2c_hid wmi video button sg efivarfs [ 12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 4.12.0-desktop-debug-drm+ #2 [ 12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 03/30/2017 [ 12.768164] Workqueue: pm pm_runtime_work [ 12.768166] task: 889bf1627040 task.stack: 9541013e4000 [ 12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm] [ 12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086 [ 12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 0004 [ 12.768184] RDX: 8004 RSI: 87a2d952 RDI: [ 12.768186] RBP: 9541013e7b90 R08: 0001 R09: 039f [ 12.768187] R10: c05fe530 R11: R12: [ 12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 889bf0426000 [ 12.768190] FS: () GS:889bfec0() knlGS: [ 12.768191] CS: 0010 DS: ES: CR0: 80050033 [ 12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 003406f0 [ 12.768193] Call Trace: [ 12.768198] ? enqueue_task_fair+0x64/0x600 [ 12.768211] ? drm_get_last_vbltimestamp+0x47/0x70 [drm] [ 12.768223] ? drm_update_vblank_count+0x65/0x240 [drm] [ 12.768227] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768238] ? drm_vblank_disable_and_save+0x55/0xc0 [drm] [ 12.768250] ? drm_crtc_vblank_off+0xa9/0x1e0 [drm] [ 12.768253] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768299] ? nouveau_display_fini+0x56/0xd0 [nouveau] [ 12.768339] ? nouveau_display_suspend+0x51/0x110 [nouveau] [ 12.768378] ? nouveau_do_suspend+0x76/0x1c0 [nouveau] [ 12.768413] ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau] [ 12.768416] ? pci_pm_runtime_suspend+0x5c/0x160 [ 12.768419] ? __rpm_callback+0xb6/0x1e0 [ 12.768423] ? kobject_uevent_env+0x111/0x5e0 [ 12.768425] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768427] ? rpm_callback+0x1f/0x70 [ 12.768429] ? pci_pm_runtime_resume+0xa0/0xa0 [ 12.768431] ? rpm_suspend+0x11f/0x640 [ 12.768441] ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper] [ 12.768447] ? output_poll_execute+0x17b/0x1a0 [drm_
[PULL] drm-misc-fixes
Hi Dave, Here's the first -misc-fixes pull for the current cycle. Note that I've based it off Linus' tree, so you might want to ff drm-fixes before applying. Pretty self-explanatory set of patches, I'm sure you have a good handle on the mst group. The vc4 fix comes from drm-misc-next-fixes after the last pull was sent, so that merge is present in the shortlog. drm-misc-fixes-2017-07-20: Core Changes: - fence: Introduce new fence flag to signify timestamp is populated (Chris) - mst: Avoid processing incomplete data + fix NULL dereference (Imre) Driver Changes: - vc4: Avoid WARN from grabbing a ref from vblank that's not on (Boris) Cc: Chris Wilson Cc: Boris Brezillon Cc: Imre Deak Cheers, Sean The following changes since commit 6f6e0b217a93011f8e11b9a2d5521a08fcf36990: drm/rockchip: fix NULL check on devm_kzalloc() return value (2017-07-10 14:13:00 -0400) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-07-20 for you to fetch changes up to 636c4c3e762b62aa93632c645ca65879285b16e3: drm/mst: Avoid processing partially received up/down message transactions (2017-07-20 10:20:31 +0200) Core Changes: - fence: Introduce new fence flag to signify timestamp is populated (Chris) - mst: Avoid processing incomplete data + fix NULL dereference (Imre) Driver Changes: - vc4: Avoid WARN from grabbing a ref from vblank that's not on (Boris) Cc: Chris Wilson Cc: Boris Brezillon Cc: Imre Deak Boris Brezillon (1): drm/vc4: Fix VBLANK handling in crtc->enable() path Chris Wilson (1): dma-buf/fence: Avoid use of uninitialised timestamp Imre Deak (3): drm/mst: Fix error handling during MST sideband message reception drm/mst: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req() drm/mst: Avoid processing partially received up/down message transactions Sean Paul (1): Merge branch 'drm-misc-next-fixes' into drm-misc-fixes drivers/dma-buf/dma-fence.c | 17 - drivers/dma-buf/sync_debug.c | 2 +- drivers/dma-buf/sync_file.c | 8 - drivers/gpu/drm/drm_dp_mst_topology.c | 41 +- drivers/gpu/drm/vc4/vc4_crtc.c| 66 +++ include/linux/dma-fence.h | 2 ++ 6 files changed, 92 insertions(+), 44 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 v2 2/4] drm: Fix warning when building docs for scdc_helper
Fixes: ../drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation. ../drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. Changes in v2: - Property blockquote TMDS calculations so they look pretty (Daniel) - Remove duplicate documentation from the header file Signed-off-by: Sean Paul --- drivers/gpu/drm/drm_scdc_helper.c | 33 - include/drm/drm_scdc_helper.h | 25 - 2 files changed, 20 insertions(+), 38 deletions(-) diff --git a/drivers/gpu/drm/drm_scdc_helper.c b/drivers/gpu/drm/drm_scdc_helper.c index 3cd96a95736d..7d1b0f011d33 100644 --- a/drivers/gpu/drm/drm_scdc_helper.c +++ b/drivers/gpu/drm/drm_scdc_helper.c @@ -194,19 +194,26 @@ EXPORT_SYMBOL(drm_scdc_set_scrambling); * @adapter: I2C adapter for DDC channel * @set: ret or reset the high clock ratio * - * TMDS clock ratio calculations go like this: - * TMDS character = 10 bit TMDS encoded value - * TMDS character rate = The rate at which TMDS characters are transmitted(Mcsc) - * TMDS bit rate = 10x TMDS character rate - * As per the spec: - * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate - * = 1/10 pixel clock rate - * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate - * = 1/40 pixel clock rate - * - * Writes to the TMDS config register over SCDC channel, and: - * sets TMDS clock ratio to 1/40 when set = 1 - * sets TMDS clock ratio to 1/10 when set = 0 + * + * TMDS clock ratio calculations go like this: + * TMDS character = 10 bit TMDS encoded value + * + * TMDS character rate = The rate at which TMDS characters are + * transmitted (Mcsc) + * + * TMDS bit rate = 10x TMDS character rate + * + * As per the spec: + * TMDS clock rate for pixel clock < 340 MHz = 1x the character + * rate = 1/10 pixel clock rate + * + * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character + * rate = 1/40 pixel clock rate + * + * Writes to the TMDS config register over SCDC channel, and: + * sets TMDS clock ratio to 1/40 when set = 1 + * + * sets TMDS clock ratio to 1/10 when set = 0 * * Returns: * True if write is successful, false otherwise. diff --git a/include/drm/drm_scdc_helper.h b/include/drm/drm_scdc_helper.h index c25122bb490a..f92eb2094d6b 100644 --- a/include/drm/drm_scdc_helper.h +++ b/include/drm/drm_scdc_helper.h @@ -131,31 +131,6 @@ static inline int drm_scdc_writeb(struct i2c_adapter *adapter, u8 offset, bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter); -/** - * drm_scdc_set_scrambling - enable scrambling - * @adapter: I2C adapter for DDC channel - * @enable: bool to indicate if scrambling is to be enabled/disabled - * - * Writes the TMDS config register over SCDC channel, and: - * enables scrambling when enable = 1 - * disables scrambling when enable = 0 - * - * Returns: - * True if scrambling is set/reset successfully, false otherwise. - */ bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable); - -/** - * drm_scdc_set_high_tmds_clock_ratio - set TMDS clock ratio - * @adapter: I2C adapter for DDC channel - * @set: ret or reset the high clock ratio - * - * Writes to the TMDS config register over SCDC channel, and: - * sets TMDS clock ratio to 1/40 when set = 1 - * sets TMDS clock ratio to 1/10 when set = 0 - * - * Returns: - * True if write is successful, false otherwise. - */ bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool set); #endif -- 2.14.0.rc0.284.gd933b75aa4-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> The current drm_atomic_helper_commit_tail helper works only if the CRTC is
> accessible, and documents an alternative implementation that is supposed to
> be used if that happens.
>
> That implementation is then duplicated by some drivers. Instead of
> documenting it, let's implement an helper that all the relevant users can
> use directly.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Daniel Vetter
Should I throw this into drm-misc, or do you want to merge this through
some driver tree?
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c| 49 +++
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 27 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +--
> include/drm/drm_atomic_helper.h| 1 +-
> 4 files changed, 37 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 86d3093c6c9b..d06a65ed3a57 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1245,23 +1245,13 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
> * @old_state: atomic state object with old state structures
> *
> * This is the default implementation for the
> - * &drm_mode_config_helper_funcs.atomic_commit_tail hook.
> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
> + * that do not support runtime_pm or do not need the CRTC to be
> + * enabled to perform a commit. Otherwise, see
> + * drm_atomic_helper_commit_tail_rpm().
> *
> * Note that the default ordering of how the various stages are called is to
> - * match the legacy modeset helper library closest. One peculiarity of that
> is
> - * that it doesn't mesh well with runtime PM at all.
> - *
> - * For drivers supporting runtime PM the recommended sequence is instead ::
> - *
> - * drm_atomic_helper_commit_modeset_disables(dev, old_state);
> - *
> - * drm_atomic_helper_commit_modeset_enables(dev, old_state);
> - *
> - * drm_atomic_helper_commit_planes(dev, old_state,
> - * DRM_PLANE_COMMIT_ACTIVE_ONLY);
> - *
> - * for committing the atomic update to hardware. See the kerneldoc entries
> for
> - * these three functions for more details.
> + * match the legacy modeset helper library closest.
> */
> void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
> {
> @@ -1281,6 +1271,35 @@ void drm_atomic_helper_commit_tail(struct
> drm_atomic_state *old_state)
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
>
> +/**
> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to hardware
> + * @old_state: new modeset state to be committed
> + *
> + * This is an alternative implementation for the
> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
> + * that support runtime_pm or need the CRTC to be enabled to perform a
> + * commit. Otherwise, one should use the default implementation
> + * drm_atomic_helper_commit_tail().
> + */
> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
> +{
> + struct drm_device *dev = old_state->dev;
> +
> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> +
> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> +
> + drm_atomic_helper_commit_planes(dev, old_state,
> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> +
> + drm_atomic_helper_commit_hw_done(old_state);
> +
> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> +
> + drm_atomic_helper_cleanup_planes(dev, old_state);
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> +
> static void commit_tail(struct drm_atomic_state *old_state)
> {
> struct drm_device *dev = old_state->dev;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index d48fd7c918f8..ed1a648d518c 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -187,33 +187,8 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer
> *fb, int index)
> return exynos_fb->dma_addr[index];
> }
>
> -static void exynos_drm_atomic_commit_tail(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> -
> - drm_atomic_helper_commit_modeset_disables(dev, state);
> -
> - drm_atomic_helper_commit_modeset_enables(dev, state);
> -
> - /*
> - * Exynos can't update planes with CRTCs and encoders disabled,
> - * its updates routines, specially for FIMD, requires the clocks
> - * to be enabled. So it is necessary to handle the modeset operations
> - * *before* the commit_planes() step, this way it will always
> - * have the relevant clocks enabled to perform the update.
> - */
> - drm_atomic_helper_commit_planes(dev, state,
> - DRM_PLANE_COMMIT_
Re: [PATCH 4/4] drm: Add a few missing descriptions in drm_driver docs
On Thu, Jul 20, 2017 at 01:47:43PM -0400, Sean Paul wrote:
> Fixes the following warnings when building docs:
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'debugfs_init'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'gem_open_object'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'gem_close_object'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'prime_handle_to_fd'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'prime_fd_to_handle'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'gem_prime_export'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'gem_prime_import'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'gem_vm_ops'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'major'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'minor'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'patchlevel'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'name'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'desc'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'date'
> ../include/drm/drm_drv.h:553: warning: No description found for parameter
> 'driver_features'
>
> There are still a couple more warnings for prime helpers that are documented
> elsewhere.
>
> Signed-off-by: Sean Paul
Yeah reviewing gem/prime docs is still on my todo, which is why these
aren't complete yet. Yours are a bit terse and we probably want an
overhaul of all the gem/prime docs, but at least a start.
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_drv.h | 52
> +--
> 1 file changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 81971dc0b573..505c91354802 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -390,6 +390,11 @@ struct drm_driver {
>*/
> void (*master_drop)(struct drm_device *dev, struct drm_file *file_priv);
>
> + /**
> + * @debugfs_init:
> + *
> + * Allows drivers to create driver-specific debugfs files.
> + */
> int (*debugfs_init)(struct drm_minor *minor);
>
> /**
> @@ -408,7 +413,18 @@ struct drm_driver {
>*/
> void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
>
> + /**
> + * @gem_open_object:
> + *
> + * Driver hook called upon gem handle creation
> + */
> int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
> +
> + /**
> + * @gem_close_object:
> + *
> + * Driver hook called upon gem handle release
> + */
> void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
>
> /**
> @@ -421,19 +437,34 @@ struct drm_driver {
> size_t size);
>
> /* prime: */
> - /* export handle -> fd (see drm_gem_prime_handle_to_fd() helper) */
> + /**
> + * @prime_handle_to_fd:
> + *
> + * export handle -> fd (see drm_gem_prime_handle_to_fd() helper)
> + */
> int (*prime_handle_to_fd)(struct drm_device *dev, struct drm_file
> *file_priv,
> uint32_t handle, uint32_t flags, int *prime_fd);
> - /* import fd -> handle (see drm_gem_prime_fd_to_handle() helper) */
> + /**
> + * @prime_fd_to_handle:
> + *
> + * import fd -> handle (see drm_gem_prime_fd_to_handle() helper)
> + */
> int (*prime_fd_to_handle)(struct drm_device *dev, struct drm_file
> *file_priv,
> int prime_fd, uint32_t *handle);
> - /* export GEM -> dmabuf */
> + /**
> + * @gem_prime_export:
> + *
> + * export GEM -> dmabuf
> + */
> struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
> struct drm_gem_object *obj, int flags);
> - /* import dmabuf -> GEM */
> + /**
> + * @gem_prime_import:
> + *
> + * import dmabuf -> GEM
> + */
> struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
> struct dma_buf *dma_buf);
> - /* low-level interface used by drm_gem_prime_{import,export} */
> int (*gem_prime_pin)(struct drm_gem_object *obj);
> void (*gem_prime_unpin)(struct drm_gem_object *obj);
> struct reservation_object * (*gem_prime_res_obj)(
> @@ -505,16 +536,25 @@ struct drm_driver {
> struct drm_device *dev,
> uint32_t handle);
>
> - /* Driver private ops for this object */
> + /**
> + * @gem_vm_ops: Driver private ops for this object
>
[Bug 97942] [IGT] [BYT] [BXT] [BYT] /gem_mmap_gtt subtest basic-wc fails due to Test assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=97942 Ricardo Madrigal changed: What|Removed |Added Summary|[IGT] [BYT] [BXT] |[IGT] [BYT] [BXT] [BYT] |/gem_mmap_gtt subtest |/gem_mmap_gtt subtest |basic-wc fails due to Test |basic-wc fails due to Test |assertion failure |assertion failure -- 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 2/4] drm: Fix warning when building docs for scdc_helper
On Thu, Jul 20, 2017 at 01:47:41PM -0400, Sean Paul wrote: > Fixes: > ../drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation. > ../drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a > blank line; unexpected unindent. > > Signed-off-by: Sean Paul > --- > drivers/gpu/drm/drm_scdc_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_scdc_helper.c > b/drivers/gpu/drm/drm_scdc_helper.c > index 3cd96a95736d..53a743811298 100644 > --- a/drivers/gpu/drm/drm_scdc_helper.c > +++ b/drivers/gpu/drm/drm_scdc_helper.c > @@ -199,9 +199,9 @@ EXPORT_SYMBOL(drm_scdc_set_scrambling); > * TMDS character rate = The rate at which TMDS characters are > transmitted(Mcsc) > * TMDS bit rate = 10x TMDS character rate > * As per the spec: > - * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate > + * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate \ > * = 1/10 pixel clock rate > - * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate > + * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate \ > * = 1/40 pixel clock rate Shouldn't we make the entire thing a blockquote? I.e. indent plus on its own line? -Daniel > * > * Writes to the TMDS config register over SCDC channel, and: > -- > 2.14.0.rc0.284.gd933b75aa4-goog > > ___ > 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 97942] [IGT] [BYT] [BXT] /gem_mmap_gtt subtest basic-wc fails due to Test assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=97942 --- Comment #7 from Ricardo Madrigal --- The following tests fail on BYT with latest configuration Test list igt@gem_mmap_gtt@coherency Graphic Stack Component: drm tag: libdrm-2.4.81-31-g23e234a commit: 23e234a3503f51b9d9c585123d33b936f522808d Component: cairo tag: 1.15.6-2-g57b4050 commit: 57b40507dda3f58dfc8635548d606b86dc7bcf51 Component: intel-gpu-tools tag: intel-gpu-tools-1.19-96-gfb1ddc4 commit: fb1ddc47003ad6a683db79beeb81b6cbab1feb7c Component: piglit tag: piglit-v1 commit: 56e7e5583cd4a3ca15a8cda154d46d168959dd25 == Hardware == motherboard model : . motherboard id : DN2820FYK form factor: Desktop manufacturer : . cpu family : Celeron cpu family id : 6 cpu information: Intel(R) Celeron(R) CPU N2830 @ 2.16GHz gpu card : Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e) (prog-if 00 [VGA controller]) memory ram : 7.66 GB max memory ram : 8 GB cpu thread : 2 cpu core : 2 cpu model : 55 cpu stepping : 8 socket : signature : Type 0, Family 6, Model 55, Stepping 8 hard drive : 111GiB (120GB) current cd clock frequency : 27 kHz maximum cd clock frequency : 40 kHz displays connected : HDMI-A-1 -- 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/4] drm/modes: Fix drm_mode_is_420_only() comment
On Thu, Jul 20, 2017 at 01:47:40PM -0400, Sean Paul wrote: > Fixes the following warnings when building docs: > ../drivers/gpu/drm/drm_modes.c:1623: warning: No description found for > parameter 'display' > ../drivers/gpu/drm/drm_modes.c:1623: warning: Excess function parameter > 'connector' description in 'drm_mode_is_420_only' > > Signed-off-by: Sean Paul Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_modes.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index d52f0a17a66b..4a3f68a33844 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1610,7 +1610,7 @@ int drm_mode_convert_umode(struct drm_display_mode *out, > * drm_mode_is_420_only - if a given videomode can be only supported in > YCBCR420 > * output format > * > - * @connector: drm connector under action. > + * @display: display under action > * @mode: video mode to be tested. > * > * Returns: > -- > 2.14.0.rc0.284.gd933b75aa4-goog > > ___ > 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] drm: Improve kerneldoc for drm_modeset_lock
On Thu, Jul 20, 2017 at 05:07:48PM +0100, Liviu Dudau wrote: > Explain better when the drm_modeset_acquire_ctx parameter can > be skipped for drm_modeset_lock() call. > > Signed-off-by: Liviu Dudau > Cc: Daniel Vetter Applied, thanks. -Daniel > --- > drivers/gpu/drm/drm_modeset_lock.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_modeset_lock.c > b/drivers/gpu/drm/drm_modeset_lock.c > index 64ef09a6cccb..af4e906c630d 100644 > --- a/drivers/gpu/drm/drm_modeset_lock.c > +++ b/drivers/gpu/drm/drm_modeset_lock.c > @@ -52,7 +52,12 @@ > * drm_modeset_drop_locks(&ctx); > * drm_modeset_acquire_fini(&ctx); > * > - * On top of of these per-object locks using &ww_mutex there's also an > overall > + * If all that is needed is a single modeset lock, then the &struct > + * drm_modeset_acquire_ctx is not needed and the locking can be simplified > + * by passing a NULL instead of ctx in the drm_modeset_lock() > + * call and, when done, by calling drm_modeset_unlock(). > + * > + * On top of these per-object locks using &ww_mutex there's also an overall > * &drm_mode_config.mutex, for protecting everything else. Mostly this means > * probe state of connectors, and preventing hotplug add/removal of > connectors. > * > @@ -313,11 +318,14 @@ EXPORT_SYMBOL(drm_modeset_lock_init); > * @lock: lock to take > * @ctx: acquire ctx > * > - * If ctx is not NULL, then its ww acquire context is used and the > + * If @ctx is not NULL, then its ww acquire context is used and the > * lock will be tracked by the context and can be released by calling > * drm_modeset_drop_locks(). If -EDEADLK is returned, this means a > * deadlock scenario has been detected and it is an error to attempt > * to take any more locks without first calling drm_modeset_backoff(). > + * > + * If @ctx is NULL then the function call behaves like a normal, > + * non-nesting mutex_lock() call. > */ > int drm_modeset_lock(struct drm_modeset_lock *lock, > struct drm_modeset_acquire_ctx *ctx) > -- > 2.13.2 > -- 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: [Intel-gfx] [PATCH 5/5] drm/hisilicon: Remove custom FB helper deferred setup
On Fri, Jul 07, 2017 at 09:28:11AM -0400, Sean Paul wrote:
> On Thu, Jul 6, 2017 at 9:00 AM, Daniel Vetter wrote:
> > From: Thierry Reding
> >
> > The FB helper core now supports deferred setup, so the driver's custom
> > implementation can be removed.
> >
> > v2: Dont' resurrect drm_vblank_cleanup.
> >
> > Cc: Xinliang Liu
> > Cc: Rongrong Zou
> > Cc: Xinwei Kong
> > Cc: Chen Feng
> > Signed-off-by: Thierry Reding (v1)
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Sean Paul
Merged the final patches, thanks for your review.
-Daniel
>
> > ---
> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > index 8065d6cb1d7f..1178341c3858 100644
> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> > @@ -54,14 +54,7 @@ static void kirin_fbdev_output_poll_changed(struct
> > drm_device *dev)
> > {
> > struct kirin_drm_private *priv = dev->dev_private;
> >
> > - if (priv->fbdev) {
> > - drm_fbdev_cma_hotplug_event(priv->fbdev);
> > - } else {
> > - priv->fbdev = drm_fbdev_cma_init(dev, 32,
> > -
> > dev->mode_config.num_connector);
> > - if (IS_ERR(priv->fbdev))
> > - priv->fbdev = NULL;
> > - }
> > + drm_fbdev_cma_hotplug_event(priv->fbdev);
> > }
> > #endif
> >
> > @@ -128,11 +121,18 @@ static int kirin_drm_kms_init(struct drm_device *dev)
> > /* init kms poll for handling hpd */
> > drm_kms_helper_poll_init(dev);
> >
> > - /* force detection after connectors init */
> > - (void)drm_helper_hpd_irq_event(dev);
> > + priv->fbdev = drm_fbdev_cma_init(dev, 32,
> > +dev->mode_config.num_connector);
> > + if (IS_ERR(priv->fbdev)) {
> > + DRM_ERROR("failed to initialize fbdev.\n");
> > + ret = PTR_ERR(priv->fbdev);
> > + goto err_cleanup_poll;
> > + }
> >
> > return 0;
> >
> > +err_cleanup_poll:
> > + drm_kms_helper_poll_fini(dev);
> > err_unbind_all:
> > component_unbind_all(dev->dev, dev);
> > err_dc_cleanup:
> > --
> > 2.13.2
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: Add a few missing descriptions in drm_driver docs
Fixes the following warnings when building docs:
../include/drm/drm_drv.h:553: warning: No description found for parameter
'debugfs_init'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'gem_open_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'gem_close_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'prime_handle_to_fd'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'prime_fd_to_handle'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'gem_prime_export'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'gem_prime_import'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'gem_vm_ops'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'major'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'minor'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'patchlevel'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'name'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'desc'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'date'
../include/drm/drm_drv.h:553: warning: No description found for parameter
'driver_features'
There are still a couple more warnings for prime helpers that are documented
elsewhere.
Signed-off-by: Sean Paul
---
include/drm/drm_drv.h | 52 +--
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 81971dc0b573..505c91354802 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -390,6 +390,11 @@ struct drm_driver {
*/
void (*master_drop)(struct drm_device *dev, struct drm_file *file_priv);
+ /**
+* @debugfs_init:
+*
+* Allows drivers to create driver-specific debugfs files.
+*/
int (*debugfs_init)(struct drm_minor *minor);
/**
@@ -408,7 +413,18 @@ struct drm_driver {
*/
void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
+ /**
+* @gem_open_object:
+*
+* Driver hook called upon gem handle creation
+*/
int (*gem_open_object) (struct drm_gem_object *, struct drm_file *);
+
+ /**
+* @gem_close_object:
+*
+* Driver hook called upon gem handle release
+*/
void (*gem_close_object) (struct drm_gem_object *, struct drm_file *);
/**
@@ -421,19 +437,34 @@ struct drm_driver {
size_t size);
/* prime: */
- /* export handle -> fd (see drm_gem_prime_handle_to_fd() helper) */
+ /**
+* @prime_handle_to_fd:
+*
+* export handle -> fd (see drm_gem_prime_handle_to_fd() helper)
+*/
int (*prime_handle_to_fd)(struct drm_device *dev, struct drm_file
*file_priv,
uint32_t handle, uint32_t flags, int *prime_fd);
- /* import fd -> handle (see drm_gem_prime_fd_to_handle() helper) */
+ /**
+* @prime_fd_to_handle:
+*
+* import fd -> handle (see drm_gem_prime_fd_to_handle() helper)
+*/
int (*prime_fd_to_handle)(struct drm_device *dev, struct drm_file
*file_priv,
int prime_fd, uint32_t *handle);
- /* export GEM -> dmabuf */
+ /**
+* @gem_prime_export:
+*
+* export GEM -> dmabuf
+*/
struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj, int flags);
- /* import dmabuf -> GEM */
+ /**
+* @gem_prime_import:
+*
+* import dmabuf -> GEM
+*/
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);
- /* low-level interface used by drm_gem_prime_{import,export} */
int (*gem_prime_pin)(struct drm_gem_object *obj);
void (*gem_prime_unpin)(struct drm_gem_object *obj);
struct reservation_object * (*gem_prime_res_obj)(
@@ -505,16 +536,25 @@ struct drm_driver {
struct drm_device *dev,
uint32_t handle);
- /* Driver private ops for this object */
+ /**
+* @gem_vm_ops: Driver private ops for this object
+*/
const struct vm_operations_struct *gem_vm_ops;
+ /** @major: driver major number */
int major;
+ /** @minor: driver minor number */
int minor;
+ /** @patchlevel: driver patch level */
int patchlevel;
+ /** @name: driver name */
char *name;
+ /** @desc: driver description */
char *desc;
+ /** @date: driver da
[PATCH 3/4] gpu/host1x: Remove excess parameter in host1x_subdev_add docs
Fixes the following warning when building docs:
../drivers/gpu/host1x/bus.c:50: warning: Excess function parameter 'driver'
description in 'host1x_subdev_add'
Signed-off-by: Sean Paul
---
drivers/gpu/host1x/bus.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a048e3ac523d..7ece0e9058c6 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -41,7 +41,6 @@ struct host1x_subdev {
/**
* host1x_subdev_add() - add a new subdevice with an associated device node
* @device: host1x device to add the subdevice to
- * @driver: host1x driver
* @np: device node
*/
static int host1x_subdev_add(struct host1x_device *device,
--
2.14.0.rc0.284.gd933b75aa4-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: Fix warning when building docs for scdc_helper
Fixes: ../drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation. ../drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Sean Paul --- drivers/gpu/drm/drm_scdc_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_scdc_helper.c b/drivers/gpu/drm/drm_scdc_helper.c index 3cd96a95736d..53a743811298 100644 --- a/drivers/gpu/drm/drm_scdc_helper.c +++ b/drivers/gpu/drm/drm_scdc_helper.c @@ -199,9 +199,9 @@ EXPORT_SYMBOL(drm_scdc_set_scrambling); * TMDS character rate = The rate at which TMDS characters are transmitted(Mcsc) * TMDS bit rate = 10x TMDS character rate * As per the spec: - * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate + * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate \ * = 1/10 pixel clock rate - * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate + * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate \ * = 1/40 pixel clock rate * * Writes to the TMDS config register over SCDC channel, and: -- 2.14.0.rc0.284.gd933b75aa4-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/modes: Fix drm_mode_is_420_only() comment
Fixes the following warnings when building docs: ../drivers/gpu/drm/drm_modes.c:1623: warning: No description found for parameter 'display' ../drivers/gpu/drm/drm_modes.c:1623: warning: Excess function parameter 'connector' description in 'drm_mode_is_420_only' Signed-off-by: Sean Paul --- drivers/gpu/drm/drm_modes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index d52f0a17a66b..4a3f68a33844 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1610,7 +1610,7 @@ int drm_mode_convert_umode(struct drm_display_mode *out, * drm_mode_is_420_only - if a given videomode can be only supported in YCBCR420 * output format * - * @connector: drm connector under action. + * @display: display under action * @mode: video mode to be tested. * * Returns: -- 2.14.0.rc0.284.gd933b75aa4-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: Fix some warnings when building docs
I noticed these warnings as part of my compile testing and decided to fix them. There are still a few warnings with the import/export prime helpers. They're partially documented in drm_prime.c, so suggestions welcome on how to resolve them without duplication (or perhaps duplication is best in this case). Sean Sean Paul (4): drm/modes: Fix drm_mode_is_420_only() comment drm: Fix warning when building docs for scdc_helper gpu/host1x: Remove excess parameter in host1x_subdev_add docs drm: Add a few missing descriptions in drm_driver docs drivers/gpu/drm/drm_modes.c | 2 +- drivers/gpu/drm/drm_scdc_helper.c | 4 +-- drivers/gpu/host1x/bus.c | 1 - include/drm/drm_drv.h | 52 ++- 4 files changed, 49 insertions(+), 10 deletions(-) -- 2.14.0.rc0.284.gd933b75aa4-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp: Fix read pointer for drm_dp_downsteam_debug()
Pass in the array and not a pointer to the array to drm_dp_dpcd_read(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_dp_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 213fb837e1c4..1d9e30f0dbf8 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -591,7 +591,7 @@ void drm_dp_downstream_debug(struct seq_file *m, seq_printf(m, "\t\tHW: %d.%d\n", (rev[0] & 0xf0) >> 4, rev[0] & 0xf); - len = drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, &rev, 2); + len = drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, rev, 2); if (len > 0) seq_printf(m, "\t\tSW: %d.%d\n", rev[0], rev[1]); -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/dp: Don't trust drm_dp_downstream_id()
Before we interpret drm_dp_downstream_id() as a string, make sure it is NULL terminated, even when drm_dp_downtsream_id() fails. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101660 Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_dp_helper.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 1d9e30f0dbf8..08af8d6b844b 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -544,7 +544,7 @@ void drm_dp_downstream_debug(struct seq_file *m, DP_DETAILED_CAP_INFO_AVAILABLE; int clk; int bpc; - char id[6]; + char id[7]; int len; uint8_t rev[2]; int type = port_cap[0] & DP_DS_PORT_TYPE_MASK; @@ -583,6 +583,7 @@ void drm_dp_downstream_debug(struct seq_file *m, seq_puts(m, "\t\tType: N/A\n"); } + memset(id, 0, sizeof(id)); drm_dp_downstream_id(aux, id); seq_printf(m, "\t\tID: %s\n", id); -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()
On Thu, Jul 20, 2017 at 1:27 AM, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 10:39:28AM -0700, Matthias Kaehlcke wrote:
>> Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
>> transcoders") misses some pieces, due to a problem with the patch
>> format, this patch adds the remaining bits.
>>
>> Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
>> transcoders")
>>
>> Signed-off-by: Matthias Kaehlcke
>
> Applied, and this time successfully it seems!
Great, thanks!
> Thanks a lot, and sorry for the slight ordeal, I still have no clear idea
> what happened with your v2 patch.
Me neither, supposing that 'git send-email' works correctly I guess
that I somehow deleted the '@' in the editor session opened by 'git
send-email' ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Improve kerneldoc for drm_modeset_lock
Explain better when the drm_modeset_acquire_ctx parameter can be skipped for drm_modeset_lock() call. Signed-off-by: Liviu Dudau Cc: Daniel Vetter --- drivers/gpu/drm/drm_modeset_lock.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index 64ef09a6cccb..af4e906c630d 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -52,7 +52,12 @@ * drm_modeset_drop_locks(&ctx); * drm_modeset_acquire_fini(&ctx); * - * On top of of these per-object locks using &ww_mutex there's also an overall + * If all that is needed is a single modeset lock, then the &struct + * drm_modeset_acquire_ctx is not needed and the locking can be simplified + * by passing a NULL instead of ctx in the drm_modeset_lock() + * call and, when done, by calling drm_modeset_unlock(). + * + * On top of these per-object locks using &ww_mutex there's also an overall * &drm_mode_config.mutex, for protecting everything else. Mostly this means * probe state of connectors, and preventing hotplug add/removal of connectors. * @@ -313,11 +318,14 @@ EXPORT_SYMBOL(drm_modeset_lock_init); * @lock: lock to take * @ctx: acquire ctx * - * If ctx is not NULL, then its ww acquire context is used and the + * If @ctx is not NULL, then its ww acquire context is used and the * lock will be tracked by the context and can be released by calling * drm_modeset_drop_locks(). If -EDEADLK is returned, this means a * deadlock scenario has been detected and it is an error to attempt * to take any more locks without first calling drm_modeset_backoff(). + * + * If @ctx is NULL then the function call behaves like a normal, + * non-nesting mutex_lock() call. */ int drm_modeset_lock(struct drm_modeset_lock *lock, struct drm_modeset_acquire_ctx *ctx) -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
I get the following warning from the system:
[ 25.990733] ==
[ 25.998637] WARNING: possible circular locking dependency detected
[ 26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
[ 26.014246] --
[ 26.022142] kworker/1:2/140 is trying to acquire lock:
[ 26.029001] (&priv->audio_mutex){+.+.+.}, at: []
tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.041100]
[ 26.041100] but task is already holding lock:
[ 26.050436] (crtc_ww_class_mutex){+.+.+.}, at: []
drm_modeset_lock+0x64/0xf8 [drm]
[ 26.061531]
[ 26.061531] which lock already depends on the new lock.
[ 26.061531]
[ 26.075063]
[ 26.075063] the existing dependency chain (in reverse order) is:
[ 26.086031]
[ 26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
[ 26.095657]__lock_acquire+0x18a0/0x19b8
[ 26.101918]lock_acquire+0xd0/0x2b0
[ 26.107731]__ww_mutex_lock.constprop.3+0x90/0xe78
[ 26.114817]ww_mutex_lock+0x54/0xe0
[ 26.120672]drm_modeset_lock+0x64/0xf8 [drm]
[ 26.127253]drm_helper_probe_single_connector_modes+0x7c/0x6b8
[drm_kms_helper]
[ 26.136829]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.144797]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.152429]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.161097]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.169857]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.177559]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.184310]try_to_bring_up_master+0x180/0x1e0
[ 26.191043]component_master_add_with_match+0xb0/0x108
[ 26.198458]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.204735]platform_drv_probe+0x60/0xc0
[ 26.210913]driver_probe_device+0x23c/0x2e8
[ 26.217350]__driver_attach+0xd4/0xd8
[ 26.223256]bus_for_each_dev+0x5c/0xa8
[ 26.229232]driver_attach+0x30/0x40
[ 26.234917]bus_add_driver+0x1d8/0x248
[ 26.240831]driver_register+0x6c/0x118
[ 26.246715]__platform_driver_register+0x54/0x60
[ 26.253461]0x00e1b018
[ 26.258644]do_one_initcall+0x44/0x138
[ 26.264503]do_init_module+0x64/0x1d4
[ 26.270238]load_module+0x1f90/0x2590
[ 26.275957]SyS_finit_module+0xb0/0xc8
[ 26.281765]__sys_trace_return+0x0/0x4
[ 26.281767]
[ 26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
[ 26.281778]__lock_acquire+0x18a0/0x19b8
[ 26.281782]lock_acquire+0xd0/0x2b0
[ 26.281877]drm_modeset_acquire_init+0xa8/0xe0 [drm]
[ 26.281921]drm_helper_probe_single_connector_modes+0x48/0x6b8
[drm_kms_helper]
[ 26.281929]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.281970]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.282009]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.282049]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.282088]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.282095]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.282099]try_to_bring_up_master+0x180/0x1e0
[ 26.282104]component_master_add_with_match+0xb0/0x108
[ 26.282110]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.282114]platform_drv_probe+0x60/0xc0
[ 26.282117]driver_probe_device+0x23c/0x2e8
[ 26.282121]__driver_attach+0xd4/0xd8
[ 26.282124]bus_for_each_dev+0x5c/0xa8
[ 26.282127]driver_attach+0x30/0x40
[ 26.282130]bus_add_driver+0x1d8/0x248
[ 26.282134]driver_register+0x6c/0x118
[ 26.282138]__platform_driver_register+0x54/0x60
[ 26.282141]0x00e1b018
[ 26.282145]do_one_initcall+0x44/0x138
[ 26.282149]do_init_module+0x64/0x1d4
[ 26.282152]load_module+0x1f90/0x2590
[ 26.282156]SyS_finit_module+0xb0/0xc8
[ 26.282159]__sys_trace_return+0x0/0x4
[ 26.282161]
[ 26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
[ 26.282172]print_circular_bug+0x80/0x2e0
[ 26.282176]__lock_acquire+0x15a8/0x19b8
[ 26.282180]lock_acquire+0xd0/0x2b0
[ 26.282184]__mutex_lock+0x78/0x8e0
[ 26.282188]mutex_lock_nested+0x3c/0x50
[ 26.282196]tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.282237]drm_atomic_helper_commit_modeset_disables+0x328/0x3a0
[drm_kms_helper]
[ 26.282251]malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
[ 26.282292]commit_tail+0x4c/0x80 [drm_kms_helper]
[ 26.282333]drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
[ 26.282427]drm_atomic_commit+0x54/0x70 [drm]
[ 26.282467]restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
[
Re: [PATCH 09/18] drm/sun4i: tcon: Adjust dotclock dividers range
On Thu, Jul 20, 2017 at 10:55 PM, Maxime Ripard
wrote:
> On Fri, Jul 14, 2017 at 12:14:37PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
>> wrote:
>> > It seems like the dotclock dividers are a bit less strict range, and can
>> > operate even with a smaller than 6 divider. Loose the boundaries a bit.
>> >
>> > Signed-off-by: Maxime Ripard
>> > ---
>> > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 20 +++-
>> > 1 file changed, 19 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
>> > b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
>> > index d401156490f3..0b844c0dd102 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
>> > @@ -77,7 +77,25 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw,
>> > unsigned long rate,
>> > u8 best_div = 1;
>> > int i;
>> >
>> > - for (i = 6; i <= 127; i++) {
>> > + /*
>> > +* There's something odd here.
>> > +*
>> > +* In the A13 user manual, this is stated to be >= 6 when
>> > +* dclk1 and dclk2 are used (without any hint on how to use
>> > +* them), and >= 4 when only dclk is used.
>>
>> You set it in TCON0_IO_POL_REG, which sets the clock phase delay.
>
> oh, so it's d for delay? I assumed it was for dotclock.
The manual says "data clock" for register 0x44 (TCON0_DCLK_REG)
>
>> I think we were setting this before, but you removed it as part of
>> the previous TCON clean up patches?
>
> Hmmm, I might have.. :)
>
>> In the A33, there are even more options, like DCLK / 2 (with 0 or 90
>> degree phase delay).
>
> Where did you find this documentation? I was under the impression that
> all that DCLK stuff was in the higher bits of the DCLK register, but
> apparently there's more to it.
Same section, TCON0_IO_POL_REG register bits.
The bits in TCON0_IO_POL_REG are likely a mux, letting you select which
one that is actually used on the external (with regard to the TCON) pin.
>
>> > +*
>> > +* In the A33 user manual, when only dclk is used, it is set
>> > +* to be >= 6 in the former case, and >= 1 in the
>> > +* latter. There's also some (obscure) explanations about the
>> > +* dclk1 and dclk2 vs dclk that seems to be in the upper 4
>> > +* bits. What those clocks are and what bit does what is not
>> > +* really clear.
>>
>> Looks like mux bits to me. How they differ from TCON0_IO_POL_REG is
>> beyond me ATM.
>
> It might be some additional dividers too.
Might be something like this:
TCON CH0 clk - dclk_en - no delay--[mux]--- dclk out
\\- dclk1_en - 1/3 phase delay --
\- dclk2_en - 2/3 phase delay --///
\ dclkm2_en - /2 divider - no delay //
\ 90 degree delay -/
ChenYu
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
On Thu, Jul 20, 2017 at 04:57:12PM +0200, Daniel Vetter wrote: > On Thu, Jul 20, 2017 at 4:40 PM, Liviu Dudau wrote: > > On Thu, Jul 20, 2017 at 03:24:13PM +0100, Russell King - ARM Linux wrote: > >> On Thu, Jul 20, 2017 at 03:19:10PM +0100, Liviu Dudau wrote: > >> > On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote: > >> > > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote: > >> > > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux > >> > > > wrote: > >> > > > > Actually, scrub that idea - > >> > > > > drm_helper_probe_single_connector_modes() > >> > > > > calls drm_edid_to_eld() for these cases anyway, so we must call > >> > > > > drm_helper_probe_single_connector_modes() with the audio_mutex > >> > > > > held. > >> > > > > >> > > > OK, so the lockdep warning is spurious? > >> > > > >> > > I don't think so. I think there's two ways to solve this: > >> > > > >> > > 1. replace the audio_mutex in tda998x_audio_get_eld() and > >> > >tda998x_connector_fill_modes() with a new mutex (eld_mutex) to > >> > >protect just the ELD. > >> > > > >> > > 2. remove the mutex from these two functions, and take the > >> > > connection_mutex > >> > >modeset lock in tda998x_audio_get_eld(). > >> > > > >> > > However, I don't have a view on which would be best. > >> > > >> > If you don't mind, I took the liberty of picking option 2, just because > >> > I don't like adding new locks when existing ones might do the job. > >> > >> I don't mind - but one question for the DRM people in connection with > >> your patch is whether we need the acquire context for this relatively > >> simple lock/copy/unlock sequence. This path for getting the ELD > >> shouldn't be holding any other DRM locks. > > > > Cc-ing Daniel Vetter in hope of clarifications / nod of approval. > > However, I can only see my emails in the online dri-devel archive, not > > yours, so I can't point him to the whole discussion. > > > > danvet: a while ago while I was debugging the delayed fb setup I found > > a lockdep warning with the tda998x driver. Now I've had some more time > > to investigate so I have created a patch trying to fix the issue, which > > was on v1 just a re-ordering of places where tda998x's audio_mutex lock > > was taken. Russell suggested a different approach, which I have > > implemented in [1], but we wonder if we really have to go through the > > whole dance. > > If all you do is take only one ww mutex (wrapped up in > drm_modeset_lock for kms) then you can pass a NULL acquire context. > The context is only needed when you want to take multiple locks at the > same time (to be able to resolve deadlocks). Taking a single lock > within the modeset lock class can't deadlock. Hi Daniel, Thanks for clarification. I'll post a v3 with a NULL acquire context. Best regards, Liviu > > Reading the kerneldoc that's not explained at all :-( Can you pls type > a patch to improve the docs for drm_modeset_lock? > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/14] drm/mgag200: Add support for MATROX PCI device IDs 0x520 and 0x521
Takashi Iwai writes: > On Thu, 20 Jul 2017 06:17:58 +0200, > Dave Airlie wrote: > > > > On 19 July 2017 at 00:43, Takashi Iwai wrote: > > > From: Egbert Eich > > > > > > Add two more models G200_PCI and G200 for PCI device IDs 0x520 and > > > 0x521, respectively. They need to retrieve the reference clock and > > > pclk min/max values from BIOS, and set up the PLLs accordingly. > > > > Is there any advantage in supporting these GPUs? > > Heh, you are suggesting that KMS support has no merit? ;) The merit of this patch was that I could test a lot of functionality of this driver without having access to a machine with a built-in mgag200. Such servers tend not to be home office friendly ;) Instead I was able to pull a vintage g200 discrete PCI card from my collection and shove it into a test machine. So there was some merit to have this patch and it was small enough to preserve it. Cheers, Egbert. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
On Thu, Jul 20, 2017 at 4:40 PM, Liviu Dudau wrote: > On Thu, Jul 20, 2017 at 03:24:13PM +0100, Russell King - ARM Linux wrote: >> On Thu, Jul 20, 2017 at 03:19:10PM +0100, Liviu Dudau wrote: >> > On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote: >> > > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote: >> > > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux >> > > > wrote: >> > > > > Actually, scrub that idea - drm_helper_probe_single_connector_modes() >> > > > > calls drm_edid_to_eld() for these cases anyway, so we must call >> > > > > drm_helper_probe_single_connector_modes() with the audio_mutex held. >> > > > >> > > > OK, so the lockdep warning is spurious? >> > > >> > > I don't think so. I think there's two ways to solve this: >> > > >> > > 1. replace the audio_mutex in tda998x_audio_get_eld() and >> > >tda998x_connector_fill_modes() with a new mutex (eld_mutex) to >> > >protect just the ELD. >> > > >> > > 2. remove the mutex from these two functions, and take the >> > > connection_mutex >> > >modeset lock in tda998x_audio_get_eld(). >> > > >> > > However, I don't have a view on which would be best. >> > >> > If you don't mind, I took the liberty of picking option 2, just because >> > I don't like adding new locks when existing ones might do the job. >> >> I don't mind - but one question for the DRM people in connection with >> your patch is whether we need the acquire context for this relatively >> simple lock/copy/unlock sequence. This path for getting the ELD >> shouldn't be holding any other DRM locks. > > Cc-ing Daniel Vetter in hope of clarifications / nod of approval. > However, I can only see my emails in the online dri-devel archive, not > yours, so I can't point him to the whole discussion. > > danvet: a while ago while I was debugging the delayed fb setup I found > a lockdep warning with the tda998x driver. Now I've had some more time > to investigate so I have created a patch trying to fix the issue, which > was on v1 just a re-ordering of places where tda998x's audio_mutex lock > was taken. Russell suggested a different approach, which I have > implemented in [1], but we wonder if we really have to go through the > whole dance. If all you do is take only one ww mutex (wrapped up in drm_modeset_lock for kms) then you can pass a NULL acquire context. The context is only needed when you want to take multiple locks at the same time (to be able to resolve deadlocks). Taking a single lock within the modeset lock class can't deadlock. Reading the kerneldoc that's not explained at all :-( Can you pls type a patch to improve the docs for drm_modeset_lock? Thanks, 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: [PATCH 09/18] drm/sun4i: tcon: Adjust dotclock dividers range
On Fri, Jul 14, 2017 at 12:14:37PM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
> wrote:
> > It seems like the dotclock dividers are a bit less strict range, and can
> > operate even with a smaller than 6 divider. Loose the boundaries a bit.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> > b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> > index d401156490f3..0b844c0dd102 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
> > @@ -77,7 +77,25 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw,
> > unsigned long rate,
> > u8 best_div = 1;
> > int i;
> >
> > - for (i = 6; i <= 127; i++) {
> > + /*
> > +* There's something odd here.
> > +*
> > +* In the A13 user manual, this is stated to be >= 6 when
> > +* dclk1 and dclk2 are used (without any hint on how to use
> > +* them), and >= 4 when only dclk is used.
>
> You set it in TCON0_IO_POL_REG, which sets the clock phase delay.
oh, so it's d for delay? I assumed it was for dotclock.
> I think we were setting this before, but you removed it as part of
> the previous TCON clean up patches?
Hmmm, I might have.. :)
> In the A33, there are even more options, like DCLK / 2 (with 0 or 90
> degree phase delay).
Where did you find this documentation? I was under the impression that
all that DCLK stuff was in the higher bits of the DCLK register, but
apparently there's more to it.
> > +*
> > +* In the A33 user manual, when only dclk is used, it is set
> > +* to be >= 6 in the former case, and >= 1 in the
> > +* latter. There's also some (obscure) explanations about the
> > +* dclk1 and dclk2 vs dclk that seems to be in the upper 4
> > +* bits. What those clocks are and what bit does what is not
> > +* really clear.
>
> Looks like mux bits to me. How they differ from TCON0_IO_POL_REG is
> beyond me ATM.
It might be some additional dividers too.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/18] regmap: mmio: Add function to attach a clock
On Tue, Jul 18, 2017 at 02:21:47PM +0100, Mark Brown wrote: > On Mon, Jul 17, 2017 at 11:01:07AM +0200, Maxime Ripard wrote: > > On Thu, Jul 13, 2017 at 05:01:42PM +0100, Mark Brown wrote: > > > > > This might be problematic if the clock to enable is stored in another > > > > node. > > > > Let's add a function that allows to attach a clock that has already been > > > > retrieved to a regmap in order to fix this. > > > > What is the use case for this? > > > This is useful when the clock you want to be handled by the regmap is > > not described in the device node that probed the driver, but one of > > its subnode, or an another node entirely. > > > We're in the latter case, where we have two controllers in the DT, but > > are driven by the same driver. We'll create two regmaps, but one will > > not have the proper of_node used to retrieve the clock. > > I'm sorry but I'm still not seeing why you're doing this. Can you be > more concrete please? We have two devices needed to bring DSI: the DSI controller itself and its associated PHY. The PHY configuration cannot be done through a framework because it requires more information than the various phy frameworks allow to pass through to the driver. Therefore, we have a single driver, attached to the DSI controller, which handles both the PHY and the DSI controller. Both the PHY and the DSI controller are separate device, with different memory regions. Therefore, we need to create two regmaps, with clocks attached to them. However, the default clock retrieval mechanism doesn't work for the phy regmap, since only the DSI controller device of_node is considered, while its clock is stored in a separate node. I hope it's clearer, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq
On Wed, 2017-07-19 at 23:11 -0700, Manasi Navare wrote:
> On Tue, Jul 18, 2017 at 03:11:42PM +0300, Paul Kocialkowski wrote:
> > On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > > After detecting an IRQ storm, hotplug detection will switch from
> > > irq-based detection to poll-based detection. After a short delay
> > > or
> > > when resetting storm detection from debugfs, detection will switch
> > > back to being irq-based.
> > >
> > > However, it may occur that polling does not have enough time to
> > > detect
> > > the current connector state when that second switch takes place.
> > > Thus,
> > > this sets the appropriate hotplug event bits for the concerned
> > > connectors and schedules the hotplug work, that will ensure the
> > > connectors states are in sync when switching back to irq.
> > >
> > > Without this, no irq will be triggered and the hpd change will be
> > > lost.
> >
> > Does anyone have feedback to provide on this?
> > It looks like it should be a no-brainer.
> >
> > Cheers,
> >
> > Paul
> >
> > > Signed-off-by: Paul Kocialkowski > > m>
> > > ---
> > > drivers/gpu/drm/i915/intel_hotplug.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > > b/drivers/gpu/drm/i915/intel_hotplug.c
> > > index f1200272a699..29f55480b0bb 100644
> > > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > > @@ -218,9 +218,13 @@ static void
> > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > >
> > > if (intel_connector->encoder->hpd_pin ==
> > > i) {
>
> So if this hpd pin in intel_connector->encoder is set then that
> means it got the hpd but because connector->polled is !=
> intel_connector->polled
> polling didnt detect that connector.
>
> Is that what you are trying to do here?
The first test is simply a way to match the intel_connector to the drm
connector. The second one indicates whether we are using polling or irq
mode. If they don't match (given the test earlier in the code that only
selects hpd pins that use irq mode), it means that we are switching from
polling mode to irq mode.
When that happens, it is necessary to assume that the connector state
may have changed (in the time window between the last poll and enabling
irq), so the hotplug work is scheduled. It will check whether a hpd
state change did happen or not and issue a uevent if that is the case.
> > > - if (connector->polled !=
> > > intel_connector->polled)
> > > + if (connector->polled !=
> > > intel_connector->polled) {
> > > DRM_DEBUG_DRIVER("Reenabl
> > > ing
> > > HPD on connector %s\n",
> > >connecto
> > > r-
> > > > name);
> > >
> > > +
> > > + dev_priv-
> > > >hotplug.event_bits
> > > > = (1 << i);
> > >
> > > + }
> > > +
> > > connector->polled =
> > > intel_connector-
> > > > polled;
> > >
> > > if (!connector->polled)
> > > connector->polled =
> > > DRM_CONNECTOR_POLL_HPD;
> > > @@ -232,6 +236,8 @@ static void
> > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > dev_priv->display.hpd_irq_setup(dev_priv);
> > > spin_unlock_irq(&dev_priv->irq_lock);
> > >
> > > + schedule_work(&dev_priv->hotplug.hotplug_work);
> > > +
> > > intel_runtime_pm_put(dev_priv);
> > > }
> > >
> >
> > --
> > Paul Kocialkowski
> > Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo,
> > Finland
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paul Kocialkowski
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
On Thu, Jul 20, 2017 at 03:24:13PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 20, 2017 at 03:19:10PM +0100, Liviu Dudau wrote: > > On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote: > > > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux > > > > wrote: > > > > > Actually, scrub that idea - drm_helper_probe_single_connector_modes() > > > > > calls drm_edid_to_eld() for these cases anyway, so we must call > > > > > drm_helper_probe_single_connector_modes() with the audio_mutex held. > > > > > > > > OK, so the lockdep warning is spurious? > > > > > > I don't think so. I think there's two ways to solve this: > > > > > > 1. replace the audio_mutex in tda998x_audio_get_eld() and > > >tda998x_connector_fill_modes() with a new mutex (eld_mutex) to > > >protect just the ELD. > > > > > > 2. remove the mutex from these two functions, and take the > > > connection_mutex > > >modeset lock in tda998x_audio_get_eld(). > > > > > > However, I don't have a view on which would be best. > > > > If you don't mind, I took the liberty of picking option 2, just because > > I don't like adding new locks when existing ones might do the job. > > I don't mind - but one question for the DRM people in connection with > your patch is whether we need the acquire context for this relatively > simple lock/copy/unlock sequence. This path for getting the ELD > shouldn't be holding any other DRM locks. Cc-ing Daniel Vetter in hope of clarifications / nod of approval. However, I can only see my emails in the online dri-devel archive, not yours, so I can't point him to the whole discussion. danvet: a while ago while I was debugging the delayed fb setup I found a lockdep warning with the tda998x driver. Now I've had some more time to investigate so I have created a patch trying to fix the issue, which was on v1 just a re-ordering of places where tda998x's audio_mutex lock was taken. Russell suggested a different approach, which I have implemented in [1], but we wonder if we really have to go through the whole dance. Best regards, Liviu [1] https://lists.freedesktop.org/archives/dri-devel/2017-July/147940.html > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq
On Thu, 2017-07-20 at 01:04 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > After detecting an IRQ storm, hotplug detection will switch from
> > irq-based detection to poll-based detection. After a short delay or
> > when resetting storm detection from debugfs, detection will switch
> > back to being irq-based.
> >
> > However, it may occur that polling does not have enough time to
> > detect
> > the current connector state when that second switch takes place.
>
> Some questions so that I understand this better. How short would this
> have to be for detect to not complete? Is there a way I can easily
> test this scenario?
Well, it doesn't really matter, the point is that it may happen that the
connector's hpd line changes in the time window between the last poll
(that happens every 100ms) and the moment the irq is enabled back. This
time window, however long it may be, always exists and it may happen
that this is exactly when the hpd event occurs.
It's possible to test this by triggering an hpd storm, then triggering a
regular hpd toggle and directly disabling polling mode via debugfs.
I was able to do this with a chamelium and did see the problem take
place.
> > Thus,
> > this sets the appropriate hotplug event bits for the concerned
> > connectors and schedules the hotplug work, that will ensure the
> > connectors states are in sync when switching back to irq.
>
> Not sure I understand this correctly, looks like you are setting the
> event_bits even if there was no irq during the polling interval. Is
> that right?
Yes, you are perfectly right. it is necessary to do this because the
event will not be detected either by polling (happening too late) nor by
the irq (happening too early). So we must trigger the hotplug work to
make it check whether the connectors states changed.
> > Without this, no irq will be triggered and the hpd change will be
> > lost.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/i915/intel_hotplug.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > b/drivers/gpu/drm/i915/intel_hotplug.c
> > index f1200272a699..29f55480b0bb 100644
> > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > @@ -218,9 +218,13 @@ static void
> > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> >
> > if (intel_connector->encoder->hpd_pin == i)
> > {
> > - if (connector->polled !=
> > intel_connector->polled)
> > + if (connector->polled !=
> > intel_connector->polled) {
> > DRM_DEBUG_DRIVER("Reenablin
> > g HPD on connector %s\n",
> > connector-
> > >name);
> > +
> > + dev_priv-
> > >hotplug.event_bits |= (1 << i);
> > + }
> > +
> > connector->polled =
> > intel_connector->polled;
> > if (!connector->polled)
> > connector->polled =
> > DRM_CONNECTOR_POLL_HPD;
> > @@ -232,6 +236,8 @@ static void
> > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > dev_priv->display.hpd_irq_setup(dev_priv);
> > spin_unlock_irq(&dev_priv->irq_lock);
> >
> > + schedule_work(&dev_priv->hotplug.hotplug_work);
>
> How does this work with DP connectors? From what I understand, the
> event_bits are set for DP based on the return value from
> intel_dp_hpd_pulse(). But, doesn't this patch set the bits
> unconditionally?
It works the same as other connectors, nothing specific there. The
hotplug work will read the connector's state and issue a uevent if its
value has changed.
> > +
> > intel_runtime_pm_put(dev_priv);
> > }
> >
--
Paul Kocialkowski
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/18] dt-bindings: display: Add Allwinner MIPI-DSI bindings
Hi Laurent
On Tue, Jul 18, 2017 at 01:18:42PM +0300, Laurent Pinchart wrote:
> On Monday 17 Jul 2017 13:41:49 Rob Herring wrote:
> > On Thu, Jul 13, 2017 at 04:13:06PM +0200, Maxime Ripard wrote:
> > > The Allwinner SoCs usually come with a DSI encoder. Add a binding for it.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > >
> > > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 85
> > > +++-
> > > 1 file changed, 85 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt>
> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> > > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt new file
> > > mode 100644
> > > index ..2e7c5aa7020f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> > > @@ -0,0 +1,85 @@
> > > +Allwinner A31 DSI Encoder
> > > +=
> > > +
> > > +The DSI pipeline consists of two separate blocks: the DSI controller
> > > +itself, and its associated D-PHY.
> > > +
> > > +DSI Encoder
> > > +---
> > > +
> > > +The DSI Encoder generates the DSI signal from the TCON's.
> > > +
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > +* allwinner,sun6i-a31-mipi-dsi
> > > + - reg: base address and size of memory-mapped region
> > > + - interrupts: interrupt associated to this IP
> > > + - clocks: phandles to the clocks feeding the DSI encoder
> > > +* bus: the DSI interface clock
> > > +* mod: the DSI module clock
> > > + - clock-names: the clock names mentioned above
> > > + - phys: phandle to the D-PHY
> > > + - phy-names: must be "dphy"
> > > + - resets: phandle to the reset controller driving the encoder
> > > +
> > > + - ports: A ports node with endpoint definitions as defined in
> > > +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > +port should be the input endpoint, usually coming from the
> > > +associated TCON.
> >
> > Output port for bridge/panel?
> >
> > > +
> > > +D-PHY
> > > +-
> > > +
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > +* allwinner,sun6i-a31-mipi-dphy
> > > + - reg: base address and size of memory-mapped region
> > > + - clocks: phandles to the clocks feeding the DSI encoder
> > > +* bus: the DSI interface clock
> > > +* mod: the DSI module clock
> > > + - clock-names: the clock names mentioned above
> > > + - resets: phandle to the reset controller driving the encoder
> > > +
> > > +Example:
> > > +
> > > +dsi0: dsi@01ca {
> >
> > Drop the leading 0.
> >
> > > + compatible = "allwinner,sun6i-a31-mipi-dsi";
> > > + reg = <0x01ca 0x1000>;
> > > + interrupts = ;
> > > + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> > > + <&ccu CLK_DSI_SCLK>;
> > > + clock-names = "bus", "mod";
> > > + resets = <&ccu RST_BUS_MIPI_DSI>;
> > > + phys = <&dphy0>;
> > > + phy-names = "dphy";
> > >
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> >
> > Not needed.
> >
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + dsi0_in: port@0 {
>
> I don't think the label for the port is needed, you should only reference the
> endpoint.
>
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + reg = <0>;
> > > +
> > > + dsi0_in_tcon0: endpoint@0 {
> > > + reg = <0>;
> >
> > Don't need reg when there's only 1 endpoint.
>
> And no reg for the port name either when there's a single port. This can all
> be simplified to
>
> dsi0: dsi@1ca {
> compatible = "allwinner,sun6i-a31-mipi-dsi";
> reg = <0x01ca 0x1000>;
> interrupts = ;
> clocks = <&ccu CLK_BUS_MIPI_DSI>,
><&ccu CLK_DSI_SCLK>;
> clock-names = "bus", "mod";
> resets = <&ccu RST_BUS_MIPI_DSI>;
> phys = <&dphy0>;
> phy-names = "dphy";
>
> port {
> dsi0_in_tcon0: endpoint {
> remote-endpoint = <&tcon0_out_dsi0>;
> };
> };
> };
I'll change that. Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
I get the following warning from the system:
[ 25.990733] ==
[ 25.998637] WARNING: possible circular locking dependency detected
[ 26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
[ 26.014246] --
[ 26.022142] kworker/1:2/140 is trying to acquire lock:
[ 26.029001] (&priv->audio_mutex){+.+.+.}, at: []
tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.041100]
[ 26.041100] but task is already holding lock:
[ 26.050436] (crtc_ww_class_mutex){+.+.+.}, at: []
drm_modeset_lock+0x64/0xf8 [drm]
[ 26.061531]
[ 26.061531] which lock already depends on the new lock.
[ 26.061531]
[ 26.075063]
[ 26.075063] the existing dependency chain (in reverse order) is:
[ 26.086031]
[ 26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
[ 26.095657]__lock_acquire+0x18a0/0x19b8
[ 26.101918]lock_acquire+0xd0/0x2b0
[ 26.107731]__ww_mutex_lock.constprop.3+0x90/0xe78
[ 26.114817]ww_mutex_lock+0x54/0xe0
[ 26.120672]drm_modeset_lock+0x64/0xf8 [drm]
[ 26.127253]drm_helper_probe_single_connector_modes+0x7c/0x6b8
[drm_kms_helper]
[ 26.136829]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.144797]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.152429]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.161097]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.169857]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.177559]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.184310]try_to_bring_up_master+0x180/0x1e0
[ 26.191043]component_master_add_with_match+0xb0/0x108
[ 26.198458]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.204735]platform_drv_probe+0x60/0xc0
[ 26.210913]driver_probe_device+0x23c/0x2e8
[ 26.217350]__driver_attach+0xd4/0xd8
[ 26.223256]bus_for_each_dev+0x5c/0xa8
[ 26.229232]driver_attach+0x30/0x40
[ 26.234917]bus_add_driver+0x1d8/0x248
[ 26.240831]driver_register+0x6c/0x118
[ 26.246715]__platform_driver_register+0x54/0x60
[ 26.253461]0x00e1b018
[ 26.258644]do_one_initcall+0x44/0x138
[ 26.264503]do_init_module+0x64/0x1d4
[ 26.270238]load_module+0x1f90/0x2590
[ 26.275957]SyS_finit_module+0xb0/0xc8
[ 26.281765]__sys_trace_return+0x0/0x4
[ 26.281767]
[ 26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
[ 26.281778]__lock_acquire+0x18a0/0x19b8
[ 26.281782]lock_acquire+0xd0/0x2b0
[ 26.281877]drm_modeset_acquire_init+0xa8/0xe0 [drm]
[ 26.281921]drm_helper_probe_single_connector_modes+0x48/0x6b8
[drm_kms_helper]
[ 26.281929]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.281970]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.282009]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.282049]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.282088]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.282095]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.282099]try_to_bring_up_master+0x180/0x1e0
[ 26.282104]component_master_add_with_match+0xb0/0x108
[ 26.282110]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.282114]platform_drv_probe+0x60/0xc0
[ 26.282117]driver_probe_device+0x23c/0x2e8
[ 26.282121]__driver_attach+0xd4/0xd8
[ 26.282124]bus_for_each_dev+0x5c/0xa8
[ 26.282127]driver_attach+0x30/0x40
[ 26.282130]bus_add_driver+0x1d8/0x248
[ 26.282134]driver_register+0x6c/0x118
[ 26.282138]__platform_driver_register+0x54/0x60
[ 26.282141]0x00e1b018
[ 26.282145]do_one_initcall+0x44/0x138
[ 26.282149]do_init_module+0x64/0x1d4
[ 26.282152]load_module+0x1f90/0x2590
[ 26.282156]SyS_finit_module+0xb0/0xc8
[ 26.282159]__sys_trace_return+0x0/0x4
[ 26.282161]
[ 26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
[ 26.282172]print_circular_bug+0x80/0x2e0
[ 26.282176]__lock_acquire+0x15a8/0x19b8
[ 26.282180]lock_acquire+0xd0/0x2b0
[ 26.282184]__mutex_lock+0x78/0x8e0
[ 26.282188]mutex_lock_nested+0x3c/0x50
[ 26.282196]tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.282237]drm_atomic_helper_commit_modeset_disables+0x328/0x3a0
[drm_kms_helper]
[ 26.282251]malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
[ 26.282292]commit_tail+0x4c/0x80 [drm_kms_helper]
[ 26.282333]drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
[ 26.282427]drm_atomic_commit+0x54/0x70 [drm]
[ 26.282467]restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
[
Re: [PATCH 11/18] dt-bindings: display: Add Allwinner MIPI-DSI bindings
Hi Rob,
On Mon, Jul 17, 2017 at 01:41:49PM -0500, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 04:13:06PM +0200, Maxime Ripard wrote:
> > The Allwinner SoCs usually come with a DSI encoder. Add a binding for it.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 85 +++-
> > 1 file changed, 85 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> > new file mode 100644
> > index ..2e7c5aa7020f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt
> > @@ -0,0 +1,85 @@
> > +Allwinner A31 DSI Encoder
> > +=
> > +
> > +The DSI pipeline consists of two separate blocks: the DSI controller
> > +itself, and its associated D-PHY.
> > +
> > +DSI Encoder
> > +---
> > +
> > +The DSI Encoder generates the DSI signal from the TCON's.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > +* allwinner,sun6i-a31-mipi-dsi
> > + - reg: base address and size of memory-mapped region
> > + - interrupts: interrupt associated to this IP
> > + - clocks: phandles to the clocks feeding the DSI encoder
> > +* bus: the DSI interface clock
> > +* mod: the DSI module clock
> > + - clock-names: the clock names mentioned above
> > + - phys: phandle to the D-PHY
> > + - phy-names: must be "dphy"
> > + - resets: phandle to the reset controller driving the encoder
> > +
> > + - ports: A ports node with endpoint definitions as defined in
> > +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > +port should be the input endpoint, usually coming from the
> > +associated TCON.
>
> Output port for bridge/panel?
The DSI panels and bridges are subnodes of the DSI controller. But I
should mention that :)
>
> > +
> > +D-PHY
> > +-
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > +* allwinner,sun6i-a31-mipi-dphy
> > + - reg: base address and size of memory-mapped region
> > + - clocks: phandles to the clocks feeding the DSI encoder
> > +* bus: the DSI interface clock
> > +* mod: the DSI module clock
> > + - clock-names: the clock names mentioned above
> > + - resets: phandle to the reset controller driving the encoder
> > +
> > +Example:
> > +
> > +dsi0: dsi@01ca {
>
> Drop the leading 0.
>
> > + compatible = "allwinner,sun6i-a31-mipi-dsi";
> > + reg = <0x01ca 0x1000>;
> > + interrupts = ;
> > + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> > +<&ccu CLK_DSI_SCLK>;
> > + clock-names = "bus", "mod";
> > + resets = <&ccu RST_BUS_MIPI_DSI>;
> > + phys = <&dphy0>;
> > + phy-names = "dphy";
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> Not needed.
>
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dsi0_in: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dsi0_in_tcon0: endpoint@0 {
> > + reg = <0>;
>
> Don't need reg when there's only 1 endpoint.
>
> > + remote-endpoint = <&tcon0_out_dsi0>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +dphy0: d-phy@01ca1000 {
>
> Drop leading 0.
>
> > + compatible = "allwinner,sun6i-a31-mipi-dphy";
> > + reg = <0x01ca1000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> > +<&ccu CLK_DSI_DPHY>;
> > + clock-names = "bus", "mod";
> > + resets = <&ccu RST_BUS_MIPI_DSI>;
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
>
> For what?
I'll address those comments, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote: > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux wrote: > > > Actually, scrub that idea - drm_helper_probe_single_connector_modes() > > > calls drm_edid_to_eld() for these cases anyway, so we must call > > > drm_helper_probe_single_connector_modes() with the audio_mutex held. > > > > OK, so the lockdep warning is spurious? > > I don't think so. I think there's two ways to solve this: > > 1. replace the audio_mutex in tda998x_audio_get_eld() and >tda998x_connector_fill_modes() with a new mutex (eld_mutex) to >protect just the ELD. > > 2. remove the mutex from these two functions, and take the connection_mutex >modeset lock in tda998x_audio_get_eld(). > > However, I don't have a view on which would be best. If you don't mind, I took the liberty of picking option 2, just because I don't like adding new locks when existing ones might do the job. v2 patch on the way shortly. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[maintainer-tools PATCH] Add flowchart to help determine appropriate branch
This patch adds a flowchart to the drm-misc documentation to help committers decide which branch is most appropriate for a given patch. Signed-off-by: Sean Paul --- .gitignore | 1 + Makefile | 2 +- drm-misc-commit-flow.dot | 22 ++ drm-misc.rst | 10 ++ 4 files changed, 34 insertions(+), 1 deletion(-) create mode 100644 drm-misc-commit-flow.dot diff --git a/.gitignore b/.gitignore index e2bd6b6..35ed071 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,5 @@ drm-intel-flow.svg +drm-misc-commit-flow.svg *.html .* *~ diff --git a/Makefile b/Makefile index e079e35..44fcdc9 100644 --- a/Makefile +++ b/Makefile @@ -18,7 +18,7 @@ drm-intel.html: drm-intel.rst drm-intel-flow.svg drm-intel-timeline.rst drm-inte sed -i 's/ $@ sed -i 's/ next_0[label="no"]; + is_fix -> in_origin[label="yes"]; + + in_origin -> fixes_0[label="yes"] + in_origin -> is_late[label="no"]; + + is_late -> next_1[label="no"] + is_late -> next_fixes_0[label="yes"] +} diff --git a/drm-misc.rst b/drm-misc.rst index c66ac67..05ccefb 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -73,6 +73,16 @@ updated drm-tip gets rebuilt. If there's a conflict see section on `resolving conflicts when rebuilding drm-tip `_. +Where Do I Apply My Patch? +~~ + +Consult this handy flowchart to determine the best branch for your patch. If in +doubt, apply to drm-misc-next or ask your favorite maintainer on IRC. + +.. Note: This requires SVG support in the browser. +.. raw:: html + :file: drm-misc-commit-flow.svg + Merge Timeline ~~ -- 2.14.0.rc0.284.gd933b75aa4-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed
Am Donnerstag, den 20.07.2017, 14:51 +0200 schrieb Daniel Vetter:
> It makes debugging a massive pain.
It is also considered very bad style to BUG the kernel on anything other
than filesystem eating catastrophic failures.
Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/dma-buf/dma-fence.c | 4 ++--
> include/linux/dma-fence.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 56e0a0e1b600..9a302799040e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
> ATOMIC64_INIT(0);
> */
> u64 dma_fence_context_alloc(unsigned num)
> {
> - BUG_ON(!num);
> + WARN_ON(!num);
> return atomic64_add_return(num, &dma_fence_context_counter) - num;
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
> @@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
>
> trace_dma_fence_destroy(fence);
>
> - BUG_ON(!list_empty(&fence->cb_list));
> + WARN_ON(!list_empty(&fence->cb_list));
>
> if (fence->ops->release)
> fence->ops->release(fence);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9342cf0dada4..171895072435 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
> static inline void dma_fence_set_error(struct dma_fence *fence,
> int error)
> {
> - BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> - BUG_ON(error >= 0 || error < -MAX_ERRNO);
> + WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> + WARN_ON(error >= 0 || error < -MAX_ERRNO);
>
> fence->error = error;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/18] drm/sun4i: tcon: Move out the tcon0 common setup
On Tue, Jul 18, 2017 at 11:41:36AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
> wrote:
> > Some channel0 setup has to be done, no matter what the output interface is
> > (RGB, CPU, LVDS). Move that code into a common function in order to avoid
> > duplication.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 26 --
> > 1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index a3bbf9994cfa..f051862d635e 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -125,15 +125,26 @@ static int sun4i_tcon_get_clk_delay(struct
> > drm_display_mode *mode,
> > return delay;
> > }
> >
> > -static void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > -struct drm_display_mode *mode)
> > +static void sun4i_tcon0_mode_set_common(struct sun4i_tcon *tcon,
> > + struct drm_display_mode *mode)
> > +{
> > + /* Configure the dot clock */
> > + clk_set_rate_protect(tcon->dclk, mode->crtc_clock * 1000);
>
> I'd prefer not changing APIs in a code move. It also means we could
> apply this sooner than later. Otherwise,
You're right, I've changed it.
> Reviewed-by: Chen-Yu Tsai
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: Convert to using %pOF instead of full_name
On Tue, Jul 18, 2017 at 04:43:04PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
>
> Signed-off-by: Rob Herring
Hi Rob,
Thanks for sending this patch, and thanks to Laurent, Philipp, and Maxime for
reviews/acks.
I've applied it to drm-misc-next.
Sean
> Cc: Russell King
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Javier Martinez Canillas
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: Neil Armstrong
> Cc: Carlo Caione
> Cc: Kevin Hilman
> Cc: Thierry Reding
> Cc: Laurent Pinchart
> Cc: Mark Yao
> Cc: Heiko Stuebner
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> ---
> drivers/gpu/drm/armada/armada_crtc.c| 3 +--
> drivers/gpu/drm/armada/armada_drv.c | 4 ++--
> drivers/gpu/drm/drm_mipi_dsi.c | 6 +++---
> drivers/gpu/drm/drm_modes.c | 4 ++--
> drivers/gpu/drm/drm_of.c| 4 ++--
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 +--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 3 +--
> drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 4 ++--
> drivers/gpu/drm/mediatek/mtk_dpi.c | 6 +++---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 7 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 6 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16
> drivers/gpu/drm/mediatek/mtk_dsi.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 8
> drivers/gpu/drm/meson/meson_drv.c | 5 ++---
> drivers/gpu/drm/panel/panel-lvds.c | 16
> drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 ++--
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 16
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++--
> drivers/gpu/drm/stm/ltdc.c | 3 +--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 9 -
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 4 ++--
> drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
> 26 files changed, 73 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 4fe19fde84f9..85977c08879e 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1329,8 +1329,7 @@ armada_lcd_bind(struct device *dev, struct device
> *master, void *data)
> port = of_get_child_by_name(parent, "port");
> of_node_put(np);
> if (!port) {
> - dev_err(dev, "no port node found in %s\n",
> - parent->full_name);
> + dev_err(dev, "no port node found in %pOF\n", parent);
> return -ENXIO;
> }
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index e618fab7f519..0b3227c039d7 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -232,8 +232,8 @@ static void armada_add_endpoints(struct device *dev,
> of_node_put(remote);
> continue;
> } else if (!of_device_is_available(remote->parent)) {
> - dev_warn(dev, "parent device of %s is not available\n",
> - remote->full_name);
> + dev_warn(dev, "parent device of %pOF is not
> available\n",
> + remote);
> of_node_put(remote);
> continue;
> }
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 1160a579e0dc..4b47226b90d4 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -165,14 +165,14 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host,
> struct device_node *node)
> u32 reg;
>
> if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
> - dev_err(dev, "modalias failure on %s\n", node->full_name);
> +
Re: [PATCH] xf86drm: continue after drmProcessPlatformDevice failure
On Wed, Jul 19, 2017 at 08:37:06AM -0700, Gurchetan Singh wrote: > On ChromeOS devices, readdir() processes the directory in > the following order: > > -NAME- -TYPE- > .n/a > .. n/a > vgem n/a > card1 DRM_BUS_PLATFORM > renderD129 DRM_BUS_PLATFORM > card0 DRM_BUS_PCI > renderD128DRM_BUS_PCI > controlD64DRM_BUS_PCI > > In drmGetDevices2, after drmProcessPlatformDevice fails for > /dev/dri/card1, we don't process the remaining directory entries. > As such, Vulkan fails to initialize since Mesa uses drmGetDevices2. > To fix this, continue if drmProcessPlatformDevice fails. > --- > xf86drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I'm not sure this is a good fix. drmProcessPlatformDevice() is only supposed to fail in fatal situations, such as out-of-memory. So the reason it doesn't continue is that it doesn't make sense to. In the case of out-of-memory situations, for example, the next allocation is assumed to fail as well. Now, reading the code again, maybe the reason it is failing is because the code tries to look for OF_FULLNAME and OF_COMPATIBLE_N and may not find them. I suspect that card1 and renderD129 are from a vgem device, which is, as far as I can tell, the only case of a platform device without an OF node. In that case I think we should fix drmProcessPlatformDevice() to deal with those cases instead (make the list of compatibles optional, and fallback to some other mechanism to determine the name). Otherwise we will be silently ignoring errors and skipping devices that we really shouldn't. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101850] [PIGLIT] Piglit does not recognize some tests
https://bugs.freedesktop.org/show_bug.cgi?id=101850 arkadiusz.hi...@intel.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com |.org| --- Comment #1 from arkadiusz.hi...@intel.com --- The bug is actually due to those tests not respecting "the contract". IGTs are supposed to exit with code 79 if --list-subtests is supplied and we have a binary without any subtests. Those tests used the wrong igt_main macro and the ./bin --list-subtests exited with 0. Yet another thing to add to the distcheck :-) Thanks for reporting, I'll send a patch in a minute. -- 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 13/18] dt-bindings: vendor: Add Huarui Lighting
Hi Chen-Yu, On Fri, Jul 14, 2017 at 03:53:40PM +0800, Chen-Yu Tsai wrote: > On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard > wrote: > > Huarui Lighting makes display panel, add it to the list of panels. > > I could not find any information on "Huarui Lighting" within the > context of LCD panels. The company I found makes LED lighting > fixtures, floodlights, and high power LED drivers. > > This might not be a legitimate branding? The references are sparse, but the only time I could find a vendor for that part was here, page 51: https://www.codico.com/shop/media/datasheets/Quectel_SC20_Hardware_Design_V1.2.pdf But maybe it's wrong. And since it has a BPi logo on it, maybe we should just use sinovoip as the vendor. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101850] [PIGLIT] Piglit does not recognize some tests
https://bugs.freedesktop.org/show_bug.cgi?id=101850 arkadiusz.hi...@intel.com changed: What|Removed |Added Component|tests |IGT QA Contact|pig...@lists.freedesktop.or | |g | Product|piglit |DRI Assignee|pig...@lists.freedesktop.or |dri-devel@lists.freedesktop |g |.org -- 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 07/18] drm/sun4i: tcon: Don't rely on encoders to set the TCON mode
On Fri, Jul 14, 2017 at 11:56:18AM +0800, Chen-Yu Tsai wrote:
> On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard
> wrote:
> > Just like we did for the TCON enable and disable, for historical reasons we
> > used to rely on the encoders calling the TCON mode_set function, while the
> > CRTC has a callback for that.
> >
> > Let's implement it in order to reduce the boilerplate code.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun4i_crtc.c | 11 -
> > drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 1 +-
> > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 7 +---
> > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 1 +-
> > drivers/gpu/drm/sun4i/sun4i_rgb.c | 15 +--
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 56 ++
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 10 +
> > drivers/gpu/drm/sun4i/sun4i_tv.c| 6 +--
> > 8 files changed, 40 insertions(+), 67 deletions(-)
> >
>
> [...]
>
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index dc70bc2a42a5..c4407910dfaf 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -106,29 +106,6 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon,
> > bool enable)
> > }
> > EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
> >
> > -void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel,
> > - struct drm_encoder *encoder)
> > -{
> > - u32 val;
> > -
> > - if (!tcon->quirks->has_unknown_mux)
> > - return;
> > -
> > - if (channel != 1)
> > - return;
> > -
> > - if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
> > - val = 1;
> > - else
> > - val = 0;
> > -
> > - /*
> > -* FIXME: Undocumented bits
> > -*/
> > - regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val);
> > -}
> > -EXPORT_SYMBOL(sun4i_tcon_set_mux);
> > -
> > static int sun4i_tcon_get_clk_delay(struct drm_display_mode *mode,
> > int channel)
> > {
> > @@ -147,8 +124,8 @@ static int sun4i_tcon_get_clk_delay(struct
> > drm_display_mode *mode,
> > return delay;
> > }
> >
> > -void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > - struct drm_display_mode *mode)
> > +static void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > +struct drm_display_mode *mode)
>
> Nit on the side: maybe we could mark mode as constant?
> Since the function doesn't change it. Same applies to the
> other mode_set functions. But this could be left to another
> patch.
We totally should. I'll do it.
> > {
> > unsigned int bp, hsync, vsync;
> > u8 clk_delay;
> > @@ -221,10 +198,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
> > /* Enable the output on the pins */
> > regmap_write(tcon->regs, SUN4I_TCON0_IO_TRI_REG, 0);
> > }
> > -EXPORT_SYMBOL(sun4i_tcon0_mode_set);
> >
> > -void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> > - struct drm_display_mode *mode)
> > +static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> > +struct drm_display_mode *mode)
> > {
> > unsigned int bp, hsync, vsync, vtotal;
> > u8 clk_delay;
> > @@ -312,7 +288,29 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> >SUN4I_TCON_GCTL_IOMAP_MASK,
> >SUN4I_TCON_GCTL_IOMAP_TCON1);
> > }
> > -EXPORT_SYMBOL(sun4i_tcon1_mode_set);
> > +
> > +void sun4i_tcon_mode_set(struct sun4i_tcon *tcon, struct drm_encoder
> > *encoder,
> > +struct drm_display_mode *mode)
>
> (also mark encoder as const?)
Yep.
> > +{
> > + switch (encoder->encoder_type) {
> > + case DRM_MODE_ENCODER_NONE:
> > + sun4i_tcon0_mode_set(tcon, mode);
> > + break;
> > + case DRM_MODE_ENCODER_TVDAC:
> > + /*
> > +* FIXME: Undocumented bits
> > +*/
> > + if (tcon->quirks->has_unknown_mux)
> > + regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG,
> > 1);
> > + /* Fallthrough */
> > + case DRM_MODE_ENCODER_TMDS:
> > + sun4i_tcon1_mode_set(tcon, mode);
>
> IIRC you need to clear the mux bit here. So ...
>
> > + break;
> > + default:
> > + DRM_DEBUG_DRIVER("Unknown encoder type, doing
> > nothing...\n");
> > + }
>
> I think keeping the muxing in a separate function would be cleaner.
> The above is already slightly messy if you add the bit clearing part.
> With all the other muxing possibilities in the other SoC this is
> going to get really messy.
Ok.
> > +}
> > +EXPORT_SYMBOL(sun4i_tcon_mode_set);
> >
> > static void sun4i_tcon_finish_page_flip(struct drm_device *d
Re: [PATCH 06/18] drm/sun4i: tcon: Don't rely on encoders to enable the TCON
Hi Chen-Yu,
On Fri, Jul 14, 2017 at 11:40:07AM +0800, Chen-Yu Tsai wrote:
> > static void sun4i_rgb_encoder_mode_set(struct drm_encoder *encoder,
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index d9791292553e..dc70bc2a42a5 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -32,66 +33,62 @@
> > #include "sun4i_tcon.h"
> > #include "sunxi_engine.h"
> >
> > -void sun4i_tcon_disable(struct sun4i_tcon *tcon)
> > +static void sun4i_tcon_channel_set_status(struct sun4i_tcon *tcon, int
> > channel,
> > + bool enabled)
> > {
> > - DRM_DEBUG_DRIVER("Disabling TCON\n");
> > + struct clk *clk;
> >
> > - /* Disable the TCON */
> > - regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> > - SUN4I_TCON_GCTL_TCON_ENABLE, 0);
> > -}
> > -EXPORT_SYMBOL(sun4i_tcon_disable);
> > -
> > -void sun4i_tcon_enable(struct sun4i_tcon *tcon)
> > -{
> > - DRM_DEBUG_DRIVER("Enabling TCON\n");
> > -
> > - /* Enable the TCON */
> > - regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> > - SUN4I_TCON_GCTL_TCON_ENABLE,
> > - SUN4I_TCON_GCTL_TCON_ENABLE);
> > -}
> > -EXPORT_SYMBOL(sun4i_tcon_enable);
> > -
> > -void sun4i_tcon_channel_disable(struct sun4i_tcon *tcon, int channel)
> > -{
> > - DRM_DEBUG_DRIVER("Disabling TCON channel %d\n", channel);
> > -
> > - /* Disable the TCON's channel */
> > - if (channel == 0) {
> > + switch (channel) {
> > + case 0:
> > regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
> > - SUN4I_TCON0_CTL_TCON_ENABLE, 0);
> > - clk_disable_unprepare(tcon->dclk);
> > + SUN4I_TCON0_CTL_TCON_ENABLE,
> > + enabled ? SUN4I_TCON0_CTL_TCON_ENABLE :
> > 0);
> > + clk = tcon->dclk;
> > + break;
> > + case 1:
> > + WARN_ON(!tcon->quirks->has_channel_1);
> > + regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
> > + SUN4I_TCON1_CTL_TCON_ENABLE,
> > + enabled ? SUN4I_TCON1_CTL_TCON_ENABLE :
> > 0);
> > + clk = tcon->sclk1;
> > + break;
> > + default:
> > + DRM_DEBUG_DRIVER("Unknown channel... doing nothing\n");
> > return;
> > }
> >
> > - WARN_ON(!tcon->quirks->has_channel_1);
> > - regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
> > - SUN4I_TCON1_CTL_TCON_ENABLE, 0);
> > - clk_disable_unprepare(tcon->sclk1);
> > + if (enabled)
> > + clk_prepare_enable(clk);
>
> I wonder if it's better to enable the clk before the TCON?
I think I kept the current behaviour, which seemed to work fine with
that regard.
>
> > + else
> > + clk_disable_unprepare(clk);
> > }
> > -EXPORT_SYMBOL(sun4i_tcon_channel_disable);
> >
> > -void sun4i_tcon_channel_enable(struct sun4i_tcon *tcon, int channel)
> > +void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
> > + struct drm_encoder *encoder,
> > + bool enabled)
> > {
> > - DRM_DEBUG_DRIVER("Enabling TCON channel %d\n", channel);
> > -
> > - /* Enable the TCON's channel */
> > - if (channel == 0) {
> > - regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
> > - SUN4I_TCON0_CTL_TCON_ENABLE,
> > - SUN4I_TCON0_CTL_TCON_ENABLE);
> > - clk_prepare_enable(tcon->dclk);
> > + int channel;
> > +
> > + switch (encoder->encoder_type) {
> > + case DRM_MODE_ENCODER_NONE:
> > + channel = 0;
> > + break;
> > + case DRM_MODE_ENCODER_TMDS:
> > + case DRM_MODE_ENCODER_TVDAC:
> > + channel = 1;
> > + break;
> > + default:
> > + DRM_DEBUG_DRIVER("Unknown encoder type, doing
> > nothing...\n");
>
> We could simply add all the possible types, and print a big warning
> if someone does something unexpected. IMHO this is better than having
> the user enable some hidden debug flag to figure why the display isn't
> working properly.
I'm not sure about all types of encoders, but you're right, it should
be a warning.
> > return;
> > }
> >
> > - WARN_ON(!tcon->quirks->has_channel_1);
> > - regmap_update_bits(tcon->regs, SUN4I_TCON1_CTL_REG,
> > - SUN4I_TCON1_CTL_TCON_ENABLE,
> > - SUN4I_TCON1_CTL_TCON_ENABLE);
> > - clk_prepare_enable(tcon->sclk1)
Re: [PATCH 03/18] drm/sun4i: Realign Makefile padding and reorder it
On Fri, Jul 14, 2017 at 11:13:53AM +0800, Chen-Yu Tsai wrote: > On Thu, Jul 13, 2017 at 10:12 PM, Maxime Ripard > wrote: > > Some options were not padded as they should, and the order in the Makefile > > was chaotic. Fix that. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/sun4i/Makefile | 26 +- > > 1 file changed, 13 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile > > index e29fd3a2ba9c..42871ee7acf6 100644 > > --- a/drivers/gpu/drm/sun4i/Makefile > > +++ b/drivers/gpu/drm/sun4i/Makefile > > @@ -1,23 +1,23 @@ > > -sun4i-drm-y += sun4i_drv.o > > -sun4i-drm-y += sun4i_framebuffer.o > > +sun4i-backend-y+= sun4i_backend.o sun4i_layer.o > > > > -sun4i-drm-hdmi-y += sun4i_hdmi_enc.o > > -sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o > > -sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o > > +sun4i-drm-y+= sun4i_drv.o > > +sun4i-drm-y+= sun4i_framebuffer.o > > I don't think this applies on top of Jonathan's HDMI I2C patch > you already have queued up. > > Also you might want to leave a comment describe what the > ordering should be. Otherwise it will still be messed up > down the road. Good point, I'll do that, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
The current drm_atomic_helper_commit_tail helper works only if the CRTC is
accessible, and documents an alternative implementation that is supposed to
be used if that happens.
That implementation is then duplicated by some drivers. Instead of
documenting it, let's implement an helper that all the relevant users can
use directly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_helper.c| 49 +++
drivers/gpu/drm/exynos/exynos_drm_fb.c | 27 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +--
include/drm/drm_atomic_helper.h| 1 +-
4 files changed, 37 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 86d3093c6c9b..d06a65ed3a57 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1245,23 +1245,13 @@ EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
* @old_state: atomic state object with old state structures
*
* This is the default implementation for the
- * &drm_mode_config_helper_funcs.atomic_commit_tail hook.
+ * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
+ * that do not support runtime_pm or do not need the CRTC to be
+ * enabled to perform a commit. Otherwise, see
+ * drm_atomic_helper_commit_tail_rpm().
*
* Note that the default ordering of how the various stages are called is to
- * match the legacy modeset helper library closest. One peculiarity of that is
- * that it doesn't mesh well with runtime PM at all.
- *
- * For drivers supporting runtime PM the recommended sequence is instead ::
- *
- * drm_atomic_helper_commit_modeset_disables(dev, old_state);
- *
- * drm_atomic_helper_commit_modeset_enables(dev, old_state);
- *
- * drm_atomic_helper_commit_planes(dev, old_state,
- * DRM_PLANE_COMMIT_ACTIVE_ONLY);
- *
- * for committing the atomic update to hardware. See the kerneldoc entries for
- * these three functions for more details.
+ * match the legacy modeset helper library closest.
*/
void drm_atomic_helper_commit_tail(struct drm_atomic_state *old_state)
{
@@ -1281,6 +1271,35 @@ void drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
}
EXPORT_SYMBOL(drm_atomic_helper_commit_tail);
+/**
+ * drm_atomic_helper_commit_tail_rpm - commit atomic update to hardware
+ * @old_state: new modeset state to be committed
+ *
+ * This is an alternative implementation for the
+ * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
+ * that support runtime_pm or need the CRTC to be enabled to perform a
+ * commit. Otherwise, one should use the default implementation
+ * drm_atomic_helper_commit_tail().
+ */
+void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
+{
+ struct drm_device *dev = old_state->dev;
+
+ drm_atomic_helper_commit_modeset_disables(dev, old_state);
+
+ drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+ drm_atomic_helper_commit_planes(dev, old_state,
+ DRM_PLANE_COMMIT_ACTIVE_ONLY);
+
+ drm_atomic_helper_commit_hw_done(old_state);
+
+ drm_atomic_helper_wait_for_vblanks(dev, old_state);
+
+ drm_atomic_helper_cleanup_planes(dev, old_state);
+}
+EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
+
static void commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d48fd7c918f8..ed1a648d518c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -187,33 +187,8 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer
*fb, int index)
return exynos_fb->dma_addr[index];
}
-static void exynos_drm_atomic_commit_tail(struct drm_atomic_state *state)
-{
- struct drm_device *dev = state->dev;
-
- drm_atomic_helper_commit_modeset_disables(dev, state);
-
- drm_atomic_helper_commit_modeset_enables(dev, state);
-
- /*
-* Exynos can't update planes with CRTCs and encoders disabled,
-* its updates routines, specially for FIMD, requires the clocks
-* to be enabled. So it is necessary to handle the modeset operations
-* *before* the commit_planes() step, this way it will always
-* have the relevant clocks enabled to perform the update.
-*/
- drm_atomic_helper_commit_planes(dev, state,
- DRM_PLANE_COMMIT_ACTIVE_ONLY);
-
- drm_atomic_helper_commit_hw_done(state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
-}
-
static struct drm_mode_config_helper_funcs exynos_drm_mode_config_helpers = {
- .atomic_commit_tail = exynos_drm_atomic_commit_tail,
+ .atomic_commit_tail = drm_atomic_helper_commit_tai
[PATCH v2 0/4] drm/sun4i: Fix a register access bug
The Allwinner backend has a commit bit in order to push the new configuration to the actual hardware. We've always been using that bit. However, we also should poll for that bit to clear, which we don't. Accessing any register while a commit is pending is forbidden, and will for example show a symptom of reading another, random, register. If you get this during a read/modify/write cycle, this will result in random register corruption, which are pretty bad. This can be shown using the following program (while the backend is active): http://code.bulix.org/gdl44p-161437?raw Fortunately for us, this is not really likely to happen. The window where it can happen is quite thin, and it only happens during a modeset, since it's the only time we commit some new configuration. Unfortunately for us, QT does a ridiculous amount of modeset, and will just hit that window after a while, creating a distorded (since the register we read/modify/write also has scaling attributes) or with weird colors (since it also has a invertion of red and blue components). And might fix itself later on by reading another random register with proper values for these fields. Let me know what you think, Maxime Changes from v1: - Renamed the function drm_atomic_helper_commit_tail_rpm - Dropped the changes in the rcar-du driver - Enhanced the documentation based on Daniel's comments Maxime Ripard (4): drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users drm/sun4i: Use the runtime_pm commit_tail variant drm/sun4i: engine: Add commit_poll function drm/sun4i: make sure we don't have a commit pending drivers/gpu/drm/drm_atomic_helper.c| 49 +++ drivers/gpu/drm/exynos/exynos_drm_fb.c | 27 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 21 +-- drivers/gpu/drm/sun4i/sun4i_backend.c | 14 +++- drivers/gpu/drm/sun4i/sun4i_crtc.c | 3 +- drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 6 +++- drivers/gpu/drm/sun4i/sunxi_engine.h | 14 +++- include/drm/drm_atomic_helper.h| 1 +- 8 files changed, 74 insertions(+), 61 deletions(-) base-commit: 5771a8c08880cdca3bfb4a3fc6d309d6bba20877 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/sun4i: Use the runtime_pm commit_tail variant
The backend (planes) commit can only happen when the TCON (CRTC) is
enabled, which is not guaranteed with the default commit_tail helper.
Let's use the runtime_pm version that is designed specifically to deal with
that case.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index 9872e0fc03b0..53ab61665390 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -10,6 +10,7 @@
* the License, or (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -31,6 +32,10 @@ static const struct drm_mode_config_funcs
sun4i_de_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
};
+static struct drm_mode_config_helper_funcs sun4i_de_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
struct drm_fbdev_cma *sun4i_framebuffer_init(struct drm_device *drm)
{
drm_mode_config_reset(drm);
@@ -39,6 +44,7 @@ struct drm_fbdev_cma *sun4i_framebuffer_init(struct
drm_device *drm)
drm->mode_config.max_height = 8192;
drm->mode_config.funcs = &sun4i_de_mode_config_funcs;
+ drm->mode_config.helper_private = &sun4i_de_mode_config_helpers;
return drm_fbdev_cma_init(drm, 32, drm->mode_config.num_connector);
}
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/sun4i: engine: Add commit_poll function
On the earlier Allwinner chips, with the first iteration of the display
engine, the backend commit bit needs to be polled before making any
register access to the backend.
Add an operation for that, that will be called in atomic_begin in order to
be sure to have that bit cleared before we do any modifications.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 ++
drivers/gpu/drm/sun4i/sunxi_engine.h | 14 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index f8c70439d1e2..2eba1d8639d8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -45,6 +45,8 @@ static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
spin_unlock_irqrestore(&dev->event_lock, flags);
crtc->state->event = NULL;
}
+
+ WARN_ON(sunxi_engine_commit_poll(engine));
}
static void sun4i_crtc_atomic_flush(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
b/drivers/gpu/drm/sun4i/sunxi_engine.h
index 4cb70ae65c79..6618e182613c 100644
--- a/drivers/gpu/drm/sun4i/sunxi_engine.h
+++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
@@ -17,6 +17,7 @@ struct sunxi_engine;
struct sunxi_engine_ops {
void (*commit)(struct sunxi_engine *engine);
+ int (*commit_poll)(struct sunxi_engine *engine);
struct drm_plane **(*layers_init)(struct drm_device *drm,
struct sunxi_engine *engine);
@@ -55,6 +56,19 @@ sunxi_engine_commit(struct sunxi_engine *engine)
}
/**
+ * sunxi_engine_commit_poll() - wait for all changes to be committed
+ * @engine:pointer to the engine
+ */
+static inline int
+sunxi_engine_commit_poll(struct sunxi_engine *engine)
+{
+ if (engine->ops && engine->ops->commit_poll)
+ return engine->ops->commit_poll(engine);
+
+ return 0;
+}
+
+/**
* sunxi_engine_layers_init() - Create planes (layers) for the engine
* @drm: pointer to the drm_device for which planes will be created
* @engine:pointer to the engine
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/sun4i: make sure we don't have a commit pending
In the earlier display engine designs, any register access while a commit
is pending is forbidden.
One of the symptoms is that reading a register will return another, random,
register value which can lead to register corruptions if we ever do a
read/modify/write cycle.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 14 ++
drivers/gpu/drm/sun4i/sun4i_crtc.c| 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index cf480218daa5..ce1f40f7511e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -67,6 +67,19 @@ static void sun4i_backend_commit(struct sunxi_engine *engine)
SUN4I_BACKEND_REGBUFFCTL_LOADCTL);
}
+static int sun4i_backend_commit_poll(struct sunxi_engine *engine)
+{
+ u32 val;
+
+ DRM_DEBUG_DRIVER("Polling for the commit to end\n");
+
+ return regmap_read_poll_timeout(engine->regs,
+ SUN4I_BACKEND_REGBUFFCTL_REG,
+ val,
+ !(val &
SUN4I_BACKEND_REGBUFFCTL_LOADCTL),
+ 100, 5);
+}
+
void sun4i_backend_layer_enable(struct sun4i_backend *backend,
int layer, bool enable)
{
@@ -330,6 +343,7 @@ static int sun4i_backend_of_get_id(struct device_node *node)
static const struct sunxi_engine_ops sun4i_backend_engine_ops = {
.commit = sun4i_backend_commit,
+ .commit_poll= sun4i_backend_commit_poll,
.layers_init= sun4i_layers_init,
.apply_color_correction = sun4i_backend_apply_color_correction,
.disable_color_correction =
sun4i_backend_disable_color_correction,
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 2eba1d8639d8..31550493fa1d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -34,6 +34,7 @@ static void sun4i_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
+ struct sunxi_engine *engine = scrtc->engine;
struct drm_device *dev = crtc->dev;
unsigned long flags;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 20, 2017 at 12:38:53PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 20, 2017 at 12:04:50PM +0100, Liviu Dudau wrote:
> > > When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
> > > I get the following warning from the system:
> > >
> > > [ 25.990733] ==
> > > [ 25.998637] WARNING: possible circular locking dependency detected
> > > [ 26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
> > > [ 26.014246] --
> > > [ 26.022142] kworker/1:2/140 is trying to acquire lock:
> > > [ 26.029001] (&priv->audio_mutex){+.+.+.}, at: []
> > > tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
> > > [ 26.041100]
> > > [ 26.041100] but task is already holding lock:
> > > [ 26.050436] (crtc_ww_class_mutex){+.+.+.}, at: []
> > > drm_modeset_lock+0x64/0xf8 [drm]
> > > [ 26.061531]
> > > [ 26.061531] which lock already depends on the new lock.
> > > [ 26.061531]
> > > [ 26.075063]
> > > [ 26.075063] the existing dependency chain (in reverse order) is:
> > > [ 26.086031]
> > > [ 26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
> > > [ 26.095657]__lock_acquire+0x18a0/0x19b8
> > > [ 26.101918]lock_acquire+0xd0/0x2b0
> > > [ 26.107731]__ww_mutex_lock.constprop.3+0x90/0xe78
> > > [ 26.114817]ww_mutex_lock+0x54/0xe0
> > > [ 26.120672]drm_modeset_lock+0x64/0xf8 [drm]
> > > [ 26.127253]drm_helper_probe_single_connector_modes+0x7c/0x6b8
> > > [drm_kms_helper]
> > > [ 26.136829]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
> > > [ 26.144797]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
> > > [ 26.152429]drm_fb_helper_initial_config+0x70/0x440
> > > [drm_kms_helper]
> > > [ 26.161097]drm_fbdev_cma_init_with_funcs+0x94/0x168
> > > [drm_kms_helper]
> > > [ 26.169857]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
> > > [ 26.177559]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
> > > [ 26.184310]try_to_bring_up_master+0x180/0x1e0
> > > [ 26.191043]component_master_add_with_match+0xb0/0x108
> > > [ 26.198458]hdlcd_probe+0x58/0x80 [hdlcd]
> > > [ 26.204735]platform_drv_probe+0x60/0xc0
> > > [ 26.210913]driver_probe_device+0x23c/0x2e8
> > > [ 26.217350]__driver_attach+0xd4/0xd8
> > > [ 26.223256]bus_for_each_dev+0x5c/0xa8
> > > [ 26.229232]driver_attach+0x30/0x40
> > > [ 26.234917]bus_add_driver+0x1d8/0x248
> > > [ 26.240831]driver_register+0x6c/0x118
> > > [ 26.246715]__platform_driver_register+0x54/0x60
> > > [ 26.253461]0x00e1b018
> > > [ 26.258644]do_one_initcall+0x44/0x138
> > > [ 26.264503]do_init_module+0x64/0x1d4
> > > [ 26.270238]load_module+0x1f90/0x2590
> > > [ 26.275957]SyS_finit_module+0xb0/0xc8
> > > [ 26.281765]__sys_trace_return+0x0/0x4
> > > [ 26.281767]
> > > [ 26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
> > > [ 26.281778]__lock_acquire+0x18a0/0x19b8
> > > [ 26.281782]lock_acquire+0xd0/0x2b0
> > > [ 26.281877]drm_modeset_acquire_init+0xa8/0xe0 [drm]
> > > [ 26.281921]drm_helper_probe_single_connector_modes+0x48/0x6b8
> > > [drm_kms_helper]
> > > [ 26.281929]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
> > > [ 26.281970]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
> > > [ 26.282009]drm_fb_helper_initial_config+0x70/0x440
> > > [drm_kms_helper]
> > > [ 26.282049]drm_fbdev_cma_init_with_funcs+0x94/0x168
> > > [drm_kms_helper]
> > > [ 26.282088]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
> > > [ 26.282095]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
> > > [ 26.282099]try_to_bring_up_master+0x180/0x1e0
> > > [ 26.282104]component_master_add_with_match+0xb0/0x108
> > > [ 26.282110]hdlcd_probe+0x58/0x80 [hdlcd]
> > > [ 26.282114]platform_drv_probe+0x60/0xc0
> > > [ 26.282117]driver_probe_device+0x23c/0x2e8
> > > [ 26.282121]__driver_attach+0xd4/0xd8
> > > [ 26.282124]bus_for_each_dev+0x5c/0xa8
> > > [ 26.282127]driver_attach+0x30/0x40
> > > [ 26.282130]bus_add_driver+0x1d8/0x248
> > > [ 26.282134]driver_register+0x6c/0x118
> > > [ 26.282138]__platform_driver_register+0x54/0x60
> > > [ 26.282141]0x00e1b018
> > > [ 26.282145]do_one_initcall+0x44/0x138
> > > [ 26.282149]do_init_module+0x64/0x1d4
> > > [ 26.282152]load_module+0x1f90/0x2590
> > > [ 26.282156]SyS_finit_module+0xb0/0xc8
> > > [ 26.282159]__sys_trace_return+0x0/0x4
> > > [ 26.282161]
> > > [ 26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
> > >
[PATCH] dma-fence: Don't BUG_ON when not absolutely needed
It makes debugging a massive pain.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence.c | 4 ++--
include/linux/dma-fence.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 56e0a0e1b600..9a302799040e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
ATOMIC64_INIT(0);
*/
u64 dma_fence_context_alloc(unsigned num)
{
- BUG_ON(!num);
+ WARN_ON(!num);
return atomic64_add_return(num, &dma_fence_context_counter) - num;
}
EXPORT_SYMBOL(dma_fence_context_alloc);
@@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
trace_dma_fence_destroy(fence);
- BUG_ON(!list_empty(&fence->cb_list));
+ WARN_ON(!list_empty(&fence->cb_list));
if (fence->ops->release)
fence->ops->release(fence);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9342cf0dada4..171895072435 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
static inline void dma_fence_set_error(struct dma_fence *fence,
int error)
{
- BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
- BUG_ON(error >= 0 || error < -MAX_ERRNO);
+ WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+ WARN_ON(error >= 0 || error < -MAX_ERRNO);
fence->error = error;
}
--
2.13.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/bridge/synopsys: dsi: explicitly request exclusive reset control
Hi Philippe,
On Thu, 2017-07-20 at 14:19 +0200, Philippe CORNU wrote:
> Based on patch "Convert drivers to explicit reset API" from Philipp Zabel
>
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
>
> No functional changes.
>
> Cc: Philipp Zabel
> Signed-off-by: Philippe CORNU
This reset control indeed has to be exclusive, as the driver depends on
the reset assertion to have an effect.
Acked-by: Philipp Zabel
Again, the reset seems to be optional, though. I would suggest to change
this as follows:
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 781340d..bb0bfa8 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -885,7 +885,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
> *bridge)
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
>*/
> - apb_rst = devm_reset_control_get(dev, "apb");
> + apb_rst = devm_reset_control_get_exclusive(dev, "apb");
> if (IS_ERR(apb_rst)) {
> ret = PTR_ERR(apb_rst);
> if (ret == -ENOENT) {
- apb_rst = devm_reset_control_get(dev, "apb");
+ apb_rst = devm_reset_control_get_optional_exclusive(dev, "apb");
if (IS_ERR(apb_rst)) {
ret = PTR_ERR(apb_rst);
- if (ret == -ENOENT) {
- apb_rst = NULL;
- } else {
- dev_err(dev, "Unable to get reset control: %d\n", ret);
- return ERR_PTR(ret);
- }
+ dev_err(dev, "Unable to get reset control: %d\n", ret);
+ return ERR_PTR(ret);
}
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] drm/stm: Various cleanups
2017-07-20 14:05 GMT+02:00 Philippe CORNU : > Version 2: > - Add devm_reset_control_get_exclusive to follow explicit reset API > - Add missing commit messages & reviewed-by. > > Version 1: > - Initial commit > > The purpose of this set of patches is to clean up the drm stm driver. > > Philippe CORNU (7): > drm/stm: drv: Rename platform driver name > drm/stm: ltdc: Cleanup signal polarity defines > drm/stm: ltdc: Lindent and minor cleanups > drm/stm: ltdc: Constify funcs structures > drm/stm: ltdc: add devm_reset_control & platform_get_ressource > drm/stm: ltdc: Cleanup rename returned value > drm/stm: dsi: Constify phy ops structure > > drivers/gpu/drm/stm/drv.c | 21 ++-- > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +- > drivers/gpu/drm/stm/ltdc.c| 225 > -- > 3 files changed, 116 insertions(+), 132 deletions(-) > > -- > 1.9.1 > merged in drm-misc-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/7] drm/stm: ltdc: add devm_reset_control & platform_get_ressource
Hi Philippe,
On Thu, 2017-07-20 at 14:05 +0200, Philippe CORNU wrote:
> Use devm_reset_control_get_exclusive to avoid resource leakage (based
> on patch "Convert drivers to explicit reset API" from Philipp Zabel).
>
> Also use platform_get_resource, which is more usual and
> consistent with platform_get_irq called later.
>
> Signed-off-by: Fabien Dessenne
> Signed-off-by: Philippe CORNU
> Reviewed-by: Benjamin Gaignard
> Cc: Philipp Zabel
Looking at the usage below, this driver only seems to care about the
reset deassertion before register use, so this could use the shared API.
Further, it seems that this reset is optional.
> ---
> drivers/gpu/drm/stm/ltdc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 92e58ba..d826045 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -874,7 +874,7 @@ int ltdc_load(struct drm_device *ddev)
> struct drm_panel *panel;
> struct drm_crtc *crtc;
> struct reset_control *rstc;
> - struct resource res;
> + struct resource *res;
> int irq, ret, i;
>
> DRM_DEBUG_DRIVER("\n");
> @@ -883,7 +883,7 @@ int ltdc_load(struct drm_device *ddev)
> if (ret)
> return ret;
>
> - rstc = of_reset_control_get(np, NULL);
> + rstc = devm_reset_control_get_exclusive(dev, NULL);
I would suggest to change this to
- rstc = of_reset_control_get(np, NULL);
+ rstc = devm_reset_control_get_optional_shared(dev, NULL);
+ if (IS_ERR(rstc))
+ return PTR_ERR(rstc);
> mutex_init(&ldev->err_lock);
>
> @@ -898,13 +898,14 @@ int ltdc_load(struct drm_device *ddev)
> return -ENODEV;
> }
>
> - if (of_address_to_resource(np, 0, &res)) {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> DRM_ERROR("Unable to get resource\n");
> ret = -ENODEV;
> goto err;
> }
>
> - ldev->regs = devm_ioremap_resource(dev, &res);
> + ldev->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(ldev->regs)) {
> DRM_ERROR("Unable to get ltdc registers\n");
> ret = PTR_ERR(ldev->regs);
then below you can change:
- if (!IS_ERR(rstc))
- reset_control_deassert(rstc);
+ reset_control_deassert(rstc);
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/bridge/synopsys: dsi: Register list clean up
This patch cleans up the Synopsys mipi dsi register list: - rename registers according to the Synopsys documentation (1.30 & 1.31) - fix typos - re-order registers for a better coherency Signed-off-by: Philippe CORNU Reviewed-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 92 --- 1 file changed, 56 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 63c7a01..781340d 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -30,19 +30,20 @@ #include #define DSI_VERSION0x00 + #define DSI_PWR_UP 0x04 #define RESET 0 #define POWERUPBIT(0) #define DSI_CLKMGR_CFG 0x08 -#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) -#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) +#define TO_CLK_DIVISION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVISION(div) ((div) & 0xff) #define DSI_DPI_VCID 0x0c -#define DPI_VID(vid) (((vid) & 0x3) << 0) +#define DPI_VCID(vcid) ((vcid) & 0x3) #define DSI_DPI_COLOR_CODING 0x10 -#define EN18_LOOSELY BIT(8) +#define LOOSELY18_EN BIT(8) #define DPI_COLOR_CODING_16BIT_1 0x0 #define DPI_COLOR_CODING_16BIT_2 0x1 #define DPI_COLOR_CODING_16BIT_3 0x2 @@ -61,22 +62,25 @@ #define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) #define INVACT_LPCMD_TIME(p) ((p) & 0xff) +#define DSI_DBI_VCID 0x1c #define DSI_DBI_CFG0x20 +#define DSI_DBI_PARTITIONING_EN0x24 #define DSI_DBI_CMDSIZE0x28 #define DSI_PCKHDL_CFG 0x2c -#define EN_CRC_RX BIT(4) -#define EN_ECC_RX BIT(3) -#define EN_BTA BIT(2) -#define EN_EOTP_RX BIT(1) -#define EN_EOTP_TX BIT(0) +#define CRC_RX_EN BIT(4) +#define ECC_RX_EN BIT(3) +#define BTA_EN BIT(2) +#define EOTP_RX_EN BIT(1) +#define EOTP_TX_EN BIT(0) + +#define DSI_GEN_VCID 0x30 #define DSI_MODE_CFG 0x34 #define ENABLE_VIDEO_MODE 0 #define ENABLE_CMD_MODEBIT(0) #define DSI_VID_MODE_CFG 0x38 -#define FRAME_BTA_ACK BIT(14) #define ENABLE_LOW_POWER (0x3f << 8) #define ENABLE_LOW_POWER_MASK (0x3f << 8) #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0 @@ -85,8 +89,13 @@ #define VID_MODE_TYPE_MASK 0x3 #define DSI_VID_PKT_SIZE 0x3c -#define VID_PKT_SIZE(p)(((p) & 0x3fff) << 0) -#define VID_PKT_MAX_SIZE 0x3fff +#define VID_PKT_SIZE(p)((p) & 0x3fff) + +#define DSI_VID_NUM_CHUNKS 0x40 +#define VID_NUM_CHUNKS(c) ((c) & 0x1fff) + +#define DSI_VID_NULL_SIZE 0x44 +#define VID_NULL_SIZE(b) ((b) & 0x1fff) #define DSI_VID_HSA_TIME 0x48 #define DSI_VID_HBP_TIME 0x4c @@ -95,6 +104,8 @@ #define DSI_VID_VBP_LINES 0x58 #define DSI_VID_VFP_LINES 0x5c #define DSI_VID_VACTIVE_LINES 0x60 +#define DSI_EDPI_CMD_SIZE 0x64 + #define DSI_CMD_MODE_CFG 0x68 #define MAX_RD_PKT_SIZE_LP BIT(24) #define DCS_LW_TX_LP BIT(19) @@ -108,8 +119,8 @@ #define GEN_SW_2P_TX_LPBIT(10) #define GEN_SW_1P_TX_LPBIT(9) #define GEN_SW_0P_TX_LPBIT(8) -#define EN_ACK_RQSTBIT(1) -#define EN_TEAR_FX BIT(0) +#define ACK_RQST_ENBIT(1) +#define TEAR_FX_EN BIT(0) #define CMD_MODE_ALL_LP(MAX_RD_PKT_SIZE_LP | \ DCS_LW_TX_LP | \ @@ -125,27 +136,31 @@ GEN_SW_0P_TX_LP) #define DSI_GEN_HDR0x6c +/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() */ #define GEN_HDATA(data)(((data) & 0x) << 8) -#define GEN_HDATA_MASK (0x << 8) #define GEN_HTYPE(type)(((type) & 0xff) << 0) -#define GEN_HTYPE_MASK 0xff #define DSI_GEN_PLD_DATA 0x70 #define DSI_CMD_PKT_STATUS 0x74 -#define GEN_CMD_EMPTY BIT(0) -#define GEN_CMD_FULL BIT(1) -#define GEN_PLD_W_EMPTYBIT(
[PATCH v2 0/3] drm/bridge/synopsys: dsi: Various cleanups
Version 2: - Put back Synopsys mipi dsi unused registers. - Add devm_reset_control_get_exclusive to follow explicit reset API. - Add a missing commit message & reviewed-by. Version 1: - Initial commit The purpose of this set of patches is to clean up the mipi dsi dw Synopsys drm bridge. Philippe CORNU (3): drm/bridge/synopsys: dsi: Constify funcs structures drm/bridge/synopsys: dsi: Register list clean up drm/bridge/synopsys: dsi: explicitly request exclusive reset control drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 96 --- 1 file changed, 58 insertions(+), 38 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/bridge/synopsys: dsi: explicitly request exclusive reset control
Based on patch "Convert drivers to explicit reset API" from Philipp Zabel
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Philipp Zabel
Signed-off-by: Philippe CORNU
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 781340d..bb0bfa8 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -885,7 +885,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge)
* Note that the reset was not defined in the initial device tree, so
* we have to be prepared for it not being found.
*/
- apb_rst = devm_reset_control_get(dev, "apb");
+ apb_rst = devm_reset_control_get_exclusive(dev, "apb");
if (IS_ERR(apb_rst)) {
ret = PTR_ERR(apb_rst);
if (ret == -ENOENT) {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/bridge/synopsys: dsi: Constify funcs structures
Constify dw_mipi_dsi_bridge_funcs as these functions are not supposed
to change at runtime.
Signed-off-by: Philippe CORNU
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 36f5ccb..63c7a01 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -811,7 +811,7 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge
*bridge)
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge, bridge);
}
-static struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
+static const struct drm_bridge_funcs dw_mipi_dsi_bridge_funcs = {
.mode_set = dw_mipi_dsi_bridge_mode_set,
.enable = dw_mipi_dsi_bridge_enable,
.post_disable = dw_mipi_dsi_bridge_post_disable,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/14] drm/mgag200: Consolidate depth/bpp handling
On Thu, 20 Jul 2017 13:58:14 +0200,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> Thank you for posting these patches for review.
>
>
> Am Dienstag, den 18.07.2017, 16:43 +0200 schrieb Takashi Iwai:
> > From: Egbert Eich
> >
> > The depth/bpp handling for chips with limited memory in commit
> > 918be888d613 ("drm/mgag200: on cards with < 2MB VRAM default to
> > 16-bit") was incomplete: the bpp limits were applied to mode
> > validation.
> >
> > This consolidates dpeth/bpp handling, adds it to mode validation
>
> depth
>
> > and moves the code which reads the command line specified depth
> > into the correct location.
> >
> > Fixes: 918be888d613 ("drm/mgag200: on cards with < 2MB VRAM default to
> > 16-bit")
>
> ```
> $ git tag --contains 918be888d613 | head -1
> v3.14
> ```
>
> Please mark this as stable then too?
I guess it deserves for stable, yes.
I leave the decision to the maintainer.
> Also, could the original commit author time-stamps be preserved if you
> have them in your SUSE repositories? The `Date` line could be added
> below the `From` line. That would help to know for how long the changes
> have been tested.
Unfortunately, we don't know how old the original patch was. The date
isn't preserved in the original patch, either, as it's stored in quilt
queue, not committed in a kernel git tree.
In general, the original date isn't that important, so let's skip that
part.
>
> > Signed-off-by: Egbert Eich
> > Signed-off-by: Takashi Iwai
> > ---
> > drivers/gpu/drm/mgag200/mgag200_drv.h | 2 ++
> > drivers/gpu/drm/mgag200/mgag200_fb.c | 7 +--
> > drivers/gpu/drm/mgag200/mgag200_main.c | 9 ++---
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 14 +++---
> > 4 files changed, 16 insertions(+), 16 deletions(-)
>
> […]
>
> Otherwise this looks fine.
Thanks for your review!
Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] powerpc/asm/cacheflush: Cleanup cacheflush function params
On Thu, Jul 20, 2017 at 1:43 PM, Michael Ellerman wrote:
> Matt Brown writes:
>> The cacheflush prototypes currently use start and stop values and each
>> call requires typecasting the address to an unsigned long.
>> This patch changes the cacheflush prototypes to follow the x86 style of
>> using a base and size values, with base being a void pointer.
>>
>> All callers of the cacheflush functions, including drivers, have been
>> modified to conform to the new prototypes.
>>
>> The 64 bit cacheflush functions which were implemented in assembly code
>> (flush_dcache_range, flush_inval_dcache_range) have been translated into
>> C for readability and coherence.
>> --- a/arch/powerpc/include/asm/cacheflush.h
>> +++ b/arch/powerpc/include/asm/cacheflush.h
>> @@ -51,13 +51,13 @@ static inline void __flush_dcache_icache_phys(unsigned
>> long physaddr)
>> * Write any modified data cache blocks out to memory and invalidate them.
>> * Does not invalidate the corresponding instruction cache blocks.
>> */
>> -static inline void flush_dcache_range(unsigned long start, unsigned long
>> stop)
>> +static inline void flush_dcache_range(void *start, unsigned long size)
>> {
>> - void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1));
>> - unsigned long size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 1);
>> + void *addr = (void *)((u32)start & ~(L1_CACHE_BYTES - 1));
>
> unsigned long would be nicer than u32.
Indeed. That would make this work on ppc64, too.
After which ppc64 has an identical copy (u64 = unsigned long on ppc64) below?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm/stm: dsi: Constify phy ops structure
Constify dw_mipi_dsi_stm_phy_ops as these ops are not supposed
to change at runtime.
Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 16ae00e..568c5d0 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -261,7 +261,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return 0;
}
-static struct dw_mipi_dsi_phy_ops dw_mipi_dsi_stm_phy_ops = {
+static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_stm_phy_ops = {
.init = dw_mipi_dsi_phy_init,
.get_lane_mbps = dw_mipi_dsi_get_lane_mbps,
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm/stm: ltdc: Constify funcs structures
Constify drm funcs structures.
Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/ltdc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 628825b..92e58ba 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -511,7 +511,7 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
}
}
-static struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
+static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
.load_lut = ltdc_crtc_load_lut,
.mode_set_nofb = ltdc_crtc_mode_set_nofb,
.atomic_flush = ltdc_crtc_atomic_flush,
@@ -537,7 +537,7 @@ void ltdc_crtc_disable_vblank(struct drm_device *ddev,
unsigned int pipe)
reg_clear(ldev->regs, LTDC_IER, IER_LIE);
}
-static struct drm_crtc_funcs ltdc_crtc_funcs = {
+static const struct drm_crtc_funcs ltdc_crtc_funcs = {
.destroy = drm_crtc_cleanup,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -693,7 +693,7 @@ static void ltdc_plane_atomic_disable(struct drm_plane
*plane,
oldstate->crtc->base.id, plane->base.id);
}
-static struct drm_plane_funcs ltdc_plane_funcs = {
+static const struct drm_plane_funcs ltdc_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = drm_plane_cleanup,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/stm: ltdc: Lindent and minor cleanups
Lindent then checkpatch --strict cleanups Signed-off-by: Philippe CORNU Reviewed-by: Benjamin Gaignard --- drivers/gpu/drm/stm/ltdc.c | 172 ++--- 1 file changed, 85 insertions(+), 87 deletions(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 50e8a89..628825b 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -42,52 +42,52 @@ * an extra offset specified with reg_ofs. */ #define REG_OFS_NONE 0 -#define REG_OFS_4 4 /* Insertion of "Layer Configuration 2" reg */ +#define REG_OFS_4 4 /* Insertion of "Layer Conf. 2" reg */ #define REG_OFS(ldev->caps.reg_ofs) -#define LAY_OFS0x80/* Register Offset between 2 layers */ +#define LAY_OFS0x80/* Register Offset between 2 layers */ /* Global register offsets */ -#define LTDC_IDR 0x /* IDentification */ -#define LTDC_LCR 0x0004 /* Layer Count */ -#define LTDC_SSCR 0x0008 /* Synchronization Size Configuration */ -#define LTDC_BPCR 0x000C /* Back Porch Configuration */ -#define LTDC_AWCR 0x0010 /* Active Width Configuration */ -#define LTDC_TWCR 0x0014 /* Total Width Configuration */ -#define LTDC_GCR 0x0018 /* Global Control */ -#define LTDC_GC1R 0x001C /* Global Configuration 1 */ -#define LTDC_GC2R 0x0020 /* Global Configuration 2 */ -#define LTDC_SRCR 0x0024 /* Shadow Reload Configuration */ -#define LTDC_GACR 0x0028 /* GAmma Correction */ -#define LTDC_BCCR 0x002C /* Background Color Configuration */ -#define LTDC_IER 0x0034 /* Interrupt Enable */ -#define LTDC_ISR 0x0038 /* Interrupt Status */ -#define LTDC_ICR 0x003C /* Interrupt Clear */ -#define LTDC_LIPCR 0x0040 /* Line Interrupt Position Configuration */ -#define LTDC_CPSR 0x0044 /* Current Position Status */ -#define LTDC_CDSR 0x0048 /* Current Display Status */ +#define LTDC_IDR 0x /* IDentification */ +#define LTDC_LCR 0x0004 /* Layer Count */ +#define LTDC_SSCR 0x0008 /* Synchronization Size Configuration */ +#define LTDC_BPCR 0x000C /* Back Porch Configuration */ +#define LTDC_AWCR 0x0010 /* Active Width Configuration */ +#define LTDC_TWCR 0x0014 /* Total Width Configuration */ +#define LTDC_GCR 0x0018 /* Global Control */ +#define LTDC_GC1R 0x001C /* Global Configuration 1 */ +#define LTDC_GC2R 0x0020 /* Global Configuration 2 */ +#define LTDC_SRCR 0x0024 /* Shadow Reload Configuration */ +#define LTDC_GACR 0x0028 /* GAmma Correction */ +#define LTDC_BCCR 0x002C /* Background Color Configuration */ +#define LTDC_IER 0x0034 /* Interrupt Enable */ +#define LTDC_ISR 0x0038 /* Interrupt Status */ +#define LTDC_ICR 0x003C /* Interrupt Clear */ +#define LTDC_LIPCR 0x0040 /* Line Interrupt Position Conf. */ +#define LTDC_CPSR 0x0044 /* Current Position Status */ +#define LTDC_CDSR 0x0048 /* Current Display Status */ /* Layer register offsets */ -#define LTDC_L1LC1R(0x0080) /* L1 Layer Configuration 1 */ -#define LTDC_L1LC2R(0x0084) /* L1 Layer Configuration 2 */ -#define LTDC_L1CR (0x0084 + REG_OFS) /* L1 Control */ -#define LTDC_L1WHPCR (0x0088 + REG_OFS) /* L1 Window Hor Position Config */ -#define LTDC_L1WVPCR (0x008C + REG_OFS) /* L1 Window Vert Position Config */ -#define LTDC_L1CKCR(0x0090 + REG_OFS) /* L1 Color Keying Configuration */ -#define LTDC_L1PFCR(0x0094 + REG_OFS) /* L1 Pixel Format Configuration */ -#define LTDC_L1CACR(0x0098 + REG_OFS) /* L1 Constant Alpha Config */ -#define LTDC_L1DCCR(0x009C + REG_OFS) /* L1 Default Color Configuration */ -#define LTDC_L1BFCR(0x00A0 + REG_OFS) /* L1 Blend Factors Configuration */ -#define LTDC_L1FBBCR (0x00A4 + REG_OFS) /* L1 FrameBuffer Bus Control */ -#define LTDC_L1AFBCR (0x00A8 + REG_OFS) /* L1 AuxFB Control */ -#define LTDC_L1CFBAR (0x00AC + REG_OFS) /* L1 Color FrameBuffer Address */ -#define LTDC_L1CFBLR (0x00B0 + REG_OFS) /* L1 Color FrameBuffer Length */ -#define LTDC_L1CFBLNR (0x00B4 + REG_OFS) /* L1 Color FrameBuffer Line Nb */ -#define LTDC_L1AFBAR (0x00B8 + REG_OFS) /* L1 AuxFB Address */ -#define LTDC_L1AFBLR (0x00BC + REG_OFS) /* L1 AuxFB Length */ -#define LTDC_L1AFBLNR (0x00C0 + REG_OFS) /* L1 AuxFB Line Number */ -#define LTDC_L1CLUTWR (0x00C4 + REG_OFS) /* L1 CLUT Write */ -#define LTDC_L1YS1R(0x00E0 + REG_OFS) /* L1 YCbCr Scale 1 */ -#define LTDC_L1YS2R(0x00E4 + REG_OFS) /* L1 YCbCr Scale 2 */ +#define LTDC_L1LC1R(0x80) /* L1 Layer Configuration 1 */ +#define LTDC_L1LC2R(0x84) /* L1 Layer Configuration 2 */ +#define LTDC_L1CR (0x84 + REG_OFS)/* L1 Control */ +#define LTDC_L1WHPCR
[PATCH v2 6/7] drm/stm: ltdc: Cleanup rename returned value
Rename the returned value from "res" to "ret" as it is more "readable".
Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/ltdc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index d826045..04cc66d 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -760,7 +760,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
drm_crtc *crtc)
struct ltdc_device *ldev = ddev->dev_private;
struct drm_plane *primary, *overlay;
unsigned int i;
- int res;
+ int ret;
primary = ltdc_plane_create(ddev, DRM_PLANE_TYPE_PRIMARY);
if (!primary) {
@@ -768,9 +768,9 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
drm_crtc *crtc)
return -EINVAL;
}
- res = drm_crtc_init_with_planes(ddev, crtc, primary, NULL,
+ ret = drm_crtc_init_with_planes(ddev, crtc, primary, NULL,
caps.nb_layers; i++) {
overlay = ltdc_plane_create(ddev, DRM_PLANE_TYPE_OVERLAY);
if (!overlay) {
- res = -ENOMEM;
+ ret = -ENOMEM;
DRM_ERROR("Can not create overlay plane %d\n", i);
goto cleanup;
}
@@ -793,7 +793,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
drm_crtc *crtc)
cleanup:
ltdc_plane_destroy_all(ddev);
- return res;
+ return ret;
}
/*
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/7] drm/stm: ltdc: add devm_reset_control & platform_get_ressource
Use devm_reset_control_get_exclusive to avoid resource leakage (based
on patch "Convert drivers to explicit reset API" from Philipp Zabel).
Also use platform_get_resource, which is more usual and
consistent with platform_get_irq called later.
Signed-off-by: Fabien Dessenne
Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
Cc: Philipp Zabel
---
drivers/gpu/drm/stm/ltdc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 92e58ba..d826045 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -874,7 +874,7 @@ int ltdc_load(struct drm_device *ddev)
struct drm_panel *panel;
struct drm_crtc *crtc;
struct reset_control *rstc;
- struct resource res;
+ struct resource *res;
int irq, ret, i;
DRM_DEBUG_DRIVER("\n");
@@ -883,7 +883,7 @@ int ltdc_load(struct drm_device *ddev)
if (ret)
return ret;
- rstc = of_reset_control_get(np, NULL);
+ rstc = devm_reset_control_get_exclusive(dev, NULL);
mutex_init(&ldev->err_lock);
@@ -898,13 +898,14 @@ int ltdc_load(struct drm_device *ddev)
return -ENODEV;
}
- if (of_address_to_resource(np, 0, &res)) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
DRM_ERROR("Unable to get resource\n");
ret = -ENODEV;
goto err;
}
- ldev->regs = devm_ioremap_resource(dev, &res);
+ ldev->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(ldev->regs)) {
DRM_ERROR("Unable to get ltdc registers\n");
ret = PTR_ERR(ldev->regs);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/stm: ltdc: Cleanup signal polarity defines
The GCR_PCPOL/DEPOL/VSPOL/HSPOL defines are sufficient to describe the HS, VS, DE & PC signal polarities. Signed-off-by: Philippe CORNU Reviewed-by: Benjamin Gaignard --- drivers/gpu/drm/stm/ltdc.c | 28 ++-- 1 file changed, 10 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index e46b427..50e8a89 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -104,10 +104,10 @@ #define GCR_LTDCEN BIT(0) /* LTDC ENable */ #define GCR_DENBIT(16) /* Dither ENable */ -#define GCR_PCPOL BIT(28) /* Pixel Clock POLarity */ -#define GCR_DEPOL BIT(29) /* Data Enable POLarity */ -#define GCR_VSPOL BIT(30) /* Vertical Synchro POLarity */ -#define GCR_HSPOL BIT(31) /* Horizontal Synchro POLarity */ +#define GCR_PCPOL BIT(28) /* Pixel Clock POLarity-Inverted */ +#define GCR_DEPOL BIT(29) /* Data Enable POLarity-High */ +#define GCR_VSPOL BIT(30) /* Vertical Synchro POLarity-High */ +#define GCR_HSPOL BIT(31) /* Horizontal Synchro POLarity-High */ #define GC1R_WBCH GENMASK(3, 0) /* Width of Blue CHannel output */ #define GC1R_WGCH GENMASK(7, 4) /* Width of Green Channel output */ @@ -174,14 +174,6 @@ #define LXCFBLNR_CFBLN GENMASK(10, 0) /* Color Frame Buffer Line Number */ -#define HSPOL_AL 0 /* Horizontal Sync POLarity Active Low */ -#define VSPOL_AL 0 /* Vertical Sync POLarity Active Low */ -#define DEPOL_AL 0 /* Data Enable POLarity Active Low */ -#define PCPOL_IPC 0 /* Input Pixel Clock */ -#define HSPOL_AH GCR_HSPOL /* Horizontal Sync POLarity Active High */ -#define VSPOL_AH GCR_VSPOL /* Vertical Sync POLarity Active High */ -#define DEPOL_AH GCR_DEPOL /* Data Enable POLarity Active High */ -#define PCPOL_IIPC GCR_PCPOL /* Inverted Input Pixel Clock */ #define CONSTA_MAX 0xFF/* CONSTant Alpha MAX= 1.0 */ #define BF1_PAXCA 0x600 /* Pixel Alpha x Constant Alpha */ #define BF1_CA 0x400 /* Constant Alpha */ @@ -459,20 +451,20 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc) clk_enable(ldev->pixel_clk); - /* Configures the HS, VS, DE and PC polarities. */ - val = HSPOL_AL | VSPOL_AL | DEPOL_AL | PCPOL_IPC; + /* Configures the HS, VS, DE and PC polarities. Default Active Low */ + val = 0; if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH) - val |= HSPOL_AH; + val |= GCR_HSPOL; if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH) - val |= VSPOL_AH; + val |= GCR_VSPOL; if (vm.flags & DISPLAY_FLAGS_DE_HIGH) - val |= DEPOL_AH; + val |= GCR_DEPOL; if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) - val |= PCPOL_IIPC; + val |= GCR_PCPOL; reg_update_bits(ldev->regs, LTDC_GCR, GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val); -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/stm: drv: Rename platform driver name
Rename the platform driver name from "stm" to "stm32-display"
for a better readability in /sys/bus/platform/drivers entries.
Note: We keep "stm" as drm_driver.name because it is better
when using "modetest -M stm ..." (even if recent modetest patch
avoids using -M).
Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
---
drivers/gpu/drm/stm/drv.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 83ab48f..095971f 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -20,13 +20,6 @@
#include "ltdc.h"
-#define DRIVER_NAME"stm"
-#define DRIVER_DESC"STMicroelectronics SoC DRM"
-#define DRIVER_DATE"20170330"
-#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 0
-#define DRIVER_PATCH_LEVEL 0
-
#define STM_MAX_FB_WIDTH 2048
#define STM_MAX_FB_HEIGHT 2048 /* same as width to handle orientation */
@@ -59,12 +52,12 @@ static void drv_lastclose(struct drm_device *ddev)
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
.lastclose = drv_lastclose,
- .name = DRIVER_NAME,
- .desc = DRIVER_DESC,
- .date = DRIVER_DATE,
- .major = DRIVER_MAJOR,
- .minor = DRIVER_MINOR,
- .patchlevel = DRIVER_PATCH_LEVEL,
+ .name = "stm",
+ .desc = "STMicroelectronics SoC DRM",
+ .date = "20170330",
+ .major = 1,
+ .minor = 0,
+ .patchlevel = 0,
.fops = &drv_driver_fops,
.dumb_create = drm_gem_cma_dumb_create,
.dumb_map_offset = drm_gem_cma_dumb_map_offset,
@@ -206,7 +199,7 @@ static int stm_drm_platform_remove(struct platform_device
*pdev)
.probe = stm_drm_platform_probe,
.remove = stm_drm_platform_remove,
.driver = {
- .name = DRIVER_NAME,
+ .name = "stm32-display",
.of_match_table = drv_dt_ids,
},
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] drm/stm: Various cleanups
Version 2: - Add devm_reset_control_get_exclusive to follow explicit reset API - Add missing commit messages & reviewed-by. Version 1: - Initial commit The purpose of this set of patches is to clean up the drm stm driver. Philippe CORNU (7): drm/stm: drv: Rename platform driver name drm/stm: ltdc: Cleanup signal polarity defines drm/stm: ltdc: Lindent and minor cleanups drm/stm: ltdc: Constify funcs structures drm/stm: ltdc: add devm_reset_control & platform_get_ressource drm/stm: ltdc: Cleanup rename returned value drm/stm: dsi: Constify phy ops structure drivers/gpu/drm/stm/drv.c | 21 ++-- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +- drivers/gpu/drm/stm/ltdc.c| 225 -- 3 files changed, 116 insertions(+), 132 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/14] drm/mgag200: Consolidate depth/bpp handling
Dear Takashi,
Thank you for posting these patches for review.
Am Dienstag, den 18.07.2017, 16:43 +0200 schrieb Takashi Iwai:
> From: Egbert Eich
>
> The depth/bpp handling for chips with limited memory in commit
> 918be888d613 ("drm/mgag200: on cards with < 2MB VRAM default to
> 16-bit") was incomplete: the bpp limits were applied to mode
> validation.
>
> This consolidates dpeth/bpp handling, adds it to mode validation
depth
> and moves the code which reads the command line specified depth
> into the correct location.
>
> Fixes: 918be888d613 ("drm/mgag200: on cards with < 2MB VRAM default to
> 16-bit")
```
$ git tag --contains 918be888d613 | head -1
v3.14
```
Please mark this as stable then too?
Also, could the original commit author time-stamps be preserved if you
have them in your SUSE repositories? The `Date` line could be added
below the `From` line. That would help to know for how long the changes
have been tested.
> Signed-off-by: Egbert Eich
> Signed-off-by: Takashi Iwai
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.h | 2 ++
> drivers/gpu/drm/mgag200/mgag200_fb.c | 7 +--
> drivers/gpu/drm/mgag200/mgag200_main.c | 9 ++---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 14 +++---
> 4 files changed, 16 insertions(+), 16 deletions(-)
[…]
Otherwise this looks fine.
Thanks,
Paul
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] xf86drm: continue after drmProcessPlatformDevice failure
On 19 July 2017 at 16:37, Gurchetan Singh wrote: > On ChromeOS devices, readdir() processes the directory in > the following order: > > -NAME- -TYPE- > .n/a > .. n/a > vgem n/a > card1 DRM_BUS_PLATFORM > renderD129 DRM_BUS_PLATFORM > card0 DRM_BUS_PCI > renderD128DRM_BUS_PCI > controlD64DRM_BUS_PCI > > In drmGetDevices2, after drmProcessPlatformDevice fails for > /dev/dri/card1, we don't process the remaining directory entries. > As such, Vulkan fails to initialize since Mesa uses drmGetDevices2. > To fix this, continue if drmProcessPlatformDevice fails. Added a fixes tag and addressed the host1x + usb instances. Thank you! Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101837] libdrm fails to get bus id
https://bugs.freedesktop.org/show_bug.cgi?id=101837 --- Comment #3 from Emil Velikov --- DanielP an orthogonal solution is to simply not use drmOpen. While it works, sometimes, there's a lot of hidden gotchas. Simply replace the pciaccess + drmOpen with drmDevice2 - see libdrm/tests/drmdevice.c. Notes: * radeon-top does _not_ need to open the card node, hence no need for auth - directly or via xcb * using pciaccess, or drmDevice2 with DRM_DEVICE_GET_PCI_REVISION will wake up your discrete GPU, even if you're looking for the stats of you APU - you want to avoid that if possible. * do not forget to close the fd - currently it's leaked. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i2c: tda998x: Fix lockdep warning about possible circular dependency
When enabling lockdep debugging on Juno platform with HDLCD and TDA998x
I get the following warning from the system:
[ 25.990733] ==
[ 25.998637] WARNING: possible circular locking dependency detected
[ 26.006531] 4.13.0-rc1-00284-g28c0a682ecbf-dirty #17 Not tainted
[ 26.014246] --
[ 26.022142] kworker/1:2/140 is trying to acquire lock:
[ 26.029001] (&priv->audio_mutex){+.+.+.}, at: []
tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.041100]
[ 26.041100] but task is already holding lock:
[ 26.050436] (crtc_ww_class_mutex){+.+.+.}, at: []
drm_modeset_lock+0x64/0xf8 [drm]
[ 26.061531]
[ 26.061531] which lock already depends on the new lock.
[ 26.061531]
[ 26.075063]
[ 26.075063] the existing dependency chain (in reverse order) is:
[ 26.086031]
[ 26.086031] -> #2 (crtc_ww_class_mutex){+.+.+.}:
[ 26.095657]__lock_acquire+0x18a0/0x19b8
[ 26.101918]lock_acquire+0xd0/0x2b0
[ 26.107731]__ww_mutex_lock.constprop.3+0x90/0xe78
[ 26.114817]ww_mutex_lock+0x54/0xe0
[ 26.120672]drm_modeset_lock+0x64/0xf8 [drm]
[ 26.127253]drm_helper_probe_single_connector_modes+0x7c/0x6b8
[drm_kms_helper]
[ 26.136829]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.144797]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.152429]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.161097]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.169857]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.177559]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.184310]try_to_bring_up_master+0x180/0x1e0
[ 26.191043]component_master_add_with_match+0xb0/0x108
[ 26.198458]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.204735]platform_drv_probe+0x60/0xc0
[ 26.210913]driver_probe_device+0x23c/0x2e8
[ 26.217350]__driver_attach+0xd4/0xd8
[ 26.223256]bus_for_each_dev+0x5c/0xa8
[ 26.229232]driver_attach+0x30/0x40
[ 26.234917]bus_add_driver+0x1d8/0x248
[ 26.240831]driver_register+0x6c/0x118
[ 26.246715]__platform_driver_register+0x54/0x60
[ 26.253461]0x00e1b018
[ 26.258644]do_one_initcall+0x44/0x138
[ 26.264503]do_init_module+0x64/0x1d4
[ 26.270238]load_module+0x1f90/0x2590
[ 26.275957]SyS_finit_module+0xb0/0xc8
[ 26.281765]__sys_trace_return+0x0/0x4
[ 26.281767]
[ 26.281767] -> #1 (crtc_ww_class_acquire){+.+.+.}:
[ 26.281778]__lock_acquire+0x18a0/0x19b8
[ 26.281782]lock_acquire+0xd0/0x2b0
[ 26.281877]drm_modeset_acquire_init+0xa8/0xe0 [drm]
[ 26.281921]drm_helper_probe_single_connector_modes+0x48/0x6b8
[drm_kms_helper]
[ 26.281929]tda998x_connector_fill_modes+0x44/0xa8 [tda998x]
[ 26.281970]drm_setup_crtcs+0x19c/0xba0 [drm_kms_helper]
[ 26.282009]drm_fb_helper_initial_config+0x70/0x440 [drm_kms_helper]
[ 26.282049]drm_fbdev_cma_init_with_funcs+0x94/0x168 [drm_kms_helper]
[ 26.282088]drm_fbdev_cma_init+0x38/0x50 [drm_kms_helper]
[ 26.282095]hdlcd_drm_bind+0x1f8/0x4a8 [hdlcd]
[ 26.282099]try_to_bring_up_master+0x180/0x1e0
[ 26.282104]component_master_add_with_match+0xb0/0x108
[ 26.282110]hdlcd_probe+0x58/0x80 [hdlcd]
[ 26.282114]platform_drv_probe+0x60/0xc0
[ 26.282117]driver_probe_device+0x23c/0x2e8
[ 26.282121]__driver_attach+0xd4/0xd8
[ 26.282124]bus_for_each_dev+0x5c/0xa8
[ 26.282127]driver_attach+0x30/0x40
[ 26.282130]bus_add_driver+0x1d8/0x248
[ 26.282134]driver_register+0x6c/0x118
[ 26.282138]__platform_driver_register+0x54/0x60
[ 26.282141]0x00e1b018
[ 26.282145]do_one_initcall+0x44/0x138
[ 26.282149]do_init_module+0x64/0x1d4
[ 26.282152]load_module+0x1f90/0x2590
[ 26.282156]SyS_finit_module+0xb0/0xc8
[ 26.282159]__sys_trace_return+0x0/0x4
[ 26.282161]
[ 26.282161] -> #0 (&priv->audio_mutex){+.+.+.}:
[ 26.282172]print_circular_bug+0x80/0x2e0
[ 26.282176]__lock_acquire+0x15a8/0x19b8
[ 26.282180]lock_acquire+0xd0/0x2b0
[ 26.282184]__mutex_lock+0x78/0x8e0
[ 26.282188]mutex_lock_nested+0x3c/0x50
[ 26.282196]tda998x_encoder_mode_set+0x12c/0x5a0 [tda998x]
[ 26.282237]drm_atomic_helper_commit_modeset_disables+0x328/0x3a0
[drm_kms_helper]
[ 26.282251]malidp_atomic_commit_tail+0x44/0x6b0 [mali_dp]
[ 26.282292]commit_tail+0x4c/0x80 [drm_kms_helper]
[ 26.282333]drm_atomic_helper_commit+0xe8/0x180 [drm_kms_helper]
[ 26.282427]drm_atomic_commit+0x54/0x70 [drm]
[ 26.282467]restore_fbdev_mode_atomic+0x1f0/0x220 [drm_kms_helper]
[
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
Quoting Tvrtko Ursulin (2017-07-20 11:09:53)
>
> On 19/07/2017 23:35, Christophe JAILLET wrote:
> > Goto the right label in case of error, otherwise there is a leak.
> > This has been introduced by c5cf9a9147ff. In this patch a goto has not been
> > updated.
> >
> > Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct
> > i915_priolist from")
> > Signed-off-by: Christophe JAILLET
> > ---
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > index 627e2aa09766..8cdec455cf7d 100644
> > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > @@ -206,7 +206,7 @@ struct drm_i915_private *mock_gem_device(void)
> > mkwrite_device_info(i915)->ring_mask = BIT(0);
> > i915->engine[RCS] = mock_engine(i915, "mock");
> > if (!i915->engine[RCS])
> > - goto err_dependencies;
> > + goto err_priorities;
> >
> > i915->kernel_context = mock_context(i915, NULL);
> > if (!i915->kernel_context)
>
> Reviewed-by: Tvrtko Ursulin
Thanks for the fix and review, pushed.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending
On Thu, Jul 20, 2017 at 11:53:39AM +0200, Maxime Ripard wrote: > Hi Daniel, > > On Tue, Jul 18, 2017 at 09:35:03AM +0200, Daniel Vetter wrote: > > On Tue, Jul 18, 2017 at 9:07 AM, Maxime Ripard > > wrote: > > > On Mon, Jul 17, 2017 at 02:57:19PM +0800, Chen-Yu Tsai wrote: > > >> On Mon, Jul 17, 2017 at 2:55 PM, Maxime Ripard > > >> wrote: > > >> > On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote: > > >> >> Hi, > > >> >> > > >> >> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard > > >> >> wrote: > > >> >> > In the earlier display engine designs, any register access while a > > >> >> > commit > > >> >> > is pending is forbidden. > > >> >> > > > >> >> > One of the symptoms is that reading a register will return another, > > >> >> > random, > > >> >> > register value which can lead to register corruptions if we ever do > > >> >> > a > > >> >> > read/modify/write cycle. > > >> >> > > >> >> Alternatively, if changes to the backend (layers) are guaranteed to > > >> >> happen > > >> >> while the CRTC is disabled (which seems to be the case after looking > > >> >> at > > >> >> drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we > > >> >> could just turn on register auto-commit all the time and not deal with > > >> >> this. > > >> > > > >> > As far as I understand, it will only be the case if we need a new > > >> > modeset or we changed the active CRTC or connectors. But if you change > > >> > only the format, buffers or properties it won't be the case, and we'll > > >> > need to commit. > > >> > > >> So in other words, if someone were to use it for actual compositing and > > >> moved the upper composited layer around, we would need commit support to > > >> be > > >> safe. > > >> > > >> Sounds more or less like something a video player would do. > > > > > > Not only that. A change of buffer will happen every frame or so, and > > > we can change the format whenever we want too (even if it's usually > > > going to be in sync with a new buffer). Changing a property can happen > > > any time too (like zpos for example). > > > > You can upgrade any property change to an atomic modeset by e.g. > > setting connector->mode_changed (and then making sure to call > > check_modeset() helper again perhaps). This is for cases where your hw > > can't handle a property change within 1 vblank. The default is just > > the solution for most common hw. > > > > The other way round works too, you can clear these flags in your > > atomic_check callbacks. But that requires a bit more care (to make > > sure you never clear it when there's something else also changing that > > still needs a full modeset sequence to commit to hw). > > Hmm, that's good to know, but that would imply disabling the CRTC each > time we change even a small property, with all the visual artifacts it > might imply, right? This isn't black&white, you only need to set this when needed. Of course that means you need to have code (and hopefully testcases) to make sure you only set it when needed. And userspace can ask the driver whether a given change requires a full modeset or not and then decided whether it wants to do that switch or not. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
On 19/07/2017 23:35, Christophe JAILLET wrote:
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147ff. In this patch a goto has not been
updated.
Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist
from")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 627e2aa09766..8cdec455cf7d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -206,7 +206,7 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->ring_mask = BIT(0);
i915->engine[RCS] = mock_engine(i915, "mock");
if (!i915->engine[RCS])
- goto err_dependencies;
+ goto err_priorities;
i915->kernel_context = mock_context(i915, NULL);
if (!i915->kernel_context)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 022/102] drm/sti: explicitly request exclusive reset control
2017-07-19 17:25 GMT+02:00 Philipp Zabel :
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
>
> No functional changes.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Philipp Zabel
Acked-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/sti/sti_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
> drivers/gpu/drm/sti/sti_tvout.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index a59c95a8081b7..ea6e5b5a3725b 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -1428,7 +1428,7 @@ static int sti_hdmi_probe(struct platform_device *pdev)
> if (!hdmi->notifier)
> goto release_adapter;
>
> - hdmi->reset = devm_reset_control_get(dev, "hdmi");
> + hdmi->reset = devm_reset_control_get_exclusive(dev, "hdmi");
> /* Take hdmi out of reset */
> if (!IS_ERR(hdmi->reset))
> reset_control_deassert(hdmi->reset);
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index a1c161f778044..2809db8c03216 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -1375,7 +1375,7 @@ static int sti_hqvdp_probe(struct platform_device *pdev)
> }
>
> /* Get reset resources */
> - hqvdp->reset = devm_reset_control_get(dev, "hqvdp");
> + hqvdp->reset = devm_reset_control_get_exclusive(dev, "hqvdp");
> if (!IS_ERR(hqvdp->reset))
> reset_control_deassert(hqvdp->reset);
>
> diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
> index 8959fcc743a8e..cbe0f5c162348 100644
> --- a/drivers/gpu/drm/sti/sti_tvout.c
> +++ b/drivers/gpu/drm/sti/sti_tvout.c
> @@ -857,7 +857,7 @@ static int sti_tvout_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* get reset resources */
> - tvout->reset = devm_reset_control_get(dev, "tvout");
> + tvout->reset = devm_reset_control_get_exclusive(dev, "tvout");
> /* take tvout out of reset */
> if (!IS_ERR(tvout->reset))
> reset_control_deassert(tvout->reset);
> --
> 2.11.0
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending
Hi Daniel, On Tue, Jul 18, 2017 at 09:35:03AM +0200, Daniel Vetter wrote: > On Tue, Jul 18, 2017 at 9:07 AM, Maxime Ripard > wrote: > > On Mon, Jul 17, 2017 at 02:57:19PM +0800, Chen-Yu Tsai wrote: > >> On Mon, Jul 17, 2017 at 2:55 PM, Maxime Ripard > >> wrote: > >> > On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote: > >> >> Hi, > >> >> > >> >> On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard > >> >> wrote: > >> >> > In the earlier display engine designs, any register access while a > >> >> > commit > >> >> > is pending is forbidden. > >> >> > > >> >> > One of the symptoms is that reading a register will return another, > >> >> > random, > >> >> > register value which can lead to register corruptions if we ever do a > >> >> > read/modify/write cycle. > >> >> > >> >> Alternatively, if changes to the backend (layers) are guaranteed to > >> >> happen > >> >> while the CRTC is disabled (which seems to be the case after looking at > >> >> drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we > >> >> could just turn on register auto-commit all the time and not deal with > >> >> this. > >> > > >> > As far as I understand, it will only be the case if we need a new > >> > modeset or we changed the active CRTC or connectors. But if you change > >> > only the format, buffers or properties it won't be the case, and we'll > >> > need to commit. > >> > >> So in other words, if someone were to use it for actual compositing and > >> moved the upper composited layer around, we would need commit support to be > >> safe. > >> > >> Sounds more or less like something a video player would do. > > > > Not only that. A change of buffer will happen every frame or so, and > > we can change the format whenever we want too (even if it's usually > > going to be in sync with a new buffer). Changing a property can happen > > any time too (like zpos for example). > > You can upgrade any property change to an atomic modeset by e.g. > setting connector->mode_changed (and then making sure to call > check_modeset() helper again perhaps). This is for cases where your hw > can't handle a property change within 1 vblank. The default is just > the solution for most common hw. > > The other way round works too, you can clear these flags in your > atomic_check callbacks. But that requires a bit more care (to make > sure you never clear it when there's something else also changing that > still needs a full modeset sequence to commit to hw). Hmm, that's good to know, but that would imply disabling the CRTC each time we change even a small property, with all the visual artifacts it might imply, right? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm/bridge/synopsys: dsi: Register list clean up
Hi Philippe, On Wednesday 19 Jul 2017 09:11:44 Philippe CORNU wrote: > On 07/18/2017 03:39 PM, Laurent Pinchart wrote: > > On Tuesday 18 Jul 2017 13:43:52 Philippe CORNU wrote: > > > >> This patch cleans up the Synopsys mipi dsi register list: > >> - remove unused registers > > > > Is the documentation for the DSI transmitter core public ? If not, it > > could be useful to keep unused registers for reference. That's nine > > lines only. > > Hi Laurent, > And many thanks for the code review. > > Unfortunately the Synopsys Documentation seems not public (I may google > more), so I will put back these registers :) > > Nevertheless, the stm32 documentation is public and it is probably the > same for rockchip (and hisilicon and...), and in these public > documentations, register and bitfield names are slightly different but > register addresses and bitfield descriptions are the same... That's good to know, thanks. > I do not know if it makes sense or not but we may ask Synopsys to > publicly release the mipi dsi documentation... I'd love that. There's little chance it will happen, but it certainly won't if we don't ask. > Did you manage to get it "publicly" for the Synopsys hdmi? Unfortunately not :-( I don't even have access to Synopsys documentation under NDA. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/14] drm/mgag200: Add support for MATROX PCI device IDs 0x520 and 0x521
On Thu, 20 Jul 2017 06:17:58 +0200, Dave Airlie wrote: > > On 19 July 2017 at 00:43, Takashi Iwai wrote: > > From: Egbert Eich > > > > Add two more models G200_PCI and G200 for PCI device IDs 0x520 and > > 0x521, respectively. They need to retrieve the reference clock and > > pclk min/max values from BIOS, and set up the PLLs accordingly. > > Is there any advantage in supporting these GPUs? Heh, you are suggesting that KMS support has no merit? ;) > The main idea of the mgag200 driver is for unaccelerated support for > server GPUs. > > These look like ancient desktop GPUs, I can't imagine we see them > shipping in any modern server hw, and also I'm guessing they had basic > 3D accel features that the old UMS mga driver would "support". Right, but I thought we want to move on to support KMS. If there is another big picture to glean such leftover devices, I'd love to follow that. But this patch itself is simple enough and it can't regress the other existing mgag200 devices, so it's still worth to consider, IMO. thanks, Takashi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 3/3] drm/vc4: add HDMI CEC support
Hi Eric,
On 16/07/17 12:48, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch adds support to VC4 for CEC.
>
> Thanks to Eric Anholt for providing me with the CEC register information.
>
> To prevent the firmware from eating the CEC interrupts you need to add this to
> your config.txt:
>
> mask_gpu_interrupt1=0x100
I put this text in the commit log, but I think it should also go into the
source.
Do you agree?
Should I also mention this in the kernel log via a 'dev_info'? It's not an
obvious
config option, after all.
Or do you have other ideas regarding this?
Regards,
Hans
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/Kconfig| 8 ++
> drivers/gpu/drm/vc4/vc4_hdmi.c | 227
> +++--
> drivers/gpu/drm/vc4/vc4_regs.h | 113
> 3 files changed, 342 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> index 4361bdcfd28a..fdae18aeab4f 100644
> --- a/drivers/gpu/drm/vc4/Kconfig
> +++ b/drivers/gpu/drm/vc4/Kconfig
> @@ -19,3 +19,11 @@ config DRM_VC4
> This driver requires that "avoid_warnings=2" be present in
> the config.txt for the firmware, to keep it from smashing
> our display setup.
> +
> +config DRM_VC4_HDMI_CEC
> + bool "Broadcom VC4 HDMI CEC Support"
> + depends on DRM_VC4
> + select CEC_CORE
> + help
> + Choose this option if you have a Broadcom VC4 GPU
> + and want to use CEC.
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index e0104f96011e..761b95f5deed 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -57,9 +57,14 @@
> #include
> #include
> #include
> +#include "media/cec.h"
> #include "vc4_drv.h"
> #include "vc4_regs.h"
>
> +#define HSM_CLOCK_FREQ 163682864
> +#define CEC_CLOCK_FREQ 4
> +#define CEC_CLOCK_DIV (HSM_CLOCK_FREQ / CEC_CLOCK_FREQ)
> +
> /* HDMI audio information */
> struct vc4_hdmi_audio {
> struct snd_soc_card card;
> @@ -85,6 +90,11 @@ struct vc4_hdmi {
> int hpd_gpio;
> bool hpd_active_low;
>
> + struct cec_adapter *cec_adap;
> + struct cec_msg cec_rx_msg;
> + bool cec_tx_ok;
> + bool cec_irq_was_rx;
> +
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> };
> @@ -149,6 +159,23 @@ static const struct {
> HDMI_REG(VC4_HDMI_VERTB1),
> HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
> HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
> +
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_1),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_2),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_3),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_4),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_5),
> + HDMI_REG(VC4_HDMI_CPU_STATUS),
> + HDMI_REG(VC4_HDMI_CPU_MASK_STATUS),
> +
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_1),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_2),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_3),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_4),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_1),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_2),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_3),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_4),
> };
>
> static const struct {
> @@ -216,8 +243,8 @@ vc4_hdmi_connector_detect(struct drm_connector
> *connector, bool force)
> if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio) ^
> vc4->hdmi->hpd_active_low)
> return connector_status_connected;
> - else
> - return connector_status_disconnected;
> + cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
> + return connector_status_disconnected;
> }
>
> if (drm_probe_ddc(vc4->hdmi->ddc))
> @@ -225,8 +252,8 @@ vc4_hdmi_connector_detect(struct drm_connector
> *connector, bool force)
>
> if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> return connector_status_connected;
> - else
> - return connector_status_disconnected;
> + cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
> + return connector_status_disconnected;
> }
>
> static void vc4_hdmi_connector_destroy(struct drm_connector *connector)
> @@ -247,6 +274,7 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
> struct edid *edid;
>
> edid = drm_get_edid(connector, vc4->hdmi->ddc);
> + cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
> if (!edid)
> return -ENODEV;
>
> @@ -1121,6 +1149,159 @@ static void vc4_hdmi_audio_cleanup(struct vc4_hdmi
> *hdmi)
> snd_soc_unregister_codec(dev);
> }
>
> +#ifdef CONFIG_DRM_VC4_HDMI_CEC
> +static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
> +{
> + struct vc4_dev *vc4 = priv;
> + struct vc4_hdmi *hdmi = vc4->hdmi;
> +
> + if (hdmi->cec_irq_was_rx) {
> + if (hdmi->cec_rx_msg.len)
> + cec_received_msg(hdmi->cec
[PATCH] drm/ast: Remove superfluous drm_connector_unregister() call
At destroying the connector, we need no longer to call
drm_connector_unregister() explicitly, as drm_dev_unregister()
unregisters all connectors too. Keeping it may cause a confusion by a
brainless copy-and-paste to other drivers, so let's rip it off now.
Suggested-by: Daniel Vetter
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/ast/ast_mode.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index aaef0a652f10..d7bfe45b5884 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -857,7 +857,6 @@ static void ast_connector_destroy(struct drm_connector
*connector)
{
struct ast_connector *ast_connector = to_ast_connector(connector);
ast_i2c_destroy(ast_connector->i2c);
- drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
}
--
2.14.0.rc0.11.gf79966288497.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 7/7] drm/stm: dsi: Constify phy ops structure
2017-07-18 12:20 GMT+02:00 Philippe CORNU :
Please write a commit message
> Signed-off-by: Philippe CORNU
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index 16ae00e..568c5d0 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -261,7 +261,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> return 0;
> }
>
> -static struct dw_mipi_dsi_phy_ops dw_mipi_dsi_stm_phy_ops = {
> +static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_stm_phy_ops = {
> .init = dw_mipi_dsi_phy_init,
> .get_lane_mbps = dw_mipi_dsi_get_lane_mbps,
> };
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/7] drm/stm: ltdc: Cleanup rename returned value
2017-07-18 12:20 GMT+02:00 Philippe CORNU :
Commit message is missing here
> Signed-off-by: Philippe CORNU
> ---
> drivers/gpu/drm/stm/ltdc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index f4ed21a..8cd1b9b 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -760,7 +760,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
> drm_crtc *crtc)
> struct ltdc_device *ldev = ddev->dev_private;
> struct drm_plane *primary, *overlay;
> unsigned int i;
> - int res;
> + int ret;
>
> primary = ltdc_plane_create(ddev, DRM_PLANE_TYPE_PRIMARY);
> if (!primary) {
> @@ -768,9 +768,9 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
> drm_crtc *crtc)
> return -EINVAL;
> }
>
> - res = drm_crtc_init_with_planes(ddev, crtc, primary, NULL,
> + ret = drm_crtc_init_with_planes(ddev, crtc, primary, NULL,
> - if (res) {
> + if (ret) {
> DRM_ERROR("Can not initialize CRTC\n");
> goto cleanup;
> }
> @@ -783,7 +783,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
> drm_crtc *crtc)
> for (i = 1; i < ldev->caps.nb_layers; i++) {
> overlay = ltdc_plane_create(ddev, DRM_PLANE_TYPE_OVERLAY);
> if (!overlay) {
> - res = -ENOMEM;
> + ret = -ENOMEM;
> DRM_ERROR("Can not create overlay plane %d\n", i);
> goto cleanup;
> }
> @@ -793,7 +793,7 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct
> drm_crtc *crtc)
>
> cleanup:
> ltdc_plane_destroy_all(ddev);
> - return res;
> + return ret;
> }
>
> /*
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/7] drm/stm: ltdc: add devm_reset_control & platform_get_ressource
2017-07-18 12:20 GMT+02:00 Philippe CORNU :
> Use devm_reset_control_get to avoid resource leakage.
> Also use platform_get_resource, which is more usual and
> consistent with platform_get_irq called later.
>
> Signed-off-by: Fabien Dessenne
> Signed-off-by: Philippe CORNU
Note that could be conflicting with Philippe Zabel work on reset
Reviewed-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/stm/ltdc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 92e58ba..f4ed21a 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -874,7 +874,7 @@ int ltdc_load(struct drm_device *ddev)
> struct drm_panel *panel;
> struct drm_crtc *crtc;
> struct reset_control *rstc;
> - struct resource res;
> + struct resource *res;
> int irq, ret, i;
>
> DRM_DEBUG_DRIVER("\n");
> @@ -883,7 +883,7 @@ int ltdc_load(struct drm_device *ddev)
> if (ret)
> return ret;
>
> - rstc = of_reset_control_get(np, NULL);
> + rstc = devm_reset_control_get(dev, NULL);
>
> mutex_init(&ldev->err_lock);
>
> @@ -898,13 +898,14 @@ int ltdc_load(struct drm_device *ddev)
> return -ENODEV;
> }
>
> - if (of_address_to_resource(np, 0, &res)) {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> DRM_ERROR("Unable to get resource\n");
> ret = -ENODEV;
> goto err;
> }
>
> - ldev->regs = devm_ioremap_resource(dev, &res);
> + ldev->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(ldev->regs)) {
> DRM_ERROR("Unable to get ltdc registers\n");
> ret = PTR_ERR(ldev->regs);
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/7] drm/stm: ltdc: Cleanup signal polarity defines
2017-07-18 12:20 GMT+02:00 Philippe CORNU : > The GCR_PCPOL/DEPOL/VSPOL/HSPOL defines are sufficient to > describe the HS, VS, DE & PC signal polarities. > > Signed-off-by: Philippe CORNU Reviewed-by: Benjamin Gaignard > --- > drivers/gpu/drm/stm/ltdc.c | 28 ++-- > 1 file changed, 10 insertions(+), 18 deletions(-) > > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c > index e46b427..50e8a89 100644 > --- a/drivers/gpu/drm/stm/ltdc.c > +++ b/drivers/gpu/drm/stm/ltdc.c > @@ -104,10 +104,10 @@ > > #define GCR_LTDCEN BIT(0) /* LTDC ENable */ > #define GCR_DENBIT(16) /* Dither ENable */ > -#define GCR_PCPOL BIT(28) /* Pixel Clock POLarity */ > -#define GCR_DEPOL BIT(29) /* Data Enable POLarity */ > -#define GCR_VSPOL BIT(30) /* Vertical Synchro POLarity */ > -#define GCR_HSPOL BIT(31) /* Horizontal Synchro POLarity */ > +#define GCR_PCPOL BIT(28) /* Pixel Clock POLarity-Inverted */ > +#define GCR_DEPOL BIT(29) /* Data Enable POLarity-High */ > +#define GCR_VSPOL BIT(30) /* Vertical Synchro POLarity-High */ > +#define GCR_HSPOL BIT(31) /* Horizontal Synchro POLarity-High */ > > #define GC1R_WBCH GENMASK(3, 0) /* Width of Blue CHannel output */ > #define GC1R_WGCH GENMASK(7, 4) /* Width of Green Channel output */ > @@ -174,14 +174,6 @@ > > #define LXCFBLNR_CFBLN GENMASK(10, 0) /* Color Frame Buffer Line Number */ > > -#define HSPOL_AL 0 /* Horizontal Sync POLarity Active Low */ > -#define VSPOL_AL 0 /* Vertical Sync POLarity Active Low */ > -#define DEPOL_AL 0 /* Data Enable POLarity Active Low */ > -#define PCPOL_IPC 0 /* Input Pixel Clock */ > -#define HSPOL_AH GCR_HSPOL /* Horizontal Sync POLarity Active High */ > -#define VSPOL_AH GCR_VSPOL /* Vertical Sync POLarity Active High */ > -#define DEPOL_AH GCR_DEPOL /* Data Enable POLarity Active High */ > -#define PCPOL_IIPC GCR_PCPOL /* Inverted Input Pixel Clock */ > #define CONSTA_MAX 0xFF/* CONSTant Alpha MAX= 1.0 */ > #define BF1_PAXCA 0x600 /* Pixel Alpha x Constant Alpha */ > #define BF1_CA 0x400 /* Constant Alpha */ > @@ -459,20 +451,20 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc > *crtc) > > clk_enable(ldev->pixel_clk); > > - /* Configures the HS, VS, DE and PC polarities. */ > - val = HSPOL_AL | VSPOL_AL | DEPOL_AL | PCPOL_IPC; > + /* Configures the HS, VS, DE and PC polarities. Default Active Low */ > + val = 0; > > if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH) > - val |= HSPOL_AH; > + val |= GCR_HSPOL; > > if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH) > - val |= VSPOL_AH; > + val |= GCR_VSPOL; > > if (vm.flags & DISPLAY_FLAGS_DE_HIGH) > - val |= DEPOL_AH; > + val |= GCR_DEPOL; > > if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) > - val |= PCPOL_IIPC; > + val |= GCR_PCPOL; > > reg_update_bits(ldev->regs, LTDC_GCR, > GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val); > -- > 1.9.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/7] drm/stm: ltdc: Constify funcs structures
2017-07-18 12:20 GMT+02:00 Philippe CORNU :
> Constify drm funcs structures.
>
> Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/stm/ltdc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 628825b..92e58ba 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -511,7 +511,7 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
> }
> }
>
> -static struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> +static const struct drm_crtc_helper_funcs ltdc_crtc_helper_funcs = {
> .load_lut = ltdc_crtc_load_lut,
> .mode_set_nofb = ltdc_crtc_mode_set_nofb,
> .atomic_flush = ltdc_crtc_atomic_flush,
> @@ -537,7 +537,7 @@ void ltdc_crtc_disable_vblank(struct drm_device *ddev,
> unsigned int pipe)
> reg_clear(ldev->regs, LTDC_IER, IER_LIE);
> }
>
> -static struct drm_crtc_funcs ltdc_crtc_funcs = {
> +static const struct drm_crtc_funcs ltdc_crtc_funcs = {
> .destroy = drm_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
> @@ -693,7 +693,7 @@ static void ltdc_plane_atomic_disable(struct drm_plane
> *plane,
> oldstate->crtc->base.id, plane->base.id);
> }
>
> -static struct drm_plane_funcs ltdc_plane_funcs = {
> +static const struct drm_plane_funcs ltdc_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy = drm_plane_cleanup,
> --
> 1.9.1
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 3/7] drm/stm: ltdc: Lindent and minor cleanups
2017-07-18 12:20 GMT+02:00 Philippe CORNU : > Lindent then checkpatch --strict cleanups > > Signed-off-by: Philippe CORNU > --- > drivers/gpu/drm/stm/ltdc.c | 172 > ++--- > 1 file changed, 85 insertions(+), 87 deletions(-) > > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c > index 50e8a89..628825b 100644 > --- a/drivers/gpu/drm/stm/ltdc.c > +++ b/drivers/gpu/drm/stm/ltdc.c > @@ -42,52 +42,52 @@ > * an extra offset specified with reg_ofs. > */ > #define REG_OFS_NONE 0 > -#define REG_OFS_4 4 /* Insertion of "Layer Configuration 2" reg */ > +#define REG_OFS_4 4 /* Insertion of "Layer Conf. 2" reg */ > #define REG_OFS(ldev->caps.reg_ofs) > -#define LAY_OFS0x80/* Register Offset between 2 layers */ > +#define LAY_OFS0x80/* Register Offset between 2 > layers */ > > /* Global register offsets */ > -#define LTDC_IDR 0x /* IDentification */ > -#define LTDC_LCR 0x0004 /* Layer Count */ > -#define LTDC_SSCR 0x0008 /* Synchronization Size Configuration */ > -#define LTDC_BPCR 0x000C /* Back Porch Configuration */ > -#define LTDC_AWCR 0x0010 /* Active Width Configuration */ > -#define LTDC_TWCR 0x0014 /* Total Width Configuration */ > -#define LTDC_GCR 0x0018 /* Global Control */ > -#define LTDC_GC1R 0x001C /* Global Configuration 1 */ > -#define LTDC_GC2R 0x0020 /* Global Configuration 2 */ > -#define LTDC_SRCR 0x0024 /* Shadow Reload Configuration */ > -#define LTDC_GACR 0x0028 /* GAmma Correction */ > -#define LTDC_BCCR 0x002C /* Background Color Configuration */ > -#define LTDC_IER 0x0034 /* Interrupt Enable */ > -#define LTDC_ISR 0x0038 /* Interrupt Status */ > -#define LTDC_ICR 0x003C /* Interrupt Clear */ > -#define LTDC_LIPCR 0x0040 /* Line Interrupt Position Configuration */ > -#define LTDC_CPSR 0x0044 /* Current Position Status */ > -#define LTDC_CDSR 0x0048 /* Current Display Status */ > +#define LTDC_IDR 0x /* IDentification */ > +#define LTDC_LCR 0x0004 /* Layer Count */ > +#define LTDC_SSCR 0x0008 /* Synchronization Size Configuration > */ > +#define LTDC_BPCR 0x000C /* Back Porch Configuration */ > +#define LTDC_AWCR 0x0010 /* Active Width Configuration */ > +#define LTDC_TWCR 0x0014 /* Total Width Configuration */ > +#define LTDC_GCR 0x0018 /* Global Control */ > +#define LTDC_GC1R 0x001C /* Global Configuration 1 */ > +#define LTDC_GC2R 0x0020 /* Global Configuration 2 */ > +#define LTDC_SRCR 0x0024 /* Shadow Reload Configuration */ > +#define LTDC_GACR 0x0028 /* GAmma Correction */ > +#define LTDC_BCCR 0x002C /* Background Color Configuration */ > +#define LTDC_IER 0x0034 /* Interrupt Enable */ > +#define LTDC_ISR 0x0038 /* Interrupt Status */ > +#define LTDC_ICR 0x003C /* Interrupt Clear */ > +#define LTDC_LIPCR 0x0040 /* Line Interrupt Position Conf. */ > +#define LTDC_CPSR 0x0044 /* Current Position Status */ > +#define LTDC_CDSR 0x0048 /* Current Display Status */ > > /* Layer register offsets */ > -#define LTDC_L1LC1R(0x0080) /* L1 Layer Configuration 1 */ > -#define LTDC_L1LC2R(0x0084) /* L1 Layer Configuration 2 */ > -#define LTDC_L1CR (0x0084 + REG_OFS) /* L1 Control */ > -#define LTDC_L1WHPCR (0x0088 + REG_OFS) /* L1 Window Hor Position Config */ > -#define LTDC_L1WVPCR (0x008C + REG_OFS) /* L1 Window Vert Position Config > */ > -#define LTDC_L1CKCR(0x0090 + REG_OFS) /* L1 Color Keying Configuration */ > -#define LTDC_L1PFCR(0x0094 + REG_OFS) /* L1 Pixel Format Configuration */ > -#define LTDC_L1CACR(0x0098 + REG_OFS) /* L1 Constant Alpha Config */ > -#define LTDC_L1DCCR(0x009C + REG_OFS) /* L1 Default Color Configuration > */ > -#define LTDC_L1BFCR(0x00A0 + REG_OFS) /* L1 Blend Factors Configuration > */ > -#define LTDC_L1FBBCR (0x00A4 + REG_OFS) /* L1 FrameBuffer Bus Control */ > -#define LTDC_L1AFBCR (0x00A8 + REG_OFS) /* L1 AuxFB Control */ > -#define LTDC_L1CFBAR (0x00AC + REG_OFS) /* L1 Color FrameBuffer Address */ > -#define LTDC_L1CFBLR (0x00B0 + REG_OFS) /* L1 Color FrameBuffer Length */ > -#define LTDC_L1CFBLNR (0x00B4 + REG_OFS) /* L1 Color FrameBuffer Line Nb */ > -#define LTDC_L1AFBAR (0x00B8 + REG_OFS) /* L1 AuxFB Address */ > -#define LTDC_L1AFBLR (0x00BC + REG_OFS) /* L1 AuxFB Length */ > -#define LTDC_L1AFBLNR (0x00C0 + REG_OFS) /* L1 AuxFB Line Number */ > -#define LTDC_L1CLUTWR (0x00C4 + REG_OFS) /* L1 CLUT Write */ > -#define LTDC_L1YS1R(0x00E0 + REG_OFS) /* L1 YCbCr Scale 1 */ > -#define LTDC_L1YS2R(0x00E4 + REG_OFS) /* L1 YCbCr Scale 2 */ > +#define LTDC_L1LC1R(0x80)
Re: [PATCH v1 1/7] drm/stm: drv: Rename platform driver name
2017-07-18 12:20 GMT+02:00 Philippe CORNU :
> Rename the platform driver name from "stm" to "stm32-display"
> for a better readability in /sys/bus/platform/drivers entries.
>
> Note: We keep "stm" as drm_driver.name because it is better
> when using "modetest -M stm ..." (even if recent modetest patch
> avoids using -M).
>
> Signed-off-by: Philippe CORNU
Reviewed-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/stm/drv.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 83ab48f..095971f 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -20,13 +20,6 @@
>
> #include "ltdc.h"
>
> -#define DRIVER_NAME"stm"
> -#define DRIVER_DESC"STMicroelectronics SoC DRM"
> -#define DRIVER_DATE"20170330"
> -#define DRIVER_MAJOR 1
> -#define DRIVER_MINOR 0
> -#define DRIVER_PATCH_LEVEL 0
> -
> #define STM_MAX_FB_WIDTH 2048
> #define STM_MAX_FB_HEIGHT 2048 /* same as width to handle orientation */
>
> @@ -59,12 +52,12 @@ static void drv_lastclose(struct drm_device *ddev)
> .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
>DRIVER_ATOMIC,
> .lastclose = drv_lastclose,
> - .name = DRIVER_NAME,
> - .desc = DRIVER_DESC,
> - .date = DRIVER_DATE,
> - .major = DRIVER_MAJOR,
> - .minor = DRIVER_MINOR,
> - .patchlevel = DRIVER_PATCH_LEVEL,
> + .name = "stm",
> + .desc = "STMicroelectronics SoC DRM",
> + .date = "20170330",
> + .major = 1,
> + .minor = 0,
> + .patchlevel = 0,
> .fops = &drv_driver_fops,
> .dumb_create = drm_gem_cma_dumb_create,
> .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> @@ -206,7 +199,7 @@ static int stm_drm_platform_remove(struct platform_device
> *pdev)
> .probe = stm_drm_platform_probe,
> .remove = stm_drm_platform_remove,
> .driver = {
> - .name = DRIVER_NAME,
> + .name = "stm32-display",
> .of_match_table = drv_dt_ids,
> },
> };
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
