Re: [Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers
On 05/19/2018 01:19 AM, Boris Ostrovsky wrote:
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 49 +++
include/xen/grant_table.h | 7 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e1dbcc..c27bcc420575 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -729,6 +729,55 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
}
EXPORT_SYMBOL(gnttab_free_pages);
+int gnttab_dma_alloc_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void **vaddr, dma_addr_t *dev_bus_addr)
+{
+ int i;
+ int ret;
+
+ ret = alloc_dma_xenballooned_pages(dev, coherent, nr_pages, pages,
+ vaddr, dev_bus_addr);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < nr_pages; i++) {
+#if BITS_PER_LONG < 64
+ struct xen_page_foreign *foreign;
+
+ foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
+ if (!foreign) {
+ gnttab_dma_free_pages(dev, flags, nr_pages, pages,
+ *vaddr, *dev_bus_addr);
+ return -ENOMEM;
+ }
+ set_page_private(pages[i], (unsigned long)foreign);
+#endif
+ SetPagePrivate(pages[i]);
+ }
+ return 0;
+}
+EXPORT_SYMBOL(gnttab_dma_alloc_pages);
+
+void gnttab_dma_free_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void *vaddr, dma_addr_t dev_bus_addr)
+{
+ int i;
+
+ for (i = 0; i < nr_pages; i++) {
+ if (PagePrivate(pages[i])) {
+#if BITS_PER_LONG < 64
+ kfree((void *)page_private(pages[i]));
+#endif
+ ClearPagePrivate(pages[i]);
+ }
+ }
+ free_dma_xenballooned_pages(dev, coherent, nr_pages, pages,
+ vaddr, dev_bus_addr);
+}
+EXPORT_SYMBOL(gnttab_dma_free_pages);
Given that these routines look almost exactly like their non-dma
counterparts I wonder whether common code could be factored out.
Yes, this can be done
-boris
+
/* Handling of paged out grant targets (GNTST_eagain) */
#define MAX_DELAY 256
static inline void
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 34b1379f9777..20ee2b5ba965 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -195,6 +195,13 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_dma_alloc_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void **vaddr, dma_addr_t *dev_bus_addr);
+void gnttab_dma_free_pages(struct device *dev, bool coherent,
+ int nr_pages, struct page **pages,
+ void *vaddr, dma_addr_t dev_bus_addr);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers
On 05/19/2018 01:04 AM, Boris Ostrovsky wrote:
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
A commit message would be useful.
Sure, v1 will have it
Signed-off-by: Oleksandr Andrushchenko
for (i = 0; i < nr_pages; i++) {
- page = alloc_page(gfp);
- if (page == NULL) {
- nr_pages = i;
- state = BP_EAGAIN;
- break;
+ if (ext_pages) {
+ page = ext_pages[i];
+ } else {
+ page = alloc_page(gfp);
+ if (page == NULL) {
+ nr_pages = i;
+ state = BP_EAGAIN;
+ break;
+ }
}
scrub_page(page);
list_add(&page->lru, &pages);
@@ -529,7 +565,7 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
i = 0;
list_for_each_entry_safe(page, tmp, &pages, lru) {
/* XENMEM_decrease_reservation requires a GFN */
- frame_list[i++] = xen_page_to_gfn(page);
+ frames[i++] = xen_page_to_gfn(page);
#ifdef CONFIG_XEN_HAVE_PVMMU
/*
@@ -552,18 +588,22 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
#endif
list_del(&page->lru);
- balloon_append(page);
+ if (!ext_pages)
+ balloon_append(page);
So what you are proposing is not really ballooning. You are just
piggybacking on existing interfaces, aren't you?
Sort of. Basically I need to {increase|decrease}_reservation, not actually
allocating ballooned pages.
Do you think I can simply EXPORT_SYMBOL for {increase|decrease}_reservation?
Any other suggestion?
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106589] HP w2207 monitor not waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #2 from Tom Seewald --- Created attachment 139655 --> https://bugs.freedesktop.org/attachment.cgi?id=139655&action=edit HP w2207 EDID Adding HP w2207 EDID -- 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 106589] HP w2207 monitor not waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #3 from Tom Seewald --- Created attachment 139656 --> https://bugs.freedesktop.org/attachment.cgi?id=139656&action=edit kernel config file Attaching config -- 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 106589] HP w2207 monitor not waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=106589 --- Comment #1 from Tom Seewald --- Created attachment 139654 --> https://bugs.freedesktop.org/attachment.cgi?id=139654&action=edit current kernel commandline Attaching kernel commandline. -- 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 106589] HP w2207 monitor not waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=106589 Bug ID: 106589 Summary: HP w2207 monitor not waking from sleep Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: tseew...@gmail.com Created attachment 139653 --> https://bugs.freedesktop.org/attachment.cgi?id=139653&action=edit dmesg on 4.17-rc6 Problem: After allowing both of my monitors to go to sleep, my HP w2207 is no longer detected as being connected to the computer, and cannot be woken up. Its display cable must be removed and reinserted into my AMD gpu for it to be detected. Expected: The monitor, like my other samsung, will wake up and the OS will see it as connected. Why I think this is possible to fix in software: The problem does not occur when using my 660Ti with Nvidia's 390.x driver. Hardware: GPU: RX 560 4GB Monitor 1: HP w2207 (Affected) Monitor 2: Samsung S23A700 (*Not* affected) I have tried DVI->DVI and DVI->HDMI cables with the HP w2207, no change in behavior. The monitor will not wake even when it is the only monitor connected. I have tested another monitor (an ancient 4:3 dell) in conjunction with the S23A700, and both wake normally. Software: Mesa version: 18.0 X11 version: 1.19.6 Kernel commandline: See attachment for one example (I have tried disabling amdgpu.dpm and amdgpu.dc to no effect) EDID: See attachments Kernel config: see attachments The only dmesg output before and after the sleep is: [drm] SADs count is: -2, don't need to read it [drm] SADs count is: -2, don't need to read it Kernels tested: 4.16.9 4.16.10 4.17-rc6 amd-drm-staging-next (current as of May 18th 2018) No changes between any of them. I also see that the kernel renames the display after a reconnect, I'm not sure if that is normal either. e.g. At boot: card1-HDMI-A-3 After unplugging/replugging: card1-HDMI-A-4 Please let me know what additional information or troubleshooting steps you would like me to take. Thanks for your time. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/mtk: Remove impossible internal error
On Fri, 2018-05-18 at 14:47 +0100, Daniel Stone wrote:
> We cannot create a framebuffer with no objects, so there's no point
> testing for it.
>
> v2: Remove the error entirely. (Sean, CK, Thierry)
>
Reviewed-by: CK Hu
> Signed-off-by: Daniel Stone
> Cc: Sean Paul
> Cc: Thierry Reding
> Cc: CK Hu
> Cc: Philipp Zabel
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 2f4b0ffee598..149fc4372917 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -95,11 +95,6 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
> if (!fb)
> return 0;
>
> - if (!mtk_fb_get_gem_obj(fb)) {
> - DRM_DEBUG_KMS("buffer is null\n");
> - return -EFAULT;
> - }
> -
> if (!state->crtc)
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199633] Stable kernel regression after 4.16.3: startxfce4 no longer works: X startup seems to hang
https://bugzilla.kernel.org/show_bug.cgi?id=199633 --- Comment #6 from Ant (untaintablean...@hotmail.co.uk) --- (Note that this patch was backported to 4.16 in 4.16.4, hence why 4.16.3 doesn't have the issue. But reverting the patch is ill-advised as it address an important security vulnerability.) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199633] Stable kernel regression after 4.16.3: startxfce4 no longer works: X startup seems to hang
https://bugzilla.kernel.org/show_bug.cgi?id=199633 Ant (untaintablean...@hotmail.co.uk) changed: What|Removed |Added CC||untaintablean...@hotmail.co ||.uk --- Comment #5 from Ant (untaintablean...@hotmail.co.uk) --- I've recently had the same issue caused by that very patch you mentioned (random: fix crng_ready() test) and had exactly the same problem. https://bugzilla.kernel.org/show_bug.cgi?id=199567 I installed rng-tools and turned back on options in my custom kernel that lead to more entropy generation (for example CONFIG_ATH9K_HWRNG) and can successfully use kernels past 4.17-rc1 (just before the patch was applied) again without any hang or lasting black screen. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 Ant (untaintablean...@hotmail.co.uk) changed: What|Removed |Added CC||untaintablean...@hotmail.co ||.uk --- Comment #4 from Ant (untaintablean...@hotmail.co.uk) --- Sounds like the same bug I had https://bugzilla.kernel.org/show_bug.cgi?id=199567 that started with rc2 onwards as well. Have a look at my findings (including the kernel commit that caused it) and see if it's the same issue. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199567] black screen irrespective of amdgpu.dc=1 or 0 at boot on kernels 4.17-rc2 and onwards caused by low entropy
https://bugzilla.kernel.org/show_bug.cgi?id=199567 Ant (untaintablean...@hotmail.co.uk) changed: What|Removed |Added Summary|[amdgpu] just a black |black screen irrespective |screen irrespective of |of amdgpu.dc=1 or 0 at boot |amdgpu.dc=1 or 0 at boot on |on kernels 4.17-rc2 and |kernels 4.17-rc2 and|onwards caused by low |onwards |entropy -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199567] [amdgpu] just a black screen irrespective of amdgpu.dc=1 or 0 at boot on kernels 4.17-rc2 and onwards
https://bugzilla.kernel.org/show_bug.cgi?id=199567 Ant (untaintablean...@hotmail.co.uk) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DOCUMENTED --- Comment #4 from Ant (untaintablean...@hotmail.co.uk) --- All sorted after finding the problem is known https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until-crng-init-done/442956#442956 specifically: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572#82 As the patch addresses an important vulnerability (CVE-2018-1108), it shouldn't be reverted. Instead, it is advised to install things like rng-tools and increase entropy generation. As the work to solve this is documented and well underway, I'm happy to close this bug. Cheers. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/fsl-dcu: fixes for v4.18
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: http://git.agner.ch/git/linux-drm-fsl-dcu.git tags/drm-fsl-dcu-fixes-for-v4.18 for you to fetch changes up to 63e482f172f4680a4ff00305dd140589ae270306: MAINTAINERS: drm: fsl-dcu: Update to Alison's NXP email address (2018-05-20 21:40:04 +0200) drm/fsl-dcu updates - Update MAINTAINERS file to reflect correct email address Fabio Estevam (1): MAINTAINERS: drm: fsl-dcu: Update to Alison's NXP email address MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] MAINTAINERS: drm: fsl-dcu: Update to Alison's NXP email address
On 20.05.2018 17:03, Fabio Estevam wrote: > From: Fabio Estevam > > The freescale.com email domain is not valid anymore, so use > the nxp.com domain instead. Applied, will send a pull request soon. Sorry about the delay. -- Stefan > > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - State that the fsl.com is not a valid domain anymore. > > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4923621..794c130 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4661,7 +4661,7 @@ F: > Documentation/devicetree/bindings/display/exynos/ > > DRM DRIVERS FOR FREESCALE DCU > M: Stefan Agner > -M: Alison Wang > +M: Alison Wang > L: dri-devel@lists.freedesktop.org > S: Supported > F: drivers/gpu/drm/fsl-dcu/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/vkms: Add basic CRTC initialization
A, I got it!
Thanks a lot Haneen :)
On Sun, May 20, 2018 at 1:44 PM, Haneen Mohammed
wrote:
> On Sun, May 20, 2018 at 11:28:37AM -0300, Rodrigo Siqueira wrote:
> > Hi Haneen,
> >
> > Thanks for the feedback :)
> >
> > On 05/20, Haneen Mohammed wrote:
> > > On Wed, May 16, 2018 at 08:56:21PM -0300, Rodrigo Siqueira wrote:
> > > > This commit adds the essential infrastructure for around CRTCs which
> > > > is composed of: a new data struct for output data information, a
> > > > function for creating planes, and a simple encoder attached to the
> > > > connector. Finally, due to the introduction of a new initialization
> > > > function, connectors were moved from vkms_drv.c to vkms_display.c.
> > > >
> > > > Signed-off-by: Rodrigo Siqueira
> > > > ---
> > > > drivers/gpu/drm/vkms/Makefile | 2 +-
> > > > drivers/gpu/drm/vkms/vkms_crtc.c | 35
> > > > drivers/gpu/drm/vkms/vkms_drv.c| 60 ++--
> > > > drivers/gpu/drm/vkms/vkms_drv.h| 24 +++-
> > > > drivers/gpu/drm/vkms/vkms_output.c | 91
> ++
> > > > drivers/gpu/drm/vkms/vkms_plane.c | 46 +++
> > > > 6 files changed, 211 insertions(+), 47 deletions(-)
> > > > create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c
> > > > create mode 100644 drivers/gpu/drm/vkms/vkms_output.c
> > > > create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/
> Makefile
> > > > index 2aef948d3a34..3f774a6a9c58 100644
> > > > --- a/drivers/gpu/drm/vkms/Makefile
> > > > +++ b/drivers/gpu/drm/vkms/Makefile
> > > > @@ -1,3 +1,3 @@
> > > > -vkms-y := vkms_drv.o
> > > > +vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o
> > > >
> > > > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > new file mode 100644
> > > > index ..bf76cd39ece7
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > @@ -0,0 +1,35 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * This program is free software; you can redistribute it and/or
> modify
> > > > + * it under the terms of the GNU General Public License as
> published by
> > > > + * the Free Software Foundation; either version 2 of the License, or
> > > > + * (at your option) any later version.
> > > > + */
> > > > +
> > > > +#include "vkms_drv.h"
> > > > +#include
> > > > +#include
> > > > +
> > > > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > > > + .set_config = drm_atomic_helper_set_config,
> > > > + .destroy= drm_crtc_cleanup,
> > > > + .page_flip = drm_atomic_helper_page_flip,
> > > > + .reset = drm_atomic_helper_crtc_reset,
> > > > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > > > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > > > +};
> > > > +
> > > > +int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > > > +struct drm_plane *primary, struct drm_plane *cursor)
> > > > +{
> > > > + int ret;
> > > > +
> > >
> > > Just as a follow up, I have noticed that vkms breaks when inspecting
> > > its state in the debugfs, also when running igt tests with kms and core
> > > filters, and adding the following fixed that issue:
> >
> > Could you explain me how you tested the state with debugfs?
> >
> > I will add the fixes suggested in your comments.
> >
> > Thanks
> >
>
> I just tried to read this file: /sys/kernel/debug/dri/0/state, which
> then caused a null pointer dereference error.
>
> > > 1) a drm_crtc_helper_funcs with dummy atomic_check.
> > >
> > > > + ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
> > > > + &vkms_crtc_funcs, NULL);
> > > > + if (ret) {
> > > > + DRM_ERROR("Failed to init CRTC\n");
> > > > + return ret;
> > > > + }
> > > > +
> > > > + return ret;
> > > > +}
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > index aec3f180f96d..070613e32934 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > @@ -6,7 +6,6 @@
> > > > */
> > > >
> > > > #include
> > > > -#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -59,25 +58,24 @@ static struct drm_driver vkms_driver = {
> > > > .minor = DRIVER_MINOR,
> > > > };
> > > >
> > > > -static const u32 vkms_formats[] = {
> > > > - DRM_FORMAT_XRGB,
> > > > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> > > > + .atomic_check = drm_atomic_helper_check,
> > > > + .atomic_commit = drm_atomic_helper_commit,
> > > > };
> > > >
> > > > -static void vkms_connector_destroy(struct drm_connector *connector)
> > > > +static int vkms_modeset_init(struct vkms_device *vkmsdev)
> > > > {
> > > > - drm_connector_unregis
[PATCH] drm/bridge: dw-hdmi: Switch to SPDX identifier
From: Fabio Estevam Adopt the SPDX license identifier headers to ease license compliance management. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index ec8d000..3bc62d5 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1,15 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * DesignWare High-Definition Multimedia Interface (HDMI) driver * * Copyright (C) 2013-2015 Mentor Graphics Inc. * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. * Copyright (C) 2010, Guennadi Liakhovetski - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * */ #include #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97025] flip queue failed: Device or resource busy
https://bugs.freedesktop.org/show_bug.cgi?id=97025 --- Comment #29 from Bernd Steinhauser --- (In reply to Michel Dänzer from comment #28) > (In reply to Bernd Steinhauser from comment #27) > > > > Although I'm not sure if it works as expected, since the display does still > > seem to disconnect when I turn the screen off. > > AFAIK that's either a monitor or general DisplayPort issue. The drivers > can't prevent it but have to cope with it. Quite possible. I've seen such behaviour on Windows as well on some displays. Don't really get it, it's very annoying if your windows are rearrange just because you turned off a display to save some power. Anyway back to topic: [595475.710884] [drm:amdgpu_atombios_dp_link_train] *ERROR* displayport link status failed [595475.710902] [drm:amdgpu_atombios_dp_link_train] *ERROR* clock recovery failed I do still get those messages sometimes, but at least I didn't experience any lockups or freezes. -- 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 v2] MAINTAINERS: drm: fsl-dcu: Update to Alison's NXP email address
From: Fabio Estevam The freescale.com email domain is not valid anymore, so use the nxp.com domain instead. Signed-off-by: Fabio Estevam --- Changes since v1: - State that the fsl.com is not a valid domain anymore. MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4923621..794c130 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4661,7 +4661,7 @@ F: Documentation/devicetree/bindings/display/exynos/ DRM DRIVERS FOR FREESCALE DCU M: Stefan Agner -M: Alison Wang +M: Alison Wang L: dri-devel@lists.freedesktop.org S: Supported F: drivers/gpu/drm/fsl-dcu/ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/vkms: Add basic CRTC initialization
Hi Haneen,
Thanks for the feedback :)
On 05/20, Haneen Mohammed wrote:
> On Wed, May 16, 2018 at 08:56:21PM -0300, Rodrigo Siqueira wrote:
> > This commit adds the essential infrastructure for around CRTCs which
> > is composed of: a new data struct for output data information, a
> > function for creating planes, and a simple encoder attached to the
> > connector. Finally, due to the introduction of a new initialization
> > function, connectors were moved from vkms_drv.c to vkms_display.c.
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/Makefile | 2 +-
> > drivers/gpu/drm/vkms/vkms_crtc.c | 35
> > drivers/gpu/drm/vkms/vkms_drv.c| 60 ++--
> > drivers/gpu/drm/vkms/vkms_drv.h| 24 +++-
> > drivers/gpu/drm/vkms/vkms_output.c | 91 ++
> > drivers/gpu/drm/vkms/vkms_plane.c | 46 +++
> > 6 files changed, 211 insertions(+), 47 deletions(-)
> > create mode 100644 drivers/gpu/drm/vkms/vkms_crtc.c
> > create mode 100644 drivers/gpu/drm/vkms/vkms_output.c
> > create mode 100644 drivers/gpu/drm/vkms/vkms_plane.c
> >
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index 2aef948d3a34..3f774a6a9c58 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -1,3 +1,3 @@
> > -vkms-y := vkms_drv.o
> > +vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o
> >
> > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > new file mode 100644
> > index ..bf76cd39ece7
> > --- /dev/null
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -0,0 +1,35 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include "vkms_drv.h"
> > +#include
> > +#include
> > +
> > +static const struct drm_crtc_funcs vkms_crtc_funcs = {
> > + .set_config = drm_atomic_helper_set_config,
> > + .destroy= drm_crtc_cleanup,
> > + .page_flip = drm_atomic_helper_page_flip,
> > + .reset = drm_atomic_helper_crtc_reset,
> > + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> > +};
> > +
> > +int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > + struct drm_plane *primary, struct drm_plane *cursor)
> > +{
> > + int ret;
> > +
>
> Just as a follow up, I have noticed that vkms breaks when inspecting
> its state in the debugfs, also when running igt tests with kms and core
> filters, and adding the following fixed that issue:
Could you explain me how you tested the state with debugfs?
I will add the fixes suggested in your comments.
Thanks
> 1) a drm_crtc_helper_funcs with dummy atomic_check.
>
> > + ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
> > + &vkms_crtc_funcs, NULL);
> > + if (ret) {
> > + DRM_ERROR("Failed to init CRTC\n");
> > + return ret;
> > + }
> > +
> > + return ret;
> > +}
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index aec3f180f96d..070613e32934 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -6,7 +6,6 @@
> > */
> >
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -59,25 +58,24 @@ static struct drm_driver vkms_driver = {
> > .minor = DRIVER_MINOR,
> > };
> >
> > -static const u32 vkms_formats[] = {
> > - DRM_FORMAT_XRGB,
> > +static const struct drm_mode_config_funcs vkms_mode_funcs = {
> > + .atomic_check = drm_atomic_helper_check,
> > + .atomic_commit = drm_atomic_helper_commit,
> > };
> >
> > -static void vkms_connector_destroy(struct drm_connector *connector)
> > +static int vkms_modeset_init(struct vkms_device *vkmsdev)
> > {
> > - drm_connector_unregister(connector);
> > - drm_connector_cleanup(connector);
> > -}
> > + struct drm_device *dev = &vkmsdev->drm;
> >
> > -static const struct drm_connector_funcs vkms_connector_funcs = {
> > - .fill_modes = drm_helper_probe_single_connector_modes,
> > - .destroy = vkms_connector_destroy,
> > -};
> > + drm_mode_config_init(dev);
> > + dev->mode_config.funcs = &vkms_mode_funcs;
> > + dev->mode_config.min_width = XRES_MIN;
> > + dev->mode_config.min_height = YRES_MIN;
> > + dev->mode_config.max_width = XRES_MAX;
> > + dev->mode_config.max_height = YRES_MAX;
> >
> > -static const struct drm_mode_config_funcs vkms_mode_funcs = {
> > - .atomic_check = drm_atomic_helper_c
Re: [PATCH 2/3] drm/rockchip: lvds: avoid duplicating drm_bridge_attach
Am Mittwoch, 2. Mai 2018, 09:40:24 CEST schrieb Peter Rosin: > drm_bridge_attach takes care of these assignments, so there is no need > to open-code them a second time. > > Signed-off-by: Peter Rosin applied to drm-misc-next Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199633] Stable kernel regression after 4.16.3: startxfce4 no longer works: X startup seems to hang
https://bugzilla.kernel.org/show_bug.cgi?id=199633 --- Comment #4 from Klaus Kusche (klaus.kus...@computerix.info) --- Found time to bisect, the result was a surprise: The culprit is the random patchset by Theodore Tso: [1/5] random: fix crng_ready() test [2/5] random: use a different mixing algorithm for add_device_randomness() [3/5] random: set up the NUMA crng instances after the CRNG is fully initialized [4/5] random: crng_reseed() should lock the crng instance that it is modifying [5/5] random: add new ioctl RNDRESEEDCRNG Don't know exactly which one of those five, because the results with only part of the patchset applied are inconsistent. To double-check the result, I installed a 4.16.9. X session startup failed as described above. Then I replaced drivers/char/random.c in 4.16.9 with the 4.16.3 version and this fixed X startup. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199493] no audio over HDMI with amdgpu.dc=1 (on R9 380X)
https://bugzilla.kernel.org/show_bug.cgi?id=199493 --- Comment #5 from har...@gmx.de --- Thank you for clarifiction, our observations/issues are similar obviously. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] arm64: dts: renesas: r8a77995-draak: add X12 input dot clock
Hi Ulrich, Thank you for the patch. On Wednesday, 16 May 2018 11:38:22 EEST Simon Horman wrote: > On Tue, May 15, 2018 at 02:20:40PM +0200, Ulrich Hecht wrote: > > 74.25 Mhz oscillator X12 is connected to DU_DOTCLKIN0. > > > > Signed-off-by: Ulrich Hecht Reviewed-by: Laurent Pinchart > > --- > > > > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 11 +++ > > 1 file changed, 11 insertions(+) > > This looks fine but I will wait to see if there are other reviews before > applying. > > Reviewed-by: Simon Horman As far as I'm concerned this patch can be merged already. I would however possibly hold off merging patch 3/5 and 4/5 until they can be tested. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm: Match sysfs name in link removal to link creation" has been added to the 4.16-stable tree
This is a note to let you know that I've just added the patch titled
drm: Match sysfs name in link removal to link creation
to the 4.16-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-match-sysfs-name-in-link-removal-to-link-creation.patch
and it can be found in the queue-4.16 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 7f6df440b8623c441c42d070bf592e2d2c1fa9bb Mon Sep 17 00:00:00 2001
From: Haneen Mohammed
Date: Fri, 11 May 2018 07:15:42 +0300
Subject: drm: Match sysfs name in link removal to link creation
From: Haneen Mohammed
commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream.
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().
Fixes: 6449b088dd51 ("drm: Add fake controlD* symlinks for backwards
compat")
Cc: Dave Airlie
Cc: Alex Deucher
Cc: Emil Velikov
Cc: David Herrmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Haneen Mohammed
[seanpaul added Fixes and Cc tags]
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20180511041542.GA4253@haneen-vb
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -716,7 +716,7 @@ static void remove_compat_control_link(s
if (!minor)
return;
- name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
+ name = kasprintf(GFP_KERNEL, "controlD%d", minor->index + 64);
if (!name)
return;
Patches currently in stable-queue which might be from hamohammed...@gmail.com
are
queue-4.16/drm-match-sysfs-name-in-link-removal-to-link-creation.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm: Match sysfs name in link removal to link creation" has been added to the 4.14-stable tree
This is a note to let you know that I've just added the patch titled
drm: Match sysfs name in link removal to link creation
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-match-sysfs-name-in-link-removal-to-link-creation.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From 7f6df440b8623c441c42d070bf592e2d2c1fa9bb Mon Sep 17 00:00:00 2001
From: Haneen Mohammed
Date: Fri, 11 May 2018 07:15:42 +0300
Subject: drm: Match sysfs name in link removal to link creation
From: Haneen Mohammed
commit 7f6df440b8623c441c42d070bf592e2d2c1fa9bb upstream.
This patch matches the sysfs name used in the unlinking with the
linking function. Otherwise, remove_compat_control_link() fails to remove
sysfs created by create_compat_control_link() in drm_dev_register().
Fixes: 6449b088dd51 ("drm: Add fake controlD* symlinks for backwards
compat")
Cc: Dave Airlie
Cc: Alex Deucher
Cc: Emil Velikov
Cc: David Herrmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Haneen Mohammed
[seanpaul added Fixes and Cc tags]
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20180511041542.GA4253@haneen-vb
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -749,7 +749,7 @@ static void remove_compat_control_link(s
if (!minor)
return;
- name = kasprintf(GFP_KERNEL, "controlD%d", minor->index);
+ name = kasprintf(GFP_KERNEL, "controlD%d", minor->index + 64);
if (!name)
return;
Patches currently in stable-queue which might be from hamohammed...@gmail.com
are
queue-4.14/drm-match-sysfs-name-in-link-removal-to-link-creation.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] arm64: dts: renesas: r8a77995-draak: add HDMI output
Hi Ulrich,
Thank you for the patch.
On Tuesday, 15 May 2018 15:20:39 EEST Ulrich Hecht wrote:
> Adds LVDS decoder, HDMI encoder and connector for Draak boards.
>
> Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 80 +++
> 1 file changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts index 9d73de8..b059e32
> 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -27,6 +27,41 @@
> stdout-path = "serial0:115200n8";
> };
>
> + lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> + vcc-supply = <®_3p3v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + thc63lvd1024_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + thc63lvd1024_out: endpoint {
> + remote-endpoint = <&adv7511_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_out: endpoint {
> + remote-endpoint = <&adv7511_out>;
> + };
> + };
> + };
> +
> vga {
> compatible = "vga-connector";
>
> @@ -154,6 +189,39 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + hdmi@39 {
> + compatible = "adi,adv7511w";
> + reg = <0x39>, <0x3f>, <0x38>, <0x3c>;
> + reg-names = "main", "edid", "packet", "cec";
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "rgb";
> + adi,input-clock = "1x";
> + adi,input-style = <1>;
> + adi,input-justification = "evenly";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511_in: endpoint {
> + remote-endpoint = <&thc63lvd1024_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_con_out>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -176,6 +244,18 @@
> };
> };
>
> +&lvds0 {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <&thc63lvd1024_in>;
> + };
> + };
> + };
> +};
> +
> &ehci0 {
> status = "okay";
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] arm64: dts: renesas: r8a77995: Add LVDS support
Hi Ulrich,
Thank you for the patch.
On Tuesday, 15 May 2018 15:20:38 EEST Ulrich Hecht wrote:
> From: Kieran Bingham
>
> The r8a77995 D3 platform has 2 LVDS channels connected to the DU.
>
> Signed-off-by: Kieran Bingham
> [uli: moved lvds* into the soc node, added PM domains, resets]
> Signed-off-by: Ulrich Hecht
> ---
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56
> 1 file changed, 56 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi index ba98865..8e78110d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -757,12 +757,68 @@
> port@1 {
> reg = <1>;
> du_out_lvds0: endpoint {
> + remote-endpoint = <&lvds0_in>;
> };
> };
>
> port@2 {
> reg = <2>;
> du_out_lvds1: endpoint {
> + remote-endpoint = <&lvds1_in>;
> + };
> + };
> + };
> + };
> +
> + lvds0: lvds-encoder@feb9 {
> + compatible = "renesas,r8a77995-lvds";
> + reg = <0 0xfeb9 0 0x20>;
> + clocks = <&cpg CPG_MOD 727>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 727>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds0_in: endpoint {
> + remote-endpoint =
> <&du_out_lvds0>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds0_out: endpoint {
> + };
> + };
> + };
> + };
> +
> + lvds1: lvds-encoder@feb90100 {
> + compatible = "renesas,r8a77995-lvds";
> + reg = <0 0xfeb90100 0 0x20>;
> + clocks = <&cpg CPG_MOD 727>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 727>;
While there seems to be a single clock for both LVDS encoders, it appears that
two separate reset lines are used.
Apart from that,
Reviewed-by: Laurent Pinchart
Given that the LVDS encoder driver isn't functional yet I wouldn't rule out a
need to update the LVDS DT bindings in order to properly support D3. I don't
mind if this patch gets merged already (provided the reset problem gets fixed
of course), as long as it won't be considered a blocker for DT bindings
rework. Otherwise I'd prefer delaying upstreaming until the whole series can
be tested.
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds1_in: endpoint {
> + remote-endpoint =
> <&du_out_lvds1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + lvds1_out: endpoint {
> };
> };
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: rcar-du: lvds: Add R8A77995 support
Hi Ulrich,
Thank you for the patch.
On Tuesday, 15 May 2018 15:20:37 EEST Ulrich Hecht wrote:
> Add support for the R-Car D3 (R8A77995) SoC to the LVDS encoder driver.
>
> Signed-off-by: Ulrich Hecht
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 3d2d3bb..58fb9f8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -511,6 +511,11 @@ static const struct rcar_lvds_device_info
> rcar_lvds_r8a77970_info = { .quirks = RCAR_LVDS_QUIRK_GEN2_PLLCR |
> RCAR_LVDS_QUIRK_GEN3_LVEN, };
>
> +static const struct rcar_lvds_device_info rcar_lvds_r8a77995_info = {
> + .gen = 3,
> + .quirks = RCAR_LVDS_QUIRK_GEN3_LVEN,
I'm afraid this won't be enough. With this patch the driver will call
rcar_lvds_lvdpllcr_gen3(), which writes values to the LVDPLLCR register that
don't match the register layout for D3.
While I'm fine with an initial version that doesn't support fine-grained
control of the LVDS PLL to achieve the HDMI clock accuracy requirements, we
need the LVDS encoder to be at least functional for the patches to get merged.
There are also other registers not related to the PLL that need to be set
(such as the LVDSTRIPE register), and other differences in register layouts
(for instance the D3 doesn't have a PLLON bit in register LVDC0).
Even the LVEN bit seems to need special handling on D3. According to version
1.00 of the datasheet it should be set to 1 at the same time as bit LVRES.
Could you please study the datasheet in details and update the code
accordingly ?
> +};
> +
> static const struct of_device_id rcar_lvds_of_table[] = {
> { .compatible = "renesas,r8a7743-lvds", .data = &rcar_lvds_gen2_info },
> { .compatible = "renesas,r8a7790-lvds", .data = &rcar_lvds_r8a7790_info
> },
> @@ -519,6 +524,7 @@ static const struct of_device_id rcar_lvds_of_table[] =
> { { .compatible = "renesas,r8a7795-lvds", .data = &rcar_lvds_gen3_info }, {
> .compatible = "renesas,r8a7796-lvds", .data = &rcar_lvds_gen3_info }, {
> .compatible = "renesas,r8a77970-lvds", .data = &rcar_lvds_r8a77970_info },
> + { .compatible = "renesas,r8a77995-lvds", .data =
> &rcar_lvds_r8a77995_info
> }, { }
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] R-Car D3 LVDS/HDMI support
Hi Ulrich, On Tuesday, 15 May 2018 15:20:35 EEST Ulrich Hecht wrote: > Hi! > > This adds D3 support to the DU and LVDS drivers, not including LVDS PLL > support. > > It also adds LVDS encoders to the D3 device tree, and LVDS decoder, HDMI > encoder and HDMI output connector to the Draak device tree. > > In theory that should be good enough to provide HDMI output on the Draak > board, but in practice the lack of LVDS PLL support prevents generation of > close-enough dot clock frequencies. > > This series is based on renesas-drivers-2018-05-02-v4.17-rc3 and requires > Jacopo's "drm: bridge: Add thc63lvd1024 LVDS decoder driver" patch. As HDMI output isn't functional yet this is difficult to test. Could you add support for the VGA output (using the DU DPAD) in v2 of the patch series ? VGA should work without LVDS PLL support as the clock frequency requirements are not as strict as for HDMI. > Kieran Bingham (1): > arm64: dts: renesas: r8a77995: Add LVDS support > > Koji Matsuoka (1): > drm: rcar-du: Add r8a77995 device support > > Ulrich Hecht (3): > drm: rcar-du: lvds: Add R8A77995 support > arm64: dts: renesas: r8a77995-draak: add HDMI output > arm64: dts: renesas: r8a77995-draak: add X12 input dot clock > > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 91 +++ > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 56 > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 > drivers/gpu/drm/rcar-du/rcar_lvds.c| 6 ++ > 4 files changed, 179 insertions(+) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: rcar-du: Add r8a77995 device support
Hi Ulrich,
Thank you for the patch.
On Tuesday, 15 May 2018 15:20:36 EEST Ulrich Hecht wrote:
> From: Koji Matsuoka
>
> Add support for the R-Car D3 (R8A77995) SoC to the R-Car DU driver.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Ulrich Hecht
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 05745e8..ba82842 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -266,6 +266,31 @@ static const struct rcar_du_device_info
> rcar_du_r8a77970_info = { .num_lvds = 1,
> };
>
> +static const struct rcar_du_device_info rcar_du_r8a77995_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> + | RCAR_DU_FEATURE_EXT_CTRL_REGS
> + | RCAR_DU_FEATURE_VSP1_SOURCE,
> + .num_crtcs = 2,
> + .routes = {
> + /* R8A77995 has two LVDS output and one RGB output.
> + */
This comment holds on a single line.
Apart from that the patch looks good to me, but it conflicts with
commit 5361cc7f8e9146f393cfcb76890d8c80a4e73086
Author: Kieran Bingham
Date: Fri Apr 27 23:21:52 2018 +0100
drm: rcar-du: Split CRTC handling to support hardware indexing
that has been queued in Dave's DRM tree for v4.18. The num_crtcs field has
been replaced with a channels_mask field. I can fix when applying but I can't
test the result as I don't have a D3 board, so I'd prefer if you could submit
a v2 rebased on top of Dave's drm-next branch.
I'm also wondering whether we also need
commit 6f3850955384cff722f02530f570806897b02a87
Author: Koji Matsuoka
Date: Wed Dec 6 20:30:24 2017 +0900
drm: rcar-du: Fix digital RGB routing for R8A77995
from the BSP. What's your opinion ?
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(0) | BIT(1),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS1] = {
> + .possible_crtcs = BIT(1),
> + .port = 2,
> + },
> + },
> + .num_lvds = 2,
> +};
> +
> static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
> @@ -278,6 +303,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
> { .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
> { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info },
> + { .compatible = "renesas,du-r8a77995", .data = &rcar_du_r8a77995_info },
> { }
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 06/24] drm/lima: add lima uapi header
On Fri, May 18, 2018 at 5:33 PM, Marek Vasut wrote:
>
> On 05/18/2018 11:27 AM, Qiang Yu wrote:
>
> Commit message is missing
>
> > Signed-off-by: Qiang Yu
> > ---
> > include/uapi/drm/lima_drm.h | 195
> > 1 file changed, 195 insertions(+)
> > create mode 100644 include/uapi/drm/lima_drm.h
> >
> > diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> > new file mode 100644
> > index ..9df95e46fb2c
> > --- /dev/null
> > +++ b/include/uapi/drm/lima_drm.h
>
> Please convert this to the SPDX license identifiers, that is
>
> // SPDX...
>
OK.
> > @@ -0,0 +1,195 @@
> > +/*
> > + * Copyright (C) 2017-2018 Lima Project
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
>
> [...]
>
> > +#if defined(__cplusplus)
> > +extern "C" {
> > +#endif
>
> Is this C++ stuff needed ?
>
This file is used by both kernel and user space programs, so I added this
following other xxx_drm.h files here.
> [...]
>
> > +#define LIMA_SUBMIT_FLAG_EXPLICIT_FENCE (1 << 0)
> > +#define LIMA_SUBMIT_FLAG_SYNC_FD_OUT(1 << 1)
>
> BIT(0) and BIT(1) if applicable
I can use BIT() for kernel only files but not this user/kernel shared one,
because I see BIT is defined in the kernel only, user need to define it if
this file use it.
> [...]
>
> --
> Best regards,
> Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 06/24] drm/lima: add lima uapi header
On Fri, May 18, 2018 at 5:33 PM, Marek Vasut wrote:
> On 05/18/2018 11:27 AM, Qiang Yu wrote:
>
> Commit message is missing
>
> > Signed-off-by: Qiang Yu
> > ---
> > include/uapi/drm/lima_drm.h | 195
> > 1 file changed, 195 insertions(+)
> > create mode 100644 include/uapi/drm/lima_drm.h
> >
> > diff --git a/include/uapi/drm/lima_drm.h b/include/uapi/drm/lima_drm.h
> > new file mode 100644
> > index ..9df95e46fb2c
> > --- /dev/null
> > +++ b/include/uapi/drm/lima_drm.h
>
> Please convert this to the SPDX license identifiers, that is
>
> // SPDX...
>
> OK.
> > @@ -0,0 +1,195 @@
> > +/*
> > + * Copyright (C) 2017-2018 Lima Project
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> obtaining a
> > + * copy of this software and associated documentation files (the
> "Software"),
> > + * to deal in the Software without restriction, including without
> limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
>
> [...]
>
> > +#if defined(__cplusplus)
> > +extern "C" {
> > +#endif
>
> Is this C++ stuff needed ?
>
This file is used by both kernel and user space programs, so I added this
following other xxx_drm.h files here.
>
> [...]
>
> > +#define LIMA_SUBMIT_FLAG_EXPLICIT_FENCE (1 << 0)
> > +#define LIMA_SUBMIT_FLAG_SYNC_FD_OUT(1 << 1)
>
> BIT(0) and BIT(1) if applicable
>
I can use BIT() for kernel only files but not this user/kernel shared one,
because I see BIT is defined in the kernel only, user need to define it if
this file use it.
> [...]
>
> --
> Best regards,
> Marek Vasut
>
Regards,
Qiang
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL FOR v4.17] R-Car DU regression fix
Hi Dave, This patch fixes a v4.17 regression. I'm sorry for sending it so late. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git drm/du/fixes for you to fetch changes up to 643ca198aacc671f32ef7c0c2783f0b539070a36: drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector (2018-05-20 10:16:59 +0300) Laurent Pinchart (1): drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector drivers/gpu/drm/rcar-du/rcar_lvds.c | 3 +++ 1 file changed, 3 insertions(+) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
