Re: [PATCH] drm/vblank: Fix flip event vblank count
Hi Ville, On 10.10.2017 15:33, Ville Syrjala wrote: > From: Ville Syrjälä > > On machines where the vblank interrupt fires some time after the start > of vblank (or we just manage to race with the vblank interrupt handler) > we will currently stuff a stale vblank counter value into the flip event, > and thus we'll prematurely complete the flip. > > Switch over to drm_crtc_accurate_vblank_count() to make sure we have an > up to date counter value, crucially also remember to add the +1 so that > the delayed vblank interrupt won't complete the flip prematurely. > > Cc: sta...@vger.kernel.org > Cc: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_vblank.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 70f2b9593edc..f14e6c92e332 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -869,7 +869,7 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > assert_spin_locked(&dev->event_lock); > > e->pipe = pipe; > - e->event.sequence = drm_vblank_count(dev, pipe); > + e->event.sequence = drm_crtc_accurate_vblank_count(crtc) + 1; With this patch drm_crtc_arm_vblank_event calls drm_crtc_accurate_vblank_count, which requires get_vblank_timestamp callback, otherwise it issue WARN every time it is called. On the other side most of the users of drm_crtc_arm_vblank_event do not implement this callback. As a result one can observe multiple WARNs. It was observed on Exynos platform but grep shows it can affect many other platforms: $ git grep -l drm_crtc_arm_vblank_event drivers/gpu/drm/ drivers/gpu/drm/arm/hdlcd_crtc.c drivers/gpu/drm/arm/malidp_drv.c drivers/gpu/drm/drm_vblank.c drivers/gpu/drm/exynos/exynos_drm_crtc.c drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c drivers/gpu/drm/i915/intel_sprite.c drivers/gpu/drm/imx/ipuv3-crtc.c drivers/gpu/drm/mxsfb/mxsfb_crtc.c drivers/gpu/drm/nouveau/nouveau_display.c drivers/gpu/drm/pl111/pl111_display.c drivers/gpu/drm/sti/sti_crtc.c drivers/gpu/drm/stm/ltdc.c drivers/gpu/drm/sun4i/sun4i_crtc.c drivers/gpu/drm/tve200/tve200_display.c drivers/gpu/drm/vmwgfx/vmwgfx_kms.c drivers/gpu/drm/zte/zx_vou.c $ git grep -l get_vblank_timestamp drivers/gpu/drm/ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c drivers/gpu/drm/drm_vblank.c drivers/gpu/drm/i915/i915_irq.c drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c drivers/gpu/drm/nouveau/nouveau_drm.c drivers/gpu/drm/radeon/radeon_drv.c drivers/gpu/drm/vc4/vc4_drv.c Regards Andrzej > e->event.crtc_id = crtc->base.id; > list_add_tail(&e->base.link, &dev->vblank_event_list); > } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103234] KWin crashed when Alt+Tab-ing through open windows
https://bugs.freedesktop.org/show_bug.cgi?id=103234 --- Comment #6 from Dennis Schridde --- This is the ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/mesa/mesa-17.2.2.ebuild Patches would be listed in a PATCHES variable or applied in src_prepare(). The ebuild has only eapply_user there, which would apply patches in /etc/portage/patches/media-libs/mesa (or a version specific directory), which I don't have. Hence I believe there are no patches applied on my system. I will extract the sources again and will try to attach GDB, while DrKonqi (KDE's bug-reporting tool) has the process stopped, the next time I reproduce the crash in the coming days. I will also install using the / git ebuild and see whether I can reproduce there. -- 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 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
https://bugs.freedesktop.org/show_bug.cgi?id=103316 --- Comment #1 from Christian König --- Mhm, please attach the full dmesg. Is that a regression? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/9] Exynos DRM: rewrite IPP subsystem and userspace API
Hi Daniel, On 2017-10-17 14:24, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 01:07:43PM +0200, Marek Szyprowski wrote: This patchset performs complete rewrite of Exynos DRM IPP subsystem and its userspace API. Why such rewrite is needed? Exynos DRM IPP API is over-engineered in general, but not really extensible on the other side. It is also buggy, with significant design flaws: - Userspace API covers memory-2-memory picture operations together with CRTC writeback and duplicating features, which belongs to video plane. - Lack of support of the all required image formats (for example NV12 Samsung-tiled cannot be used due to lack of pixel format modifier support). - Userspace API designed only to mimic hardware behaviour, not easy to understand. - Lack of proper input validation in the core, drivers also didn't do that correctly, so it was possible to set incorrect parameters and easil trigger IOMMU fault or memory trash. - Drivers were partially disfunctional or supported only a subset of modes. Due to the above limitations and issues the Exynos DRM IPP API was not used by any of the open-source projects. I assume that it is safe to remove this broken API without any damage to open-source community. All remaining users (mainly Tizen project related) will be updated to the new version. This patchset changes Exynos DRM IPP subsystem to something useful. The userspace API is much simpler, state-less and easy to understand. Also the code of the core and driver is significantly smaller and easier to understand. Patches were tested on Exynos4412 based Odroid U3, Exynos5422 Odroid XU3 and Exynos5433 TM2 boards, on top of Linux next-20171016 kernel. When submitting uapi changes, please link to the corresponding userspace work. Otherwise pretty hard to find this stuff. A simple userspace test tool has been sent together with v1: https://www.spinics.net/lists/linux-samsung-soc/msg60498.html Tobias Jakobi has added support for this new API to his fork of libdrm and mpv video player: https://github.com/tobiasjakobi/libdrm/tree/ippv2 https://github.com/tobiasjakobi/mpv Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/12] drm/panel: Keep track of enabled/prepared
On 17.10.2017 23:13, Sean Paul wrote:
> This patch adds state tracking to the drm_panel functions which keep
> track of enabled and prepared. If the calls are unbalanced, a WARNING is
> issued.
>
> The motivation for this change is that a number of panel drivers
> (including panel-simple) all do this to protect their regulator
> refcounts. The atomic framework ensures the calls are balanced, and
> there aren't any panel drivers being used by legacy drivers. As such,
> these checks are useless, but let's add a WARNING just in case something
> crazy happens (like a legacy driver using a panel).
>
> Less code == better.
>
> Changes in v2:
> - Reduced enabled/prepared bools to one enum (Andrzej)
> - Don't update state if the operation fails (Andrzej)
> - Issue warning even if operation is not implemented
>
> Changes in v3:
> - Functions no longer static inline (Daniel)
> - Added a helper function to share state change code (Andrzej)
> - Only warn when a panel is present (Daniel)
> - Update state if function is not implemented (Andrzej)
>
> Cc: Andrzej Hajda
> Cc: Daniel Vetter
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/drm_panel.c | 63
> -
> include/drm/drm_panel.h | 15 +++
> 2 files changed, 66 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 6f28598a5d0e..6547850b5e80 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -21,6 +21,7 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include
> #include
> #include
>
> @@ -48,6 +49,7 @@ static LIST_HEAD(panel_list);
> void drm_panel_init(struct drm_panel *panel)
> {
> INIT_LIST_HEAD(&panel->list);
> + panel->state = DRM_PANEL_POWER_OFF;
> }
> EXPORT_SYMBOL(drm_panel_init);
>
> @@ -126,6 +128,23 @@ int drm_panel_detach(struct drm_panel *panel)
> }
> EXPORT_SYMBOL(drm_panel_detach);
>
> +static int drm_panel_change_state(struct drm_panel *panel,
> + enum drm_panel_state cur_state,
> + enum drm_panel_state new_state,
> + int (*hook)(struct drm_panel *panel))
> +{
> + int ret;
> +
> + WARN_ON(panel->state != cur_state);
> + if (hook)
> + ret = hook(panel);
> + else
> + ret = -ENOSYS;
You have missed my 2 comments:
- do not change state on callback error,
- return 0 in case there is no callback.
Regards
Andrzej
> +
> + panel->state = new_state;
> + return ret;
> +}
> +
> /**
> * drm_panel_unprepare - power off a panel
> * @panel: DRM panel
> @@ -135,14 +154,19 @@ EXPORT_SYMBOL(drm_panel_detach);
> * is usually no longer possible to communicate with the panel until another
> * call to drm_panel_prepare().
> *
> + * Atomic framework will ensure that prepare/unprepare are properly balanced.
> + * If this is not the case, a WARNING will be issued.
> + *
> * Return: 0 on success or a negative error code on failure.
> */
> int drm_panel_unprepare(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->unprepare)
> - return panel->funcs->unprepare(panel);
> + if (!panel)
> + return -EINVAL;
>
> - return panel ? -ENOSYS : -EINVAL;
> + return drm_panel_change_state(panel, DRM_PANEL_POWER_PREPARED,
> + DRM_PANEL_POWER_OFF,
> + panel->funcs ? panel->funcs->unprepare : NULL);
> }
> EXPORT_SYMBOL(drm_panel_unprepare);
>
> @@ -154,14 +178,19 @@ EXPORT_SYMBOL(drm_panel_unprepare);
> * drivers. For smart panels it should still be possible to communicate with
> * the integrated circuitry via any command bus after this call.
> *
> + * Atomic framework will ensure that enable/disable are properly balanced.
> + * If this is not the case, a WARNING will be issued.
> + *
> * Return: 0 on success or a negative error code on failure.
> */
> int drm_panel_disable(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs->disable)
> - return panel->funcs->disable(panel);
> + if (!panel)
> + return -EINVAL;
>
> - return panel ? -ENOSYS : -EINVAL;
> + return drm_panel_change_state(panel, DRM_PANEL_POWER_ENABLED,
> + DRM_PANEL_POWER_PREPARED,
> + panel->funcs ? panel->funcs->disable : NULL);
> }
> EXPORT_SYMBOL(drm_panel_disable);
>
> @@ -173,14 +202,19 @@ EXPORT_SYMBOL(drm_panel_disable);
> * the panel. After this has completed it is possible to communicate with any
> * integrated circuitry via a command bus.
> *
> + * Atomic framework will ensure that prepare/unprepare are properly balanced.
> + * If this is not the case, a WARNING will be issued.
> + *
> * Return: 0 on success or a negative error code on failure.
> */
> int drm_panel_prepare(struct drm_panel *panel)
> {
> - if (panel && panel->funcs && panel->funcs-
Re: [PATCH v3] drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl
On Tue, 17 Oct 2017 17:16:29 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > This ioctl will allow us to purge inactive userspace buffers when the
> > system is running out of contiguous memory.
> >
> > For now, the purge logic is rather dumb in that it does not try to
> > release only the amount of BO needed to meet the last CMA alloc request
> > but instead purges all objects placed in the purgeable pool as soon as
> > we experience a CMA allocation failure.
> >
> > Note that the in-kernel BO cache is always purged before the purgeable
> > cache because those objects are known to be unused while objects marked
> > as purgeable by a userspace application/library might have to be
> > restored when they are marked back as unpurgeable, which can be
> > expensive.
> >
> > Signed-off-by: Boris Brezillon
>
> Looking good! Just a couple things I'd like to sort out before we
> merge.
>
> > ---
> > Hello,
> >
> > Updates to libdrm, mesa and igt making use of this kernel feature can
> > be found on my github repos [1][2][3].
> >
> > There's currently no debugfs hook to manually force a purge, but this
> > is being discussed and might be added later on.
> >
> > Regards,
> >
> > Boris
> >
> > [1]https://github.com/bbrezillon/drm/tree/vc4/purgeable
> > [2]https://github.com/bbrezillon/mesa/tree/vc4/purgeable
> > [3]https://github.com/bbrezillon/igt/tree/vc4/purgeable
> >
> > Changes in v3:
> > - Use %zd formatters when printing size_t values
> > - rework detection of BOs that do not support the MADV ioctl
> > - replace DRM_ERROR by DRM_DEBUG in the ioctl path
> > - do not explicitly memzero purged BO mem
> > - check that pad is set to zero in the madv ioctl function
> >
> > Changes in v2:
> > - Do not re-allocate BO's memory after when WILLNEED is asked after a purge
> > - Add purgeable/purged stats to debugfs and dumpstats
> > - Pad the drm_vc4_gem_madvise to make it 64-bit aligned
> > - Forbid madvise calls on internal BO objects (everything that is not
> > meant to be exposed to userspace)
> > - Do not increment/decrement usecnt on internal BOs (they cannot be marked
> > purgeable, so doing that is useless and error prone)
> > - Fix a few bugs related to usecnt refcounting
> > ---
> > drivers/gpu/drm/vc4/vc4_bo.c| 292
> > ++--
> > drivers/gpu/drm/vc4/vc4_drv.c | 10 +-
> > drivers/gpu/drm/vc4/vc4_drv.h | 30 +
> > drivers/gpu/drm/vc4/vc4_gem.c | 156 -
> > drivers/gpu/drm/vc4/vc4_plane.c | 20 +++
> > include/uapi/drm/vc4_drm.h | 19 +++
> > 6 files changed, 512 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> > index 3afdbf4bc10b..e4d13bbef54f 100644
> > --- a/drivers/gpu/drm/vc4/vc4_bo.c
> > +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> > @@ -42,6 +42,8 @@ static bool is_user_label(int label)
> >
> > static void vc4_bo_stats_dump(struct vc4_dev *vc4)
> > {
> > + size_t purgeable_size, purged_size;
> > + unsigned int npurgeable, npurged;
> > int i;
> >
> > for (i = 0; i < vc4->num_labels; i++) {
> > @@ -53,6 +55,21 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
> > vc4->bo_labels[i].size_allocated / 1024,
> > vc4->bo_labels[i].num_allocated);
> > }
> > +
> > + mutex_lock(&vc4->purgeable.lock);
> > + npurgeable = vc4->purgeable.num;
> > + purgeable_size = vc4->purgeable.size;
> > + purged_size = vc4->purgeable.purged_size;
> > + npurged = vc4->purgeable.purged_num;
> > + mutex_unlock(&vc4->purgeable.lock);
> > +
> > + if (npurgeable)
> > + DRM_INFO("%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
> > +purgeable_size / 1024, npurgeable);
> > +
> > + if (npurged)
> > + DRM_INFO("%30s: %6zdkb BOs (%d)\n", "total purged BO",
> > +purged_size / 1024, npurged);
> > }
> >
> > #ifdef CONFIG_DEBUG_FS
> > @@ -61,6 +78,8 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
> > struct drm_info_node *node = (struct drm_info_node *)m->private;
> > struct drm_device *dev = node->minor->dev;
> > struct vc4_dev *vc4 = to_vc4_dev(dev);
> > + size_t purgeable_size, purged_size;
> > + unsigned int npurgeable, npurged;
> > int i;
> >
> > mutex_lock(&vc4->bo_lock);
> > @@ -75,6 +94,21 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void
> > *unused)
> > }
> > mutex_unlock(&vc4->bo_lock);
> >
> > + mutex_lock(&vc4->purgeable.lock);
> > + npurgeable = vc4->purgeable.num;
> > + purgeable_size = vc4->purgeable.size;
> > + purged_size = vc4->purgeable.purged_size;
> > + npurged = vc4->purgeable.purged_num;
> > + mutex_unlock(&vc4->purgeable.lock);
> > +
> > + if (npurgeable)
> > + seq_printf(m, "%30s: %6dkb BOs (%d)\n", "userspace BO cache",
> > + purgeable_size / 1024, npurgeable);
> > +
> > + if (npurged)
> > + seq_printf(m, "%30s:
Re: [PATCH v2 1/4] video: fb: Make fbcon dmi quirks usuable for drm drivers too
On Tue, Oct 17, 2017 at 06:17:21PM +0200, Hans de Goede wrote:
> Hi,
>
> Sorry for being slow to reply, I've been a bit overwhelmed with
> other stuff lately.
>
> On 10/02/2017 10:01 AM, Daniel Vetter wrote:
> > On Sun, Oct 01, 2017 at 05:33:14PM +0200, Hans de Goede wrote:
> > > Some x86 clamshell design devices use portrait tablet LCD panels and a
> > > display engine which cannot (transparently) rotate in hardware, so we
> > > need to rotate things in software / let user space deal with this.
> > >
> > > The fbcon code has a set of DMI based quirks to automatically detect
> > > such tablet LCD panels and rotate the fbcon to compensate.
> > >
> > > The plan was for userspace (e.g. a Wayland compositor) to simply read
> > > /sys/class/graphics/fbcon/rotate and apply the rotation from there to
> > > the LCD panel to compensate.
> > >
> > > However this will not work when an external monitor gets plugged in,
> > > since with fbcon rotation is not per output, so the fbcon quirk code
> > > disables the rotation when an external monitor is present.
> > >
> > > Using /sys/class/graphics/fbcon/rotate will not help in that case
> > > since it will indicate no rotation is in use. So instead we are going
> > > to need a drm connecter property for this.
> > >
> > > This commit is a preparation patch for adding the drm-connecter
> > > property, by making the fbcon quirk code generally usable so that
> > > the drm code can use it to check for rotation quirks.
> > >
> > > Note this commit re-uses the FB_CMDLINE Kconfig option for selecting
> > > if the quirk code should be build, since that is already selected by
> > > both the drm and fbcon code.
> > >
> > > Signed-off-by: Hans de Goede
> >
> > Can we pls just outright move this out of fbdev? fbdev is dead, I don't
> > want to add/maintain new stuff in there (except fbcon, but that should not
> > deal with stuff like this).
>
> Sure we can do that, but fbcon also needs access to the quirks, so then
> we need to have some part of the drm code which always gets builtin into
> the kernel and make the drm code export a function for this which the
> fbcon code uses.
>
> The reason why fbcon uses this is because there are cases where the BIOS
> does not setup the EFIFB with the correct rotation, typically because
> the hardware does not support 90 / 270 degrees rotation and the
> screen has been mounted rotated 90 / 270 degrees rotation.
Oh dear, I hoped we could ignore that.
So yeah we need to load the same quirk table for efifb and for i915. How
much I wish we'd just have merged simpledrm by now :-)
I still don't think that fbcon should have access to the quirks directly,
but efifb and drm_fb_helper should set the same hint flags probably.
Wrt the location, I don't even think we need to have this built-in. Put a
new module for intel-quirks into drivers/gpu/platform and select that from
both, and it should all work out I think.
Or is there some other gotcha?
Thanks, Daniel
>
> Regards,
>
> Hans
>
>
> > This probably means some serious patch series acrobatics, or just breaking
> > the current fbcon-only hack and rebuilding it in drm (in the same series).
> >
> > -Daniel
> >
> > > ---
> > > Changes in v2:
> > > -Rebased on 4.14-rc1
> > > ---
> > > drivers/video/fbdev/core/Makefile | 6 +++---
> > > .../core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c} | 15 +--
> > > drivers/video/fbdev/core/fbcon.c | 22
> > > ++
> > > drivers/video/fbdev/core/fbcon.h | 6 --
> > > include/linux/fb.h | 6 ++
> > > 5 files changed, 32 insertions(+), 23 deletions(-)
> > > rename drivers/video/fbdev/core/{fbcon_dmi_quirks.c => fb_dmi_quirks.c}
> > > (91%)
> > >
> > > diff --git a/drivers/video/fbdev/core/Makefile
> > > b/drivers/video/fbdev/core/Makefile
> > > index 73493bbd7a15..06caf037a822 100644
> > > --- a/drivers/video/fbdev/core/Makefile
> > > +++ b/drivers/video/fbdev/core/Makefile
> > > @@ -1,4 +1,7 @@
> > > obj-$(CONFIG_FB_CMDLINE) += fb_cmdline.o
> > > +ifeq ($(CONFIG_DMI),y)
> > > +obj-$(CONFIG_FB_CMDLINE) += fb_dmi_quirks.o
> > > +endif
> > > obj-$(CONFIG_FB_NOTIFY) += fb_notify.o
> > > obj-$(CONFIG_FB) += fb.o
> > > fb-y := fbmem.o fbmon.o fbcmap.o fbsysfs.o
> > > \
> > > @@ -14,9 +17,6 @@ ifeq ($(CONFIG_FRAMEBUFFER_CONSOLE_ROTATION),y)
> > > fb-y += fbcon_rotate.o fbcon_cw.o
> > > fbcon_ud.o \
> > >fbcon_ccw.o
> > > endif
> > > -ifeq ($(CONFIG_DMI),y)
> > > -fb-y += fbcon_dmi_quirks.o
> > > -endif
> > > endif
> > > fb-objs := $(fb-y)
> > > diff --git a/drivers/video/fbdev/core/fbcon_dmi_quirks.c
> > > b/drivers/video/fbdev/core/fb_dmi_quirks.c
> > > similarity index 91%
> > > rename from drivers/video/fbd
Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync
On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote: > On 17.10.2017 19:16, Daniel Vetter wrote: > > On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote: > > > On 17/10/17 05:04 PM, Daniel Vetter wrote: > > > > On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: > > > > > On 17/10/17 02:22 PM, Daniel Vetter wrote: > > > > > > On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote: > > > > > > > On 17/10/17 11:34 AM, Nicolai Hähnle wrote: > > > > > > > > > > > > > > Common sense suggests that there need to be two side to > > > > > > > > FreeSync / VESA > > > > > > > > Adaptive Sync support: > > > > > > > > > > > > > > > > 1. Query the display capabilities. This means querying minimum > > > > > > > > / maximum > > > > > > > > refresh duration, plus possibly a query for when the > > > > > > > > earliest/latest > > > > > > > > timing of the *next* refresh. > > > > > > > > > > > > > > > > 2. Signal desired present time. This means passing a target > > > > > > > > timer value > > > > > > > > instead of a target vblank count, e.g. something like this for > > > > > > > > the KMS > > > > > > > > interface: > > > > > > > > > > > > > > > >int drmModePageFlipTarget64(int fd, uint32_t crtc_id, > > > > > > > > uint32_t fb_id, > > > > > > > >uint32_t flags, void *user_data, > > > > > > > >uint64_t target); > > > > > > > > > > > > > > > >+ a flag to indicate whether target is the vblank count or > > > > > > > > the > > > > > > > > CLOCK_MONOTONIC (?) time in ns. > > > > > > > > > > > > > > drmModePageFlip(Target) is part of the pre-atomic KMS API, but > > > > > > > adapative > > > > > > > sync should probably only be supported via the atomic API, > > > > > > > presumably > > > > > > > via output properties. > > > > > > > > > > > > +1 > > > > > > > > > > > > At least now that DC is on track to land properly, and you want to > > > > > > do this > > > > > > for DC-only anyway there's no reason to pimp the legacy interfaces > > > > > > further. And atomic is soo much easier to extend. > > > > > > > > > > > > The big question imo is where we need to put the flag on the kms > > > > > > side, > > > > > > since freesync is not just about presenting earlier, but also about > > > > > > presenting later. But for backwards compat we can't stretch the > > > > > > refresh > > > > > > rate by default for everyone, or clients that rely on high precision > > > > > > timestamps and regular refresh will get a bad surprise. > > > > > > > > > > The idea described above is that adaptive sync would be used for flips > > > > > with a target timestamp. Apps which don't want to use adaptive sync > > > > > wouldn't set a target timestamp. > > > > > > > > > > > > > > > > I think a boolean enable_freesync property is probably what we > > > > > > want, which > > > > > > enables freesync for as long as it's set. > > > > > > > > > > The question then becomes under what circumstances the property is > > > > > (not) > > > > > set. Not sure offhand this will actually solve any problem, or just > > > > > push > > > > > it somewhere else. > > > > > > > > I thought that's what the driconf switch is for, with a policy of > > > > "please > > > > schedule asap" instead of a specific timestamp. > > > > > > The driconf switch is just for the user's intention to use adaptive sync > > > when possible. A property as you suggest cannot be set by the client > > > directly, because it can't know when adaptive sync can actually be used > > > (only when its window is fullscreen and using page flipping). So the > > > property would have to be set by the X server/driver / Wayland > > > compositor / ... instead. The question is whether such a property is > > > actually needed, or whether the kernel could just enable adaptive sync > > > when there's a flip with a target timestamp, and disable it when there's > > > a flip without a target timestamp, or something like that. > > > > If your adaptive sync also supports extending the vblank beyond the > > nominal limit, then you can't do that with a per-flip flag. Because > > absent of a userspace requesting adaptive sync you must flip at the > > nominal vrefresh rate. So if your userspace is a tad bit late with the > > frame and would like to extend the frame to avoid missing a frame > > entirely it'll be too late by the time the vblank actually gets > > submitted. That's a bit a variation of what Ville brought up about > > what we're going to do when the timestamp was missed by the time all > > the depending fences signalled. > > These are very good points. It does sound like we'd need both an > "AdaptiveSync" boolean property and an (optional) "DesiredPresentTime" > property. > > The DesiredPresentTime property applies only to a single commit and could > perhaps be left out in a first version. The AdaptiveSync property is > persistent. When enabled, it means: > > - handle page flip reques
Re: [PATCH 1/9] drm/panel: simple: add a macro for defining display modes in a simpler and less error prone way
Hi,
On Tue, 17 Oct 2017 14:08:18 +0200 Thierry Reding wrote:
> On Wed, Oct 11, 2017 at 01:23:33PM +0200, Lothar Waßmann wrote:
> > Create a macro that eases the definition of display mode parameters by
> > accecpting the parameters:
> > freq, hactive, hfront-porch, hsynclen, hback-porch,
> > vactive, vfront-porch, vsynclen, vback-porch, vrefresh
> > that can be usually directly taken from an LCD datasheet.
> >
> > Put the calculations that are now open coded repeating the same
> > parameters multiple times into the macro expansion.
> >
> > Signed-off-by: Lothar Waßmann
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 474fa75..dec639d 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -411,6 +411,20 @@ static const struct panel_desc
> > ampire_am_480272h3tmqw_t01h = {
> > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > };
> >
> > +#define SP_DISPLAY_MODE(freq, ha, hfp, hs, hbp, va, vfp, vs, vbp, vr,
> > flgs) { \
> > + .clock = freq, \
> > + .hdisplay = ha, \
> > + .hsync_start = (ha) + (hfp),\
> > + .hsync_end = (ha) + (hfp) + (hs), \
> > + .htotal = (ha) + (hfp) + (hs) + (hbp), \
> > + .vdisplay = (va), \
> > + .vsync_start = (va) + (vfp),\
> > + .vsync_end = (va) + (vfp) + (vs), \
> > + .vtotal = (va) + (vfp) + (vs) + (vbp), \
> > + .vrefresh = vr, \
> > + .flags = flgs, \
> > + }
>
> I don't think this simplifies anything. It's now completely non-obvious
> which parameter is which, so you actually have to go look at the macro
> definition when you add a new mode to make sure you get them right.
>
In the original code you have to repeat the same parameters (e.g.
vertical front porch (vfp)) in multiple places which is error prone.
Lothar Waßmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/12] of: overlay: remove a dependency on device node full_name
From: Frank Rowand
The "%pOF" printf format was recently added to print the
full name of a device tree node, with the intent of changing
the node full_name field to contain only the node name instead
of the full path of the node.
dup_and_fixup_symbol_prop() duplicates a property from the
"/__symbols__" node of an overlay device tree. The value
of each duplicated property must be fixed up to include
the full path of a node in the live device tree. The
current code uses the node's full_name for that purpose.
Update the code to use the "%pOF" printf format to
determine the node's full path.
Signed-off-by: Frank Rowand
---
drivers/of/base.c | 2 +-
drivers/of/of_private.h | 2 ++
drivers/of/overlay.c| 90 ++---
3 files changed, 59 insertions(+), 35 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b98f3adffbb0..3de07e6e82a0 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -658,7 +658,7 @@ struct device_node *of_get_child_by_name(const struct
device_node *node,
}
EXPORT_SYMBOL(of_get_child_by_name);
-static struct device_node *__of_find_node_by_path(struct device_node *parent,
+struct device_node *__of_find_node_by_path(struct device_node *parent,
const char *path)
{
struct device_node *child;
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 248730567dbe..92a9a3687446 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -110,6 +110,8 @@ extern void *__unflatten_device_tree(const void *blob,
struct property *__of_prop_dup(const struct property *prop, gfp_t allocflags);
__printf(2, 3) struct device_node *__of_node_dup(const struct device_node *np,
const char *fmt, ...);
+struct device_node *__of_find_node_by_path(struct device_node *parent,
+ const char *path);
struct device_node *__of_find_node_by_full_path(struct device_node *node,
const char *path);
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 602218e07ec3..0e9aefc1ff15 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -37,6 +37,7 @@ struct fragment {
/**
* struct overlay_changeset
* @ovcs_list: list on which we are located
+ * @overlay_tree: expanded device tree that contains the fragment nodes
* @count: count of fragment structures
* @fragments: fragment nodes in the overlay expanded device tree
* @symbols_fragment: last element of @fragments[] is the __symbols__ node
@@ -45,6 +46,7 @@ struct fragment {
struct overlay_changeset {
int id;
struct list_head ovcs_list;
+ struct device_node *overlay_tree;
int count;
struct fragment *fragments;
bool symbols_fragment;
@@ -145,12 +147,13 @@ static int overlay_notify(struct overlay_changeset *ovcs,
}
/*
- * The properties in the "/__symbols__" node are "symbols".
+ * The values of properties in the "/__symbols__" node are paths in
+ * the ovcs->overlay_tree. When duplicating the properties, the paths
+ * need to be adjusted to be the correct path for the live device tree.
*
- * The value of properties in the "/__symbols__" node is the path of a
- * node in the subtree of a fragment node's "__overlay__" node, for
- * example "/fragment@0/__overlay__/symbol_path_tail". Symbol_path_tail
- * can be a single node or it may be a multi-node path.
+ * The paths refer to a node in the subtree of a fragment node's "__overlay__"
+ * node, for example "/fragment@0/__overlay__/symbol_path_tail",
+ * where symbol_path_tail can be a single node or it may be a multi-node path.
*
* The duplicated property value will be modified by replacing the
* "/fragment_name/__overlay/" portion of the value with the target
@@ -160,59 +163,76 @@ static struct property *dup_and_fixup_symbol_prop(
struct overlay_changeset *ovcs, const struct property *prop)
{
struct fragment *fragment;
- struct property *new;
- const char *overlay_name;
- char *symbol_path_tail;
- char *symbol_path;
+ struct property *new_prop;
+ struct device_node *fragment_node;
+ struct device_node *overlay_node;
+ const char *path;
+ const char *path_tail;
const char *target_path;
int k;
- int symbol_path_tail_len;
int overlay_name_len;
+ int path_len;
+ int path_tail_len;
int target_path_len;
if (!prop->value)
return NULL;
- symbol_path = prop->value;
+ if (strnlen(prop->value, prop->length) >= prop->length)
+ return NULL;
+ path = prop->value;
+ path_len = strlen(path);
- new = kzalloc(sizeof(*new), GFP_KERNEL);
- if (!new)
+ if (path_len < 1)
return NULL;
+ fragment_node = __of_find_node_by_path(ovcs->overlay_tree, pat
Re: [PATCH] drm/nouveau/fbcon: fix oops without fbdev emulation
Ben, David, I would hate if Linux 4.14 is released without this fix, as it would be a regression for my machine. As I mentioned, Linux 4.13 registers nouveaufb even without the dock, but Linux 4.14 doesn't. And that would cause an oops even if CONFIG_DRM_FBDEV_EMULATION is enabled. Please let me know if any assistance is needed on my part to get the patch merged. Pavel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/12] drm/panel: Move [un]prepare and [dis|en]able functions
On Tue, Oct 17, 2017 at 05:13:05PM -0400, Sean Paul wrote:
> In preparation for state tracking in drm_panel, move the panel functions
> into drm_panel.c so we beef them up in later patches.
>
> Signed-off-by: Sean Paul
I'll take the easy ones, on patches 1&2:
Reviewed-by: Daniel Vetter
> ---
> New in v3
>
> drivers/gpu/drm/drm_panel.c | 77
> include/drm/drm_panel.h | 78
> +++--
> 2 files changed, 82 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 308d442a531b..6f28598a5d0e 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -126,6 +126,83 @@ int drm_panel_detach(struct drm_panel *panel)
> }
> EXPORT_SYMBOL(drm_panel_detach);
>
> +/**
> + * drm_panel_unprepare - power off a panel
> + * @panel: DRM panel
> + *
> + * Calling this function will completely power off a panel (assert the
> panel's
> + * reset, turn off power supplies, ...). After this function has completed,
> it
> + * is usually no longer possible to communicate with the panel until another
> + * call to drm_panel_prepare().
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_unprepare(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->unprepare)
> + return panel->funcs->unprepare(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_unprepare);
> +
> +/**
> + * drm_panel_disable - disable a panel
> + * @panel: DRM panel
> + *
> + * This will typically turn off the panel's backlight or disable the display
> + * drivers. For smart panels it should still be possible to communicate with
> + * the integrated circuitry via any command bus after this call.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_disable(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->disable)
> + return panel->funcs->disable(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_disable);
> +
> +/**
> + * drm_panel_prepare - power on a panel
> + * @panel: DRM panel
> + *
> + * Calling this function will enable power and deassert any reset signals to
> + * the panel. After this has completed it is possible to communicate with any
> + * integrated circuitry via a command bus.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_prepare(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->prepare)
> + return panel->funcs->prepare(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_prepare);
> +
> +/**
> + * drm_panel_enable - enable a panel
> + * @panel: DRM panel
> + *
> + * Calling this function will cause the panel display drivers to be turned on
> + * and the backlight to be enabled. Content will be visible on screen after
> + * this call completes.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_enable(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->enable)
> + return panel->funcs->enable(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_enable);
> +
> #ifdef CONFIG_OF
> /**
> * of_drm_find_panel - look up a panel using a device tree node
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index ab59d71a24c3..0a9442069d3c 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -95,79 +95,6 @@ struct drm_panel {
> struct list_head list;
> };
>
> -/**
> - * drm_panel_unprepare - power off a panel
> - * @panel: DRM panel
> - *
> - * Calling this function will completely power off a panel (assert the
> panel's
> - * reset, turn off power supplies, ...). After this function has completed,
> it
> - * is usually no longer possible to communicate with the panel until another
> - * call to drm_panel_prepare().
> - *
> - * Return: 0 on success or a negative error code on failure.
> - */
> -static inline int drm_panel_unprepare(struct drm_panel *panel)
> -{
> - if (panel && panel->funcs && panel->funcs->unprepare)
> - return panel->funcs->unprepare(panel);
> -
> - return panel ? -ENOSYS : -EINVAL;
> -}
> -
> -/**
> - * drm_panel_disable - disable a panel
> - * @panel: DRM panel
> - *
> - * This will typically turn off the panel's backlight or disable the display
> - * drivers. For smart panels it should still be possible to communicate with
> - * the integrated circuitry via any command bus after this call.
> - *
> - * Return: 0 on success or a negative error code on failure.
> - */
> -static inline int drm_panel_disable(struct drm_panel *panel)
> -{
> - if (panel && panel->funcs && panel->funcs->disable)
> - return panel->funcs-
Re: [PATCH 4/9] drm/panel: simple: add support for overriding the pixel clock polarity
Hi, On Tue, 17 Oct 2017 14:14:22 +0200 Thierry Reding wrote: > On Wed, Oct 11, 2017 at 01:23:36PM +0200, Lothar Waßmann wrote: > > The Ka-Ro electronics MB7 baseboard has an on-board LCD->LVDS > > converter that requires a fixed pixelclk polarity, no matter what the > > panel's display_mode specifies. Add an option to override the pixelclk > > polarity defined in the panel's display_mode via DTB. > > I'd argue that the LCD->LVDS converter should be modelled specifically > in DT to handle this case. It could be a implemented as a DRM bridge > driver, for example. > IMO that's just overkill for a simple chip that is in no way configurable nor detectable by software. Lothar Waßmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/12] of: overlay: expand check of whether overlay changeset can be removed
From: Frank Rowand
The test of whether it is safe to remove an overlay changeset
looked at whether any node in the overlay changeset was in a
subtree rooted at any more recently applied overlay changeset
node.
The test failed to determine whether any node in the overlay
changeset was the root of a subtree that contained a more
recently applied overlay changeset node. Add this additional
check to the test.
The test is still lacking any check for any phandle dependencies.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 78c50fd57750..4cdee169a5ab 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -707,13 +707,13 @@ static int find_node(struct device_node *tree, struct
device_node *np)
}
/*
- * Is @remove_ce_np a child of or the same as any
+ * Is @remove_ce_node a child of, a parent of, or the same as any
* node in an overlay changeset more topmost than @remove_ovcs?
*
* Returns 1 if found, else 0
*/
-static int node_in_later_cs(struct overlay_changeset *remove_ovcs,
- struct device_node *remove_ce_np)
+static int node_overlaps_later_cs(struct overlay_changeset *remove_ovcs,
+ struct device_node *remove_ce_node)
{
struct overlay_changeset *ovcs;
struct of_changeset_entry *ce;
@@ -723,10 +723,16 @@ static int node_in_later_cs(struct overlay_changeset
*remove_ovcs,
break;
list_for_each_entry(ce, &ovcs->cset.entries, node) {
- if (find_node(ce->np, remove_ce_np)) {
- pr_err("%s: #%d clashes #%d @%pOF\n",
+ if (find_node(ce->np, remove_ce_node)) {
+ pr_err("%s: #%d overlaps with #%d @%pOF\n",
__func__, remove_ovcs->id, ovcs->id,
- remove_ce_np);
+ remove_ce_node);
+ return 1;
+ }
+ if (find_node(remove_ce_node, ce->np)) {
+ pr_err("%s: #%d overlaps with #%d @%pOF\n",
+ __func__, remove_ovcs->id, ovcs->id,
+ remove_ce_node);
return 1;
}
}
@@ -750,7 +756,7 @@ static int overlay_removal_is_ok(struct overlay_changeset
*remove_ovcs)
struct of_changeset_entry *remove_ce;
list_for_each_entry(remove_ce, &remove_ovcs->cset.entries, node) {
- if (node_in_later_cs(remove_ovcs, remove_ce->np)) {
+ if (node_overlaps_later_cs(remove_ovcs, remove_ce->np)) {
pr_err("overlay #%d is not topmost\n", remove_ovcs->id);
return 0;
}
--
Frank Rowand
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/23] drm/sun4i: sun8i: properly support UI channels
在 2017-10-17 17:06，Maxime Ripard 写道：
The current code has the wrong macro to get the registers offsets of
the
UI-registers, with an off-by-0x1000 error.
It works so far by accident, since the UI channel used everywhere else
is
the number of VI planes, which has always been 1 so far, and the offset
between two UI channels is 0x1000.
No, I number the VI channels and UI channels in the same sequence, as
it's
also what Allwinner does -- VI channels and UI channels all have the
size
0x1000.
On H3/A64/A83T, the sequence is: 0 - VI, 1 - UI0(, 2 - UI1, 3 - UI2);
on V3s, the sequence is: 0 - VI0, 1 - VI1, 2 - UI.
This patch assumes that there's only one VI channel, which breaks V3s
support.
Let's correct that behaviour by setting the UI chan number in the
sun8i_ui
structure, and remove the hardcoded values pretty much everywhere. Once
we
have sane values, we can convert the macros to their actual definition.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 50
--
drivers/gpu/drm/sun4i/sun8i_mixer.h | 32 ++-
drivers/gpu/drm/sun4i/sun8i_ui.c| 12 ---
drivers/gpu/drm/sun4i/sun8i_ui.h| 1 +-
4 files changed, 46 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 1955b2a36ac5..5afe8ef709a5 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -37,14 +37,12 @@ static void sun8i_mixer_commit(struct sunxi_engine
*engine)
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
-void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
- int layer, bool enable)
+void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer, struct
sun8i_ui *ui,
+ bool enable)
{
u32 val;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
+ DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", ui->id,
ui->chan);
if (enable)
val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
@@ -52,16 +50,16 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer
*mixer,
val = 0;
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
/* Set the alpha configuration */
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
regmap_update_bits(mixer->engine.regs,
- SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
+ SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ui->chan, ui->id),
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
}
@@ -90,14 +88,13 @@ static int sun8i_mixer_drm_format_to_layer(struct
drm_plane *plane,
}
int sun8i_mixer_update_layer_coord(struct sun8i_mixer *mixer,
-int layer, struct drm_plane *plane)
+ struct sun8i_ui *ui)
{
+ struct drm_plane *plane = &ui->plane;
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
- /* Currently the first UI channel is used */
- int chan = mixer->cfg->vi_num;
- DRM_DEBUG_DRIVER("Updating layer %d\n", layer);
+ DRM_DEBUG_DRIVER("Updating layer %d\n", ui->id);
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
DRM_DEBUG_DRIVER("Primary layer, updating global size W: %u H:
%u\n",
@@ -115,7 +112,7 @@ int sun8i_mixer_update_layer_coord(struct
sun8i_mixer *mixer,
state->crtc_h));
DRM_DEBUG_DRIVER("Updating channel size\n");
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_OVL_SIZE(chan),
+SUN8I_MIXER_CHAN_UI_OVL_SIZE(ui->chan),
SUN8I_MIXER_SIZE(state->crtc_w,
state->crtc_h));
}
@@ -123,35 +120,34 @@ int sun8i_mixer_update_layer_coord(struct
sun8i_mixer *mixer,
/* Set the line width */
DRM_DEBUG_DRIVER("Layer line width: %d bytes\n", fb->pitches[0]);
regmap_write(mixer->engine.regs,
-SUN8I_MIXER_CHAN_UI_LAYER_PITCH(chan, layer),
+SUN8I_MIXER_CHAN_UI_LAYER_PITCH(ui->chan, ui->id),
fb->pitches[0]);
/* Se
[PATCH v4 2/2] drm/print: Update old comment style
Remove old comment style used by doxygen.
And remove comment left from commit 99cdb35e787b ("drm/doc: move printf
helpers out of drmP.h") after refactoring drmP.h.
Signed-off-by: Haneen Mohammed
---
Changes in v4:
- Nothing.
include/drm/drm_print.h | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 41dd757..7b9c86a 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -179,9 +179,8 @@ void drm_dev_printk(const struct device *dev, const char
*level,
__printf(3, 4)
void drm_printk(const char *level, unsigned int category,
const char *format, ...);
-/***/
-/** \name Macros to make printk easier */
-/*@{*/
+
+/* Macros to make printk easier */
#define _DRM_PRINTK(once, level, fmt, ...) \
do {\
@@ -206,8 +205,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Error output.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_ERROR(dev, fmt, ...) \
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
@@ -218,8 +217,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
@@ -249,8 +248,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Debug output.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
@@ -301,8 +300,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, args...) \
DEV__DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
@@ -321,10 +320,4 @@ void drm_printk(const char *level, unsigned int category,
#define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...) \
DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##args)
-/* Format strings and argument splitters to simplify printing
- * various "complex" objects
- */
-
-/*@}*/
-
#endif /* DRM_PRINT_H_ */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/12] of: overlay: rename identifiers in dup_and_fixup_symbol_prop()
From: Frank Rowand
More renaming of identifiers to better reflect what they do.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 69610637af88..bb8867cae05b 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -90,17 +90,29 @@ static int overlay_notify(struct overlay_changeset *ovcs,
return 0;
}
+/*
+ * The properties in the "/__symbols__" node are "symbols".
+ *
+ * The value of properties in the "/__symbols__" node is the path of a
+ * node in the subtree of a fragment node's "__overlay__" node, for
+ * example "/fragment@0/__overlay__/symbol_path_tail". Symbol_path_tail
+ * can be a single node or it may be a multi-node path.
+ *
+ * The duplicated property value will be modified by replacing the
+ * "/fragment_name/__overlay/" portion of the value with the target
+ * path from the fragment node.
+ */
static struct property *dup_and_fixup_symbol_prop(
struct overlay_changeset *ovcs, const struct property *prop)
{
struct fragment *fragment;
struct property *new;
const char *overlay_name;
- char *label_path;
+ char *symbol_path_tail;
char *symbol_path;
const char *target_path;
int k;
- int label_path_len;
+ int symbol_path_tail_len;
int overlay_name_len;
int target_path_len;
@@ -126,18 +138,18 @@ static struct property *dup_and_fixup_symbol_prop(
target_path = fragment->target->full_name;
target_path_len = strlen(target_path);
- label_path = symbol_path + overlay_name_len;
- label_path_len = strlen(label_path);
+ symbol_path_tail = symbol_path + overlay_name_len;
+ symbol_path_tail_len = strlen(symbol_path_tail);
new->name = kstrdup(prop->name, GFP_KERNEL);
- new->length = target_path_len + label_path_len + 1;
+ new->length = target_path_len + symbol_path_tail_len + 1;
new->value = kzalloc(new->length, GFP_KERNEL);
if (!new->name || !new->value)
goto err_free;
strcpy(new->value, target_path);
- strcpy(new->value + target_path_len, label_path);
+ strcpy(new->value + target_path_len, symbol_path_tail);
of_property_set_flag(new, OF_DYNAMIC);
--
Frank Rowand
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/12] of: overlay: remove unneeded check for NULL kbasename()
From: Frank Rowand kbasename() will not return NULL if passed a valid string. If the parameter passed to kbasename() in this case is already NULL then the devicetree has been corrupted. Signed-off-by: Frank Rowand --- drivers/of/overlay.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c index 0e9aefc1ff15..c99842bb4b09 100644 --- a/drivers/of/overlay.c +++ b/drivers/of/overlay.c @@ -331,8 +331,6 @@ static int add_changeset_node(struct overlay_changeset *ovcs, int ret = 0; node_kbasename = kbasename(node->full_name); - if (!node_kbasename) - return -ENOMEM; for_each_child_of_node(target_node, tchild) if (!of_node_cmp(node_kbasename, kbasename(tchild->full_name))) -- Frank Rowand ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm/meson: power domain init related fixes
On Tue, Oct 17, 2017 at 10:07:40AM +0200, Neil Armstrong wrote: > A PM Power Domain driver has been pushed at [1] to solve the main issue. URL to [1] missing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection
On 17 October 2017 at 13:05, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 01:03:46PM +1100, Daniel Axtens wrote:
>> Bjorn Helgaas writes:
>>
>> > The default VGA device is normally set in vga_arbiter_add_pci_device() when
>> > we call it for the first enabled device that can be accessed with the
>> > legacy VGA resources ([mem 0xa-0xb], etc.)
>> >
>> > That default device can be overridden by an EFI device that owns the boot
>> > framebuffer. As a fallback, we can also select a VGA device that can't be
>> > accessed via legacy VGA resources, or a VGA device that isn't even enabled.
>> >
>> > Factor out this EFI and fallback selection from vga_arb_device_init() into
>> > a separate vga_arb_select_default_device() function. This doesn't change
>> > any behavior, but it untangles the "bridge control possible" checking and
>> > messages from the default device selection.
>> >
>> > Tested-by: Zhou Wang # D05 Hisi Hip07, Hip08
>> > Signed-off-by: Bjorn Helgaas
>> > ---
>> > drivers/gpu/vga/vgaarb.c | 57
>> > --
>> > 1 file changed, 35 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
>> > index 8035e38d5110..d35d6d271f3f 100644
>> > --- a/drivers/gpu/vga/vgaarb.c
>> > +++ b/drivers/gpu/vga/vgaarb.c
>> > @@ -1402,29 +1402,14 @@ static struct miscdevice vga_arb_device = {
>> > MISC_DYNAMIC_MINOR, "vga_arbiter", &vga_arb_device_fops
>> > };
>> >
>> > -static int __init vga_arb_device_init(void)
>> > +static void __init vga_arb_select_default_device(void)
>> > {
>> > - int rc;
>> > struct pci_dev *pdev;
>> > struct vga_device *vgadev;
>> >
>> > - rc = misc_register(&vga_arb_device);
>> > - if (rc < 0)
>> > - pr_err("error %d registering device\n", rc);
>> > -
>> > - bus_register_notifier(&pci_bus_type, &pci_notifier);
>> > -
>> > - /* We add all pci devices satisfying vga class in the arbiter by
>> > -* default */
>> > - pdev = NULL;
>> > - while ((pdev =
>> > - pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>> > - PCI_ANY_ID, pdev)) != NULL)
>> > - vga_arbiter_add_pci_device(pdev);
>> > -
>> > +#if defined(CONFIG_X86) || defined(CONFIG_IA64)
>> > list_for_each_entry(vgadev, &vga_list, list) {
>> > struct device *dev = &vgadev->pdev->dev;
>> > -#if defined(CONFIG_X86) || defined(CONFIG_IA64)
>> > /*
>> > * Override vga_arbiter_add_pci_device()'s I/O based detection
>> > * as it may take the wrong device (e.g. on Apple system under
>> > @@ -1461,12 +1446,8 @@ static int __init vga_arb_device_init(void)
>> > vgaarb_info(dev, "overriding boot device\n");
>> > vga_set_default_device(vgadev->pdev);
>> > }
>> > -#endif
>> > - if (vgadev->bridge_has_one_vga)
>> > - vgaarb_info(dev, "bridge control possible\n");
>> > - else
>> > - vgaarb_info(dev, "no bridge control possible\n");
>> > }
>> > +#endif
>> >
>> > if (!vga_default_device()) {
>> > list_for_each_entry(vgadev, &vga_list, list) {
>> > @@ -1492,6 +1473,38 @@ static int __init vga_arb_device_init(void)
>> > vga_set_default_device(vgadev->pdev);
>> > }
>> > }
>> > +}
>> > +
>> > +static int __init vga_arb_device_init(void)
>> > +{
>> > + int rc;
>> > + struct pci_dev *pdev;
>> > + struct vga_device *vgadev;
>> > +
>> > + rc = misc_register(&vga_arb_device);
>> > + if (rc < 0)
>> > + pr_err("error %d registering device\n", rc);
>> > +
>> > + bus_register_notifier(&pci_bus_type, &pci_notifier);
>> > +
>> > + /* We add all PCI devices satisfying VGA class in the arbiter by
>> > +* default */
>> > + pdev = NULL;
>> > + while ((pdev =
>> > + pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
>> > + PCI_ANY_ID, pdev)) != NULL)
>> > + vga_arbiter_add_pci_device(pdev);
>> > +
>> > + list_for_each_entry(vgadev, &vga_list, list) {
>> > + struct device *dev = &vgadev->pdev->dev;
>> > +
>> > + if (vgadev->bridge_has_one_vga)
>> > + vgaarb_info(dev, "bridge control possible\n");
>> > + else
>> > + vgaarb_info(dev, "no bridge control possible\n");
>> > + }
>>
>> Initially I wondered if this info printk could be moved into
>> vga_arbiter_check_bridge_sharing(), but it's been separated out since
>> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
>> possible."), and upon closer examination, it seems you can't be sure a
>> device doesn't share a bridge until the end of the process, so this is
>> indeed correct.
>>
>> Everything else also looks good to me.
>>
>> Reviewed-by: Daniel Axtens
>
> R-b for both patches? And ok with everyone if I pull this into drm-misc
> for 4.15 (deadline is end of
[PATCH v3 00/12] of: overlay: clean up device tree overlay code
From: Frank Rowand I have found the device tree overlay code to be difficult to read and maintain. This patch series attempts to improve that situation. The cleanup includes some changes visible to users of overlays. The only in kernel user of overlays is fixed up for those changes. The in kernel user is: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c Following the cleanup patches are a set of patches to fix various issues. The first five patches are intended to not make any functional changes, and are segrated to ease review. Version 3 applies on top of ac0f3e30d87e "of: overlay: fix memory leak related to duplicated property" Changes from version 2: - rebase on Rob's dt/next branch - 3/12: do missing renames in of_fill_overlay_info() so that 3/12 and 4/12 build. This function is removed in 5/12. Changes from version 1: - squash "[PATCH] of: overlay: move resolve phandles into of_overlay_apply()" into "[PATCH 09/12] of: overlay: avoid race condition between applying multiple overlays" Frank Rowand (12): of: overlay.c: Remove comments that state the obvious, to reduce clutter of: overlay.c: Convert comparisons to zero or NULL to logical expressions of: overlay: rename identifiers to more reflect what they do of: overlay: rename identifiers in dup_and_fixup_symbol_prop() of: overlay: minor restructuring of: overlay: detect cases where device tree may become corrupt of: overlay: expand check of whether overlay changeset can be removed of: overlay: loosen overly strict phandle clash check of: overlay: avoid race condition between applying multiple overlays of: overlay: simplify applying symbols from an overlay of: overlay: remove a dependency on device node full_name of: overlay: remove unneeded check for NULL kbasename() Documentation/devicetree/overlay-notes.txt | 12 +- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 14 +- drivers/of/base.c|2 +- drivers/of/dynamic.c | 137 +++- drivers/of/of_private.h | 22 +- drivers/of/overlay.c | 1042 -- drivers/of/resolver.c|7 + drivers/of/unittest.c| 81 +- include/linux/of.h | 17 +- 9 files changed, 874 insertions(+), 460 deletions(-) -- Frank Rowand ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm: Move debug macros out of drmP.h
On Tue, Oct 17, 2017 at 03:54:13PM -0400, Sean Paul wrote:
> On Tue, Oct 17, 2017 at 02:43:38AM -0600, Haneen Mohammed wrote:
> > This patch extract DRM_* debug macros from drmP.h to drm_print.h and
> > move printing related functions used by these macros from drm_drv.[hc]
> > to drm_print.[hc].
> >
> > Signed-off-by: Haneen Mohammed
> > ---
> > Changes in v3:
> > - Move debug macros and print functions into drm_print.[hc] instead of
> > introducing drm_debug.[hc].
> >
> > drivers/gpu/drm/drm_drv.c | 47 -
> > drivers/gpu/drm/drm_print.c | 47 +
> > include/drm/drmP.h | 150
> > +-
> > include/drm/drm_drv.h | 7 --
> > include/drm/drm_print.h | 156
> >
> > 5 files changed, 204 insertions(+), 203 deletions(-)
> >
>
>
>
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 7277783a..2ba73ff4 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -75,6 +75,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -142,160 +143,11 @@ struct pci_controller;
> > /*@{*/
> >
>
> Any reason why you didn't move the DRM_UT_* defines as well? They're sprinkled
> through a couple drivers, but it's all related to debug messaging.
>
> Sean
>
No, I didn't know they are specifically related to debug messaging.
I will include them then in a revised patch.
Thank you,
Haneen
> > /***/
> > -/** \name Macros to make printk easier */
> > -/*@{*/
> > -
> > -#define _DRM_PRINTK(once, level, fmt, ...) \
> > - do {\
> > - printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
> > -##__VA_ARGS__);\
> > - } while (0)
> > -
> > -#define DRM_INFO(fmt, ...) \
> > - _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
> > -#define DRM_NOTE(fmt, ...) \
> > - _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
> > -#define DRM_WARN(fmt, ...) \
> > - _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
> > -
> > -#define DRM_INFO_ONCE(fmt, ...)
> > \
> > - _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
> > -#define DRM_NOTE_ONCE(fmt, ...)
> > \
> > - _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
> > -#define DRM_WARN_ONCE(fmt, ...)
> > \
> > - _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
> > -
> > -/**
> > - * Error output.
> > - *
> > - * \param fmt printf() like format string.
> > - * \param arg arguments
> > - */
> > -#define DRM_DEV_ERROR(dev, fmt, ...)
> > \
> > - drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
> > - fmt, ##__VA_ARGS__)
> > -#define DRM_ERROR(fmt, ...)
> > \
> > - drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__)
> > -
> > -/**
> > - * Rate limited error output. Like DRM_ERROR() but won't flood the log.
> > - *
> > - * \param fmt printf() like format string.
> > - * \param arg arguments
> > - */
> > -#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
> > -({ \
> > - static DEFINE_RATELIMIT_STATE(_rs, \
> > - DEFAULT_RATELIMIT_INTERVAL, \
> > - DEFAULT_RATELIMIT_BURST); \
> > - \
> > - if (__ratelimit(&_rs)) \
> > - DRM_DEV_ERROR(dev, fmt, ##__VA_ARGS__); \
> > -})
> > -#define DRM_ERROR_RATELIMITED(fmt, ...)
> > \
> > - DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
> > -
> > -#define DRM_DEV_INFO(dev, fmt, ...)
> > \
> > - drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt, \
> > - ##__VA_ARGS__)
> > -
> > -#define DRM_DEV_INFO_ONCE(dev, fmt, ...) \
> > -({ \
> > - static bool __print_once __read_mostly; \
> > - if (!__print_once) {\
> > - __print_once = true;\
> > - DRM_DEV_INFO(dev, fmt, ##__VA_ARGS__); \
> > - } \
> > -})
> > -
> > -/**
> > - * Debug output.
> > - *
> > - * \pa
[PATCH v3 1/2] drm: Move debug macros out of drmP.h
This patch extract DRM_* debug macros from drmP.h to drm_print.h and
move printing related functions used by these macros from drm_drv.[hc]
to drm_print.[hc].
Signed-off-by: Haneen Mohammed
---
Changes in v3:
- Move debug macros and print functions into drm_print.[hc] instead of
introducing drm_debug.[hc].
drivers/gpu/drm/drm_drv.c | 47 -
drivers/gpu/drm/drm_print.c | 47 +
include/drm/drmP.h | 150 +-
include/drm/drm_drv.h | 7 --
include/drm/drm_print.h | 156
5 files changed, 204 insertions(+), 203 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index be38ac7..9710c78 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -74,53 +74,6 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
-
-void drm_dev_printk(const struct device *dev, const char *level,
- unsigned int category, const char *function_name,
- const char *prefix, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- if (category != DRM_UT_NONE && !(drm_debug & category))
- return;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- if (dev)
- dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
- &vaf);
- else
- printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_dev_printk);
-
-void drm_printk(const char *level, unsigned int category,
- const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- if (category != DRM_UT_NONE && !(drm_debug & category))
- return;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- printk("%s" "[" DRM_NAME ":%ps]%s %pV",
- level, __builtin_return_address(0),
- strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_printk);
-
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 74c466a..0b3bf47 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -63,3 +63,50 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
va_end(args);
}
EXPORT_SYMBOL(drm_printf);
+
+#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
+
+void drm_dev_printk(const struct device *dev, const char *level,
+ unsigned int category, const char *function_name,
+ const char *prefix, const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+
+ va_start(args, format);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ if (dev)
+ dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
+ &vaf);
+ else
+ printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL(drm_dev_printk);
+
+void drm_printk(const char *level, unsigned int category,
+ const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+
+ va_start(args, format);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+ level, __builtin_return_address(0),
+ strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL(drm_printk);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7277783a..2ba73ff4 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -142,160 +143,11 @@ struct pci_controller;
/*@{*/
/***/
-/** \name Macros to make printk easier */
-/*@{*/
-
-#define _DRM_PRINTK(once, level, fmt, ...) \
- do {\
- printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
- } while (0)
-
-#define DRM_INFO(fmt, ...) \
- _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
-#define DRM_NOTE(fmt, ...) \
- _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
-#define DRM_WARN(fmt, ...)
Re: [PATCH v2 3/8] drm/fb-helper: Add simple init/fini functions
ah, yeah have to agree it was pretty tough figuring that out at first, I was pretty green with kernel space. But considering i just wrote a working linux DRM kernel driver with minimal knowledge of kernels or even really how embedded devices share memory resources... good job is all I have to say. anyway, what's one small layer of code abstraction when we're doing it all in the name of abstracting our code to non-existance at run-time? These DRM modules are all just directing each other where to find the resources, and since everyone knows what an image is made up of, it's a fairly small overhead to encapsulate across each barrier. I'd say split it up even more... for example there could be one module that directs the interface between SPI transport layers and graphic buffers/ux, and one that directs instructions/buffers/ux back and forth from userspace to the proper transport layer and proper rendering layer (which we seem to be missing... i'm sure it could be reused in any case where two devices on a separate bus need to communicate either directly to each other or to the rendering layers). I could have been pretty happy not even having to know what DMA was to code what was missing, which was just the spi transmission instructions. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/panel: simple: make it possible to override LCD bus format
Hi, On Tue, 17 Oct 2017 14:12:40 +0200 Thierry Reding wrote: > On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote: > > The baseboards for the Ka-Ro electronics series of i.MX modules > > use a 24bit LCD interface, no matter what LCD bus width the SoC on the > > module provides and what the LCD panel expects. LCDs with 6bit per color > > will ignore the 2 LSBs of each color lane, and modules using a SoC > > that provides only 6bit per color, drive the display information on the > > 6 MSBs of each color lane and tie the 2 LSBs of each color lane to GND. > > > > Thus, no matter what combination of LCD and SoC is used, the LCD port > > can be used without shuffling bit lanes by always configuring the LCD > > output to 24bit mode. > > > > Add a function to handle certain quirks of the LCD interface to the > > panel driver to be able to override the bus format specified in a > > panel's display_mode. > > I think the above paragraph clearly indicates that this is the wrong > place to workaround this. You say yourself that the LCD interface has > quirks that need to be handled, so why do you want to force this > handling into the panel driver? > The quirk is in the interfacing of the SoM's LCD output to the LCD panel. Thus it can be handled in either place. > The panel remains the same, no matter what interface you connect it to. > Because that's just ONE place to change, no matter what LCD driver is being used. Lothar Waßmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm/print: Update old comment style
Remove old comment style used by doxygen.
And remove comment left from commit 99cdb35e787b ("drm/doc: move printf
helpers out of drmP.h") after refactoring drmP.h.
Signed-off-by: Haneen Mohammed
---
Changes in v3:
- nothing
include/drm/drm_print.h | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 9dacc5e..d208a85 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -136,9 +136,8 @@ void drm_dev_printk(const struct device *dev, const char
*level,
__printf(3, 4)
void drm_printk(const char *level, unsigned int category,
const char *format, ...);
-/***/
-/** \name Macros to make printk easier */
-/*@{*/
+
+/* Macros to make printk easier */
#define _DRM_PRINTK(once, level, fmt, ...) \
do {\
@@ -163,8 +162,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Error output.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_ERROR(dev, fmt, ...) \
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
@@ -175,8 +174,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) \
({ \
@@ -206,8 +205,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Debug output.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
@@ -258,8 +257,8 @@ void drm_printk(const char *level, unsigned int category,
/**
* Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
*
- * \param fmt printf() like format string.
- * \param arg arguments
+ * @dev: device pointer
+ * @fmt: printf() like format string.
*/
#define DRM_DEV_DEBUG_RATELIMITED(dev, fmt, args...) \
DEV__DRM_DEFINE_DEBUG_RATELIMITED(dev, CORE, fmt, ##args)
@@ -278,10 +277,4 @@ void drm_printk(const char *level, unsigned int category,
#define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...) \
DRM_DEV_DEBUG_PRIME_RATELIMITED(NULL, fmt, ##args)
-/* Format strings and argument splitters to simplify printing
- * various "complex" objects
- */
-
-/*@}*/
-
#endif /* DRM_PRINT_H_ */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/amd/powerplay: Don't cast kzalloc() return value
The kzalloc function returns a void pointer and the assignment operator converts it to the type of pointer it is assigned to. Therefore, there is no need to cast. Issue found by alloc_cast.cocci: * WARNING: casting value returned by memory allocation function to is useless. Path to the cocci script: scripts/coccinelle/api/alloc/alloc_cast.cocci Signed-off-by: Georgiana Chelu --- Changes in v2: * adjusted the subject prefix of the patches * added the cocci script used to generate the patches .../amd/powerplay/hwmgr/vega10_processpptables.c | 24 -- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c index e343df190375..d968c3834481 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c @@ -291,8 +291,7 @@ static int get_mm_clock_voltage_table( table_size = sizeof(uint32_t) + sizeof(phm_ppt_v1_mm_clock_voltage_dependency_record) * mm_dependency_table->ucNumEntries; - mm_table = (phm_ppt_v1_mm_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + mm_table = kzalloc(table_size, GFP_KERNEL); if (!mm_table) return -ENOMEM; @@ -519,8 +518,7 @@ static int get_socclk_voltage_dependency_table( sizeof(phm_ppt_v1_clock_voltage_dependency_record) * clk_dep_table->ucNumEntries; - clk_table = (phm_ppt_v1_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + clk_table = kzalloc(table_size, GFP_KERNEL); if (!clk_table) return -ENOMEM; @@ -554,8 +552,7 @@ static int get_mclk_voltage_dependency_table( sizeof(phm_ppt_v1_clock_voltage_dependency_record) * mclk_dep_table->ucNumEntries; - mclk_table = (phm_ppt_v1_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + mclk_table = kzalloc(table_size, GFP_KERNEL); if (!mclk_table) return -ENOMEM; @@ -596,8 +593,7 @@ static int get_gfxclk_voltage_dependency_table( sizeof(phm_ppt_v1_clock_voltage_dependency_record) * clk_dep_table->ucNumEntries; - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + clk_table = kzalloc(table_size, GFP_KERNEL); if (!clk_table) return -ENOMEM; @@ -663,8 +659,7 @@ static int get_pix_clk_voltage_dependency_table( sizeof(phm_ppt_v1_clock_voltage_dependency_record) * clk_dep_table->ucNumEntries; - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + clk_table = kzalloc(table_size, GFP_KERNEL); if (!clk_table) return -ENOMEM; @@ -728,8 +723,7 @@ static int get_dcefclk_voltage_dependency_table( sizeof(phm_ppt_v1_clock_voltage_dependency_record) * num_entries; - clk_table = (struct phm_ppt_v1_clock_voltage_dependency_table *) - kzalloc(table_size, GFP_KERNEL); + clk_table = kzalloc(table_size, GFP_KERNEL); if (!clk_table) return -ENOMEM; @@ -772,8 +766,7 @@ static int get_pcie_table(struct pp_hwmgr *hwmgr, sizeof(struct phm_ppt_v1_pcie_record) * atom_pcie_table->ucNumEntries; - pcie_table = (struct phm_ppt_v1_pcie_table *) - kzalloc(table_size, GFP_KERNEL); + pcie_table = kzalloc(table_size, GFP_KERNEL); if (!pcie_table) return -ENOMEM; @@ -1026,8 +1019,7 @@ static int get_vddc_lookup_table( table_size = sizeof(uint32_t) + sizeof(phm_ppt_v1_voltage_lookup_record) * max_levels; - table = (phm_ppt_v1_voltage_lookup_table *) - kzalloc(table_size, GFP_KERNEL); + table = kzalloc(table_size, GFP_KERNEL); if (NULL == table) return -ENOMEM; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/12] of: overlay.c: Remove comments that state the obvious, to reduce clutter
From: Frank Rowand
Follows recommendations in Documentation/process/coding-style.rst,
section 8, Commenting.
Some in function comments are promoted to function header comments.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 47 ++-
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index af3b9a16df26..a42dd7b094c4 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -143,7 +143,6 @@ static struct property *dup_and_fixup_symbol_prop(struct
of_overlay *ov,
strcpy(new->value, target_path);
strcpy(new->value + target_path_len, label_path);
- /* mark the property as dynamic */
of_property_set_flag(new, OF_DYNAMIC);
return new;
@@ -157,6 +156,10 @@ static struct property *dup_and_fixup_symbol_prop(struct
of_overlay *ov,
}
+/*
+ * Some special properties are not updated (no error returned).
+ * Update of property in symbols node is not allowed.
+ */
static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop,
bool is_symbols_node)
@@ -164,17 +167,14 @@ static int of_overlay_apply_single_property(struct
of_overlay *ov,
struct property *propn = NULL, *tprop;
int ret = 0;
- /* NOTE: Multiple changes of single properties not supported */
tprop = of_find_property(target, prop->name, NULL);
- /* special properties are not meant to be updated (silent NOP) */
if (of_prop_cmp(prop->name, "name") == 0 ||
of_prop_cmp(prop->name, "phandle") == 0 ||
of_prop_cmp(prop->name, "linux,phandle") == 0)
return 0;
if (is_symbols_node) {
- /* changing a property in __symbols__ node not allowed */
if (tprop)
return -EINVAL;
propn = dup_and_fixup_symbol_prop(ov, prop);
@@ -185,10 +185,9 @@ static int of_overlay_apply_single_property(struct
of_overlay *ov,
if (propn == NULL)
return -ENOMEM;
- /* not found? add */
if (tprop == NULL)
ret = of_changeset_add_property(&ov->cset, target, propn);
- else /* found? update */
+ else
ret = of_changeset_update_property(&ov->cset, target, propn);
if (ret) {
@@ -210,13 +209,11 @@ static int of_overlay_apply_single_device_node(struct
of_overlay *ov,
if (cname == NULL)
return -ENOMEM;
- /* NOTE: Multiple mods of created nodes not supported */
for_each_child_of_node(target, tchild)
if (!of_node_cmp(cname, kbasename(tchild->full_name)))
break;
if (tchild != NULL) {
- /* new overlay phandle value conflicts with existing value */
if (child->phandle)
return -EINVAL;
@@ -224,12 +221,10 @@ static int of_overlay_apply_single_device_node(struct
of_overlay *ov,
ret = of_overlay_apply_one(ov, tchild, child, 0);
of_node_put(tchild);
} else {
- /* create empty tree as a target */
tchild = __of_node_dup(child, "%pOF/%s", target, cname);
if (!tchild)
return -ENOMEM;
- /* point to parent */
tchild->parent = target;
ret = of_changeset_attach_node(&ov->cset, tchild);
@@ -250,6 +245,8 @@ static int of_overlay_apply_single_device_node(struct
of_overlay *ov,
* Note that the in case of an error the target node is left
* in a inconsistent state. Error recovery should be performed
* by using the changeset.
+ *
+ * Do not allow symbols node to have any children.
*/
static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay,
@@ -269,7 +266,6 @@ static int of_overlay_apply_one(struct of_overlay *ov,
}
}
- /* do not allow symbols node to have any children */
if (is_symbols_node)
return 0;
@@ -299,7 +295,6 @@ static int of_overlay_apply(struct of_overlay *ov)
{
int i, err;
- /* first we apply the overlays atomically */
for (i = 0; i < ov->count; i++) {
struct of_overlay_info *ovinfo = &ov->ovinfo_tab[i];
@@ -316,10 +311,10 @@ static int of_overlay_apply(struct of_overlay *ov)
/*
* Find the target node using a number of different strategies
- * in order of preference
+ * in order of preference:
*
- * "target" property containing the phandle of the target
- * "target-path" property containing the path of the target
+ * 1) "target" property containing the phandle of the target
+ * 2) "target-path" property containing the path of the target
*/
static struct device_node *find_target_node(struct device_node *info_node)
{
@@ -
Re: [PATCH v6 1/2] drm_fourcc: Add new P010, P016 video format
On 10/12/2017 07:56 PM, Tapani Pälli wrote:
Is this one going to land soon? The discussion was a bit hard to read
but it looks like in the end consensus was that everything looks good
in this patch.
I am very sorry, I am too busy with the other dma problem in rockchip.
The main problem is that none of the driver have used those format.
Although the rockchip vop supports 10 bit pixel format but not the p010.
Thanks;
On 03/01/2017 01:21 AM, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..3e0fd58 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,9 @@ const struct drm_format_info
*__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY, .depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes
= 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_P010, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016, .depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h
b/include/uapi/drm/drm_fourcc.h
index ef20abb..762646d 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /*
2x2 subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /*
2x2 subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /*
2x2 subsampled Cr:Cb plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/amd/powerplay: Place the constant on the right side of the test
Move the constant on the right side of the comparison in order to make the code easier to read. Issue found by checkpatch script: * WARNING: Comparisons should place the constant on the right side of the test Signed-off-by: Georgiana Chelu --- Changes in v2: * adjusted the subject prefix of the patches drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c index 769ac11a9215..f14c7611fad3 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c @@ -1021,7 +1021,7 @@ static int get_vddc_lookup_table( table = kzalloc(table_size, GFP_KERNEL); - if (NULL == table) + if (table == NULL) return -ENOMEM; table->count = vddc_lookup_pp_tables->ucNumEntries; @@ -1130,12 +1130,12 @@ int vega10_pp_tables_initialize(struct pp_hwmgr *hwmgr) hwmgr->pptable = kzalloc(sizeof(struct phm_ppt_v2_information), GFP_KERNEL); - PP_ASSERT_WITH_CODE((NULL != hwmgr->pptable), + PP_ASSERT_WITH_CODE((hwmgr->pptable != NULL), "Failed to allocate hwmgr->pptable!", return -ENOMEM); powerplay_table = get_powerplay_table(hwmgr); - PP_ASSERT_WITH_CODE((NULL != powerplay_table), + PP_ASSERT_WITH_CODE((powerplay_table != NULL), "Missing PowerPlay Table!", return -1); result = check_powerplay_tables(hwmgr, powerplay_table); @@ -1229,7 +1229,7 @@ int vega10_get_number_of_powerplay_table_entries(struct pp_hwmgr *hwmgr) const ATOM_Vega10_State_Array *state_arrays; const ATOM_Vega10_POWERPLAYTABLE *pp_table = get_powerplay_table(hwmgr); - PP_ASSERT_WITH_CODE((NULL != pp_table), + PP_ASSERT_WITH_CODE((pp_table != NULL), "Missing PowerPlay Table!", return -1); PP_ASSERT_WITH_CODE((pp_table->sHeader.format_revision >= ATOM_Vega10_TABLE_REVISION_VEGA10), -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_kms_helper cycle detected build error in next
* Daniel Vetter [171017 05:09]: > On Mon, Oct 16, 2017 at 07:35:24AM -0700, Tony Lindgren wrote: > > > > Meanwhile, can you guys provide few more clues which patch to pick > > for the rest of us? > > > > Something like patch subject line, commit id in drm-misc or something > > along those lines would be nice.. > > I guess linux-next still not yet back to the daily update schedule, that's > why you need this? It's been in trees since last week, and now also in > drm-next ... Usually no one ever cares about the commit if we fix it right > away. > > Anyway > > commit 512721a14a2a94b48ca0863d48f9829922a816b8 > Author: Maarten Lankhorst > Date: Fri Oct 13 16:08:53 2017 +0200 > > drm/drm_of: Move drm_of_panel_bridge_remove_function into header. OK thanks looks like Linux next is building for me again now. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/2] drm: Move debug macros out of drmP.h
This patchset move debug macros from drmP.h to drm_print.h and move printing related functions used by the debug macros from drm_drv.[hc] to drm_print.[hc]. In addition, it fixes old comment style. Changes in v3: - Move debug macros and print functions into drm_print.[hc] instead of introducing drm_debug.[hc]. Haneen Mohammed (2): drm: Move debug macros out of drmP.h drm/print: Update old comment style drivers/gpu/drm/drm_drv.c | 47 -- drivers/gpu/drm/drm_print.c | 47 ++ include/drm/drmP.h | 150 +--- include/drm/drm_drv.h | 7 --- include/drm/drm_print.h | 149 +++ 5 files changed, 197 insertions(+), 203 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/12] of: overlay: detect cases where device tree may become corrupt
From: Frank Rowand
When an attempt to apply an overlay changeset fails, an effort
is made to revert any partial application of the changeset.
When an attempt to remove an overlay changeset fails, an effort
is made to re-apply any partial reversion of the changeset.
The existing code does not check for failure to recover a failed
overlay changeset application or overlay changeset revert.
Add the missing checks and flag the devicetree as corrupt if the
state of the devicetree can not be determined.
Improve and expand the returned errors to more fully reflect the
result of the effort to undo the partial effects of a failed attempt
to apply or remove an overlay changeset.
If the device tree might be corrupt, do not allow further attempts
to apply or remove an overlay changeset.
When creating an overlay changeset from an overlay device tree,
add some additional warnings if the state of the overlay device
tree is not as expected.
Signed-off-by: Frank Rowand
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 5 +-
drivers/of/dynamic.c | 135 +++---
drivers/of/of_private.h | 8 +-
drivers/of/overlay.c | 253 ++-
drivers/of/unittest.c| 57 +++---
include/linux/of.h | 10 +-
6 files changed, 372 insertions(+), 96 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index 5f5b7ba35f1d..7a7be0515bfd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -204,7 +204,7 @@ static void __init tilcdc_convert_slave_node(void)
/* For all memory needed for the overlay tree. This memory can
be freed after the overlay has been applied. */
struct kfree_table kft;
- int ret;
+ int ovcs_id, ret;
if (kfree_table_init(&kft))
return;
@@ -247,7 +247,8 @@ static void __init tilcdc_convert_slave_node(void)
tilcdc_node_disable(slave);
- ret = of_overlay_apply(overlay);
+ ovcs_id = 0;
+ ret = of_overlay_apply(overlay, &ovcs_id);
if (ret)
pr_err("%s: Applying overlay changeset failed: %d\n",
__func__, ret);
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 4bc96af4d8e2..747d87619faf 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -491,11 +491,12 @@ static void __of_changeset_entry_invert(struct
of_changeset_entry *ce,
}
}
-static void __of_changeset_entry_notify(struct of_changeset_entry *ce, bool
revert)
+static int __of_changeset_entry_notify(struct of_changeset_entry *ce,
+ bool revert)
{
struct of_reconfig_data rd;
struct of_changeset_entry ce_inverted;
- int ret;
+ int ret = 0;
if (revert) {
__of_changeset_entry_invert(ce, &ce_inverted);
@@ -517,11 +518,12 @@ static void __of_changeset_entry_notify(struct
of_changeset_entry *ce, bool reve
default:
pr_err("invalid devicetree changeset action: %i\n",
(int)ce->action);
- return;
+ ret = -EINVAL;
}
if (ret)
pr_err("changeset notifier error @%pOF\n", ce->np);
+ return ret;
}
static int __of_changeset_entry_apply(struct of_changeset_entry *ce)
@@ -655,32 +657,82 @@ void of_changeset_destroy(struct of_changeset *ocs)
}
EXPORT_SYMBOL_GPL(of_changeset_destroy);
-int __of_changeset_apply(struct of_changeset *ocs)
+/*
+ * Apply the changeset entries in @ocs.
+ * If apply fails, an attempt is made to revert the entries that were
+ * successfully applied.
+ *
+ * If multiple revert errors occur then only the final revert error is
reported.
+ *
+ * Returns 0 on success, a negative error value in case of an error.
+ * If a revert error occurs, it is returned in *ret_revert.
+ */
+int __of_changeset_apply_entries(struct of_changeset *ocs, int *ret_revert)
{
struct of_changeset_entry *ce;
- int ret;
+ int ret, ret_tmp;
- /* perform the rest of the work */
pr_debug("changeset: applying...\n");
list_for_each_entry(ce, &ocs->entries, node) {
ret = __of_changeset_entry_apply(ce);
if (ret) {
pr_err("Error applying changeset (%d)\n", ret);
- list_for_each_entry_continue_reverse(ce, &ocs->entries,
node)
- __of_changeset_entry_revert(ce);
+ list_for_each_entry_continue_reverse(ce, &ocs->entries,
+node) {
+ ret_tmp = __of_changeset_entry_revert(ce);
+ if (ret_tmp)
+ *ret_revert = ret_tmp;
+ }
[PATCH v4 1/2] drm: Move debug macros out of drmP.h
This patch extract DRM_* debug macros from drmP.h to drm_print.h and
move printing related functions used by these macros from drm_drv.[hc]
to drm_print.[hc].
Signed-off-by: Haneen Mohammed
---
Changes in v4:
- Move DRM_UT_ debug messaging macros from drmP.h to drm_print.h.
drivers/gpu/drm/drm_drv.c | 47 ---
drivers/gpu/drm/drm_print.c | 47 +++
include/drm/drmP.h | 193 +-
include/drm/drm_drv.h | 7 --
include/drm/drm_print.h | 199
5 files changed, 247 insertions(+), 246 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index be38ac7..9710c78 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -74,53 +74,6 @@ static bool drm_core_init_complete = false;
static struct dentry *drm_debugfs_root;
-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
-
-void drm_dev_printk(const struct device *dev, const char *level,
- unsigned int category, const char *function_name,
- const char *prefix, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- if (category != DRM_UT_NONE && !(drm_debug & category))
- return;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- if (dev)
- dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
- &vaf);
- else
- printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_dev_printk);
-
-void drm_printk(const char *level, unsigned int category,
- const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- if (category != DRM_UT_NONE && !(drm_debug & category))
- return;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- printk("%s" "[" DRM_NAME ":%ps]%s %pV",
- level, __builtin_return_address(0),
- strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
-
- va_end(args);
-}
-EXPORT_SYMBOL(drm_printk);
-
/*
* DRM Minors
* A DRM device can provide several char-dev interfaces on the DRM-Major. Each
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 74c466a..0b3bf47 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -63,3 +63,50 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
va_end(args);
}
EXPORT_SYMBOL(drm_printf);
+
+#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
+
+void drm_dev_printk(const struct device *dev, const char *level,
+ unsigned int category, const char *function_name,
+ const char *prefix, const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+
+ va_start(args, format);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ if (dev)
+ dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
+ &vaf);
+ else
+ printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL(drm_dev_printk);
+
+void drm_printk(const char *level, unsigned int category,
+ const char *format, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ if (category != DRM_UT_NONE && !(drm_debug & category))
+ return;
+
+ va_start(args, format);
+ vaf.fmt = format;
+ vaf.va = &args;
+
+ printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+ level, __builtin_return_address(0),
+ strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", &vaf);
+
+ va_end(args);
+}
+EXPORT_SYMBOL(drm_printk);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7277783a..ccd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -75,6 +75,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,208 +95,16 @@ struct dma_buf_attachment;
struct pci_dev;
struct pci_controller;
-/*
- * The following categories are defined:
- *
- * CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c, drm_memory.c, ...
- * This is the category used by the DRM_DEBUG() macro.
- *
- * DRIVER: Used in the vendor specific part of the driver: i915, radeon, ...
- *This is the category used by the DRM_DEBUG_DRIVER() macro.
- *
- * KMS: used in the modesetting code.
- * This is the category used by the DRM_DEBUG_KMS() macro.
- *
- * PRIME: used in the prime code.
- * This is the category used by the DRM_DEBUG_PRIME() macro.
- *
- * ATOMIC: used in the atomic code.
- * This is the category used by the DRM_DEBUG_ATOMIC() macro.
- *
- * VBL: used for verbose debug message in the vblank code
- *
Re: [PATCH 2/9] drm/panel: simple: simplify display_mode definitions by using macro
Hi,
On Tue, 17 Oct 2017 15:08:31 +0200 Thierry Reding wrote:
> On Tue, Oct 17, 2017 at 03:05:16PM +0200, Lothar Waßmann wrote:
> > Hi,
> >
> > On Tue, 17 Oct 2017 14:09:37 +0200 Thierry Reding wrote:
> > > On Wed, Oct 11, 2017 at 01:23:34PM +0200, Lothar Waßmann wrote:
> > > > Use the newly defined macro to generate the display_mode data entries
> > > > for all panels. This reduces the code size significantly and makes the
> > > > code more readable.
> > > >
> > > > Signed-off-by: Lothar Waßmann
> > > > ---
> > > > drivers/gpu/drm/panel/panel-simple.c | 799
> > > > ++-
> > > > 1 file changed, 134 insertions(+), 665 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > index dec639d..fde9c41 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -89,6 +89,20 @@ struct panel_simple {
> > > > struct gpio_desc *enable_gpio;
> > > > };
> > > >
> > > > +#define SP_DISPLAY_MODE(freq, ha, hfp, hs, hbp, va, vfp, vs, vbp, vr,
> > > > flgs) { \
> > > > + .clock = freq,
> > > > \
> > > > + .hdisplay = ha,
> > > > \
> > > > + .hsync_start = (ha) + (hfp),
> > > > \
> > > > + .hsync_end = (ha) + (hfp) + (hs),
> > > > \
> > > > + .htotal = (ha) + (hfp) + (hs) + (hbp),
> > > > \
> > > > + .vdisplay = (va),
> > > > \
> > > > + .vsync_start = (va) + (vfp),
> > > > \
> > > > + .vsync_end = (va) + (vfp) + (vs),
> > > > \
> > > > + .vtotal = (va) + (vfp) + (vs) + (vbp),
> > > > \
> > > > + .vrefresh = vr,
> > > > \
> > > > + .flags = flgs,
> > > > \
> > > > +}
> > > > +
> > > > static inline struct panel_simple *to_panel_simple(struct drm_panel
> > > > *panel)
> > > > {
> > > > return container_of(panel, struct panel_simple, base);
> > > [...]
> > > > @@ -411,33 +415,9 @@ static const struct panel_desc
> > > > ampire_am_480272h3tmqw_t01h = {
> > > > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > > > };
> > > >
> > > > -#define SP_DISPLAY_MODE(freq, ha, hfp, hs, hbp, va, vfp, vs, vbp, vr,
> > > > flgs) { \
> > > > - .clock = freq,
> > > > \
> > > > - .hdisplay = ha,
> > > > \
> > > > - .hsync_start = (ha) + (hfp),
> > > > \
> > > > - .hsync_end = (ha) + (hfp) + (hs),
> > > > \
> > > > - .htotal = (ha) + (hfp) + (hs) + (hbp),
> > > > \
> > > > - .vdisplay = (va),
> > > > \
> > > > - .vsync_start = (va) + (vfp),
> > > > \
> > > > - .vsync_end = (va) + (vfp) + (vs),
> > > > \
> > > > - .vtotal = (va) + (vfp) + (vs) + (vbp),
> > > > \
> > > > - .vrefresh = vr,
> > > > \
> > > > - .flags = flgs,
> > > > \
> > > > - }
> > >
> > > Your first patch should put this in the right place to begin with so
> > > that this patch is really just the conversion.
> > >
> > > Again, I don't think this macro actually improves the way modes are
> > > defined.
> > >
> > I'm not happy with this panel driver stuff anyway. With the legacy
> > 'display-timings' node that provided the timing data directly in the
> > DTB, every bootloader could pick up the timing data and feed it to
> > whatever driver it used for the display.
> > With the panel driver stuff the whole Linux driver has to be replicated
> > in the boot loader in order to be able to use the same DTB as Linux for
> > its HW configuration.
> > And adding a new panel involves recompiling the kernel and the boot
> > loader, rather than adding the timing data from the panel's datasheet
> > into the DTB.
>
> This isn't the first time I've heard this. Please read this for more
> background information on why the situation is what it is:
>
>
> http://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html
>
Thanks for the link. That's what I have been looking for already for
some time but couldn't find any references to.
Lothar Waßmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
[PATCH v3 02/12] of: overlay.c: Convert comparisons to zero or NULL to logical expressions
From: Frank Rowand
Use normal shorthand for comparing a variable to zero.
For variable "XXX":
convert (XXX == 0) to (!XXX)
convert (XXX != 0) to (XXX)
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index a42dd7b094c4..d3f4a5974a11 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -169,9 +169,9 @@ static int of_overlay_apply_single_property(struct
of_overlay *ov,
tprop = of_find_property(target, prop->name, NULL);
- if (of_prop_cmp(prop->name, "name") == 0 ||
- of_prop_cmp(prop->name, "phandle") == 0 ||
- of_prop_cmp(prop->name, "linux,phandle") == 0)
+ if (!of_prop_cmp(prop->name, "name") ||
+ !of_prop_cmp(prop->name, "phandle") ||
+ !of_prop_cmp(prop->name, "linux,phandle"))
return 0;
if (is_symbols_node) {
@@ -182,10 +182,10 @@ static int of_overlay_apply_single_property(struct
of_overlay *ov,
propn = __of_prop_dup(prop, GFP_KERNEL);
}
- if (propn == NULL)
+ if (!propn)
return -ENOMEM;
- if (tprop == NULL)
+ if (!tprop)
ret = of_changeset_add_property(&ov->cset, target, propn);
else
ret = of_changeset_update_property(&ov->cset, target, propn);
@@ -206,14 +206,14 @@ static int of_overlay_apply_single_device_node(struct
of_overlay *ov,
int ret = 0;
cname = kbasename(child->full_name);
- if (cname == NULL)
+ if (!cname)
return -ENOMEM;
for_each_child_of_node(target, tchild)
if (!of_node_cmp(cname, kbasename(tchild->full_name)))
break;
- if (tchild != NULL) {
+ if (tchild) {
if (child->phandle)
return -EINVAL;
@@ -271,7 +271,7 @@ static int of_overlay_apply_one(struct of_overlay *ov,
for_each_child_of_node(overlay, child) {
ret = of_overlay_apply_single_device_node(ov, target, child);
- if (ret != 0) {
+ if (ret) {
pr_err("Failed to apply single node @%pOF/%s\n",
target, child->name);
of_node_put(child);
@@ -300,7 +300,7 @@ static int of_overlay_apply(struct of_overlay *ov)
err = of_overlay_apply_one(ov, ovinfo->target, ovinfo->overlay,
ovinfo->is_symbols_node);
- if (err != 0) {
+ if (err) {
pr_err("apply failed '%pOF'\n", ovinfo->target);
return err;
}
@@ -323,11 +323,11 @@ static struct device_node *find_target_node(struct
device_node *info_node)
int ret;
ret = of_property_read_u32(info_node, "target", &val);
- if (ret == 0)
+ if (!ret)
return of_find_node_by_phandle(val);
ret = of_property_read_string(info_node, "target-path", &path);
- if (ret == 0)
+ if (!ret)
return of_find_node_by_path(path);
pr_err("Failed to find target for node %p (%s)\n",
@@ -354,11 +354,11 @@ static int of_fill_overlay_info(struct of_overlay *ov,
struct device_node *info_node, struct of_overlay_info *ovinfo)
{
ovinfo->overlay = of_get_child_by_name(info_node, "__overlay__");
- if (ovinfo->overlay == NULL)
+ if (!ovinfo->overlay)
goto err_fail;
ovinfo->target = find_target_node(info_node);
- if (ovinfo->target == NULL)
+ if (!ovinfo->target)
goto err_fail;
return 0;
@@ -398,13 +398,13 @@ static int of_build_overlay_info(struct of_overlay *ov,
cnt++;
ovinfo = kcalloc(cnt, sizeof(*ovinfo), GFP_KERNEL);
- if (ovinfo == NULL)
+ if (!ovinfo)
return -ENOMEM;
cnt = 0;
for_each_child_of_node(tree, node) {
err = of_fill_overlay_info(ov, node, &ovinfo[cnt]);
- if (err == 0)
+ if (!err)
cnt++;
}
@@ -422,7 +422,7 @@ static int of_build_overlay_info(struct of_overlay *ov,
cnt++;
}
- if (cnt == 0) {
+ if (!cnt) {
kfree(ovinfo);
return -ENODEV;
}
@@ -478,7 +478,7 @@ int of_overlay_create(struct device_node *tree)
int err, id;
ov = kzalloc(sizeof(*ov), GFP_KERNEL);
- if (ov == NULL)
+ if (!ov)
return -ENOMEM;
ov->id = -1;
@@ -629,7 +629,7 @@ int of_overlay_destroy(int id)
mutex_lock(&of_mutex);
ov = idr_find(&ov_idr, id);
- if (ov == NULL) {
+ if (!ov) {
err = -ENODEV;
pr_err("destroy: Could not find overlay
[PATCH v2 0/3] drm/amd/powerplay: Fix coccinelle and checkpatch issues
The first two patches fix coccinelle issues and the last patch fix a checkpatch issue. First patch: The return value of kzalloc does not need a cast because the assignment operator will take care of this. Second patch: The 'result' variable does not change its value until the end of the function. Instead of using the variable, return its default value. Third patch: Placing the constant on the right side will make the code easier to read, as most of the people read from right to left. Changes in v2: * adjusted the subject prefix of the patches * added the cocci script used to generate the patches Georgiana Chelu (3): drm/amd/powerplay: Don't cast kzalloc() return value drm/amd/powerplay: Remove useless variable drm/amd/powerplay: Place the constant on the right side of the test .../amd/powerplay/hwmgr/vega10_processpptables.c | 35 -- 1 file changed, 13 insertions(+), 22 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/12] of: overlay: loosen overly strict phandle clash check
From: Frank Rowand When an overlay contains a node that already exists in the live device tree, the overlay node is not allowed to change the phandle of the existing node. The existing check refused to allow an overlay node to set the node phandle even when the existing node did not have a phandle. Relax the check to allow an overlay node to set the phandle value if the existing node does not have a phandle. Signed-off-by: Frank Rowand --- drivers/of/overlay.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c index 4cdee169a5ab..791753321ed2 100644 --- a/drivers/of/overlay.c +++ b/drivers/of/overlay.c @@ -311,10 +311,10 @@ static int add_changeset_node(struct overlay_changeset *ovcs, return build_changeset_next_level(ovcs, tchild, node, 0); } - if (node->phandle) - return -EINVAL; - - ret = build_changeset_next_level(ovcs, tchild, node, 0); + if (node->phandle && tchild->phandle) + ret = -EINVAL; + else + ret = build_changeset_next_level(ovcs, tchild, node, 0); of_node_put(tchild); return ret; -- Frank Rowand ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/12] of: overlay: simplify applying symbols from an overlay
From: Frank Rowand
The code to apply symbols from an overlay to the live device tree
was implemented with the intent to be minimally intrusive on the
existing code. After recent restructuring of the overlay apply
code, it is easier to disintangle the code that applies the
symbols, and to make the overlay changeset creation code more
straight forward and understandable.
Remove the extra complexity, and make the code more obvious.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 91 +---
1 file changed, 65 insertions(+), 26 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index d164f86e5541..602218e07ec3 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -32,21 +32,22 @@
struct fragment {
struct device_node *target;
struct device_node *overlay;
- bool is_symbols_node;
};
/**
* struct overlay_changeset
- * @ovcs_list: list on which we are located
- * @count: count of @fragments structures
- * @fragments: info about fragment nodes in overlay expanded device tree
- * @cset: changeset to apply fragments to live device tree
+ * @ovcs_list: list on which we are located
+ * @count: count of fragment structures
+ * @fragments: fragment nodes in the overlay expanded device tree
+ * @symbols_fragment: last element of @fragments[] is the __symbols__ node
+ * @cset: changeset to apply fragments to live device tree
*/
struct overlay_changeset {
int id;
struct list_head ovcs_list;
int count;
struct fragment *fragments;
+ bool symbols_fragment;
struct of_changeset cset;
};
@@ -68,8 +69,7 @@ static int devicetree_corrupt(void)
static int build_changeset_next_level(struct overlay_changeset *ovcs,
struct device_node *target_node,
- const struct device_node *overlay_node,
- bool is_symbols_node);
+ const struct device_node *overlay_node);
/*
* of_resolve_phandles() finds the largest phandle in the live tree.
@@ -221,7 +221,7 @@ static struct property *dup_and_fixup_symbol_prop(
* @ovcs: overlay changeset
* @target_node: where to place @overlay_prop in live tree
* @overlay_prop: property to add or update, from overlay tree
- * is_symbols_node:1 if @target_node is "/__symbols__"
+ * @is_symbols_prop: 1 if @overlay_prop is from node "/__symbols__"
*
* If @overlay_prop does not already exist in @target_node, add changeset entry
* to add @overlay_prop in @target_node, else add changeset entry to update
@@ -237,7 +237,7 @@ static struct property *dup_and_fixup_symbol_prop(
static int add_changeset_property(struct overlay_changeset *ovcs,
struct device_node *target_node,
struct property *overlay_prop,
- bool is_symbols_node)
+ bool is_symbols_prop)
{
struct property *new_prop = NULL, *prop;
int ret = 0;
@@ -249,7 +249,7 @@ static int add_changeset_property(struct overlay_changeset
*ovcs,
!of_prop_cmp(overlay_prop->name, "linux,phandle"))
return 0;
- if (is_symbols_node) {
+ if (is_symbols_prop) {
if (prop)
return -EINVAL;
new_prop = dup_and_fixup_symbol_prop(ovcs, overlay_prop);
@@ -330,13 +330,13 @@ static int add_changeset_node(struct overlay_changeset
*ovcs,
if (ret)
return ret;
- return build_changeset_next_level(ovcs, tchild, node, 0);
+ return build_changeset_next_level(ovcs, tchild, node);
}
if (node->phandle && tchild->phandle)
ret = -EINVAL;
else
- ret = build_changeset_next_level(ovcs, tchild, node, 0);
+ ret = build_changeset_next_level(ovcs, tchild, node);
of_node_put(tchild);
return ret;
@@ -347,7 +347,6 @@ static int add_changeset_node(struct overlay_changeset
*ovcs,
* @ovcs: overlay changeset
* @target_node: where to place @overlay_node in live tree
* @overlay_node: node from within an overlay device tree fragment
- * @is_symbols_node: @overlay_node is node "/__symbols__"
*
* Add the properties (if any) and nodes (if any) from @overlay_node to the
* @ovcs->cset changeset. If an added node has child nodes, they will
@@ -360,16 +359,14 @@ static int add_changeset_node(struct overlay_changeset
*ovcs,
*/
static int build_changeset_next_level(struct overlay_changeset *ovcs,
struct device_node *target_node,
- const struct device_node *overlay_node,
- bool is_symbols_node)
+ const struct device_node *overlay_node)
{
struct device_node *child;
struct property *prop;
int ret;
for_each_property_of_node(overlay_node, prop) {
-
[PATCH v3 05/12] of: overlay: minor restructuring
From: Frank Rowand
Continue improving the readability of overlay.c. The previous patches
renamed identifiers. This patch is split out from the previous patches
to make the previous patches easier to review.
Changes are:
- minor code restructuring
- some initialization of an overlay changeset occurred outside of
init_overlay_changeset(), move that into init_overlay_changeset()
- consolidate freeing an overlay changeset into free_overlay_changeset()
This patch is intended to not introduce any functional change.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 205 +++
1 file changed, 92 insertions(+), 113 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index bb8867cae05b..905916e17eec 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -55,6 +55,9 @@ static int build_changeset_next_level(struct
overlay_changeset *ovcs,
const struct device_node *overlay_node,
bool is_symbols_node);
+static LIST_HEAD(ovcs_list);
+static DEFINE_IDR(ovcs_idr);
+
static BLOCKING_NOTIFIER_HEAD(overlay_notify_chain);
int of_overlay_notifier_register(struct notifier_block *nb)
@@ -160,8 +163,6 @@ static struct property *dup_and_fixup_symbol_prop(
kfree(new->value);
kfree(new);
return NULL;
-
-
}
/**
@@ -258,13 +259,7 @@ static int add_changeset_node(struct overlay_changeset
*ovcs,
if (!of_node_cmp(node_kbasename, kbasename(tchild->full_name)))
break;
- if (tchild) {
- if (node->phandle)
- return -EINVAL;
-
- ret = build_changeset_next_level(ovcs, tchild, node, 0);
- of_node_put(tchild);
- } else {
+ if (!tchild) {
tchild = __of_node_dup(node, "%pOF/%s",
target_node, node_kbasename);
if (!tchild)
@@ -276,11 +271,15 @@ static int add_changeset_node(struct overlay_changeset
*ovcs,
if (ret)
return ret;
- ret = build_changeset_next_level(ovcs, tchild, node, 0);
- if (ret)
- return ret;
+ return build_changeset_next_level(ovcs, tchild, node, 0);
}
+ if (node->phandle)
+ return -EINVAL;
+
+ ret = build_changeset_next_level(ovcs, tchild, node, 0);
+ of_node_put(tchild);
+
return ret;
}
@@ -394,41 +393,6 @@ static struct device_node *find_target_node(struct
device_node *info_node)
}
/**
- * of_fill_overlay_info() - Fill an overlay info structure
- * @ov Overlay to fill
- * @info_node: Device node containing the overlay
- * @ovinfo:Pointer to the overlay info structure to fill
- *
- * Fills an overlay info structure with the overlay information
- * from a device node. This device node must have a target property
- * which contains a phandle of the overlay target node, and an
- * __overlay__ child node which has the overlay contents.
- * Both ovinfo->target & ovinfo->overlay have their references taken.
- *
- * Returns 0 on success, or a negative error value.
- */
-static int of_fill_overlay_info(struct overlay_changeset *ovcset,
- struct device_node *info_node, struct fragment *fragment)
-{
- fragment->overlay = of_get_child_by_name(info_node, "__overlay__");
- if (!fragment->overlay)
- goto err_fail;
-
- fragment->target = find_target_node(info_node);
- if (!fragment->target)
- goto err_fail;
-
- return 0;
-
-err_fail:
- of_node_put(fragment->target);
- of_node_put(fragment->overlay);
-
- memset(fragment, 0, sizeof(*fragment));
- return -EINVAL;
-}
-
-/**
* init_overlay_changeset() - initialize overlay changeset from overlay tree
* @ovcs Overlay changeset to build
* @tree: Contains all the overlay fragments and overlay fixup nodes
@@ -438,32 +402,61 @@ static int of_fill_overlay_info(struct overlay_changeset
*ovcset,
* nodes and the __symbols__ node. Any other top level node will be ignored.
*
* Returns 0 on success, -ENOMEM if memory allocation failure, -EINVAL if error
- * detected in @tree, or -ENODEV if no valid nodes found.
+ * detected in @tree, or -ENOSPC if idr_alloc() error.
*/
static int init_overlay_changeset(struct overlay_changeset *ovcs,
struct device_node *tree)
{
- struct device_node *node;
+ struct device_node *node, *overlay_node;
struct fragment *fragment;
struct fragment *fragments;
int cnt, ret;
+ INIT_LIST_HEAD(&ovcs->ovcs_list);
+
+ of_changeset_init(&ovcs->cset);
+
+ ovcs->id = idr_alloc(&ovcs_idr, ovcs, 1, 0, GFP_KERNEL);
+ if (ovcs->id <= 0)
+ return ovcs->id;
+
cnt = 0;
- for_each_child_of_node(tree, node)
- cnt++;
- if (of_get_c
Re: [PATCH 2/9] drm/panel: simple: simplify display_mode definitions by using macro
Hi,
On Tue, 17 Oct 2017 14:09:37 +0200 Thierry Reding wrote:
> On Wed, Oct 11, 2017 at 01:23:34PM +0200, Lothar Waßmann wrote:
> > Use the newly defined macro to generate the display_mode data entries
> > for all panels. This reduces the code size significantly and makes the
> > code more readable.
> >
> > Signed-off-by: Lothar Waßmann
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 799
> > ++-
> > 1 file changed, 134 insertions(+), 665 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index dec639d..fde9c41 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -89,6 +89,20 @@ struct panel_simple {
> > struct gpio_desc *enable_gpio;
> > };
> >
> > +#define SP_DISPLAY_MODE(freq, ha, hfp, hs, hbp, va, vfp, vs, vbp, vr,
> > flgs) { \
> > + .clock = freq, \
> > + .hdisplay = ha, \
> > + .hsync_start = (ha) + (hfp),\
> > + .hsync_end = (ha) + (hfp) + (hs), \
> > + .htotal = (ha) + (hfp) + (hs) + (hbp), \
> > + .vdisplay = (va), \
> > + .vsync_start = (va) + (vfp),\
> > + .vsync_end = (va) + (vfp) + (vs), \
> > + .vtotal = (va) + (vfp) + (vs) + (vbp), \
> > + .vrefresh = vr, \
> > + .flags = flgs, \
> > +}
> > +
> > static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
> > {
> > return container_of(panel, struct panel_simple, base);
> [...]
> > @@ -411,33 +415,9 @@ static const struct panel_desc
> > ampire_am_480272h3tmqw_t01h = {
> > .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> > };
> >
> > -#define SP_DISPLAY_MODE(freq, ha, hfp, hs, hbp, va, vfp, vs, vbp, vr,
> > flgs) { \
> > - .clock = freq, \
> > - .hdisplay = ha, \
> > - .hsync_start = (ha) + (hfp),\
> > - .hsync_end = (ha) + (hfp) + (hs), \
> > - .htotal = (ha) + (hfp) + (hs) + (hbp), \
> > - .vdisplay = (va), \
> > - .vsync_start = (va) + (vfp),\
> > - .vsync_end = (va) + (vfp) + (vs), \
> > - .vtotal = (va) + (vfp) + (vs) + (vbp), \
> > - .vrefresh = vr, \
> > - .flags = flgs, \
> > - }
>
> Your first patch should put this in the right place to begin with so
> that this patch is really just the conversion.
>
> Again, I don't think this macro actually improves the way modes are
> defined.
>
I'm not happy with this panel driver stuff anyway. With the legacy
'display-timings' node that provided the timing data directly in the
DTB, every bootloader could pick up the timing data and feed it to
whatever driver it used for the display.
With the panel driver stuff the whole Linux driver has to be replicated
in the boot loader in order to be able to use the same DTB as Linux for
its HW configuration.
And adding a new panel involves recompiling the kernel and the boot
loader, rather than adding the timing data from the panel's datasheet
into the DTB.
Lothar Waßmann
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/12] of: overlay: rename identifiers to more reflect what they do
From: Frank Rowand
This patch is aimed primarily at drivers/of/overlay.c, but those
changes also have a small impact in a few other files.
overlay.c is difficult to read and maintain. Improve readability:
- Rename functions, types and variables to better reflect what
they do and to be consistent with names in other places,
such as the device tree overlay FDT (flattened device tree),
and make the algorithms more clear
- Use the same names consistently throughout the file
- Update comments for name changes
- Fix incorrect comments
This patch is intended to not introduce any functional change.
Signed-off-by: Frank Rowand
---
Documentation/devicetree/overlay-notes.txt | 12 +-
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 5 +-
drivers/of/dynamic.c | 2 +-
drivers/of/overlay.c | 530 ++-
drivers/of/unittest.c| 20 +-
include/linux/of.h | 12 +-
6 files changed, 310 insertions(+), 271 deletions(-)
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
index eb7f2685fda1..c4aa0adf13ec 100644
--- a/Documentation/devicetree/overlay-notes.txt
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -87,15 +87,15 @@ Overlay in-kernel API
The API is quite easy to use.
-1. Call of_overlay_create() to create and apply an overlay. The return value
-is a cookie identifying this overlay.
+1. Call of_overlay_apply() to create and apply an overlay changeset. The return
+value is an error or a cookie identifying this overlay.
-2. Call of_overlay_destroy() to remove and cleanup the overlay previously
-created via the call to of_overlay_create(). Removal of an overlay that
-is stacked by another will not be permitted.
+2. Call of_overlay_remove() to remove and cleanup the overlay changeset
+previously created via the call to of_overlay_apply(). Removal of an overlay
+changeset that is stacked by another will not be permitted.
Finally, if you need to remove all overlays in one-go, just call
-of_overlay_destroy_all() which will remove every single one in the correct
+of_overlay_remove_all() which will remove every single one in the correct
order.
Overlay DTS Format
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index 623a9140493c..5f5b7ba35f1d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -247,9 +247,10 @@ static void __init tilcdc_convert_slave_node(void)
tilcdc_node_disable(slave);
- ret = of_overlay_create(overlay);
+ ret = of_overlay_apply(overlay);
if (ret)
- pr_err("%s: Creating overlay failed: %d\n", __func__, ret);
+ pr_err("%s: Applying overlay changeset failed: %d\n",
+ __func__, ret);
else
pr_info("%s: ti,tilcdc,slave node successfully converted\n",
__func__);
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 39e8cf731764..4bc96af4d8e2 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -758,7 +758,7 @@ int of_changeset_revert(struct of_changeset *ocs)
EXPORT_SYMBOL_GPL(of_changeset_revert);
/**
- * of_changeset_action - Perform a changeset action
+ * of_changeset_action - Add an action to the tail of the changeset list
*
* @ocs: changeset pointer
* @action:action to perform
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index d3f4a5974a11..69610637af88 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -25,67 +25,63 @@
#include "of_private.h"
/**
- * struct of_overlay_info - Holds a single overlay info
+ * struct fragment - info about fragment nodes in overlay expanded device tree
* @target:target of the overlay operation
- * @overlay: pointer to the overlay contents node
- *
- * Holds a single overlay state, including all the overlay logs &
- * records.
+ * @overlay: pointer to the __overlay__ node
*/
-struct of_overlay_info {
+struct fragment {
struct device_node *target;
struct device_node *overlay;
bool is_symbols_node;
};
/**
- * struct of_overlay - Holds a complete overlay transaction
- * @node: List on which we are located
- * @count: Count of ovinfo structures
- * @ovinfo_tab:Overlay info table (count sized)
- * @cset: Changeset to be used
- *
- * Holds a complete overlay transaction
+ * struct overlay_changeset
+ * @ovcs_list: list on which we are located
+ * @count: count of @fragments structures
+ * @fragments: info about fragment nodes in overlay expanded device tree
+ * @cset: changeset to apply fragments to live device tree
*/
-struct of_overlay {
+struct overlay_changeset {
int id;
- struct list_head node;
+ struct list_head ovcs_list;
int count;
- struct of_overl
[PATCH v2 2/3] drm/amd/powerplay: Remove useless variable
The result variable is initialized at the beginning of the function, but
its value does not change during the function execution. Thus, remove the
variable and return the SUCCESS value, which is 0.
Issue found by coccinelle script:
* Unneeded variable: "result". Return "0"
Path to the cocci script: scripts/coccinelle/misc/returnvar.cocci
Signed-off-by: Georgiana Chelu
---
Changes in v2:
* adjusted the subject prefix of the patches
* added the cocci script used to generate the patches
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
index d968c3834481..769ac11a9215 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c
@@ -1174,7 +1174,6 @@ int vega10_pp_tables_initialize(struct pp_hwmgr *hwmgr)
static int vega10_pp_tables_uninitialize(struct pp_hwmgr *hwmgr)
{
- int result = 0;
struct phm_ppt_v2_information *pp_table_info =
(struct phm_ppt_v2_information *)(hwmgr->pptable);
@@ -1217,7 +1216,7 @@ static int vega10_pp_tables_uninitialize(struct pp_hwmgr
*hwmgr)
kfree(hwmgr->pptable);
hwmgr->pptable = NULL;
- return result;
+ return 0;
}
const struct pp_table_func vega10_pptable_funcs = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/12] of: overlay: rename identifiers to more reflect what they do
On 10/17/17 07:38, Rob Herring wrote: > On Mon, Oct 16, 2017 at 8:17 PM, wrote: >> From: Frank Rowand >> >> This patch is aimed primarily at drivers/of/overlay.c, but those >> changes also have a small impact in a few other files. >> >> overlay.c is difficult to read and maintain. Improve readability: >> - Rename functions, types and variables to better reflect what >> they do and to be consistent with names in other places, >> such as the device tree overlay FDT (flattened device tree), >> and make the algorithms more clear >> - Use the same names consistently throughout the file >> - Update comments for name changes >> - Fix incorrect comments >> >> This patch is intended to not introduce any functional change. >> >> Signed-off-by: Frank Rowand >> --- >> Documentation/devicetree/overlay-notes.txt | 12 +- >> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 5 +- >> drivers/of/dynamic.c | 2 +- >> drivers/of/overlay.c | 506 >> ++- >> drivers/of/unittest.c| 20 +- >> include/linux/of.h | 12 +- >> 6 files changed, 294 insertions(+), 263 deletions(-) > > Doesn't build: > > ../drivers/of/overlay.c:397:41: warning: ‘struct of_overlay_info’ > declared inside parameter list will not be visible outside of this > definition or declaration >struct device_node *info_node, struct of_overlay_info *ovinfo) > ^~~ > ../drivers/of/overlay.c:396:40: warning: ‘struct of_overlay’ declared > inside parameter list will not be visible outside of this definition > or declaration > static int of_fill_overlay_info(struct of_overlay *ov, > ^~ > ../drivers/of/overlay.c: In function ‘of_fill_overlay_info’: > ../drivers/of/overlay.c:399:8: error: dereferencing pointer to > incomplete type ‘struct of_overlay_info’ > ovinfo->overlay = of_get_child_by_name(info_node, "__overlay__"); > ^~ > ../drivers/of/overlay.c: In function ‘init_overlay_changeset’: > ../drivers/of/overlay.c:450:30: error: passing argument 1 of > ‘of_fill_overlay_info’ from incompatible pointer type > [-Werror=incompatible-pointer-types] >ret = of_fill_overlay_info(ovcs, node, &fragments[cnt]); > ^~~~ > ../drivers/of/overlay.c:396:12: note: expected ‘struct of_overlay *’ > but argument is of type ‘struct overlay_changeset *’ > static int of_fill_overlay_info(struct of_overlay *ov, > ^~~~ > ../drivers/of/overlay.c:450:42: error: passing argument 3 of > ‘of_fill_overlay_info’ from incompatible pointer type > [-Werror=incompatible-pointer-types] >ret = of_fill_overlay_info(ovcs, node, &fragments[cnt]); > ^ > ../drivers/of/overlay.c:396:12: note: expected ‘struct of_overlay_info > *’ but argument is of type ‘struct fragment *’ > static int of_fill_overlay_info(struct of_overlay *ov, > ^~~~ > > > I could have messed something up as every commit so far conflicts with > "of: overlay: fix memory leak related to duplicated property". Can you > rebase on to my dt/next branch too. > > Rob > OK, I'll rebase. -Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] drm: Move debug macros out of drmP.h
This patchset move debug macros from drmP.h to drm_print.h and move printing related functions used by the debug macros from drm_drv.[hc] to drm_print.[hc]. In addition, it fixes old comment style. Changes in v4: - Move DRM_UT_ debug messaging macros from drmP.h to drm_print.h. Changes in v3: - Move debug macros and print functions into drm_print.[hc] instead of introducing drm_debug.[hc]. Haneen Mohammed (2): drm: Move debug macros out of drmP.h drm/print: Update old comment style drivers/gpu/drm/drm_drv.c | 47 --- drivers/gpu/drm/drm_print.c | 47 +++ include/drm/drmP.h | 193 +--- include/drm/drm_drv.h | 7 -- include/drm/drm_print.h | 192 +++ 5 files changed, 240 insertions(+), 246 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/23] drm/sun4i: Add A83T support
在 2017-10-17 17:06，Maxime Ripard 写道：
Add support for the A83T display pipeline.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 +
drivers/gpu/drm/sun4i/sun8i_mixer.c | 4
4 files changed, 10 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 46df3b78ae9e..c0fa233ec1fc 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -90,6 +90,7 @@ Required properties:
* allwinner,sun6i-a31-tcon
* allwinner,sun6i-a31s-tcon
* allwinner,sun8i-a33-tcon
+ * allwinner,sun8i-a83t-tcon
Should be tcon0 -- tcon0 on A83T has only channel 0 and tcon1 has only
channel 1.
* allwinner,sun8i-v3s-tcon
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
@@ -209,6 +210,7 @@ supported.
Required properties:
- compatible: value must be one of:
+* allwinner,sun8i-a83t-de2-mixer
Since the capability of mixer0 and mixer1 are different (smart
backlight, write-back, VEP of the VI channel and extra UI
channels), I suggest to use ID-specific compatibles here.
* allwinner,sun8i-v3s-de2-mixer
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
@@ -236,6 +238,7 @@ Required properties:
* allwinner,sun6i-a31-display-engine
* allwinner,sun6i-a31s-display-engine
* allwinner,sun8i-a33-display-engine
+* allwinner,sun8i-a83t-display-engine
* allwinner,sun8i-v3s-display-engine
- allwinner,pipelines: list of phandle to the display engine
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a27efad9bc76..439f116bb3b5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -189,6 +189,7 @@ static bool sun4i_drv_node_is_tcon(struct
device_node *node)
of_device_is_compatible(node, "allwinner,sun6i-a31-tcon") ||
of_device_is_compatible(node, "allwinner,sun6i-a31s-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-a33-tcon") ||
+ of_device_is_compatible(node, "allwinner,sun8i-a83t-tcon") ||
of_device_is_compatible(node, "allwinner,sun8i-v3s-tcon");
}
@@ -347,6 +348,7 @@ static const struct of_device_id
sun4i_drv_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-display-engine" },
{ .compatible = "allwinner,sun6i-a31s-display-engine" },
{ .compatible = "allwinner,sun8i-a33-display-engine" },
+ { .compatible = "allwinner,sun8i-a83t-display-engine" },
{ .compatible = "allwinner,sun8i-v3s-display-engine" },
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 6a20a467ee6d..eb3c8bad4977 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1063,6 +1063,7 @@ static const struct of_device_id
sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-tcon", .data = &sun6i_a31_quirks
},
{ .compatible = "allwinner,sun6i-a31s-tcon", .data =
&sun6i_a31s_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks
},
+ { .compatible = "allwinner,sun8i-a83t-tcon", .data =
&sun8i_v3s_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks
},
{ }
};
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 86c6c24b5105..c6030ce130d3 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -385,6 +385,10 @@ static const struct sun8i_mixer_cfg
sun8i_v3s_mixer_cfg = {
static const struct of_device_id sun8i_mixer_of_table[] = {
{
+ .compatible = "allwinner,sun8i-a83t-de2-mixer",
+ .data = &sun8i_v3s_mixer_cfg,
As I said, V3s has 2 VI channels, so it totally shouldn't share
config with A83T.
+ },
+ {
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
},
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/8] Acer Chromebook R13 support
Hi Ulrich, On 10/16/2017 05:31 PM, Ulrich Hecht wrote: Hi! This is a new revision of the Acer Chromebook R13 support series. It does not offer anything new in terms of functionality, but eliminates three out of four ugly hacks and adds a few minor cleanups; see below for details. Thanks to Robin Murphy and CK Hu for their comments and suggestions! I'm still looking for advice on how to implement the dual-role mmsys device correctly; see "hack: mediatek: get mmsys to register as both DRM and clock device" for details on this. Like the previous revision, you can find this series at https://github.com/uli/kernel/tree/elm-working, which also contains a config file and several ancillary bits that are required to build a kernel partition for the Chromebook. Instructions on how to do so (and various other things that have to be done to get it running on your device) are available at https://www.elinux.org/User:Uli/Acer_Chromebook_R13_GPU_test_system (These instructions have been written for the vendor kernel, but apply to mainline as well, except that you won't need any extra patches.) I appreciate your efforts to get this done. From what I understand you rebased the patches from the chromium kernel to mainline. So you should keep the signed-off-by from the original author and just add you signed-off-by below that. Also it would be nice to CC these persons so that they are aware of your effort. CU Uli Changes since RFC v1: - cmdq: remove obsolete driver; not currently used anyway Are you sure about this? I remember that Dan (CC'ed) told me that this is one of the requirements to get upstream working. Dan, can you clarify please? Regards, Matthias - dt: remove CD GPIO from mmc1, does not seem to be correct - mmc: remove mtk-sd.c revert hack (works fine without the CD pin) - dsi: fix port number for drm_of_find_panel_or_bridge(), remove hack - fbdev: add missing Signed-off-bys - iommu: remove io-pgtable sanity check hack, has been properly fixed - minor style fixes Ulrich Hecht (8): drm/bridge: GPIO-controlled display multiplexer driver platform/chrome: ChromeOS firmware interface driver drm/bridge: Parade PS8640 MIPI DSI -> eDP converter driver drm/bridge: Analogix ANX7688 HDMI -> DP bridge driver arm64: dts: mediatek: Add Elm Rev. 3 device tree hack: mediatek: get mmsys to register as both DRM and clock device drm/mediatek: Add DRM-based framebuffer device drm: mediatek: Fix drm_of_find_panel_or_bridge conversion arch/arm64/boot/dts/mediatek/Makefile|1 + arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts | 21 + arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 210 arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi | 1013 drivers/clk/mediatek/clk-mt8173.c|4 +- drivers/gpu/drm/bridge/Kconfig | 32 + drivers/gpu/drm/bridge/Makefile |5 + drivers/gpu/drm/bridge/analogix-anx7688.c| 233 + drivers/gpu/drm/bridge/generic-gpio-mux.c| 316 +++ drivers/gpu/drm/bridge/parade-ps8640.c | 1104 ++ drivers/gpu/drm/mediatek/Makefile|2 + drivers/gpu/drm/mediatek/mtk_dpi.c |5 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c |5 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_drv.h |4 +- drivers/gpu/drm/mediatek/mtk_drm_fb.c| 13 + drivers/gpu/drm/mediatek/mtk_drm_fb.h|3 + drivers/gpu/drm/mediatek/mtk_drm_fbdev.c | 181 drivers/gpu/drm/mediatek/mtk_drm_fbdev.h | 32 + drivers/gpu/drm/mediatek/mtk_dsi.c |2 +- drivers/gpu/drm/mediatek/mtk_hdmi.c |5 +- drivers/platform/chrome/Kconfig | 18 + drivers/platform/chrome/Makefile |2 + drivers/platform/chrome/chromeos.c | 120 +++ drivers/platform/chrome/chromeos.h | 61 ++ drivers/platform/chrome/chromeos_arm.c | 264 ++ drivers/platform/chrome/elog.h | 186 include/linux/chromeos_platform.h| 27 + 28 files changed, 3874 insertions(+), 10 deletions(-) create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi create mode 100644 drivers/gpu/drm/bridge/analogix-anx7688.c create mode 100644 drivers/gpu/drm/bridge/generic-gpio-mux.c create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.c create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fbdev.h create mode 100644 drivers/platform/chrome/chromeos.c create mode 100644 drivers/platform/chrome/chromeos.h create mode 100644 drivers/platform/chrome/chromeos_arm.c crea
Re: [PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection
On Wed, Oct 18, 2017 at 11:24:43AM +1100, Daniel Axtens wrote:
> Hi Daniel,
>
> >> Initially I wondered if this info printk could be moved into
> >> vga_arbiter_check_bridge_sharing(), but it's been separated out since
> >> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
> >> possible."), and upon closer examination, it seems you can't be sure a
> >> device doesn't share a bridge until the end of the process, so this is
> >> indeed correct.
> >>
> >> Everything else also looks good to me.
> >>
> >> Reviewed-by: Daniel Axtens
> >
> > R-b for both patches? And ok with everyone if I pull this into drm-misc
> > for 4.15 (deadline is end of this week for feature-y stuff)?
>
> I had only intended it for patch 2, but I've now read over patch 1 to my
> satisfaction, so it too is:
>
> Reviewed-by: Daniel Axtens
Both applied for 4.15, thanks.
-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: [RFC PATCH 3/4] extcon: add possibility to get extcon device by of node
Hi,
On 2017년 09월 28일 22:07, Andrzej Hajda wrote:
> Since extcon property is not allowed in DT, extcon subsystem requires
> another way to get extcon device. Lets try the simplest approach - get
> edev by of_node.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/extcon/extcon.c | 44 ++--
> include/linux/extcon.h | 6 ++
> 2 files changed, 40 insertions(+), 10 deletions(-)
Looks good to me. Just I added the minor comment.
Acked-by: Chanwoo Choi
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index cb38c2747684..fdb8c1d767c1 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
> EXPORT_SYMBOL_GPL(extcon_dev_unregister);
>
> #ifdef CONFIG_OF
> +
> +/*
> + * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
> + * @node : OF node identyfying edev
> + *
> + * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
> + */
> +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
> +{
> + struct extcon_dev *edev;
> +
> + mutex_lock(&extcon_dev_list_lock);
> + list_for_each_entry(edev, &extcon_dev_list, entry)
> + if (edev->dev.parent && edev->dev.parent->of_node == node)
> + goto end;
> + edev = ERR_PTR(-EPROBE_DEFER);
> +end:
The extcon.c already use the 'out' statement for goto.
I'd like you to use 'out' instead of 'end'.
> + mutex_unlock(&extcon_dev_list_lock);
> +
> + return edev;
> +}
> +
> /*
> * extcon_get_edev_by_phandle - Get the extcon device from devicetree.
> * @dev : the instance to the given device
> @@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct
> device *dev, int index)
> return ERR_PTR(-ENODEV);
> }
>
> - mutex_lock(&extcon_dev_list_lock);
> - list_for_each_entry(edev, &extcon_dev_list, entry) {
> - if (edev->dev.parent && edev->dev.parent->of_node == node) {
> - mutex_unlock(&extcon_dev_list_lock);
> - of_node_put(node);
> - return edev;
> - }
> - }
> - mutex_unlock(&extcon_dev_list_lock);
> + edev = extcon_get_edev_by_of_node(node);
> of_node_put(node);
>
> - return ERR_PTR(-EPROBE_DEFER);
> + return edev;
> }
> +
> #else
> +
> +struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +
> struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
> {
> return ERR_PTR(-ENOSYS);
> }
> +
> #endif /* CONFIG_OF */
> +
> +EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
> EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
>
> /**
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 744d60ca80c3..2f88e7491672 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -261,6 +261,7 @@ extern void devm_extcon_unregister_notifier_all(struct
> device *dev,
> * Following APIs get the extcon_dev from devicetree or by through extcon
> name.
> */
> extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
> +extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node
> *node);
> extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
>int index);
>
> @@ -382,6 +383,11 @@ static inline struct extcon_dev
> *extcon_get_extcon_dev(const char *extcon_name)
> return ERR_PTR(-ENODEV);
> }
>
> +static inline struct extcon_dev *extcon_get_edev_by_of_node(struct
> device_node *node)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +
> static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device
> *dev,
> int index)
> {
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/12] of: overlay: avoid race condition between applying multiple overlays
From: Frank Rowand
The process of applying an overlay consists of:
- unflatten an overlay FDT (flattened device tree) into an
EDT (expanded device tree)
- fixup the phandle values in the overlay EDT to fit in a
range above the phandle values in the live device tree
- create the overlay changeset to reflect the contents of
the overlay EDT
- apply the overlay changeset, to modify the live device tree,
potentially changing the maximum phandle value in the live
device tree
There is currently no protection against two overlay applies
concurrently determining what range of phandle values are in use
in the live device tree, and subsequently changing that range.
Add a mutex to prevent multiple overlay applies from occurring
simultaneously.
Move of_resolve_phandles() into of_overlay_apply() so that it does not
have to be duplicated by each caller of of_overlay_apply().
The test in of_resolve_phandles() that the overlay tree is detached is
temporarily disabled so that old style overlay unittests do not fail.
Signed-off-by: Frank Rowand
---
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 6 --
drivers/of/of_private.h | 12 +++
drivers/of/overlay.c | 32
drivers/of/resolver.c| 7 ++
drivers/of/unittest.c| 22 +--
include/linux/of.h | 3 ---
6 files changed, 67 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
index 7a7be0515bfd..54025af534d4 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -145,7 +145,6 @@ static struct device_node * __init
tilcdc_get_overlay(struct kfree_table *kft)
__dtb_tilcdc_slave_compat_begin;
static void *overlay_data;
struct device_node *overlay;
- int ret;
if (!size) {
pr_warn("%s: No overlay data\n", __func__);
@@ -164,11 +163,6 @@ static struct device_node * __init
tilcdc_get_overlay(struct kfree_table *kft)
}
of_node_set_flag(overlay, OF_DETACHED);
- ret = of_resolve_phandles(overlay);
- if (ret) {
- pr_err("%s: Failed to resolve phandles: %d\n", __func__, ret);
- return NULL;
- }
return overlay;
}
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 36357f571df2..248730567dbe 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -76,6 +76,18 @@ static inline int __of_attach_node_sysfs(struct device_node
*np)
static inline void __of_detach_node_sysfs(struct device_node *np) {}
#endif
+#if defined(CONFIG_OF_RESOLVE)
+int of_resolve_phandles(struct device_node *tree);
+#endif
+
+#if defined(CONFIG_OF_OVERLAY)
+void of_overlay_mutex_lock(void);
+void of_overlay_mutex_unlock(void);
+#else
+static inline void of_overlay_mutex_lock(void) {};
+static inline void of_overlay_mutex_unlock(void) {};
+#endif
+
#if defined(CONFIG_OF_UNITTEST) && defined(CONFIG_OF_OVERLAY)
extern void __init unittest_unflatten_overlay_base(void);
#else
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 791753321ed2..d164f86e5541 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -71,6 +71,28 @@ static int build_changeset_next_level(struct
overlay_changeset *ovcs,
const struct device_node *overlay_node,
bool is_symbols_node);
+/*
+ * of_resolve_phandles() finds the largest phandle in the live tree.
+ * of_overlay_apply() may add a larger phandle to the live tree.
+ * Do not allow race between two overlays being applied simultaneously:
+ *mutex_lock(&of_overlay_phandle_mutex)
+ *of_resolve_phandles()
+ *of_overlay_apply()
+ *mutex_unlock(&of_overlay_phandle_mutex)
+ */
+static DEFINE_MUTEX(of_overlay_phandle_mutex);
+
+void of_overlay_mutex_lock(void)
+{
+ mutex_lock(&of_overlay_phandle_mutex);
+}
+
+void of_overlay_mutex_unlock(void)
+{
+ mutex_unlock(&of_overlay_phandle_mutex);
+}
+
+
static LIST_HEAD(ovcs_list);
static DEFINE_IDR(ovcs_idr);
@@ -624,6 +646,12 @@ int of_overlay_apply(struct device_node *tree, int
*ovcs_id)
goto out;
}
+ of_overlay_mutex_lock();
+
+ ret = of_resolve_phandles(tree);
+ if (ret)
+ goto err_overlay_unlock;
+
mutex_lock(&of_mutex);
ret = init_overlay_changeset(ovcs, tree);
@@ -669,9 +697,13 @@ int of_overlay_apply(struct device_node *tree, int
*ovcs_id)
}
mutex_unlock(&of_mutex);
+ of_overlay_mutex_unlock();
goto out;
+err_overlay_unlock:
+ of_overlay_mutex_unlock();
+
err_free_overlay_changeset:
free_overlay_changeset(ovcs);
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index bd21a66f6930..cfaeef5f6cb1 100644
--- a/driver
[PATCH] drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels
Dithering is supported on TCON channel 0 which is used for LCD panels.
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 37 +
drivers/gpu/drm/sun4i/sun4i_tcon.h | 18 +-
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 68751b999877..cf313ca858b3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -12,11 +12,13 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
@@ -168,7 +170,9 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
struct drm_display_mode *mode)
{
unsigned int bp, hsync, vsync;
+ u32 bus_format = 0;
u8 clk_delay;
+ struct drm_connector *connector = tcon->panel->connector;
u32 val = 0;
/* Configure the dot clock */
@@ -230,6 +234,39 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
val);
+ if (connector->display_info.num_bus_formats)
+ bus_format = connector->display_info.bus_formats[0];
+
+ switch (bus_format) {
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ /* Enable dithering */
+ /* FIXME: Undocumented bits */
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED0_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED1_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED2_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED3_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED4_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_SEED5_REG, 0x);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB0_REG, 0x0101);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB1_REG, 0x1515);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB2_REG, 0x5757);
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_TAB3_REG, 0x7f7f);
+ val = SUN4I_TCON0_FRM_CTL_ENABLE;
+
+ if (bus_format == MEDIA_BUS_FMT_RGB565_1X16) {
+ val |= SUN4I_TCON0_FRM_CTL_MODE_R;
+ val |= SUN4I_TCON0_FRM_CTL_MODE_B;
+ }
+
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_CTL_REG, val);
+ break;
+ default:
+ /* Disable dithering */
+ regmap_write(tcon->regs, SUN4I_TCON0_FRM_CTL_REG, 0);
+ break;
+ }
+
/* Map output pins to channel 0 */
regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
SUN4I_TCON_GCTL_IOMAP_MASK,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index d9e1357cc8ae..d64d45144c91 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -31,7 +31,23 @@
#define SUN4I_TCON_GINT0_VBLANK_INT(pipe) BIT(15 - (pipe))
#define SUN4I_TCON_GINT1_REG 0x8
-#define SUN4I_TCON_FRM_CTL_REG 0x10
+
+#define SUN4I_TCON0_FRM_CTL_REG0x10
+#define SUN4I_TCON0_FRM_CTL_ENABLE BIT(31)
+#define SUN4I_TCON0_FRM_CTL_MODE_R BIT(6)
+#define SUN4I_TCON0_FRM_CTL_MODE_G BIT(5)
+#define SUN4I_TCON0_FRM_CTL_MODE_B BIT(4)
+
+#define SUN4I_TCON0_FRM_SEED0_REG 0x14
+#define SUN4I_TCON0_FRM_SEED1_REG 0x18
+#define SUN4I_TCON0_FRM_SEED2_REG 0x1c
+#define SUN4I_TCON0_FRM_SEED3_REG 0x20
+#define SUN4I_TCON0_FRM_SEED4_REG 0x24
+#define SUN4I_TCON0_FRM_SEED5_REG 0x28
+#define SUN4I_TCON0_FRM_TAB0_REG 0x2c
+#define SUN4I_TCON0_FRM_TAB1_REG 0x30
+#define SUN4I_TCON0_FRM_TAB2_REG 0x34
+#define SUN4I_TCON0_FRM_TAB3_REG 0x38
#define SUN4I_TCON0_CTL_REG0x40
#define SUN4I_TCON0_CTL_TCON_ENABLEBIT(31)
--
2.14.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helper: check that drivers call drm_crtc_vblank_off
On Tue, Oct 17, 2017 at 06:32:52PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 17, 2017 at 05:27:14PM +0200, Daniel Vetter wrote:
> > At least when they have vblank support they need to call this, or the
> > vblank core will happily call into their crtc->enable_vblank callback
> > even when the crtc is off. Which leads to a boom when the clocks are
> > off on most hardware (besides the inevitable confusion in the
> > book-keeping).
> >
> > The consistency checks in drm_vblank.c will then make sure that
> > vblank_off/on calls are balanced, and if drivers forget to re-enable
> > it all the commits will stall, so I think we're covered.
> >
> > It'd be nice to be able to place this check outside of commit helpers,
> > but tha's not really possible (due to nonblocking commits and all
> > that). Placing it into atomic helpers should at least cover most
> > drivers.
> >
> > Also note that vblank support is still optional (for virtual drivers,
> > which tend to not have this), check for that.
> >
> > v2: Fixup the handling for vblank_put (Rob).
> >
> > Cc: Rob Clark
> > Tested-by: Rob Clark
> > Cc: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Ville Syrjälä
Applied, thanks for your review.
-Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ae56d91433ff..029c8c1d97f6 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -860,6 +860,7 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> >
> > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > new_crtc_state, i) {
> > const struct drm_crtc_helper_funcs *funcs;
> > + int ret;
> >
> > /* Shut down everything that needs a full modeset. */
> > if (!drm_atomic_crtc_needs_modeset(new_crtc_state))
> > @@ -883,6 +884,14 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> > funcs->disable(crtc);
> > else
> > funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > +
> > + if (!(dev->irq_enabled && dev->num_crtcs))
> > + continue;
> > +
> > + ret = drm_crtc_vblank_get(crtc);
> > + WARN_ONCE(ret != -EINVAL, "driver forgot to call
> > drm_crtc_vblank_off()\n");
> > + if (ret == 0)
> > + drm_crtc_vblank_put(crtc);
> > }
> > }
> >
> > --
> > 2.14.1
>
> --
> Ville Syrjälä
> Intel OTC
--
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: [RFC 06/11] arm64: dts: mediatek: Add Elm Rev. 3 device tree
Hi,
On Fri, 2017-09-29 at 15:09 +0200, Ulrich Hecht wrote:
> Signed-off-by: Ulrich Hecht
> ---
> arch/arm64/boot/dts/mediatek/Makefile|1 +
> arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts | 21 +
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 210 +
> arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi | 1014
> ++
> 4 files changed, 1246 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 151723b..0521e29 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-elm-rev3.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts
> new file mode 100644
> index 000..68d4095
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-rev3.dts
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright 2016 MediaTek Inc.
> + * Author: Eddie Huang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +#include "mt8173-elm.dtsi"
> +
> +/ {
> + model = "Mediatek Elm rev3 board";
> + compatible = "google,elm-rev3", "google,elm", "mediatek,mt8173";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> new file mode 100644
> index 000..850037f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
> @@ -0,0 +1,210 @@
> +/*
> + * Copyright 2016 MediaTek Inc.
> + * Author: Eddie Huang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "mt8173-oak.dtsi"
> +
> +/ {
> + hdmicon: connector {
> + compatible = "hdmi-connector";
> + label = "hdmi";
> + type = "a";
> +
> + port {
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&hdmi_mux_out_hdmi>;
> + };
> + };
> + };
> +
> + hdmi_mux: hdmi_mux {
> + compatible = "gpio-display-mux";
Where is the binding for this?
> + status = "okay";
> + detect-gpios = <&pio 36 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_mux_pins>;
If you use gpio_request or related api, it will set pinmux
automatically.
Do we really need this pinctrl?
> + ddc-i2c-bus = <&hdmiddc0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 { /* input */
> + reg = <0>;
> +
> + hdmi_mux_in: endpoint {
> + remote-endpoint = <&hdmi0_out>;
> + };
> + };
> +
> + port@1 { /* output */
> + reg = <1>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hdmi_mux_out_anx: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&anx7688_in>;
> + };
> +
> + hdmi_mux_out_hdmi: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + sound: sound {
> + compatible = "mediatek,mt8173-rt5650";
> +
Re: [PATCH 04/48] drm: omapdrm: Merge the omapdss and omapdss-base modules
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 17:59, Laurent Pinchart wrote: > There's no need for the omapdss-base code to be part of a separate > module. Merge it with the omapdss module. This allows removing the > exports for internal symbols. The need was to support DSS6 driver, which is built as separate module. That's not in the mainline yet. If we merge dss6 driver into the same omapdrm.ko, then there should be no issues. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync
On 18/10/17 10:10 AM, Daniel Vetter wrote: > On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote: >> On 17.10.2017 19:16, Daniel Vetter wrote: >>> On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote: On 17/10/17 05:04 PM, Daniel Vetter wrote: > On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: >> On 17/10/17 02:22 PM, Daniel Vetter wrote: >>> On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: >>> >>> Finally I'm not sure we want to insist on a target time for freesync. At >>> least as far as I understand things you just want "as soon as possible". >>> This might change with some of the VK/EGL/GLX extensions where you >>> specify a precise timing (media playback). But that needs a bit more >>> work >>> to make it happen I think, so perhaps better to postpone. >> >> I don't see why. There's an obvious use case for this now, for video >> playback. At least VDPAU already has target timestamps for this. >> >> >>> Also note that right now no driver expect amdgpu has support for a >>> target >>> vblank on a flip. That's imo another reason for not requiring target >>> support for at least basic freesync support. >> >> I think that's a bad reason. :) Adding it for atomic drivers shouldn't >> be that hard. > > I thought the primary reason for adaptive sync is the adaptive frame rate > to cope with the occasional stall in games. If the intended use-case is > vr/media, then I agree going with timestamps from the beginning makes > sense. That still leaves the "schedule asap, with some leeway" mode. Or is > that (no longer) something we want? Both are use cases for adaptive sync. Both can be covered by a target timestamp. There may be other possible solutions which work for both though. >>> >>> Hm, how do you make the "flip as soon as ready" semantics work with >>> timestamps, without requiring userspace to wait for the fences to >>> signal before submitting? Set the timestamp to now and force the miss? >> >> Like I wrote in my reply to Ville, I think it makes sense to always treat >> stale timestamps as "flip as soon as ready". > > Makes sense, and matches what we do with the vblank target right now. But > with stuff like VR it might be that we need a window, and when things are > delayed too much it's better to re-render a newly distorted frame instead > of motion sickness. We'll see. VR's real tough anyway :-) I suspect a VR compositor will have to deal with this before submitting the flip to the kernel, i.e. wait for the frame to finish rendering, and if it takes too long, render a reprojected frame and flip to that instead. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_evict.c
between commit:
99b169d3c2052 ("drm/i915: Fix eviction when the GGTT is idle but full")
from the drm-intel-fixes tree and commit:
9c1477e83e629 ("drm/i915/selftests: Exercise adding requests to a full GGTT")
from the drm-intel tree.
I fixed it up (null diff) 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.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/11] drm/exynos/hdmi: quirk for support mode timings conversion
On 18.10.2017 04:31, Inki Dae wrote:
>
> 2017년 10월 17일 17:04에 Andrzej Hajda 이(가) 쓴 글:
>> On 17.10.2017 09:38, Inki Dae wrote:
>>> 2017년 09월 29일 19:05에 Andrzej Hajda 이(가) 쓴 글:
MIXER in SoCs prior to Exynos5420 supports only 4 video modes:
720x480, 720x576, 1280x720, 1920x1080. Support for other modes
can be enabled by manipulating timings of HDMI. To do it
adjusted_mode should contain actual mode set on crtc.
With this patch it is possible to enable 1024x768 and 1280x1024
modes in MIXER.
Suggested-by: Daniel Drake
Signed-off-by: Andrzej Hajda
Reviewed-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 7225b6521148..4b081f6cfdcb 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1239,6 +1239,17 @@ static void hdmi_v13_mode_apply(struct hdmi_context
*hdata)
static void hdmi_v14_mode_apply(struct hdmi_context *hdata)
{
struct drm_display_mode *m = &hdata->encoder.crtc->state->mode;
+ struct drm_display_mode *am =
&hdata->encoder.crtc->state->adjusted_mode;
+ int hquirk = 0;
+
+ /*
+ * In case video mode coming from CRTC differs from requested one HDMI
+ * sometimes is able to almost properly perform conversion - only
+ * first line is distorted.
+ */
+ if ((m->vdisplay != am->vdisplay) &&
+ (m->hdisplay == 1280 || m->hdisplay == 1024))
+ hquirk = 258;
>>> Andrzej,
>>>
>>> The distorted value couldn't be described logically? Just I wonder why the
>>> difference happens.
>> Without low level documentation of the IP one could only guess what
>> happens there.
>> In case of 1024x768 one can reason as follows:
>> - mixer sends image in format 1280x720, so it sends 1280 - 1024 = 256
>> pixels too much, so if we trim it in HDMI by 256 it should display it
>> correctly,
>> - but another quirk few lines later suppress 2 pixels from
>> hsync_(start,end), so to balance it we should add these pixels here, so
>> finally we have 256 + 2 = 258.
>>
>> This explanation seems quite reasonable, except it does not work for
>> 1280x1024 mode.
> We aren't sure 100% but above comment would be helpful to other developers.
> So could you leave the comment?
I have made a mistake, in case of requested 1024x768 mode mixer sends
image in 1920x1080 format.
So the whole reasoning does not make sense.
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>> Regards
>> Andrzej
>>
>>> Thanks,
>>> Inki Dae
>>>
hdmi_reg_writev(hdata, HDMI_H_BLANK_0, 2, m->htotal - m->hdisplay);
hdmi_reg_writev(hdata, HDMI_V_LINE_0, 2, m->vtotal);
@@ -1332,8 +1343,8 @@ static void hdmi_v14_mode_apply(struct hdmi_context
*hdata)
hdmi_reg_writev(hdata, HDMI_V_SYNC_LINE_AFT_PXL_6_0, 2, 0x);
hdmi_reg_writev(hdata, HDMI_TG_H_FSZ_L, 2, m->htotal);
- hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay);
- hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay);
+ hdmi_reg_writev(hdata, HDMI_TG_HACT_ST_L, 2, m->htotal - m->hdisplay -
hquirk);
+ hdmi_reg_writev(hdata, HDMI_TG_HACT_SZ_L, 2, m->hdisplay + hquirk);
hdmi_reg_writev(hdata, HDMI_TG_V_FSZ_L, 2, m->vtotal);
if (hdata->drv_data == &exynos5433_hdmi_driver_data)
hdmi_reg_writeb(hdata, HDMI_TG_DECON_EN, 1);
>>
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Hi Laurent, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support > the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only > there's no need to keep two seperate drivers. > > The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds to > merging the omapdss and omapdss-base modules (04/48). It then prepares the > omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) > and prepares the omapdrm code (12/48). > > Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All > those drivers defer probing when their video source can't be found at probe > time. This would cause endless probe deferral when merging omapdrm and omapdss > as the drivers need omapdss to be fully initialized to probe successfully, but > cause omapdrm to defer probing when they're not available. > > Patch 20/48 merges the omapdrm and omapdss drivers. > > The next patches are added bonuses that start removal of global variables from > the driver. The code relies heavily on global variables for objects that are > instance-specific, and should thus be dynamically allocated. Most of the > patches change internal APIs to pass objects to driver functions (21/48 to > 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous > cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and 46/48 > then allocate instance objects dynamically to replace global variables, and > patches 47/48 and 48/48 move global variables to existing instance objects. > > The series has been tested on a Pandaboard with the DVI and HDMI output. Here's what I get on AM5 EVM: # ./s-drm-new [ 17.535638] sysrq: SysRq : Changing Loglevel [ 17.540179] sysrq: Loglevel set to 9 insmod nfs/work/linux/sound/soc/omap/snd-soc-omap-hdmi-audio.ko insmod nfs/work/linux/drivers/media/cec/cec.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbcopyarea.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbimgblt.ko insmod nfs/work/linux/drivers/video/fbdev/core/cfbfillrect.ko insmod nfs/work/linux/drivers/gpu/drm/drm.ko insmod nfs/work/linux/drivers/gpu/drm/drm_kms_helper.ko insmod nfs/work/linux/drivers/gpu/drm/omapdrm/omapdrm.ko [ 17.966444] dmm 4e00.dmm: initialized all PAT entries [ 18.004857] DSS: OMAP DSS rev 6.1 [ 18.010743] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.025076] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.050076] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.074540] omapdss_dss 5800.dss: master bind failed: -517 [ 18.083499] DSS: OMAP DSS rev 6.1 [ 18.088284] alloc_contig_range: [fd874, fd875) PFNs busy [ 18.095583] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) # [ 18.113296] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.119651] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.134440] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.154449] omapdss_dss 5800.dss: master bind failed: -517 [ 18.163344] DSS: OMAP DSS rev 6.1 [ 18.167982] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.179600] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.185013] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.190805] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.203003] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.219239] omapdss_dss 5800.dss: master bind failed: -517 [ 18.228977] DSS: OMAP DSS rev 6.1 [ 18.232446] alloc_contig_range: [fd874, fd875) PFNs busy [ 18.238816] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.250433] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.255847] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.261406] alloc_contig_range: [fd9a0, fd9c0) PFNs busy [ 18.267156] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> 5804.encoder mapping ok [ 18.279429] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 18.297217] omapdss_dss 5800.dss: master bind failed: -517 [ 18.305306] DSS: OMAP DSS rev 6.1 [ 18.309734] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 18.321303] alloc_contig_range: [fd8c0, fd8e0) PFNs busy [ 18.326830] alloc_contig_range: [fd8e0, fd900) PFNs busy [ 18.332468] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-
Re: [PATCH 00/48] omapdrm: Merge omapdrm and omapdss
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 18/10/17 12:46, Tomi Valkeinen wrote: > Hi Laurent, > > On 13/10/17 17:58, Laurent Pinchart wrote: >> Hello, >> >> This patch series merges the omapdrm and omapdss drivers into a single driver >> called omapdrm. The split in two drivers was historical, in order to support >> the FBDEV, V4L2 and DRM/KMS APIs. Now that the driver supports DRM/KMS only >> there's no need to keep two seperate drivers. >> >> The series starts with a few cleanups (01/48 to 03/48) and quickly proceeds >> to >> merging the omapdss and omapdss-base modules (04/48). It then prepares the >> omapdss code (05/48 to 08/48), perform a few more cleanups (09/48 to 11/48) >> and prepares the omapdrm code (12/48). >> >> Patches 13/48 to 19/48 prepare the connector, encoder and panel drivers. All >> those drivers defer probing when their video source can't be found at probe >> time. This would cause endless probe deferral when merging omapdrm and >> omapdss >> as the drivers need omapdss to be fully initialized to probe successfully, >> but >> cause omapdrm to defer probing when they're not available. >> >> Patch 20/48 merges the omapdrm and omapdss drivers. >> >> The next patches are added bonuses that start removal of global variables >> from >> the driver. The code relies heavily on global variables for objects that are >> instance-specific, and should thus be dynamically allocated. Most of the >> patches change internal APIs to pass objects to driver functions (21/48 to >> 28/48, 36/48, 39/48 to 41/38, 43/48 to 45/48) with a few miscellaneous >> cleanups (29/48, 35/48, 37/48, 38/48, 42/48). Patches 30/48 to 34/48 and >> 46/48 >> then allocate instance objects dynamically to replace global variables, and >> patches 47/48 and 48/48 move global variables to existing instance objects. >> >> The series has been tested on a Pandaboard with the DVI and HDMI output. > > Here's what I get on AM5 EVM: > > # ./s-drm-new > [ 17.535638] sysrq: SysRq : Changing Loglevel > [ 17.540179] sysrq: Loglevel set to 9 > insmod nfs/work/linux/sound/soc/omap/snd-soc-omap-hdmi-audio.ko > insmod nfs/work/linux/drivers/media/cec/cec.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbcopyarea.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbimgblt.ko > insmod nfs/work/linux/drivers/video/fbdev/core/cfbfillrect.ko > insmod nfs/work/linux/drivers/gpu/drm/drm.ko > insmod nfs/work/linux/drivers/gpu/drm/drm_kms_helper.ko > insmod nfs/work/linux/drivers/gpu/drm/omapdrm/omapdrm.ko > [ 17.966444] dmm 4e00.dmm: initialized all PAT entries > [ 18.004857] DSS: OMAP DSS rev 6.1 > [ 18.010743] omapdss_dss 5800.dss: bound 58001000.dispc (ops > dispc_component_ops [omapdrm]) > [ 18.025076] omap-hdmi-audio omap-hdmi-audio.2.auto: snd-soc-dummy-dai <-> > 5804.encoder mapping ok > [ 18.050076] omapdss_dss 5800.dss: bound 5804.encoder (ops > hdmi5_component_ops [omapdrm]) > [ 18.074540] omapdss_dss 5800.dss: master bind failed: -517 If I disable HDMI audio, the spam goes away, and I just get: [ 14.783558] dmm 4e00.dmm: initialized all PAT entries [ 14.805775] DSS: OMAP DSS rev 6.1 [ 14.809989] omapdss_dss 5800.dss: bound 58001000.dispc (ops dispc_component_ops [omapdrm]) [ 14.821844] omapdss_dss 5800.dss: bound 5804.encoder (ops hdmi5_component_ops [omapdrm]) [ 14.833482] omapdss_dss 5800.dss: master bind failed: -517 When I remove modules, something is left enabled as I get: [ 99.623954] platform 5800.dss: enabled after unload, idling If, after loading omapdrm as above, I also load encoder/panel drivers, I get a picture after a spam of "omapdss_dss 5800.dss: master bind failed: -517" and "alloc_contig_range: [fd874, fd875) PFNs busy" messages. But then, I can't unload any modules as they are all in use. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the sound-asoc tree with the drm-misc tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in:
drivers/gpu/drm/amd/include/amd_shared.h
between commit:
cfa289fd4986c ("drm/amdgpu: rename amdgpu_dpm_funcs to amd_pm_funcs")
from the drm-misc tree and commit:
1e4448648333a ("drm/amdgpu Moving amdgpu asic types to a separate file")
from the sound-asoc 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.
diff --cc drivers/gpu/drm/amd/include/amd_shared.h
index de6fc2731b98,3a49fbd8baf8..
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@@ -23,37 -23,10 +23,39 @@@
#ifndef __AMD_SHARED_H__
#define __AMD_SHARED_H__
- #define AMD_MAX_USEC_TIMEOUT 20 /* 200 ms */
+ #include
+struct seq_file;
+
+/*
+ * Supported ASIC types
+ */
+enum amd_asic_type {
+ CHIP_TAHITI = 0,
+ CHIP_PITCAIRN,
+ CHIP_VERDE,
+ CHIP_OLAND,
+ CHIP_HAINAN,
+ CHIP_BONAIRE,
+ CHIP_KAVERI,
+ CHIP_KABINI,
+ CHIP_HAWAII,
+ CHIP_MULLINS,
+ CHIP_TOPAZ,
+ CHIP_TONGA,
+ CHIP_FIJI,
+ CHIP_CARRIZO,
+ CHIP_STONEY,
+ CHIP_POLARIS10,
+ CHIP_POLARIS11,
+ CHIP_POLARIS12,
+ CHIP_VEGA10,
+ CHIP_RAVEN,
+ CHIP_LAST,
+};
+
+ #define AMD_MAX_USEC_TIMEOUT 20 /* 200 ms */
+
/*
* Chip flags
*/
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
On Sun, Oct 15, 2017 at 12:06:44AM +0530, Harsha Sharma wrote: > Replace instances of drm_framebuffer_reference/unreference() with > *_get/put() suffixes and drm_dev_unref with *_put() suffix > because get/put is shorter and consistent with the > kernel use of *_get/put suffixes. > Done with following coccinelle semantic patch > > @@ > expression ex; > @@ > > ( > -drm_framebuffer_unreference(ex); > +drm_framebuffer_put(ex); > | > -drm_dev_unref(ex); > +drm_dev_put(ex); > | > -drm_framebuffer_reference(ex); > +drm_framebuffer_get(ex); > ) > > Signed-off-by: Harsha Sharma Applied to drm-intel, thanks. -Daniel > --- > Changes in v5: > -rebase drm_dev_put change on drm-tip > Changes in v4: > -change one instance of *_put to *_get > Changes in v3: > -Removed changes in selftests > Changes in v2: > -Added cocinelle patch in log message > -cc to all driver-specific mailing lists > drivers/gpu/drm/i915/i915_pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c > index bf467f30c99b..1223961c3700 100644 > --- a/drivers/gpu/drm/i915/i915_pci.c > +++ b/drivers/gpu/drm/i915/i915_pci.c > @@ -645,7 +645,7 @@ static void i915_pci_remove(struct pci_dev *pdev) > struct drm_device *dev = pci_get_drvdata(pdev); > > i915_driver_unload(dev); > - drm_dev_unref(dev); > + drm_dev_put(dev); > } > > static int i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id > *ent) > -- > 2.11.0 > -- 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: linux-next: manual merge of the sound-asoc tree with the drm-misc tree
On Wed, Oct 18, 2017 at 10:57:33AM +0100, Mark Brown wrote:
> 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.
Actually I'm just going to discard the AMD drivers from the ASoC tree
because the build produces reams of errors like those below, the changes
to move the chip type definitions around weren't fully baked. Please
resend both the pull request and the patches with this fixed. Note also
that if you're basing something on Linus' tree you should use a tagged
release rather than just a random commit.
In file included from
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu.h:51:0,
from
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:31:
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd_shared.h:33:6:
error: nested redefinition of 'enum amd_asic_type'
enum amd_asic_type {
^
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd_shared.h:33:6:
error: redeclaration of 'enum amd_asic_type'
In file included from
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/../include/amd_shared.h:26:0,
from
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu.h:51,
from
/home/broonie/tmpfs/next/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c:31:
/home/broonie/tmpfs/next/include/drm/amd_asic_type.h:28:6: note: originally
defined here
enum amd_asic_type {
^
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102566] [IGT][KBL] pm_rc6_residency@rc6-accuracy is failing with assertion: ratio > 0.9 && ratio <= 1
https://bugs.freedesktop.org/show_bug.cgi?id=102566 Chris Wilson changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Resolution|--- |FIXED Status|NEEDINFO|RESOLVED Component|DRM/Intel |IGT --- Comment #5 from Chris Wilson --- commit 62616c672a623b635141473133674321a4acbdc5 (upstream/master, origin/master, origin/HEAD) Author: Chris Wilson Date: Tue Oct 17 11:19:38 2017 +0100 igt/pm_rc6_residency: Allow some leeway on the upper %% bound As we use rounding when converting from hw clocks to time, we may report a residency greater than wallclock (by a small margin), so allow us to overshoot by 5% (just due to our inaccuracy). -- 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: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync
On 18.10.2017 10:10, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote: On 17.10.2017 19:16, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote: On 17/10/17 05:04 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: On 17/10/17 02:22 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: Common sense suggests that there need to be two side to FreeSync / VESA Adaptive Sync support: 1. Query the display capabilities. This means querying minimum / maximum refresh duration, plus possibly a query for when the earliest/latest timing of the *next* refresh. 2. Signal desired present time. This means passing a target timer value instead of a target vblank count, e.g. something like this for the KMS interface: int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, void *user_data, uint64_t target); + a flag to indicate whether target is the vblank count or the CLOCK_MONOTONIC (?) time in ns. drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative sync should probably only be supported via the atomic API, presumably via output properties. +1 At least now that DC is on track to land properly, and you want to do this for DC-only anyway there's no reason to pimp the legacy interfaces further. And atomic is soo much easier to extend. The big question imo is where we need to put the flag on the kms side, since freesync is not just about presenting earlier, but also about presenting later. But for backwards compat we can't stretch the refresh rate by default for everyone, or clients that rely on high precision timestamps and regular refresh will get a bad surprise. The idea described above is that adaptive sync would be used for flips with a target timestamp. Apps which don't want to use adaptive sync wouldn't set a target timestamp. I think a boolean enable_freesync property is probably what we want, which enables freesync for as long as it's set. The question then becomes under what circumstances the property is (not) set. Not sure offhand this will actually solve any problem, or just push it somewhere else. I thought that's what the driconf switch is for, with a policy of "please schedule asap" instead of a specific timestamp. The driconf switch is just for the user's intention to use adaptive sync when possible. A property as you suggest cannot be set by the client directly, because it can't know when adaptive sync can actually be used (only when its window is fullscreen and using page flipping). So the property would have to be set by the X server/driver / Wayland compositor / ... instead. The question is whether such a property is actually needed, or whether the kernel could just enable adaptive sync when there's a flip with a target timestamp, and disable it when there's a flip without a target timestamp, or something like that. If your adaptive sync also supports extending the vblank beyond the nominal limit, then you can't do that with a per-flip flag. Because absent of a userspace requesting adaptive sync you must flip at the nominal vrefresh rate. So if your userspace is a tad bit late with the frame and would like to extend the frame to avoid missing a frame entirely it'll be too late by the time the vblank actually gets submitted. That's a bit a variation of what Ville brought up about what we're going to do when the timestamp was missed by the time all the depending fences signalled. These are very good points. It does sound like we'd need both an "AdaptiveSync" boolean property and an (optional) "DesiredPresentTime" property. The DesiredPresentTime property applies only to a single commit and could perhaps be left out in a first version. The AdaptiveSync property is persistent. When enabled, it means: - handle page flip requests as soon as possible - while no page flip is requested, delay vblank as long as possible How does that sound? Yeah, that's what I had in mind. No idea it'll work out on real hw/full stack. Here's another question that occurred to me while thinking about how all this could be prototyped. What happens when a FreeSync aware application / compositor enables the FreeSync property and then shuts down (crashes) without disabling it again? It seems to me that a non-FreeSync aware compositor would then be operating in FreeSync mode without expecting it. Can we fix that somehow? Do we care? Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102566] [IGT][KBL] pm_rc6_residency@rc6-accuracy is failing with assertion: ratio > 0.9 && ratio <= 1
https://bugs.freedesktop.org/show_bug.cgi?id=102566 Marta Löfstedt changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #6 from Marta Löfstedt --- Reproduced on GLK-shards: (pm_rc6_residency:2203) CRITICAL: Test assertion failure function residency_accuracy, file pm_rc6_residency.c:85: (pm_rc6_residency:2203) CRITICAL: Failed assertion: ratio > 0.9 && ratio <= 1 (pm_rc6_residency:2203) CRITICAL: Sysfs RC6 residency counter is inaccurate. Subtest rc6-accuracy failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3252/shard-glkb5/igt@pm_rc6_reside...@rc6-accuracy.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102566] [IGT][KBL] pm_rc6_residency@rc6-accuracy is failing with assertion: ratio > 0.9 && ratio <= 1
https://bugs.freedesktop.org/show_bug.cgi?id=102566 Chris Wilson changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Chris Wilson --- Which as you will note is from before the fix. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/9] drm/exynos: fimc: Convert driver to IPP v2 core API
Hi Marek,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.14-rc5 next-20171017]
[cannot apply to drm-exynos/exynos-drm/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/Exynos-DRM-rewrite-IPP-subsystem-and-userspace-API/20171017-211928
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
Note: the
linux-review/Marek-Szyprowski/Exynos-DRM-rewrite-IPP-subsystem-and-userspace-API/20171017-211928
HEAD 57651df66b6c59b10ecb5e6a2048c05cc273afa9 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c:1255:4: error: implicit declaration
>> of function 'IPP_SCALE_LIMIT' [-Werror=implicit-function-declaration]
{ IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
^~~
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c:1255:20: error: expected expression
>> before '.' token
{ IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
^
drivers/gpu/drm/exynos/exynos_drm_fimc.c:1264:20: error: expected expression
before '.' token
{ IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
^
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c:1264:20: error: '(const struct
>> drm_exynos_ipp_limit *)&' is a pointer; did you mean
>> to use '->'?
>> drivers/gpu/drm/exynos/exynos_drm_fimc.c:1264:4: error: initializer element
>> is not constant
{ IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
^~~
drivers/gpu/drm/exynos/exynos_drm_fimc.c:1264:4: note: (near initialization
for 'fimc_4210_limits_v2[3].type')
cc1: some warnings being treated as errors
vim +/IPP_SCALE_LIMIT +1255 drivers/gpu/drm/exynos/exynos_drm_fimc.c
1250
1251 static const struct drm_exynos_ipp_limit fimc_4210_limits_v1[] = {
1252 { IPP_SIZE_LIMIT(BUFFER, .h = {32, 8192, 8}, .v = {32, 8192,
2}) },
1253 { IPP_SIZE_LIMIT(AREA, .h = {32, 4224, 2}, .v = {32, 0, 2}) },
1254 { IPP_SIZE_LIMIT(ROTATED, .h = {128, 1920}, .v = {128, 0}) },
> 1255 { IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
1256.v = { (1 << 16) / 64, (1 << 16) * 64}) },
1257 { }
1258 };
1259
1260 static const struct drm_exynos_ipp_limit fimc_4210_limits_v2[] = {
1261 { IPP_SIZE_LIMIT(BUFFER, .h = {32, 8192, 8}, .v = {32, 8192,
2}) },
1262 { IPP_SIZE_LIMIT(AREA, .h = {32, 1920, 2}, .v = {32, 0, 2}) },
1263 { IPP_SIZE_LIMIT(ROTATED, .h = {128, 1366}, .v = {128, 0}) },
> 1264 { IPP_SCALE_LIMIT(.h = { (1 << 16) / 64, (1 << 16) * 64},
1265.v = { (1 << 16) / 64, (1 << 16) * 64}) },
1266 { }
1267 };
1268
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304
--- Comment #3 from Nicolai Hähnle ---
After thinking about it some more, I think it's very likely that your
application also has a bug, a write-after-read bug to be precise.
What I'm suspecting is that you're doing this:
Thread 1 Thread 2
glBindTexture(tex);
glDraw*(...);
glFlush();
glTextureSubImage(tex, ...);
Unless you use glFinish() or glFenceSync() / glWaitSync() synchronization,
there is no guarantee that thread 1's draw has completed before thread 2's
texture change. In other words, the implementation is allowed to execute the
texture modification *before* the draw. Especially with Gallium threading, this
is quite likely to happen.
(We still also have a bug in the driver, but until I can actually double-check
your code, I'd say it's quite likely that you have a write-after-read hazard
like the one explained above.)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] amdkfd next 4.15
Hi Dave, This is the amdkfd pull request for 4.15 merge window. The patches here are relevant only for Kaveri and Carrizo. Still no dGPU patches. The main goal is to continue alignment with the internal AMD development tree. The following is a summary of the changes: - Improvements and fixes to suspend/resume code - Improvements and fixes to process termination code - Cleanups in the queue unmapping functionality - Reuse code from amdgpu Thanks, Oded The following changes since commit 40d86701a625eed9e644281b9af228d6a52d8ed9: drm/plane: drop num_overlay_planes (v3) (2017-10-17 11:32:29 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2017-10-18 for you to fetch changes up to e139cd2a2ff842bd4a5d089b9d251ca62f58ecac: drm/amdkfd: Improve multiple SDMA queues support per process (2017-09-27 00:09:56 -0400) Felix Kuehling (5): drm/amdkfd: Adjust dequeue latencies and timeouts drm/amdkfd: Fix MQD updates drm/amdkfd: Improve process termination handling drm/amdkfd: Clean up process queue management drm/amdkfd: Limit queue number per process and device to 127 Yong Zhao (11): drm/amdkfd: Reorganize kfd resume code drm/amdkfd: Fix suspend/resume issue on Carrizo v2 drm/amdkfd: Rectify the jiffies calculation error with milliseconds v2 drm/amdkfd: Use VMID bitmap from KGD v2 drm/amdkfd: Reuse CHIP_* from amdgpu v2 drm/amdkfd: Drop _nocpsch suffix from shared functions drm/amdkfd: Avoid name confusion involved in queue unmapping drm/amdkfd: move locking outside of unmap_queues_cpsch drm/amdkfd: Pass filter params to unmap_queues_cpsch drm/amdkfd: Avoid submitting an unnecessary packet to HWS drm/amdkfd: Compress unnecessary function parameters shaoyunl (1): drm/amdkfd: Improve multiple SDMA queues support per process drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 3 +- drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 14 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c| 106 ++--- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 440 ++--- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 13 +- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 20 +- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 3 + drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c| 29 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 77 ++-- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 131 -- .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 64 +-- 11 files changed, 562 insertions(+), 338 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] vgaarb: Factor out EFI and fallback default device selection
Daniel Vetter writes:
> On Wed, Oct 18, 2017 at 11:24:43AM +1100, Daniel Axtens wrote:
>> Hi Daniel,
>>
>> >> Initially I wondered if this info printk could be moved into
>> >> vga_arbiter_check_bridge_sharing(), but it's been separated out since
>> >> 3448a19da479b ("vgaarb: use bridges to control VGA routing where
>> >> possible."), and upon closer examination, it seems you can't be sure a
>> >> device doesn't share a bridge until the end of the process, so this is
>> >> indeed correct.
>> >>
>> >> Everything else also looks good to me.
>> >>
>> >> Reviewed-by: Daniel Axtens
>> >
>> > R-b for both patches? And ok with everyone if I pull this into drm-misc
>> > for 4.15 (deadline is end of this week for feature-y stuff)?
>>
>> I had only intended it for patch 2, but I've now read over patch 1 to my
>> satisfaction, so it too is:
>>
>> Reviewed-by: Daniel Axtens
>
> Both applied for 4.15, thanks.
Cool - thanks!
A special thanks to Bjorn for persisting with this and coming up with a
nice simple solution :)
Regards,
Daniel
> -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: [Mesa-dev] Upstream support for FreeSync / Adaptive Sync
On 17.10.2017 21:53, Ville Syrjälä wrote: On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote: On 17.10.2017 16:09, Ville Syrjälä wrote: On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote: On 17/10/17 02:22 PM, Daniel Vetter wrote: On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote: On 17/10/17 11:34 AM, Nicolai Hähnle wrote: Common sense suggests that there need to be two side to FreeSync / VESA Adaptive Sync support: 1. Query the display capabilities. This means querying minimum / maximum refresh duration, plus possibly a query for when the earliest/latest timing of the *next* refresh. 2. Signal desired present time. This means passing a target timer value instead of a target vblank count, e.g. something like this for the KMS interface: int drmModePageFlipTarget64(int fd, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, void *user_data, uint64_t target); + a flag to indicate whether target is the vblank count or the CLOCK_MONOTONIC (?) time in ns. drmModePageFlip(Target) is part of the pre-atomic KMS API, but adapative sync should probably only be supported via the atomic API, presumably via output properties. +1 At least now that DC is on track to land properly, and you want to do this for DC-only anyway there's no reason to pimp the legacy interfaces further. And atomic is soo much easier to extend. The big question imo is where we need to put the flag on the kms side, since freesync is not just about presenting earlier, but also about presenting later. But for backwards compat we can't stretch the refresh rate by default for everyone, or clients that rely on high precision timestamps and regular refresh will get a bad surprise. The idea described above is that adaptive sync would be used for flips with a target timestamp. Apps which don't want to use adaptive sync wouldn't set a target timestamp. I think a boolean enable_freesync property is probably what we want, which enables freesync for as long as it's set. The question then becomes under what circumstances the property is (not) set. Not sure offhand this will actually solve any problem, or just push it somewhere else. Finally I'm not sure we want to insist on a target time for freesync. At least as far as I understand things you just want "as soon as possible". This might change with some of the VK/EGL/GLX extensions where you specify a precise timing (media playback). But that needs a bit more work to make it happen I think, so perhaps better to postpone. I don't see why. There's an obvious use case for this now, for video playback. At least VDPAU already has target timestamps for this. Also note that right now no driver expect amdgpu has support for a target vblank on a flip. That's imo another reason for not requiring target support for at least basic freesync support. I think that's a bad reason. :) Adding it for atomic drivers shouldn't be that hard. Apart from the actual implementation hurdles it does open up some new questions: All good questions, thanks! Let me try to take a crack at them: - Is it going to be per-plane or per-crtc? My understanding is that planes are combined to form a single signal that goes out to the monitor(s). The planes are scanned out together by a crtc, so it should be per-crtc. I guess one might imagine a compositor with one video player type of client, and another game/benchmark type of client. If both clients queue their next frames around the same time, the compositor might think to combine them to a single atomic ioctl call. But it's possible the video player client would want its frame presented much later than the other client, which would require a per-plane timestamp. But I guess it's not totally unreasonable to ask the compositor to do two ioctls in this case since we aren't actually looking for a single atomic update of two planes. Right. And remember that the desired time stamp isn't about when the planes get switched out, but about when the vblank happens. You can't have different vblank times for different planes going to the same monitor. - What happens if the target timestamp is already stale? - What happens if the target timestamp is good when it gets scheduled, but can't be met once the fences and whatnot have signalled? Treat it as "flip as soon as possible" in both cases. - What happens if another operation is already queued with a more recent timestamp? This is a problem already today, isn't it? You could have two page flips being queued before the next vblank. What happens in that case? I think currently we get -EBUSY. But there's has been talk about replacing queued flips, async flips, etc. so it seems like people are starting to want something a bit different. I guess it's always possible to start with the EBUSY idea and change it later with some kind of flags or something. Not sure how well flags work with at
[Bug 103168] [CI] igt@prime_mmap_coherency@[write-and-fail|write] - fai - Failed assertion: !(!stale)
https://bugs.freedesktop.org/show_bug.cgi?id=103168 Marta Löfstedt changed: What|Removed |Added Summary|[CI]|[CI] |igt@prime_mmap_coherency@wr |igt@prime_mmap_coherency@[w |ite-and-fail - fai - Failed |rite-and-fail|write] - fai |assertion: !(!stale)|- Failed assertion: ||!(!stale) --- Comment #2 from Marta Löfstedt --- Also, GLK-shards fail on igt@prime_mmap_coherency@write (prime_mmap_coherency:1627) CRITICAL: Test assertion failure function main, file prime_mmap_coherency.c:302: (prime_mmap_coherency:1627) CRITICAL: Failed assertion: !(stale) (prime_mmap_coherency:1627) CRITICAL: num of stale cache lines 304 Subtest write failed. DEBUG (prime_mmap_coherency:1627) DEBUG: Test requirement passed: !(errno == EINVAL) https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3255/shard-glkb4/igt@prime_mmap_cohere...@write.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103168] [CI] igt@prime_mmap_coherency@[write-and-fail|write] - fai - Failed assertion: !(!stale)
https://bugs.freedesktop.org/show_bug.cgi?id=103168 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Chris Wilson --- Test removed in commit 22fdae38cbad3794a315bfd8d9fd833eba4a35dc Author: Chris Wilson Date: Wed Oct 11 10:51:22 2017 +0100 igt/prime_mmap_coherency: Only assert correct usage of sync API Ignore the unexpected success when the CPU cache is randomly flushed that makes !llc appear to work without sync. It happens, the cpu cache is a fickle beast that we do not have sole control over. Instead limit the test to detect failures when the API is being adhered to. -- 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 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 --- Comment #4 from Luc --- Yes, we use the glFenceSync() / glWaitSync() system. We have multiple buffers going around and after each vsync a check is done which can be recycled using the non blocking glWaitSync. However, will check if this is done everywhere correctly in our code. Reason of the multi-threading was the format change done during texture upload (which took a lot of cpu power). However, now we do this in a worker thread with optimized code, before doing the texture upload (so to assure the format is compatible with the GPU before requesting the texture upload). Therefore I adapted the code so that both (texture upload and rendering/flush) are now done in one thread as a work around. -- 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 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, &arg) == -22
https://bugs.freedesktop.org/show_bug.cgi?id=103107 --- Comment #3 from Marta Löfstedt --- Also, GLK-shards (gem_ctx_param:1501) CRITICAL: Test assertion failure function __real_main31, file gem_ctx_param.c:152: (gem_ctx_param:1501) CRITICAL: Failed assertion: __gem_context_set_param(fd, &arg) == -22 (gem_ctx_param:1501) CRITICAL: error: 0 != -22 Subtest invalid-param-set failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3255/shard-glkb5/igt@gem_ctx_pa...@invalid-param-set.html (gem_ctx_param:1476) CRITICAL: Test assertion failure function __real_main31, file gem_ctx_param.c:147: (gem_ctx_param:1476) CRITICAL: Failed assertion: __gem_context_get_param(fd, &arg) == -22 (gem_ctx_param:1476) CRITICAL: error: 0 != -22 Subtest invalid-param-get failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3255/shard-glkb3/igt@gem_ctx_pa...@invalid-param-get.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/9] drm/bridge: analogix_dp: Fix connector & encoder cleanup
Since we are initing connector in the core driver and encoder in the
plat driver, let's clean them up in the right places.
Signed-off-by: Jeffy Chen
---
Changes in v5: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 --
drivers/gpu/drm/exynos/exynos_dp.c | 7 +--
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 15 ++-
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 74d274b6d31d..3f910ab36ff6 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1409,7 +1409,6 @@ analogix_dp_bind(struct device *dev, struct drm_device
*drm_dev,
ret = analogix_dp_create_bridge(drm_dev, dp);
if (ret) {
DRM_ERROR("failed to create bridge (%d)\n", ret);
- drm_encoder_cleanup(dp->encoder);
goto err_disable_pm_runtime;
}
@@ -1432,7 +1431,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
{
analogix_dp_bridge_disable(dp->bridge);
dp->connector.funcs->destroy(&dp->connector);
- dp->encoder->funcs->destroy(dp->encoder);
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index f7e5b2c405ed..33319a858f3a 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct
device *master, void *data)
dp->plat_data.encoder = encoder;
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
return 0;
}
@@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct
device *master,
{
struct exynos_dp_device *dp = dev_get_drvdata(dev);
- return analogix_dp_unbind(dp->adp);
+ analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops exynos_dp_ops = {
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index fa0365de31d2..c0fb3f3748f4 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -261,13 +261,8 @@ static struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
-static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
- .destroy = rockchip_dp_drm_encoder_destroy,
+ .destroy = drm_encoder_cleanup,
};
static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
@@ -361,12 +356,13 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
- rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
-
dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
- if (IS_ERR(dp->adp))
+ if (IS_ERR(dp->adp)) {
+ dp->encoder.funcs->destroy(&dp->encoder);
return PTR_ERR(dp->adp);
+ }
+ rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
return 0;
}
@@ -377,6 +373,7 @@ static void rockchip_dp_unbind(struct device *dev, struct
device *master,
rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dp->adp);
+ dp->encoder.funcs->destroy(&dp->encoder);
}
static const struct component_ops rockchip_dp_component_ops = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/9] drm/bridge: analogix: Do not use device's drvdata
The driver that instantiates the bridge should own the drvdata, as all
driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
owned by its driver struct. Moreover, storing two different pointer
types in driver data depending on driver initialization status is barely
a good practice and in fact has led to many bugs in this driver.
Let's clean up this mess and change Analogix entry points to simply
accept some opaque struct pointer, adjusting their users at the same
time to avoid breaking the compilation.
Signed-off-by: Tomasz Figa
Signed-off-by: Jeffy Chen
Reviewed-by: Andrzej Hajda
Reviewed-by: Sean Paul
Acked-by: Jingoo Han
Acked-by: Archit Taneja
---
Changes in v5: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 50 +-
drivers/gpu/drm/exynos/exynos_dp.c | 26 ++-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 49 -
include/drm/bridge/analogix_dp.h | 19
4 files changed, 74 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5dd3f1cd074a..74d274b6d31d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,17 +98,15 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
return 0;
}
-int analogix_dp_psr_supported(struct device *dev)
+int analogix_dp_psr_supported(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
return dp->psr_support;
}
EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
-int analogix_dp_enable_psr(struct device *dev)
+int analogix_dp_enable_psr(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
if (!dp->psr_support)
@@ -129,9 +127,8 @@ int analogix_dp_enable_psr(struct device *dev)
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
-int analogix_dp_disable_psr(struct device *dev)
+int analogix_dp_disable_psr(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
int ret;
@@ -1281,8 +1278,9 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux
*aux,
return analogix_dp_transfer(dp, msg);
}
-int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
-struct analogix_dp_plat_data *plat_data)
+struct analogix_dp_device *
+analogix_dp_bind(struct device *dev, struct drm_device *drm_dev,
+struct analogix_dp_plat_data *plat_data)
{
struct platform_device *pdev = to_platform_device(dev);
struct analogix_dp_device *dp;
@@ -1292,14 +1290,12 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
if (!plat_data) {
dev_err(dev, "Invalided input plat_data\n");
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
}
dp = devm_kzalloc(dev, sizeof(struct analogix_dp_device), GFP_KERNEL);
if (!dp)
- return -ENOMEM;
-
- dev_set_drvdata(dev, dp);
+ return ERR_PTR(-ENOMEM);
dp->dev = &pdev->dev;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1316,7 +1312,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
ret = analogix_dp_dt_parse_pdata(dp);
if (ret)
- return ret;
+ return ERR_PTR(ret);
dp->phy = devm_phy_get(dp->dev, "dp");
if (IS_ERR(dp->phy)) {
@@ -1330,14 +1326,14 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
if (ret == -ENOSYS || ret == -ENODEV)
dp->phy = NULL;
else
- return ret;
+ return ERR_PTR(ret);
}
}
dp->clock = devm_clk_get(&pdev->dev, "dp");
if (IS_ERR(dp->clock)) {
dev_err(&pdev->dev, "failed to get clock\n");
- return PTR_ERR(dp->clock);
+ return ERR_CAST(dp->clock);
}
clk_prepare_enable(dp->clock);
@@ -1346,7 +1342,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
dp->reg_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dp->reg_base))
- return PTR_ERR(dp->reg_base);
+ return ERR_CAST(dp->reg_base);
dp->force_hpd = of_property_read_bool(dev->of_node, "force-hpd");
@@ -1367,7 +1363,7 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
"hpd_gpio");
if (ret) {
dev_err(&pdev->dev, "failed to get hpd gpio\n");
- return ret;
+ return ERR_PTR(ret);
[PATCH v5 0/9] rockchip: kevin: Enable edp display
Make edp display works on chromebook kevin(at least for boot animation). Also solve some issues i meet during the bringup. Changes in v5: Call the destroy hook in the error handling path like in unbind(). Call the destroy hook in the error handling path like in unbind(). Update cleanup order in unbind(). Add disable to unbind(), and inline clk_prepare_enable() with bind(). Jeffy Chen (9): arm64: dts: rockchip: Enable edp disaplay on kevin drm/rockchip: analogix_dp: Remove unnecessary init code drm/bridge: analogix: Do not use device's drvdata drm/bridge: analogix_dp: Fix connector & encoder cleanup drm/rockchip: dw-mipi-dsi: Fix error handling path drm/rockchip: inno_hdmi: Fix error handling path drm/bridge/synopsys: dw-hdmi: Add missing bridge detach drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata drm/rockchip: dw_hdmi: Fix error handling path arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 16 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 52 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 53 ++--- drivers/gpu/drm/exynos/exynos_dp.c | 29 +--- drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +++--- drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 +++-- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 +++- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 87 ++ drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 -- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 39 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 22 -- include/drm/bridge/analogix_dp.h | 19 +++-- include/drm/bridge/dw_hdmi.h | 17 +++-- 14 files changed, 257 insertions(+), 183 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/9] drm/rockchip: dw-mipi-dsi: Fix error handling path
Add missing pm_runtime_disable() in bind()'s error handling path.
Also cleanup encoder & connector in unbind().
Fixes: 80a9a059d4e4 ("drm/rockchip/dsi: add dw-mipi power domain support")
Signed-off-by: Jeffy Chen
---
Changes in v5:
Call the destroy hook in the error handling path like in unbind().
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index b15755b6129c..e72d4e2b61aa 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1282,7 +1282,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = dw_mipi_dsi_register(drm, dsi);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register mipi_dsi: %d\n", ret);
- goto err_pllref;
+ goto err_disable_pllref;
}
pm_runtime_enable(dev);
@@ -1292,23 +1292,24 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
ret = mipi_dsi_host_register(&dsi->dsi_host);
if (ret) {
DRM_DEV_ERROR(dev, "Failed to register MIPI host: %d\n", ret);
- goto err_cleanup;
+ goto err_disable_pm_runtime;
}
if (!dsi->panel) {
ret = -EPROBE_DEFER;
- goto err_mipi_dsi_host;
+ goto err_unreg_mipi_dsi_host;
}
dev_set_drvdata(dev, dsi);
return 0;
-err_mipi_dsi_host:
+err_unreg_mipi_dsi_host:
mipi_dsi_host_unregister(&dsi->dsi_host);
-err_cleanup:
- drm_encoder_cleanup(&dsi->encoder);
- drm_connector_cleanup(&dsi->connector);
-err_pllref:
+err_disable_pm_runtime:
+ pm_runtime_disable(dev);
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+err_disable_pllref:
clk_disable_unprepare(dsi->pllref_clk);
return ret;
}
@@ -1320,6 +1321,10 @@ static void dw_mipi_dsi_unbind(struct device *dev,
struct device *master,
mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
+
+ dsi->connector.funcs->destroy(&dsi->connector);
+ dsi->encoder.funcs->destroy(&dsi->encoder);
+
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 7/9] drm/bridge/synopsys: dw-hdmi: Add missing bridge detach
We inited connector in attach(), so need a detach() to cleanup.
Also fix wrong use of dw_hdmi_remove() in bind().
Signed-off-by: Jeffy Chen
---
Changes in v5: None
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..ff1b3d2b5d06 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1966,6 +1966,13 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
*bridge)
return 0;
}
+static void dw_hdmi_bridge_detach(struct drm_bridge *bridge)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ drm_connector_cleanup(&hdmi->connector);
+}
+
static enum drm_mode_status
dw_hdmi_bridge_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
@@ -2022,6 +2029,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
.attach = dw_hdmi_bridge_attach,
+ .detach = dw_hdmi_bridge_detach,
.enable = dw_hdmi_bridge_enable,
.disable = dw_hdmi_bridge_disable,
.mode_set = dw_hdmi_bridge_mode_set,
@@ -2591,7 +2599,7 @@ int dw_hdmi_bind(struct platform_device *pdev, struct
drm_encoder *encoder,
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
- dw_hdmi_remove(pdev);
+ __dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
return ret;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/9] drm/rockchip: analogix_dp: Remove unnecessary init code
Remove unnecessary init code, since we would do it in the power_on()
callback.
Also move of parse code to probe().
Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip platform dp driver")
Signed-off-by: Jeffy Chen
---
Changes in v5: None
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 27 ++---
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 4d3f6ad0abdd..8cae5ad926cd 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -269,7 +269,7 @@ static struct drm_encoder_funcs rockchip_dp_encoder_funcs =
{
.destroy = rockchip_dp_drm_encoder_destroy,
};
-static int rockchip_dp_init(struct rockchip_dp_device *dp)
+static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
@@ -303,19 +303,6 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
return PTR_ERR(dp->rst);
}
- ret = clk_prepare_enable(dp->pclk);
- if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
- return ret;
- }
-
- ret = rockchip_dp_pre_init(dp);
- if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "failed to pre init %d\n", ret);
- clk_disable_unprepare(dp->pclk);
- return ret;
- }
-
return 0;
}
@@ -361,10 +348,6 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
if (!dp_data)
return -ENODEV;
- ret = rockchip_dp_init(dp);
- if (ret < 0)
- return ret;
-
dp->data = dp_data;
dp->drm_dev = drm_dev;
@@ -398,7 +381,6 @@ static void rockchip_dp_unbind(struct device *dev, struct
device *master,
rockchip_drm_psr_unregister(&dp->encoder);
analogix_dp_unbind(dev, master, data);
- clk_disable_unprepare(dp->pclk);
}
static const struct component_ops rockchip_dp_component_ops = {
@@ -414,7 +396,7 @@ static int rockchip_dp_probe(struct platform_device *pdev)
int ret;
ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel, NULL);
- if (ret)
+ if (ret < 0)
return ret;
dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
@@ -422,9 +404,12 @@ static int rockchip_dp_probe(struct platform_device *pdev)
return -ENOMEM;
dp->dev = dev;
-
dp->plat_data.panel = panel;
+ ret = rockchip_dp_of_probe(dp);
+ if (ret < 0)
+ return ret;
+
/*
* We just use the drvdata until driver run into component
* add function, and then we would set drvdata to null, so
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/9] drm/rockchip: inno_hdmi: Fix error handling path
Add missing error handling in bind().
Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
Signed-off-by: Jeffy Chen
---
Changes in v5:
Call the destroy hook in the error handling path like in unbind().
Update cleanup order in unbind().
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index ee584d87111f..9a96ff6b022b 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -851,8 +851,10 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
}
irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- return irq;
+ if (irq < 0) {
+ ret = irq;
+ goto err_disable_clk;
+ }
inno_hdmi_reset(hdmi);
@@ -860,7 +862,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
if (IS_ERR(hdmi->ddc)) {
ret = PTR_ERR(hdmi->ddc);
hdmi->ddc = NULL;
- return ret;
+ goto err_disable_clk;
}
/*
@@ -874,7 +876,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
ret = inno_hdmi_register(drm, hdmi);
if (ret)
- return ret;
+ goto err_put_adapter;
dev_set_drvdata(dev, hdmi);
@@ -884,7 +886,17 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
ret = devm_request_threaded_irq(dev, irq, inno_hdmi_hardirq,
inno_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
+ if (ret < 0)
+ goto err_cleanup_hdmi;
+ return 0;
+err_cleanup_hdmi:
+ hdmi->connector.funcs->destroy(&hdmi->connector);
+ hdmi->encoder.funcs->destroy(&hdmi->encoder);
+err_put_adapter:
+ i2c_put_adapter(hdmi->ddc);
+err_disable_clk:
+ clk_disable_unprepare(hdmi->pclk);
return ret;
}
@@ -896,8 +908,8 @@ static void inno_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
- clk_disable_unprepare(hdmi->pclk);
i2c_put_adapter(hdmi->ddc);
+ clk_disable_unprepare(hdmi->pclk);
}
static const struct component_ops inno_hdmi_ops = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 8/9] drm/bridge/synopsys: dw-hdmi: Do not use device's drvdata
Let plat drivers own the drvdata, so that they could cleanup resources
in their unbind().
Signed-off-by: Jeffy Chen
---
Changes in v5: None
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 22 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 20 ++
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 14 --
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 23 ---
include/drm/bridge/dw_hdmi.h| 17 ++--
6 files changed, 77 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ff1b3d2b5d06..6fbfafc5832b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2072,7 +2072,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
}
-void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
{
mutex_lock(&hdmi->mutex);
@@ -2098,13 +2098,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool
hpd, bool rx_sense)
}
mutex_unlock(&hdmi->mutex);
}
-
-void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
-{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
- __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
-}
EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
@@ -2140,9 +2133,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
*/
if (intr_stat &
(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
- __dw_hdmi_setup_rx_sense(hdmi,
-phy_stat & HDMI_PHY_HPD,
-phy_stat & HDMI_PHY_RX_SENSE);
+ dw_hdmi_setup_rx_sense(hdmi, phy_stat & HDMI_PHY_HPD,
+ phy_stat & HDMI_PHY_RX_SENSE);
if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
cec_notifier_set_phys_addr(hdmi->cec_notifier,
@@ -2512,8 +2504,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- platform_set_drvdata(pdev, hdmi);
-
return hdmi;
err_iahb:
@@ -2559,25 +2549,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/*
-
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
drm_bridge_add(&hdmi->bridge);
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_probe);
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
__dw_hdmi_remove(hdmi);
@@ -2587,31 +2575,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
/*
-
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+ struct drm_encoder *encoder,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
int ret;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
__dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..b01d03e02ce0 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -26,6 +26,8 @@ struct imx_hdmi {
[PATCH v5 9/9] drm/rockchip: dw_hdmi: Fix error handling path
Add missing clk_disable_unprepare() in bind()'s error handling path and
unbind().
Also inline clk_prepare_enable() with bind().
Fixes: 12b9f204e804 ("drm: bridge/dw_hdmi: add rockchip rk3288 support")
Signed-off-by: Jeffy Chen
---
Changes in v5:
Add disable to unbind(), and inline clk_prepare_enable() with bind().
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 791ab938f998..e936dfe6c03d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -193,13 +193,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
- ret = clk_prepare_enable(hdmi->vpll_clk);
- if (ret) {
- DRM_DEV_ERROR(hdmi->dev,
- "Failed to enable HDMI vpll: %d\n", ret);
- return ret;
- }
-
return 0;
}
@@ -374,6 +367,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev,
struct device *master,
return ret;
}
+ ret = clk_prepare_enable(hdmi->vpll_clk);
+ if (ret) {
+ DRM_DEV_ERROR(hdmi->dev,
+ "Failed to enable HDMI vpll: %d\n", ret);
+ return ret;
+ }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_encoder_init(drm, encoder, &dw_hdmi_rockchip_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
@@ -381,6 +381,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct
device *master,
hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
if (IS_ERR(hdmi->hdmi)) {
encoder->funcs->destroy(encoder);
+ clk_disable_unprepare(hdmi->vpll_clk);
return PTR_ERR(hdmi->hdmi);
}
@@ -396,6 +397,7 @@ static void dw_hdmi_rockchip_unbind(struct device *dev,
struct device *master,
dw_hdmi_unbind(hdmi->hdmi);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
+ clk_disable_unprepare(hdmi->vpll_clk);
}
static const struct component_ops dw_hdmi_rockchip_ops = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 --- Comment #5 from Nicolai Hähnle --- Interesting. It's possible that there's a gap in the glWaitSync implementation. I'm still looking into these things. -- 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 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 --- Comment #6 from Nicolai Hähnle --- Created attachment 134908 --> https://bugs.freedesktop.org/attachment.cgi?id=134908&action=edit simple sanity check patch Does the attached patch help? -- 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 04/48] drm: omapdrm: Merge the omapdss and omapdss-base modules
Hi Tomi, On Wednesday, 18 October 2017 12:19:26 EEST Tomi Valkeinen wrote: > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > On 13/10/17 17:59, Laurent Pinchart wrote: > > There's no need for the omapdss-base code to be part of a separate > > module. Merge it with the omapdss module. This allows removing the > > exports for internal symbols. > > The need was to support DSS6 driver, which is built as separate module. > That's not in the mainline yet. > > If we merge dss6 driver into the same omapdrm.ko, then there should be > no issues. As this series merges omapdrm and omapdss I think it would make sense to support DSS[2-5] and DSS6 in the same module (probably with a Kconfig option to select which variant(s) to support). -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103304] multi-threaded usage of Gallium RadeonSI leads to NULL pointer exception in pb_cache_reclaim_buffer
https://bugs.freedesktop.org/show_bug.cgi?id=103304 --- Comment #7 from Nicolai Hähnle --- Though on second thought, that patch should have no effect, assuming that you glFlush() properly after the glFenceSync(). -- 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 00/48] omapdrm: Merge omapdrm and omapdss
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 17:58, Laurent Pinchart wrote: > Hello, > > This patch series merges the omapdrm and omapdss drivers into a single driver > called omapdrm. The split in two drivers was historical, in order to support So how do the loadtime and runtime dependencies go with this series? In the current mainline, it's kind of clear: We have omapdss, and the panel and encoder drivers register themselves to omapdss. So panels and encoders depend on omapdss. On top of that we have omapdrm which then uses both omapdss and panels. Unloading happens in reverse order. With only omapdrm, the panels and encoders must depend on that. But omapdrm will use the panels, so there's a runtime dependency that way. Do we need to use sysfs's unbind first to remove some drivers, before module unloading is possible? Which ones? Does it work? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: remove dead igafb driver
igafb driver hasn't compiled since at least kernel v2.6.34 as
commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
missed updating igafb.c to use dp->phandle instead of dp->node.
Cc: "David S. Miller"
Cc: Bhumika Goyal
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/Kconfig | 10
drivers/video/fbdev/Makefile |1
drivers/video/fbdev/igafb.c | 579 ---
include/video/iga.h | 24 -
4 files changed, 614 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig 2017-10-18 14:35:21.927448311 +0200
+++ b/drivers/video/fbdev/Kconfig 2017-10-18 14:39:19.455445309 +0200
@@ -905,16 +905,6 @@ config FB_LEO
This is the frame buffer device driver for the SBUS-based Sun ZX
(leo) frame buffer cards.
-config FB_IGA
- bool "IGA 168x display support"
- depends on (FB = y) && SPARC32
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- help
- This is the framebuffer device for the INTERGRAPHICS 1680 and
- successor frame buffer cards.
-
config FB_XVR500
bool "Sun XVR-500 3DLABS Wildcat support"
depends on (FB = y) && PCI && SPARC64
Index: b/drivers/video/fbdev/Makefile
===
--- a/drivers/video/fbdev/Makefile 2017-10-18 14:35:21.927448311 +0200
+++ b/drivers/video/fbdev/Makefile 2017-10-18 14:39:30.555445169 +0200
@@ -64,7 +64,6 @@ obj-$(CONFIG_FB_HGA) += hga
obj-$(CONFIG_FB_XVR500) += sunxvr500.o
obj-$(CONFIG_FB_XVR2500) += sunxvr2500.o
obj-$(CONFIG_FB_XVR1000) += sunxvr1000.o
-obj-$(CONFIG_FB_IGA) += igafb.o
obj-$(CONFIG_FB_APOLLO) += dnfb.o
obj-$(CONFIG_FB_Q40) += q40fb.o
obj-$(CONFIG_FB_TGA) += tgafb.o
Index: b/drivers/video/fbdev/igafb.c
===
--- a/drivers/video/fbdev/igafb.c 2017-10-18 14:35:22.007448310 +0200
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,579 +0,0 @@
-/*
- * linux/drivers/video/igafb.c -- Frame buffer device for IGA 1682
- *
- * Copyright (C) 1998 Vladimir Roganov and Gleb Raiko
- *
- * This driver is partly based on the Frame buffer device for ATI Mach64
- * and partially on VESA-related code.
- *
- * Copyright (C) 1997-1998 Geert Uytterhoeven
- * Copyright (C) 1998 Bernd Harries
- * Copyright (C) 1998 Eddie C. Dost (e...@skynet.be)
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive for
- * more details.
- */
-
-/**
-
- TODO:
- Despite of IGA Card has advanced graphic acceleration,
- initial version is almost dummy and does not support it.
- Support for video modes and acceleration must be added
- together with accelerated X-Windows driver implementation.
-
- Most important thing at this moment is that we have working
- JavaEngine1 console & X with new console interface.
-
-**/
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#ifdef CONFIG_SPARC
-#include
-#include
-#endif
-
-#include
-
-struct pci_mmap_map {
-unsigned long voff;
-unsigned long poff;
-unsigned long size;
-unsigned long prot_flag;
-unsigned long prot_mask;
-};
-
-struct iga_par {
- struct pci_mmap_map *mmap_map;
- unsigned long frame_buffer_phys;
- unsigned long io_base;
-};
-
-struct fb_info fb_info;
-
-struct fb_fix_screeninfo igafb_fix __initdata = {
-.id= "IGA 1682",
- .type = FB_TYPE_PACKED_PIXELS,
- .mmio_len = 1000
-};
-
-struct fb_var_screeninfo default_var = {
- /* 640x480, 60 Hz, Non-Interlaced (25.175 MHz dotclock) */
- .xres = 640,
- .yres = 480,
- .xres_virtual = 640,
- .yres_virtual = 480,
- .bits_per_pixel = 8,
- .red= {0, 8, 0 },
- .green = {0, 8, 0 },
- .blue = {0, 8, 0 },
- .height = -1,
- .width = -1,
- .accel_flags= FB_ACCEL_NONE,
- .pixclock = 39722,
- .left_margin= 48,
- .right_margin = 16,
- .upper_margin = 33,
- .lower_margin = 10,
- .hsync_len = 96,
- .vsync_len = 2,
- .vmode = FB_VMODE_NONINTERLACED
-};
-
-#ifdef CONFIG_SPARC
-struct fb_var_screeninfo default_var_1024x768 __initdata = {
- /* 1024x768,
Re: [PATCH] video: fbdev: remove dead igafb driver
From: John Paul Adrian Glaubitz
Date: Wed, 18 Oct 2017 15:14:27 +0200
> Hi Bartlomiej!
>
> On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote:
>> igafb driver hasn't compiled since at least kernel v2.6.34 as
>> commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
>> missed updating igafb.c to use dp->phandle instead of dp->node.
> Would it take a lot of work to port the driver to the new interface?
>
> I'm not sure which SPARC machines use this particular framebuffer, but
> my plans are to fix up all these old framebuffer drivers. I have
> already
> received several Amiga (Zorro) graphics cards for testing the updated
> drivers on Amiga.
>
> It could be that I actually have this particular SPARC framebuffer in
> my hardware collection.
Unless you have a 32-bit sparc laptop, you don't have a machine that
will use this driver.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 4/9] drm/bridge: analogix_dp: Fix connector & encoder cleanup
On 18.10.2017 14:09, Jeffy Chen wrote:
> Since we are initing connector in the core driver and encoder in the
> plat driver, let's clean them up in the right places.
>
> Signed-off-by: Jeffy Chen
> ---
>
> Changes in v5: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 --
> drivers/gpu/drm/exynos/exynos_dp.c | 7 +--
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 15 ++-
> 3 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 74d274b6d31d..3f910ab36ff6 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1409,7 +1409,6 @@ analogix_dp_bind(struct device *dev, struct drm_device
> *drm_dev,
> ret = analogix_dp_create_bridge(drm_dev, dp);
> if (ret) {
> DRM_ERROR("failed to create bridge (%d)\n", ret);
> - drm_encoder_cleanup(dp->encoder);
> goto err_disable_pm_runtime;
> }
>
> @@ -1432,7 +1431,6 @@ void analogix_dp_unbind(struct analogix_dp_device *dp)
> {
> analogix_dp_bridge_disable(dp->bridge);
> dp->connector.funcs->destroy(&dp->connector);
> - dp->encoder->funcs->destroy(dp->encoder);
>
> if (dp->plat_data->panel) {
> if (drm_panel_unprepare(dp->plat_data->panel))
> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
> b/drivers/gpu/drm/exynos/exynos_dp.c
> index f7e5b2c405ed..33319a858f3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
> @@ -185,8 +185,10 @@ static int exynos_dp_bind(struct device *dev, struct
> device *master, void *data)
> dp->plat_data.encoder = encoder;
>
> dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
> - if (IS_ERR(dp->adp))
> + if (IS_ERR(dp->adp)) {
> + dp->encoder.funcs->destroy(&dp->encoder);
> return PTR_ERR(dp->adp);
> + }
>
> return 0;
> }
> @@ -196,7 +198,8 @@ static void exynos_dp_unbind(struct device *dev, struct
> device *master,
> {
> struct exynos_dp_device *dp = dev_get_drvdata(dev);
>
> - return analogix_dp_unbind(dp->adp);
> + analogix_dp_unbind(dp->adp);
> + dp->encoder.funcs->destroy(&dp->encoder);
> }
>
> static const struct component_ops exynos_dp_ops = {
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index fa0365de31d2..c0fb3f3748f4 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -261,13 +261,8 @@ static struct drm_encoder_helper_funcs
> rockchip_dp_encoder_helper_funcs = {
> .atomic_check = rockchip_dp_drm_encoder_atomic_check,
> };
>
> -static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
> - .destroy = rockchip_dp_drm_encoder_destroy,
> + .destroy = drm_encoder_cleanup,
> };
>
> static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
> @@ -361,12 +356,13 @@ static int rockchip_dp_bind(struct device *dev, struct
> device *master,
> dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
> INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
>
> - rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
> -
> dp->adp = analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
> - if (IS_ERR(dp->adp))
> + if (IS_ERR(dp->adp)) {
> + dp->encoder.funcs->destroy(&dp->encoder);
> return PTR_ERR(dp->adp);
> + }
>
> + rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
You are changing here order of calls: psr_reg after bind, it does not
seem to be related to patch subject.
Anyway psr_register can fail and its result is not checked, but it can
be addressed in separate patch.
So maybe it would be better to leave the order as is, unless there is
reason for change it in one patch, in such case please explain it in
commit message.
Beside this:
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> return 0;
> }
>
> @@ -377,6 +373,7 @@ static void rockchip_dp_unbind(struct device *dev, struct
> device *master,
>
> rockchip_drm_psr_unregister(&dp->encoder);
> analogix_dp_unbind(dp->adp);
> + dp->encoder.funcs->destroy(&dp->encoder);
> }
>
> static const struct component_ops rockchip_dp_component_ops = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-fence: remove duplicate word in comment
Signed-off-by: Frank Binns
---
include/linux/dma-fence.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index ca97422..efdabbb 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -128,7 +128,7 @@ struct dma_fence_cb {
* implementation know that there is another driver waiting on
* the signal (ie. hw->sw case).
*
- * This function can be called called from atomic context, but not
+ * This function can be called from atomic context, but not
* from irq context, so normal spinlocks can be used.
*
* A return value of false indicates the fence already passed,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103317] Tearing in WQHD, but not in FHD
https://bugs.freedesktop.org/show_bug.cgi?id=103317 Michel Dänzer changed: What|Removed |Added Attachment #134888|text/x-log |text/plain mime type|| -- 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 103317] Tearing in WQHD, but not in FHD
https://bugs.freedesktop.org/show_bug.cgi?id=103317 Michel Dänzer changed: What|Removed |Added Attachment #134889|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vblank: Fix flip event vblank count
On Wed, Oct 18, 2017 at 09:07:47AM +0200, Andrzej Hajda wrote: > Hi Ville, > > On 10.10.2017 15:33, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > On machines where the vblank interrupt fires some time after the start > > of vblank (or we just manage to race with the vblank interrupt handler) > > we will currently stuff a stale vblank counter value into the flip event, > > and thus we'll prematurely complete the flip. > > > > Switch over to drm_crtc_accurate_vblank_count() to make sure we have an > > up to date counter value, crucially also remember to add the +1 so that > > the delayed vblank interrupt won't complete the flip prematurely. > > > > Cc: sta...@vger.kernel.org > > Cc: Daniel Vetter > > Suggested-by: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_vblank.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index 70f2b9593edc..f14e6c92e332 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -869,7 +869,7 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc, > > assert_spin_locked(&dev->event_lock); > > > > e->pipe = pipe; > > - e->event.sequence = drm_vblank_count(dev, pipe); > > + e->event.sequence = drm_crtc_accurate_vblank_count(crtc) + 1; > > With this patch drm_crtc_arm_vblank_event calls > drm_crtc_accurate_vblank_count, which requires get_vblank_timestamp > callback, otherwise it issue WARN every time it is called. Argh! Maybe just remove the WARN then? > On the other side most of the users of drm_crtc_arm_vblank_event do not > implement this callback. As a result one can observe multiple WARNs. > It was observed on Exynos platform but grep shows it can affect many > other platforms: > > $ git grep -l drm_crtc_arm_vblank_event drivers/gpu/drm/ > drivers/gpu/drm/arm/hdlcd_crtc.c > drivers/gpu/drm/arm/malidp_drv.c > drivers/gpu/drm/drm_vblank.c > drivers/gpu/drm/exynos/exynos_drm_crtc.c > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > drivers/gpu/drm/i915/intel_sprite.c > drivers/gpu/drm/imx/ipuv3-crtc.c > drivers/gpu/drm/mxsfb/mxsfb_crtc.c > drivers/gpu/drm/nouveau/nouveau_display.c > drivers/gpu/drm/pl111/pl111_display.c > drivers/gpu/drm/sti/sti_crtc.c > drivers/gpu/drm/stm/ltdc.c > drivers/gpu/drm/sun4i/sun4i_crtc.c > drivers/gpu/drm/tve200/tve200_display.c > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > drivers/gpu/drm/zte/zx_vou.c > > $ git grep -l get_vblank_timestamp drivers/gpu/drm/ > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > drivers/gpu/drm/drm_vblank.c > drivers/gpu/drm/i915/i915_irq.c > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c > drivers/gpu/drm/nouveau/nouveau_drm.c > drivers/gpu/drm/radeon/radeon_drv.c > drivers/gpu/drm/vc4/vc4_drv.c > > Regards > Andrzej > > > e->event.crtc_id = crtc->base.id; > > list_add_tail(&e->base.link, &dev->vblank_event_list); > > } > -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103317] Tearing in WQHD, but not in FHD
https://bugs.freedesktop.org/show_bug.cgi?id=103317 --- Comment #2 from Michel Dänzer --- Please attach the output of xrandr --verbose while the problem occurs (i.e. while e.g. 0ad is running and showing flickering). Does not enabling TearFree or Option "EnablePageFlip" "off" avoid the problem? -- 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 v9 1/5] PCI: add a define for the PCI resource type mask v2
From: Christian König
We use this mask multiple times in the bus setup.
v2: fix some style nit picks
Signed-off-by: Christian König
Reviewed-by: Andy Shevchenko
---
drivers/pci/pci.h | 3 +++
drivers/pci/setup-bus.c | 12 +++-
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 22e061738c6f..5c475edc78c2 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -4,6 +4,9 @@
#define PCI_FIND_CAP_TTL 48
#define PCI_VSEC_ID_INTEL_TBT 0x1234 /* Thunderbolt */
+#define PCI_RES_TYPE_MASK \
+ (IORESOURCE_IO | IORESOURCE_MEM | IORESOURCE_PREFETCH |\
+IORESOURCE_MEM_64)
extern const unsigned char pcie_link_speed[];
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 958da7db9033..37450d9e1132 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1523,8 +1523,6 @@ static void pci_bridge_release_resources(struct pci_bus
*bus,
{
struct pci_dev *dev = bus->self;
struct resource *r;
- unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
unsigned old_flags = 0;
struct resource *b_res;
int idx = 1;
@@ -1567,7 +1565,7 @@ static void pci_bridge_release_resources(struct pci_bus
*bus,
*/
release_child_resources(r);
if (!release_resource(r)) {
- type = old_flags = r->flags & type_mask;
+ type = old_flags = r->flags & PCI_RES_TYPE_MASK;
dev_printk(KERN_DEBUG, &dev->dev, "resource %d %pR released\n",
PCI_BRIDGE_RESOURCES + idx, r);
/* keep the old size */
@@ -1758,8 +1756,6 @@ void pci_assign_unassigned_root_bus_resources(struct
pci_bus *bus)
enum release_type rel_type = leaf_only;
LIST_HEAD(fail_head);
struct pci_dev_resource *fail_res;
- unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
int pci_try_num = 1;
enum enable_type enable_local;
@@ -1818,7 +1814,7 @@ void pci_assign_unassigned_root_bus_resources(struct
pci_bus *bus)
*/
list_for_each_entry(fail_res, &fail_head, list)
pci_bus_release_bridge_resources(fail_res->dev->bus,
-fail_res->flags & type_mask,
+fail_res->flags &
PCI_RES_TYPE_MASK,
rel_type);
/* restore size and flags */
@@ -1862,8 +1858,6 @@ void pci_assign_unassigned_bridge_resources(struct
pci_dev *bridge)
LIST_HEAD(fail_head);
struct pci_dev_resource *fail_res;
int retval;
- unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
again:
__pci_bus_size_bridges(parent, &add_list);
@@ -1889,7 +1883,7 @@ void pci_assign_unassigned_bridge_resources(struct
pci_dev *bridge)
*/
list_for_each_entry(fail_res, &fail_head, list)
pci_bus_release_bridge_resources(fail_res->dev->bus,
-fail_res->flags & type_mask,
+fail_res->flags &
PCI_RES_TYPE_MASK,
whole_subtree);
/* restore size and flags */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5
From: Christian König
Most BIOS don't enable this because of compatibility reasons.
Manually enable a 64bit BAR of 64GB size so that we have
enough room for PCI devices.
v2: style cleanups, increase size, add resource name, set correct flags,
print message that windows was added
v3: add defines for all the magic numbers, style cleanups
v4: add some comment that the BIOS should actually allow this using
_PRS and _SRS.
v5: only enable this if CONFIG_PHYS_ADDR_T_64BIT is set
Signed-off-by: Christian König
Reviewed-by: Andy Shevchenko
---
arch/x86/pci/fixup.c | 80
1 file changed, 80 insertions(+)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 11e407489db0..7b6bd76713c5 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -618,3 +618,83 @@ static void quirk_apple_mbp_poweroff(struct pci_dev *pdev)
dev_info(dev, "can't work around MacBook Pro poweroff issue\n");
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10,
quirk_apple_mbp_poweroff);
+
+#ifdef CONFIG_PHYS_ADDR_T_64BIT
+
+#define AMD_141b_MMIO_BASE(x) (0x80 + (x) * 0x8)
+#define AMD_141b_MMIO_BASE_RE_MASK BIT(0)
+#define AMD_141b_MMIO_BASE_WE_MASK BIT(1)
+#define AMD_141b_MMIO_BASE_MMIOBASE_MASK GENMASK(31,8)
+
+#define AMD_141b_MMIO_LIMIT(x) (0x84 + (x) * 0x8)
+#define AMD_141b_MMIO_LIMIT_MMIOLIMIT_MASK GENMASK(31,8)
+
+#define AMD_141b_MMIO_HIGH(x) (0x180 + (x) * 0x4)
+#define AMD_141b_MMIO_HIGH_MMIOBASE_MASK GENMASK(7,0)
+#define AMD_141b_MMIO_HIGH_MMIOLIMIT_SHIFT 16
+#define AMD_141b_MMIO_HIGH_MMIOLIMIT_MASK GENMASK(23,16)
+
+/*
+ * The PCI Firmware Spec, rev 3.2 notes that ACPI should optionally allow
+ * configuring host bridge windows using the _PRS and _SRS methods.
+ *
+ * But this is rarely implemented, so we manually enable a large 64bit BAR for
+ * PCIe device on AMD Family 15h (Models 30h-3fh) Processors here.
+ */
+static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
+{
+ struct resource *res, *conflict;
+ u32 base, limit, high;
+ unsigned i;
+
+ for (i = 0; i < 8; ++i) {
+ pci_read_config_dword(dev, AMD_141b_MMIO_BASE(i), &base);
+ pci_read_config_dword(dev, AMD_141b_MMIO_HIGH(i), &high);
+
+ /* Is this slot free? */
+ if (!(base & (AMD_141b_MMIO_BASE_RE_MASK |
+ AMD_141b_MMIO_BASE_WE_MASK)))
+ break;
+
+ base >>= 8;
+ base |= high << 24;
+
+ /* Abort if a slot already configures a 64bit BAR. */
+ if (base > 0x1)
+ return;
+ }
+ if (i == 8)
+ return;
+
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return;
+
+ res->name = "PCI Bus :00";
+ res->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
+ IORESOURCE_MEM_64 | IORESOURCE_WINDOW;
+ res->start = 0x1ull;
+ res->end = 0xfdull - 1;
+
+ /* Just grab the free area behind system memory for this */
+ while ((conflict = request_resource_conflict(&iomem_resource, res)))
+ res->start = conflict->end + 1;
+
+ dev_info(&dev->dev, "adding root bus resource %pR\n", res);
+
+ base = ((res->start >> 8) & AMD_141b_MMIO_BASE_MMIOBASE_MASK) |
+ AMD_141b_MMIO_BASE_RE_MASK | AMD_141b_MMIO_BASE_WE_MASK;
+ limit = ((res->end + 1) >> 8) & AMD_141b_MMIO_LIMIT_MMIOLIMIT_MASK;
+ high = ((res->start >> 40) & AMD_141b_MMIO_HIGH_MMIOBASE_MASK) |
+ res->end + 1) >> 40) << AMD_141b_MMIO_HIGH_MMIOLIMIT_SHIFT)
+& AMD_141b_MMIO_HIGH_MMIOLIMIT_MASK);
+
+ pci_write_config_dword(dev, AMD_141b_MMIO_HIGH(i), high);
+ pci_write_config_dword(dev, AMD_141b_MMIO_LIMIT(i), limit);
+ pci_write_config_dword(dev, AMD_141b_MMIO_BASE(i), base);
+
+ pci_bus_add_resource(dev->bus, res, 0);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
+
+#endif
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 2/5] PCI: add resizeable BAR infrastructure v5
From: Christian König
Just the defines and helper functions to read the possible sizes of a BAR and
update it's size.
See
https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf
and PCIe r3.1, sec 7.22.
This is useful for hardware with large local storage (mostly GFX) which only
expose 256MB BARs initially to be compatible with 32bit systems.
v2: provide read helper as well
v3: improve function names, use unsigned values, add better comments.
v4: move definition, improve commit message, s/bar/BAR/
v5: split out helper to find ctrl reg pos, style fixes, comment fixes,
add pci_rbar_size_to_bytes as well
Signed-off-by: Christian König
Reviewed-by: Andy Shevchenko
---
drivers/pci/pci.c | 104 ++
drivers/pci/pci.h | 8
include/uapi/linux/pci_regs.h | 11 -
3 files changed, 121 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b4b7eab29400..3aca7393c43c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2957,6 +2957,110 @@ bool pci_acs_path_enabled(struct pci_dev *start,
}
/**
+ * pci_rbar_find_pos - find position of resize ctrl reg for BAR
+ * @dev: PCI device
+ * @bar: BAR to find
+ *
+ * Helper to find the postion of the ctrl register for a BAR.
+ * Returns -ENOTSUPP of resizeable BARs are not supported at all.
+ * Returns -ENOENT if not ctrl register for the BAR could be found.
+ */
+static int pci_rbar_find_pos(struct pci_dev *pdev, int bar)
+{
+ unsigned int pos, nbars;
+ unsigned int i;
+ u32 ctrl;
+
+ pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_REBAR);
+ if (!pos)
+ return -ENOTSUPP;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ nbars = (ctrl & PCI_REBAR_CTRL_NBAR_MASK) >> PCI_REBAR_CTRL_NBAR_SHIFT;
+
+ for (i = 0; i < nbars; ++i, pos += 8) {
+ int bar_idx;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ bar_idx = (ctrl & PCI_REBAR_CTRL_BAR_IDX_MASK) >>
+ PCI_REBAR_CTRL_BAR_IDX_SHIFT;
+ if (bar_idx == bar)
+ return pos;
+ }
+
+ return -ENOENT;
+}
+
+/**
+ * pci_rbar_get_possible_sizes - get possible sizes for BAR
+ * @dev: PCI device
+ * @bar: BAR to query
+ *
+ * Get the possible sizes of a resizeable BAR as bitmask defined in the spec
+ * (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizeable.
+ */
+u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar)
+{
+ u32 cap;
+ int pos;
+
+ pos = pci_rbar_find_pos(pdev, bar);
+ if (pos < 0)
+ return 0;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
+ return (cap & PCI_REBAR_CTRL_SIZES_MASK) >>
+ PCI_REBAR_CTRL_SIZES_SHIFT;
+}
+
+/**
+ * pci_rbar_get_current_size - get the current size of a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ *
+ * Read the size of a BAR from the resizeable BAR config.
+ * Returns size if found or negative error code.
+ */
+int pci_rbar_get_current_size(struct pci_dev *pdev, int bar)
+{
+ u32 ctrl;
+ int pos;
+
+ pos = pci_rbar_find_pos(pdev, bar);
+ if (pos < 0)
+ return pos;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ return (ctrl & PCI_REBAR_CTRL_BAR_SIZE_MASK) >>
+ PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+}
+
+/**
+ * pci_rbar_set_size - set a new size for a BAR
+ * @dev: PCI device
+ * @bar: BAR to set size to
+ * @size: new size as defined in the spec (0=1MB, 19=512GB)
+ *
+ * Set the new size of a BAR as defined in the spec.
+ * Returns zero if resizing was successful, error code otherwise.
+ */
+int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
+{
+ u32 ctrl;
+ int pos;
+
+ pos = pci_rbar_find_pos(pdev, bar);
+ if (pos < 0)
+ return pos;
+
+ pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
+ ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE_MASK;
+ ctrl |= size << PCI_REBAR_CTRL_BAR_SIZE_SHIFT;
+ pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
+ return 0;
+}
+
+/**
* pci_swizzle_interrupt_pin - swizzle INTx for device behind bridge
* @dev: the PCI device
* @pin: the INTx pin (1=INTA, 2=INTB, 3=INTC, 4=INTD)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 5c475edc78c2..1681895366dc 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -368,4 +368,12 @@ int acpi_get_rc_resources(struct device *dev, const char
*hid, u16 segment,
struct resource *res);
#endif
+u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar);
+int pci_rbar_get_current_size(struct pci_dev *pdev, int bar);
+int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size);
+static inline u64 pci_rbar_size_to_bytes(int size)
+{
+ return 1ULL << (size + 20
