[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #23 from Alan W. Irwin --- Created attachment 141872 --> https://bugs.freedesktop.org/attachment.cgi?id=141872=edit tarball containing daemon.log, messages, kern.log, syslog, and dmesg output The previously described uptime test lasted (until the lockup this morning) for 9+ days, but the log files included nothing that seemed relevant. The next uptime test that started this morning for exactly the same graphics stack and kernel parameters lasted only 7 hours until a lockup, and this time the (attached) log files caught substantial error messages before the crash. @Michel Dänzer: Could you please take a look at this one to see whether there is some clue in the kernel error messages concerning the source of this instability? -- 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 108194] Civilization VI - Animated leader characters small black squares artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=108194 Bug ID: 108194 Summary: Civilization VI - Animated leader characters small black squares artifacts Product: Mesa Version: 18.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@psydk.org QA Contact: dri-devel@lists.freedesktop.org Created attachment 141871 --> https://bugs.freedesktop.org/attachment.cgi?id=141871=edit A leader character covered with multiple small black squares See the attached picture. I'm not sure if the problem is related to bug 108111 so I prefer opening a new one. If both are related to a LLVM regression it's possible we'll be able to close both. Computer info: OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.23.0, 4.15.0-34-generic, LLVM 7.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.1 - padoka PPA -- 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 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=101739 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Marek Olšák --- I pushed the workaround as commit 8e0b4cb8a1fcb1572be8eca16a806520aac08a61. Closing. -- 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] drm fixes for 4.19-rc7
Hi Greg, Nothing too much happening at this point, 3 i915 fixes: compressed error handling zlib fix compiler warning cleanup and a minor code cleanup 2 tda9950: Two fixes for the HDMI CEC 1 exynos: A fix required for IOMMU interaction. Thanks, Dave. drm-fixes-2018-10-04: drm exynos, tda9950 and intel fixes The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-10-04 for you to fetch changes up to d8938c981f58ee344687b7910a611ac345960045: Merge branch 'drm-tda9950-fixes' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes (2018-10-04 10:32:14 +1000) drm exynos, tda9950 and intel fixes Anusha Srivatsa (1): drm/i915: Do not redefine the has_csr parameter. Chris Wilson (2): drm/i915: Avoid compiler warning for maybe unused gu_misc_iir drm/i915: Handle incomplete Z_FINISH for compressed error states Colin Ian King (1): drm/i2c: tda9950: fix timeout counter check Dave Airlie (3): Merge tag 'exynos-drm-fixes-for-v4.19-rc7' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Merge tag 'drm-intel-fixes-2018-10-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-tda9950-fixes' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes Hans Verkuil (1): drm/i2c: tda9950: set MAX_RETRIES for errors only Marek Szyprowski (1): drm/exynos: Use selected dma_dev default iommu domain instead of a fake one drivers/gpu/drm/exynos/exynos_drm_iommu.h | 34 +++- drivers/gpu/drm/i2c/tda9950.c | 5 +- drivers/gpu/drm/i915/i915_gpu_error.c | 88 ++- drivers/gpu/drm/i915/i915_gpu_error.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 33 +--- drivers/gpu/drm/i915/i915_pci.c | 1 - 6 files changed, 85 insertions(+), 77 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 Marek Olšák changed: What|Removed |Added CC||mar...@gmail.com --- Comment #36 from Marek Olšák --- I'm looking into it. Disabling the vectorizer is one way to fix it. -- 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] mediatek drm next for 4.20
Hi, Dave: This include hdmi output support for mt2701 and mt7623. Regards, CK The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git mediatek-drm-next-4.20 for you to fetch changes up to 84dacb9cad2804a9f5434b775ccea6aa5d9fc6ca: drm/mediatek: add a error return value when clock driver has been prepared (2018-10-03 11:56:33 +0800) Bibby Hsieh (2): drm/mediatek: implement connection from BLS to DPI0 drm/mediatek: add a error return value when clock driver has been prepared chunhui dai (9): drm/mediatek: add refcount for DPI power on/off drm/mediatek: move hardware register to node data drm/mediatek: adjust EDGE to match clock and data drm/mediatek: add clock factor for different IC drm/mediatek: convert dpi driver to use drm_of_find_panel_or_bridge drm/mediatek: add dpi driver for mt2701 and mt7623 drm/mediatek: separate hdmi phy to different file drm/mediatek: add support for SPDIF audio in HDMI drm/mediatek: add hdmi driver for MT2701 and MT7623 drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 131 -- drivers/gpu/drm/mediatek/mtk_dpi_regs.h| 2 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 2 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 + drivers/gpu/drm/mediatek/mtk_hdmi.c| 15 +- drivers/gpu/drm/mediatek/mtk_hdmi.h| 2 +- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 235 + drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 60 +++ drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 212 ++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 226 +--- 12 files changed, 627 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm: Add connector property to limit max bpc
On Mon, Oct 01, 2018 at 09:23:38AM +0200, Daniel Vetter wrote:
> On Mon, Sep 24, 2018 at 02:08:14PM -0700, Radhakrishna Sripada wrote:
> > At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> > level shifters etc. To workaround them we may need to drive the output
> > at a lower bpc. Currently the user space does not have a way to limit
> > the bpc. The default bpc to be programmed is decided by the driver and
> > is run against connector limitations.
> >
> > Creating a new connector property "max bpc" in order to limit the bpc.
> > xrandr can make use of this connector property to make sure that bpc does
> > not exceed the configured value. This property can be used by userspace to
> > set the bpc.
> >
> > V2: Initialize max_bpc to satisfy kms_properties
> > V3: Move the property to drm_connector
> > V4: Split drm and i915 components(Ville)
> > V5: Make the property per connector(Ville)
> > V6: Compare the requested bpc to connector bpc(Daniel)
> > Move the attach_property function to core(Ville)
> > V7: Fix checkpatch warnings
> > V8: Simplify the connector check code(Ville)
> > V9: Const display_info(Ville)
> > V10: Fix CI issues.
> >
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Kishore Kadiyala
> > Cc: Rodrigo Vivi
> > Cc: Manasi Navare
> > Cc: Stanislav Lisovskiy
> > Cc: Sunpeng Li
> > Signed-off-by: Radhakrishna Sripada
>
> Skimming this, I think it looks good now at a high-level.
>
> What's missing is now kernel-doc for these new prorties, needs to be added
> here:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
>
> With that I'm happy with the high-level design:
>
> Acked-by: Daniel Vetter
>
> No full review since I didn't look at the igt side for this. Userspace I
> think is ok, since it's just another connector prop.
kms_properties would test this newly added property as part of the connector
properties.
Do you suggest me to add a new subtest to try checking the different values for
the
newly added property?
--Radhakrishna Sripada
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic.c| 5 +
> > drivers/gpu/drm/drm_atomic_helper.c | 4
> > drivers/gpu/drm/drm_atomic_uapi.c | 4
> > drivers/gpu/drm/drm_connector.c | 33 +
> > include/drm/drm_connector.h | 20
> > 5 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 2870ae205237..f328bcca84a8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> > drm_connector *connector,
> > {
> > struct drm_crtc_state *crtc_state;
> > struct drm_writeback_job *writeback_job = state->writeback_job;
> > + const struct drm_display_info *info = >display_info;
> >
> > if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> > !writeback_job)
> > return 0;
> > @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> > drm_connector *connector,
> > return -EINVAL;
> > }
> >
> > + state->max_bpc = info->bpc ? info->bpc : 8;
> > + if (connector->max_bpc_property)
> > + state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index e49b22381048..75aeca35f6d9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > if (old_connector_state->link_status !=
> > new_connector_state->link_status)
> > new_crtc_state->connectors_changed = true;
> > +
> > + if (old_connector_state->max_requested_bpc !=
> > + new_connector_state->max_requested_bpc)
> > + new_crtc_state->connectors_changed = true;
> > }
> >
> > if (funcs->atomic_check)
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index d5b7f315098c..86ac33922b09 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> >
> > return set_out_fence_for_connector(state->state, connector,
> >fence_ptr);
> > + } else if (property == connector->max_bpc_property) {
> > + state->max_requested_bpc = val;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -804,6 +806,8 @@
Re: [PATCH v2] mm: Introduce new function vm_insert_kmem_page
On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote: > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote: > > These are the approaches which could have been taken to handle > > this scenario - > > > > * Replace vm_insert_page with vmf_insert_page and then write few > >extra lines of code to convert VM_FAULT_CODE to errno which > >makes driver users more complex ( also the reverse mapping errno to > >VM_FAULT_CODE have been cleaned up as part of vm_fault_t migration , > >not preferred to introduce anything similar again) > > > > * Maintain both vm_insert_page and vmf_insert_page and use it in > >respective places. But it won't gurantee that vm_insert_page will > >never be used in #PF context. > > > > * Introduce a similar API like vm_insert_page, convert all non #PF > >consumer to use it and finally remove vm_insert_page by converting > >it to vmf_insert_page. > > > > And the 3rd approach was taken by introducing vm_insert_kmem_page(). > > > > In short, vmf_insert_page will be used in page fault handlers > > context and vm_insert_kmem_page will be used to map kernel > > memory to user vma outside page fault handlers context. > > As far as I can tell, vm_insert_kmem_page() is line-for-line identical > with vm_insert_page(). Seriously, here's a diff I just did: > > -static int insert_page(struct vm_area_struct *vma, unsigned long addr, > - struct page *page, pgprot_t prot) > +static int insert_kmem_page(struct vm_area_struct *vma, unsigned long addr, > + struct page *page, pgprot_t prot) > - /* Ok, finally just insert the thing.. */ > -int vm_insert_page(struct vm_area_struct *vma, unsigned long addr, > +int vm_insert_kmem_page(struct vm_area_struct *vma, unsigned long addr, > - return insert_page(vma, addr, page, vma->vm_page_prot); > + return insert_kmem_page(vma, addr, page, vma->vm_page_prot); > -EXPORT_SYMBOL(vm_insert_page); > +EXPORT_SYMBOL(vm_insert_kmem_page); > > What on earth are you trying to do? Reading the commit log, it seems that the intention is to split out vm_insert_page() used outside of page-fault handling with the use within page-fault handling, so that different return codes can be used. I don't see that justifies the code duplication - can't vm_insert_page() and vm_insert_kmem_page() use the same mechanics to do their job, and just translate the error code from the most- specific to the least-specific error code? Do we really need two copies of the same code just to return different error codes. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108110] hades canyon can not wake from dpms on mDP
https://bugs.freedesktop.org/show_bug.cgi?id=108110 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 | Component|DRM/Intel |DRM/AMDgpu -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/18] drm/vc4: Use drm_atomic_helper_shutdown
Daniel Vetter writes: > drm_plane_helper_disable is a non-atomic drivers only function, and > will blow up (since no one passes the locking context it needs). > > Atomic drivers which want to quiescent their hw on unload should > use drm_atomic_helper_shutdown() instead. > > v2: Rebase. I've definitely never tested unload. Looks like we could drop vc4_plane_destroy() entirely? Regardless, acked-by. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, Here goes drm-intel-fixes-2018-10-03: There's one fix for our zlib incomlete Z_FINISH on our error state handling, plus a compilation warning fix and a tiny code clean up. Thanks, Rodrigo. The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38: Linux 4.19-rc6 (2018-09-30 07:15:35 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-10-03 for you to fetch changes up to 4c9613ce556fdeb671e779668b627ea3a2b61728: drm/i915: Handle incomplete Z_FINISH for compressed error states (2018-10-03 08:02:42 -0700) There's one fix for our zlib incomlete Z_FINISH on our error state handling , plus a compilation warning fix and a tiny code clean up. Anusha Srivatsa (1): drm/i915: Do not redefine the has_csr parameter. Chris Wilson (2): drm/i915: Avoid compiler warning for maybe unused gu_misc_iir drm/i915: Handle incomplete Z_FINISH for compressed error states drivers/gpu/drm/i915/i915_gpu_error.c | 88 +-- drivers/gpu/drm/i915/i915_gpu_error.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 33 + drivers/gpu/drm/i915/i915_pci.c | 1 - 4 files changed, 76 insertions(+), 47 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] pci: Add a few new IDs for Intel GPU "spurious interrupt" quirk
On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> > > which are known to break.
> >
> > Do you have a reference for this? Any public bug reports, bugzilla,
> > Intel spec reference or errata? "Which are known to break" is pretty
> > vague.
>
> Sorry I used wrong words and should have been clearer. These devices
> are validated to be broken. The test I used is very simple, just
> unplug the VGA cable and plug it again, and "spurious interrupt" will
> be seen on the interrupt line of the IGD device. I was not aware of
> any public bugs filed to Intel, nor seen any errata from Intel.
The original commit, f67fd55fa96f ("PCI: Add quirk for still enabled
interrupts on Intel Sandy Bridge GPUs"), says some systems "crash"
(not sure if that means an oops or an actual crash that requires a
reboot) and on other systems, Linux disables the shared interrupt
line. I assume disabling the interrupt line keeps devices using that
line from working, but does not directly cause a crash.
What specific symptom do you see here? I think it might be useful to
collect details, e.g., dmesg logs, /proc/interrupts contents, output
of "sudo lspci -vv", etc., for the systems you're quirking here. I'm
hoping we can eventually figure out a solution that doesn't require a
quirk for every new GPU, and maybe that info will help find it.
> > > See commit f67fd55fa96f ("PCI: Add quirk for still enabled interrupts
> > > on Intel Sandy Bridge GPUs"), and commit 7c82126a94e6 ("PCI: Add new
> > > ID for Intel GPU "spurious interrupt" quirk") for some history.
> > >
> > > Based on current findings, it is highly possible that all Intel
> > > 1st/2nd/3rd generation Core processors' IGD has such quirk.
> >
> > Can you include a reference to these "current findings"? I assume you
> > have bug reports that include the device IDs you're adding? If not,
> > how did you build this list of new IDs?
>
> By "current findings" I mean given the IDs we have here, plus previous
> one added by Thomas, it's highly possible this VGA BIOS bug exists in
> every 1st/2nd/3rd generation Core processors.
>
> > The function comment added by f67fd55fa96f ("PCI: Add quirk for still
> > enabled interrupts on Intel Sandy Bridge GPUs") suggests that this is
> > actually a BIOS issue, not a hardware erratum, i.e., I don't see
> > anything there that suggests a hardware defect.
> >
> > But there must be a hole somewhere -- the kernel can't be expected to
> > disable interrupts in device-specific ways when there's no driver
> > loaded. Maybe it's simply a BIOS defect or maybe there's some
> > interrupt or _PRT-related setup we're missing.
>
> It's a pure VGA BIOS bug, not the BIOS bug or _PRT etc. The VGA BIOS
> forgot to turn off the interrupt on these devices.
If this is a VGA BIOS defect, it's not very likely that it will
magically be fixed for all new Intel GPUs, so in effect it sounds like
we need to update this list of quirks in Linux every time a new Intel
GPU comes out. That prospect is a little daunting.
Do you happen to know if Windows has the same problem? I.e., if you
boot an old version of Windows with a new GPU, and unplug the VGA
cable, does Windows crash? If Windows can figure out how to handle
that situation gracefully, Linux should be able to do it, too.
> > > Signed-off-by: Bin Meng
> > > Cc: # v3.4+
> > > ---
> > >
> > > drivers/pci/quirks.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > index 6bc27b7..c0673a7 100644
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -3190,7 +3190,11 @@ static void disable_igfx_irq(struct pci_dev *dev)
> > >
> > > pci_iounmap(dev, regs);
> > > }
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0042, disable_igfx_irq);
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0046, disable_igfx_irq);
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x004a, disable_igfx_irq);
> > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
> > > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0106, disable_igfx_irq);
> > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
> > > DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0152, disable_igfx_irq);
> > >
> > > --
>
> Regards,
> Bin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next-fixes for 4.20
Hi Dave, We've cut over to misc-next-fixes for 4.20, so just one patch this week. It's Neil's fix for mali binary driver. drm-misc-next-fixes-2018-10-03: - Add EXPERT config option to allow phys mem leak from fbdev for blob drivers (Neil) Cc: Neil Armstrong Cheers, Sean The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323: Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-09-28 09:48:40 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-10-03 for you to fetch changes up to 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a: drm/fb_helper: Allow leaking fbdev smem_start (2018-10-03 21:08:21 +0200) - Add EXPERT config option to allow phys mem leak from fbdev for blob drivers (Neil) Cc: Neil Armstrong Neil Armstrong (1): drm/fb_helper: Allow leaking fbdev smem_start drivers/gpu/drm/Kconfig | 20 drivers/gpu/drm/drm_fb_helper.c | 33 +++-- 2 files changed, 51 insertions(+), 2 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
>
> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
> >
> >
> > Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > > The variable is now referenced unconditionally, but still
> > > declared in an #ifdef:
> > >
> > > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > > drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth'
> > > undeclared (first use in this function); did you mean 'lockdep_depth'?
> > >
> > > Remove the #ifdef so it can always be accessed.
> > >
> > > Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > > Signed-off-by: Arnd Bergmann
> > > ---
> >
> > I've already applied the previous one you sent:
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
> >
> > Not sure when it reaches linux-next now that we are past rc6.
>
> Only once we're past -rc1.
Can we revert f53705fd9803 in linux-next then to prevent the regression from
making it into 4.20?
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix kernel doc for DRM_MODE_PROP_IMMUTABLE
On Tue, Oct 02, 2018 at 02:50:55PM -0700, Manasi Navare wrote:
> This patch explains the DRM_MODE_PROP_IMMUTABLE flag a bit better
> by telling which function to call if kernel wants to update
> drm object's immutable properties.
>
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
> Signed-off-by: Manasi Navare
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_property.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 5b9efff35d6d..4a0a80d658c7 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -153,7 +153,8 @@ struct drm_property {
>* userspace. The kernel is allowed to update the value of these
>* properties. This is generally used to expose probe state to
>* userspace, e.g. the EDID, or the connector path property on DP
> - * MST sinks.
> + * MST sinks. Kernel can update the value of an immutable property
> + * by calling drm_object_property_set_value().
>*/
> uint32_t flags;
>
> --
> 2.18.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: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Hi Noralf,
Le 08/09/2018 15:46, Noralf Trønnes a écrit :
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> Cc: Neil Armstrong
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/meson/meson_drv.c | 19 ++-
> drivers/gpu/drm/meson/meson_drv.h | 1 -
> 2 files changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index d3443125e661..348b5a198b9d 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -68,15 +68,7 @@
> * - Powering Up HDMI controller and PHY
> */
>
> -static void meson_fb_output_poll_changed(struct drm_device *dev)
> -{
> - struct meson_drm *priv = dev->dev_private;
> -
> - drm_fbdev_cma_hotplug_event(priv->fbdev);
> -}
> -
> static const struct drm_mode_config_funcs meson_mode_config_funcs = {
> - .output_poll_changed = meson_fb_output_poll_changed,
> .atomic_check= drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> .fb_create = drm_gem_fb_create,
> @@ -282,13 +274,6 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
>
> drm_mode_config_reset(drm);
>
> - priv->fbdev = drm_fbdev_cma_init(drm, 32,
> - drm->mode_config.num_connector);
> - if (IS_ERR(priv->fbdev)) {
> - ret = PTR_ERR(priv->fbdev);
> - goto free_drm;
> - }
> -
> drm_kms_helper_poll_init(drm);
>
> platform_set_drvdata(pdev, priv);
> @@ -297,6 +282,8 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
> if (ret)
> goto free_drm;
>
> + drm_fbdev_generic_setup(drm, 32);
> +
> return 0;
>
> free_drm:
> @@ -313,11 +300,9 @@ static int meson_drv_bind(struct device *dev)
> static void meson_drv_unbind(struct device *dev)
> {
> struct drm_device *drm = dev_get_drvdata(dev);
> - struct meson_drm *priv = drm->dev_private;
>
> drm_dev_unregister(drm);
> drm_kms_helper_poll_fini(drm);
> - drm_fbdev_cma_fini(priv->fbdev);
> drm_mode_config_cleanup(drm);
> drm_dev_put(drm);
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.h
> b/drivers/gpu/drm/meson/meson_drv.h
> index 8450d6ac8c9b..aab96260da9f 100644
> --- a/drivers/gpu/drm/meson/meson_drv.h
> +++ b/drivers/gpu/drm/meson/meson_drv.h
> @@ -33,7 +33,6 @@ struct meson_drm {
>
> struct drm_device *drm;
> struct drm_crtc *crtc;
> - struct drm_fbdev_cma *fbdev;
> struct drm_plane *primary_plane;
>
> /* Components Data */
>
A little bit late to get this in 4.20 (or 5.0) and get rid of the old fbdev
code,
but at least we have a (dirty) workaround in place for the Mali fbdev blob...
Acked-by: Neil Armstrong
Thanks for pushing the fbdev emulation on the right path !
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fb_helper: Allow leaking fbdev smem_start
Le 28/09/2018 14:05, Neil Armstrong a écrit : > Since "drm/fb: Stop leaking physical address", the default behaviour of > the DRM fbdev emulation is to set the smem_base to 0 and pass the new > FBINFO_HIDE_SMEM_START flag. > > The main reason is to avoid leaking physical addresse to user-space, and > it follows a general move over the kernel code to avoid user-space to > manipulate physical addresses and then use some other mechanisms like > dma-buf to transfer physical buffer handles over multiple subsystems. > > But, a lot of devices depends on closed sources binaries to enable > OpenGL hardware acceleration that uses this smem_start value to > pass physical addresses to out-of-tree modules in order to render > into these physical adresses. These should use dma-buf buffers allocated > from the DRM display device instead and stop relying on fbdev overallocation > to gather DMA memory (some HW vendors delivers GBM and Wayland capable > binaries, but older unsupported devices won't have these new binaries > and are doomed until an Open Source solution like Lima finalizes). > > Since these devices heavily depends on this kind of software and because > the smem_start population was available for years, it's a breakage to > stop leaking smem_start without any alternative solutions. > > This patch adds a Kconfig depending on the EXPERT config and an unsafe > kernel module parameter tainting the kernel when enabled. > > A clear comment and Kconfig help text was added to clarify why and when > this patch should be reverted, but in the meantime it's a necessary > feature to keep. > > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Bartlomiej Zolnierkiewicz > Cc: Noralf Trønnes > Cc: Maxime Ripard > Cc: Eric Anholt > Cc: Lucas Stach > Cc: Rob Clark > Cc: Ben Skeggs > Cc: Christian König > Signed-off-by: Neil Armstrong > Reviewed-by: Maxime Ripard > Tested-by: Maxime Ripard > Acked-by: Daniel Vetter > --- > drivers/gpu/drm/Kconfig | 20 > drivers/gpu/drm/drm_fb_helper.c | 33 +++-- > 2 files changed, 51 insertions(+), 2 deletions(-) Applied to drm-misc-next-fixes with Ack from Dave on irc. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Alexandru-Cosmin Gheorghe kirjoitti 3.10.2018 klo 20.18:
On Wed, Oct 03, 2018 at 02:31:08PM +0300, Juha-Pekka Heikkila wrote:
Hi Alex,
For my patches there seems limited interest to get them merged before IGT
support these modes..I'm not holding my breath for this.
I'm interested if that counts.
I asked the same question on the DRM_FORMAT_XYUV thread, do we need to
wait for userspace to get new fourcc merged.
I'd say yes. Why would otherwise clutter headers which affect what other
guys are doing for different drivers?
If it makes any difference for you I made KMS video output plug-in for
VLC media player as part of my enablement of P01x formats. My plug-in
didn't make it to any VLC release yet but you can find it in VLC master
branch. Through my plug-in you can ask any fourcc for setting up KMS
planes, then you'll need to find which VLC fourcc matches your KMS plane
and tell VLC about it on commandline. If you have driver implementation
of P010 format which I saw earlier in your patch you can compile VLC
with P010 included in DRM headers and then you'll be able to watch
videos using your new format. For P01x formats recompile is needed as
their setup is different from other formats, packed formats should work
without anything special.
/Juha-Pekka
https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html
/Juha-Pekka
On 02.10.2018 18:00, Alexandru-Cosmin Gheorghe wrote:
Hi,
How is this going on, anything holding it back from getting merged ?
I'm interested in adding/using P010, [1]
Thank you,
Alex Gheorghe
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First come Y plane [12:4]
followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
Add P016 definition, semi-planar yuv format where each component
is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
plane [16:16]
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 10 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e27..32e07a2 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,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, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2ed46e9..daaabb1 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -178,6 +178,16 @@ extern "C" {
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
+ * component xxx msb Y [xxx:16-xxx]
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx]
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
On Wed, Oct 03, 2018 at 11:42:14AM -0700, Radhakrishna Sripada wrote:
> On Mon, Oct 01, 2018 at 04:48:01PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 24, 2018 at 02:08:15PM -0700, Radhakrishna Sripada wrote:
> > > Use the newly added "max bpc" connector property to limit pipe bpp.
> > >
> > > V3: Use drm_connector_state to access the "max bpc" property
> > > V4: Initialize the drm property, add suuport to DP(Ville)
> > > V5: Use the property in the connector and fix CI failure(Ville)
> > > V6: Use the core function to attach max_bpc property, remove the redundant
> > > clamping of pipe bpp based on connector info
> > > V7: Fix Checkpatch warnings
> > > V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Cc: Daniel Vetter
> > > Cc: Rodrigo Vivi
> > > Cc: Kishore Kadiyala
> > > Cc: Manasi Navare
> > > Cc: Stanislav Lisovskiy
> > > Signed-off-by: Radhakrishna Sripada
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 48
> > > +---
> > > drivers/gpu/drm/i915/intel_dp.c | 4 +++
> > > drivers/gpu/drm/i915/intel_hdmi.c| 5
> > > 3 files changed, 37 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 931898013506..057abfd77cc3 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -10839,30 +10839,38 @@ static void
> > > intel_modeset_update_connector_atomic_state(struct drm_device *dev)
> > > drm_connector_list_iter_end(_iter);
> > > }
> > >
> > > -static void
> > > -connected_sink_compute_bpp(struct intel_connector *connector,
> > > -struct intel_crtc_state *pipe_config)
> > > +static int
> > > +connected_sink_max_bpp(const struct drm_connector_state *conn_state,
> > > +struct intel_crtc_state *pipe_config)
> > > {
> > > - const struct drm_display_info *info = >base.display_info;
> > > - int bpp = pipe_config->pipe_bpp;
> > > + int bpp;
> > > + struct drm_display_info *info = _state->connector->display_info;
> > >
> > > - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
> > > - connector->base.base.id,
> > > - connector->base.name);
> > > + bpp = min(pipe_config->pipe_bpp, conn_state->max_bpc * 3);
> >
> > Needs a check to make sure the connector has the property.
> We do make a check for the connector property in the drm core. In the absence
> of the property, conn_state->max_bpc carries the limit imposed from
> connector->display_info.bpc and would be requiring the codepath below.
Ah yes. That part is perfectly good then.
>
> Thoughts?
>
> -- Radhakrishna Sripada
> >
> > >
> > > - /* Don't use an invalid EDID bpc value */
> > > - if (info->bpc != 0 && info->bpc * 3 < bpp) {
> > > - DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
> > > max of %d\n",
> > > - bpp, info->bpc * 3);
> > > - pipe_config->pipe_bpp = info->bpc * 3;
> > > + switch (conn_state->max_bpc) {
> > > + case 6 ... 7:
> > > + pipe_config->pipe_bpp = 6 * 3;
> > > + case 8 ... 9:
> > > + pipe_config->pipe_bpp = 8 * 3;
> > > + break;
> > > + case 10 ... 11:
> > > + pipe_config->pipe_bpp = 10 * 3;
> > > + break;
> > > + case 12:
> > > + pipe_config->pipe_bpp = 12 * 3;
> > > + break;
> > > + default:
> > > + return -EINVAL;
> > > }
> > >
> > > - /* Clamp bpp to 8 on screens without EDID 1.4 */
> > > - if (info->bpc == 0 && bpp > 24) {
> > > - DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
> > > of 24\n",
> > > - bpp);
> > > - pipe_config->pipe_bpp = 24;
> > > + if (bpp != pipe_config->pipe_bpp) {
> > > + DRM_DEBUG_KMS("Limiting display bpp to %d instead of requested "
> > > + "bpp %d, Edid bpp %d\n", bpp, 3 * info->bpc,
> > > + 3 * conn_state->max_requested_bpc);
> >
> > The format string doesn't seem to match the arguments.
> >
> > > + pipe_config->pipe_bpp = bpp;
> > > }
> > > + return 0;
> > > }
> > >
> > > static int
> > > @@ -10893,8 +10901,8 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
> > > if (connector_state->crtc != >base)
> > > continue;
> > >
> > > - connected_sink_compute_bpp(to_intel_connector(connector),
> > > -pipe_config);
> > > + if (connected_sink_max_bpp(connector_state, pipe_config) < 0)
> > > + return -EINVAL;
> > > }
> > >
> > > return bpp;
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 6b4c19123f2a..d8e128e771a1 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -5719,6 +5719,10 @@
Re: [PATCH v10 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
On Mon, Oct 01, 2018 at 04:48:01PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 24, 2018 at 02:08:15PM -0700, Radhakrishna Sripada wrote:
> > Use the newly added "max bpc" connector property to limit pipe bpp.
> >
> > V3: Use drm_connector_state to access the "max bpc" property
> > V4: Initialize the drm property, add suuport to DP(Ville)
> > V5: Use the property in the connector and fix CI failure(Ville)
> > V6: Use the core function to attach max_bpc property, remove the redundant
> > clamping of pipe bpp based on connector info
> > V7: Fix Checkpatch warnings
> > V9: Cleanup connected_sink_max_bpp and fix initial value in DP(Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Rodrigo Vivi
> > Cc: Kishore Kadiyala
> > Cc: Manasi Navare
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 48
> > +---
> > drivers/gpu/drm/i915/intel_dp.c | 4 +++
> > drivers/gpu/drm/i915/intel_hdmi.c| 5
> > 3 files changed, 37 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 931898013506..057abfd77cc3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -10839,30 +10839,38 @@ static void
> > intel_modeset_update_connector_atomic_state(struct drm_device *dev)
> > drm_connector_list_iter_end(_iter);
> > }
> >
> > -static void
> > -connected_sink_compute_bpp(struct intel_connector *connector,
> > - struct intel_crtc_state *pipe_config)
> > +static int
> > +connected_sink_max_bpp(const struct drm_connector_state *conn_state,
> > + struct intel_crtc_state *pipe_config)
> > {
> > - const struct drm_display_info *info = >base.display_info;
> > - int bpp = pipe_config->pipe_bpp;
> > + int bpp;
> > + struct drm_display_info *info = _state->connector->display_info;
> >
> > - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
> > - connector->base.base.id,
> > - connector->base.name);
> > + bpp = min(pipe_config->pipe_bpp, conn_state->max_bpc * 3);
>
> Needs a check to make sure the connector has the property.
We do make a check for the connector property in the drm core. In the absence
of the property, conn_state->max_bpc carries the limit imposed from
connector->display_info.bpc and would be requiring the codepath below.
Thoughts?
-- Radhakrishna Sripada
>
> >
> > - /* Don't use an invalid EDID bpc value */
> > - if (info->bpc != 0 && info->bpc * 3 < bpp) {
> > - DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
> > max of %d\n",
> > - bpp, info->bpc * 3);
> > - pipe_config->pipe_bpp = info->bpc * 3;
> > + switch (conn_state->max_bpc) {
> > + case 6 ... 7:
> > + pipe_config->pipe_bpp = 6 * 3;
> > + case 8 ... 9:
> > + pipe_config->pipe_bpp = 8 * 3;
> > + break;
> > + case 10 ... 11:
> > + pipe_config->pipe_bpp = 10 * 3;
> > + break;
> > + case 12:
> > + pipe_config->pipe_bpp = 12 * 3;
> > + break;
> > + default:
> > + return -EINVAL;
> > }
> >
> > - /* Clamp bpp to 8 on screens without EDID 1.4 */
> > - if (info->bpc == 0 && bpp > 24) {
> > - DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
> > of 24\n",
> > - bpp);
> > - pipe_config->pipe_bpp = 24;
> > + if (bpp != pipe_config->pipe_bpp) {
> > + DRM_DEBUG_KMS("Limiting display bpp to %d instead of requested "
> > + "bpp %d, Edid bpp %d\n", bpp, 3 * info->bpc,
> > + 3 * conn_state->max_requested_bpc);
>
> The format string doesn't seem to match the arguments.
>
> > + pipe_config->pipe_bpp = bpp;
> > }
> > + return 0;
> > }
> >
> > static int
> > @@ -10893,8 +10901,8 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
> > if (connector_state->crtc != >base)
> > continue;
> >
> > - connected_sink_compute_bpp(to_intel_connector(connector),
> > - pipe_config);
> > + if (connected_sink_max_bpp(connector_state, pipe_config) < 0)
> > + return -EINVAL;
> > }
> >
> > return bpp;
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 6b4c19123f2a..d8e128e771a1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5719,6 +5719,10 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> > struct drm_connector *connect
> > intel_attach_force_audio_property(connector);
> >
> > intel_attach_broadcast_rgb_property(connector);
> > + if (HAS_GMCH_DISPLAY(dev_priv))
> > +
Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
On Wed, Oct 03, 2018 at 10:41:20AM +0200, Daniel Vetter wrote: > On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote: > > > > > > On 2018-10-01 03:15 AM, Daniel Vetter wrote: > > > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote: > > >> These patches are part of a proposed new interface for supporting > > >> variable refresh rate via DRM properties. > > >> > > >> === Changes from v1 === > > >> > > >> For drm: > > >> > > >> * The variable_refresh_capable property is now flagged as > > >> DRM_MODE_PROP_IMMUTABLE > > >> > > >> For drm/gpu/amd/display: > > >> > > >> * Patches no longer pull in IOCTL/FreeSync refactoring code > > >> * FreeSync enable/disable behavior has been modified to reflect changes > > >> in userspace behavior from xf86-video-amdgpu and mesa > > >> > > >> === Adaptive sync and variable refresh rate === > > >> > > >> Adaptive sync is part of the DisplayPort spec and allows for graphics > > >> adapters to drive displays with varying frame timings. > > >> > > >> Variable refresh rate (VRR) is essentially the same, but defined for > > >> HDMI. > > >> > > >> === Use cases for variable refresh rate === > > >> > > >> Variable frame (flip) timings don't align well with fixed refresh rate > > >> displays. This results in stuttering, tearing and/or input lag. By > > >> adjusting the display refresh rate dynamically these issues can be > > >> reduced or eliminated. > > >> > > >> However, not all content is suitable for dynamic refresh adaptation. > > >> Content that is flipped infrequently or at random intervals tends to > > >> fair poorly. Multiple clients trying to flip under the same screen can > > >> similarly interfere with prediction. > > >> > > >> Userland needs a way to let the driver know when the content on the > > >> screen is suitable for variable refresh rate and if the user wishes to > > >> have the feature enabled. > > >> > > >> === DRM API to support variable refresh rates === > > >> > > >> This patch introduces a new API via atomic properties on the DRM > > >> connector and CRTC. > > >> > > >> The connector has two new optional properties: > > >> > > >> * bool variable_refresh_capable - set by the driver if the hardware is > > >> capable of supporting variable refresh tech > > >> > > >> * bool variable_refresh_enabled - set by the user to enable variable > > >> refresh adjustment over the connector > > >> > > >> The CRTC has one additional default property: > > >> > > >> * bool variable_refresh - a content hint to the driver specifying that > > >> the CRTC contents are suitable for variable refresh adjustment > > >> > > >> == Overview for DRM driver developers === > > >> > > >> Driver developers can attach the optional connector properties via > > >> drm_connector_attach_variable_refresh_properties on connectors that > > >> support variable refresh (typically DP or HDMI). > > >> > > >> The variable_refresh_capable property should be managed as the output on > > >> the connector changes. The property is read only from userspace. > > >> > > >> The variable_refresh_enabled property is intended to be a property > > >> controlled by userland as a global on/off switch for variable refresh > > >> technology. It should be checked before enabling variable refresh rate. > > >> > > >> === Overview for Userland developers == > > >> > > >> The variable_refresh property on the CRTC should be set to true when the > > >> CRTCs are suitable for variable refresh rate. In practice this is > > >> probably an application like a game - a single window that covers the > > >> whole CRTC surface and is the only client issuing flips. > > >> > > >> To demonstrate the suitability of the API for variable refresh and > > >> dynamic adaptation there are additional patches using this API that > > >> implement adaptive variable refresh across kernel and userland projects: > > >> > > >> * DRM (dri-devel) > > >> * amdgpu DRM kernel driver (amd-gfx) > > >> * xf86-video-amdgpu (amd-gfx) > > >> * mesa (mesa-dev) > > >> > > >> These patches enable adaptive variable refresh on X for AMD hardware > > >> provided that the user sets the variable_refresh_enabled property to > > >> true on supported connectors (ie. using xrandr --set-prop). > > >> > > >> The patches have been tested as working on upstream userland with the > > >> GNOME desktop environment under a single monitor setup. They also work > > >> on KDE in single monitor setup if the compositor is disabled. > > >> > > >> The patches require that the application window can issue screen flips > > >> via the Present extension to xf86-video-amdgpu. Due to Present extension > > >> limitations some desktop environments and multi-monitor setups are > > >> currently not compatible. > > >> > > >> Full implementation details for these changes can be reviewed in their > > >> respective mailing lists. > > >> > > >> === Previous discussions === > > >> > > >> These patches are based upon feedback from patches and
Re: [PATCH libdrm v2 2/2] amdgpu/test: Fix deadlock tests for AI and RV v2
Yes, Andrey has commit rights.
Marek
On Wed, Oct 3, 2018 at 10:34 AM Christian König
wrote:
>
> Thanks for keeping working on this.
>
> Series is Reviewed-by: Christian König as well.
>
> Do you now have commit rights?
>
> Christian.
>
> Am 02.10.2018 um 22:47 schrieb Marek Olšák:
> > For the series:
> >
> > Reviewed-by: Marek Olšák
> >
> > Marek
> > On Fri, Sep 28, 2018 at 10:46 AM Andrey Grodzovsky
> > wrote:
> >> Seems like AI and RV requires uncashed memory mapping to be able
> >> to pickup value written to memory by CPU after the WAIT_REG_MEM
> >> command was already launched.
> >> .
> >> Enable the test for AI and RV.
> >>
> >> v2:
> >> Update commit description.
> >>
> >> Signed-off-by: Andrey Grodzovsky
> >> ---
> >> tests/amdgpu/deadlock_tests.c | 13 -
> >> 1 file changed, 8 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> >> index 304482d..292ec4e 100644
> >> --- a/tests/amdgpu/deadlock_tests.c
> >> +++ b/tests/amdgpu/deadlock_tests.c
> >> @@ -80,6 +80,8 @@ static uint32_t minor_version;
> >> static pthread_t stress_thread;
> >> static uint32_t *ptr;
> >>
> >> +int use_uc_mtype = 0;
> >> +
> >> static void amdgpu_deadlock_helper(unsigned ip_type);
> >> static void amdgpu_deadlock_gfx(void);
> >> static void amdgpu_deadlock_compute(void);
> >> @@ -92,13 +94,14 @@ CU_BOOL suite_deadlock_tests_enable(void)
> >> _version,
> >> _handle))
> >> return CU_FALSE;
> >>
> >> - if (device_handle->info.family_id == AMDGPU_FAMILY_AI ||
> >> - device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> >> - device_handle->info.family_id == AMDGPU_FAMILY_RV) {
> >> + if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
> >> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
> >> suite disabled\n");
> >> enable = CU_FALSE;
> >> }
> >>
> >> + if (device_handle->info.family_id >= AMDGPU_FAMILY_AI)
> >> + use_uc_mtype = 1;
> >> +
> >> if (amdgpu_device_deinitialize(device_handle))
> >> return CU_FALSE;
> >>
> >> @@ -183,8 +186,8 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
> >> r = amdgpu_cs_ctx_create(device_handle, _handle);
> >> CU_ASSERT_EQUAL(r, 0);
> >>
> >> - r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
> >> - AMDGPU_GEM_DOMAIN_GTT, 0,
> >> + r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
> >> + AMDGPU_GEM_DOMAIN_GTT, 0, use_uc_mtype ?
> >> AMDGPU_VM_MTYPE_UC : 0,
> >> _result_handle,
> >> _result_cpu,
> >>
> >> _result_mc_address, _handle);
> >> CU_ASSERT_EQUAL(r, 0);
> >> --
> >> 2.7.4
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
On Wed, Oct 03, 2018 at 02:31:08PM +0300, Juha-Pekka Heikkila wrote:
> Hi Alex,
>
> For my patches there seems limited interest to get them merged before IGT
> support these modes..I'm not holding my breath for this.
I'm interested if that counts.
I asked the same question on the DRM_FORMAT_XYUV thread, do we need to
wait for userspace to get new fourcc merged.
>
> https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html
>
> /Juha-Pekka
>
> On 02.10.2018 18:00, Alexandru-Cosmin Gheorghe wrote:
> >Hi,
> >
> >How is this going on, anything holding it back from getting merged ?
> >I'm interested in adding/using P010, [1]
> >
> >Thank you,
> >Alex Gheorghe
> >
> >[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
> >
> >On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
> >>Add P010 definition, semi-planar yuv format where each component
> >>is 16 bits 10 msb containing color value. First come Y plane [10:6]
> >>followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
> >>
> >>Add P012 definition, semi-planar yuv format where each component
> >>is 16 bits 12 msb containing color value. First come Y plane [12:4]
> >>followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
> >>
> >>Add P016 definition, semi-planar yuv format where each component
> >>is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
> >>plane [16:16]
> >>
> >>Signed-off-by: Juha-Pekka Heikkila
> >>---
> >> drivers/gpu/drm/drm_fourcc.c | 3 +++
> >> include/uapi/drm/drm_fourcc.h | 10 ++
> >> 2 files changed, 13 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >>index 35c1e27..32e07a2 100644
> >>--- a/drivers/gpu/drm/drm_fourcc.c
> >>+++ b/drivers/gpu/drm/drm_fourcc.c
> >>@@ -173,6 +173,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, .is_yuv = true
> >> },
> >>{ .format = DRM_FORMAT_VYUY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true
> >> },
> >>{ .format = DRM_FORMAT_AYUV,.depth = 0,
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha =
> >> true, .is_yuv = true },
> >>+ { .format = DRM_FORMAT_P010,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>+ { .format = DRM_FORMAT_P012,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>+ { .format = DRM_FORMAT_P016,.depth = 0,
> >>.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true
> >>},
> >>};
> >>unsigned int i;
> >>diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >>index 2ed46e9..daaabb1 100644
> >>--- a/include/uapi/drm/drm_fourcc.h
> >>+++ b/include/uapi/drm/drm_fourcc.h
> >>@@ -178,6 +178,16 @@ extern "C" {
> >> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >> /*
> >>+ * 2 plane YCbCr
> >>+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
> >>+ * component xxx msb Y [xxx:16-xxx]
> >>+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian
> >>[xxx:16-xxx:xxx:16-xxx]
> >>+ */
> >>+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
> >>subsampled Cr:Cb plane, 10 bit per channel */
> >>+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
> >>subsampled Cr:Cb plane, 12 bit per channel */
> >>+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
> >>subsampled Cr:Cb plane, 16 bit per channel */
> >>+
> >>+/*
> >> * 3 plane YCbCr
> >> * index 0: Y plane, [7:0] Y
> >> * index 1: Cb plane, [7:0] Cb
> >>--
> >>2.7.4
> >>
> >>___
> >>dri-devel mailing list
> >>dri-devel@lists.freedesktop.org
> >>https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: fb-helper: Reject all pixel format changing requests
drm fbdev emulation doesn't support changing the pixel format at all,
so reject all pixel format changing requests.
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeniy Paltsev
---
Changes v1->v2:
* Reject all pixel format changing request, not just the invalid ones.
drivers/gpu/drm/drm_fb_helper.c | 91 -
1 file changed, 26 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 16ec93b75dbf..48598d7f673f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned
int cmd,
}
EXPORT_SYMBOL(drm_fb_helper_ioctl);
+static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1,
+ const struct fb_var_screeninfo *var_2)
+{
+ return var_1->bits_per_pixel == var_2->bits_per_pixel &&
+ var_1->grayscale == var_2->grayscale &&
+ var_1->red.offset == var_2->red.offset &&
+ var_1->red.length == var_2->red.length &&
+ var_1->red.msb_right == var_2->red.msb_right &&
+ var_1->green.offset == var_2->green.offset &&
+ var_1->green.length == var_2->green.length &&
+ var_1->green.msb_right == var_2->green.msb_right &&
+ var_1->blue.offset == var_2->blue.offset &&
+ var_1->blue.length == var_2->blue.length &&
+ var_1->blue.msb_right == var_2->blue.msb_right &&
+ var_1->transp.offset == var_2->transp.offset &&
+ var_1->transp.length == var_2->transp.length &&
+ var_1->transp.msb_right == var_2->transp.msb_right;
+}
+
/**
* drm_fb_helper_check_var - implementation for _ops.fb_check_var
* @var: screeninfo to check
@@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
{
struct drm_fb_helper *fb_helper = info->par;
struct drm_framebuffer *fb = fb_helper->fb;
- int depth;
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
@@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
return -EINVAL;
}
- switch (var->bits_per_pixel) {
- case 16:
- depth = (var->green.length == 6) ? 16 : 15;
- break;
- case 32:
- depth = (var->transp.length > 0) ? 32 : 24;
- break;
- default:
- depth = var->bits_per_pixel;
- break;
- }
-
- switch (depth) {
- case 8:
- var->red.offset = 0;
- var->green.offset = 0;
- var->blue.offset = 0;
- var->red.length = 8;
- var->green.length = 8;
- var->blue.length = 8;
- var->transp.length = 0;
- var->transp.offset = 0;
- break;
- case 15:
- var->red.offset = 10;
- var->green.offset = 5;
- var->blue.offset = 0;
- var->red.length = 5;
- var->green.length = 5;
- var->blue.length = 5;
- var->transp.length = 1;
- var->transp.offset = 15;
- break;
- case 16:
- var->red.offset = 11;
- var->green.offset = 5;
- var->blue.offset = 0;
- var->red.length = 5;
- var->green.length = 6;
- var->blue.length = 5;
- var->transp.length = 0;
- var->transp.offset = 0;
- break;
- case 24:
- var->red.offset = 16;
- var->green.offset = 8;
- var->blue.offset = 0;
- var->red.length = 8;
- var->green.length = 8;
- var->blue.length = 8;
- var->transp.length = 0;
- var->transp.offset = 0;
- break;
- case 32:
- var->red.offset = 16;
- var->green.offset = 8;
- var->blue.offset = 0;
- var->red.length = 8;
- var->green.length = 8;
- var->blue.length = 8;
- var->transp.length = 8;
- var->transp.offset = 24;
- break;
- default:
+ /*
+* drm fbdev emulation doesn't support changing the pixel format at all,
+* so reject all pixel format changing requests.
+*/
+ if (!drm_fb_pixel_format_equal(var, >var)) {
+ DRM_DEBUG("fbdev emulation doesn't support changing the pixel
format\n");
return -EINVAL;
}
+
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_check_var);
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Extend todo
On Wed, Oct 03, 2018 at 10:35:18AM -0300, Rodrigo Siqueira wrote: > On 10/03, Daniel Vetter wrote: > > Typed up all the items Rodrigo capture at the vkms workshop at > > xdc2018: > > > > https://etherpad.net/p/vkms_todo > > > > v2: Review from Rodrigo. > > - Add eBPF for atomic check, I forgot it. > > - Improve spelling. > > > > Signed-off-by: Daniel Vetter > > Cc: Gustavo Padovan > > Cc: Maarten Lankhorst > > Cc: Sean Paul > > Cc: Haneen Mohammed > > Cc: Rodrigo Siqueira > > --- > > Documentation/gpu/vkms.rst | 101 - > > 1 file changed, 99 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > index 0a6ea6216e41..7dfc349a4508 100644 > > --- a/Documentation/gpu/vkms.rst > > +++ b/Documentation/gpu/vkms.rst > > @@ -10,8 +10,8 @@ > > TODO > > > > > > -CRC API > > > > +CRC API Improvements > > + > > > > - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` > > > > @@ -22,3 +22,100 @@ CRC API > > > > - Add igt test to check extreme alpha values i.e. fully opaque and fully > >transparent (intermediate values are affected by hw-specific rounding > > modes). > > + > > +Vblank issues > > +- > > + > > +Some IGT test cases are failing. Need to analyze why and fix the issues: > > + > > +- plain-flip-fb-recreate > > +- plain-flip-ts-check > > +- flip-vs-blocking-wf-vblank > > +- plain-flip-fb-recreate-interruptible > > +- flip-vs-wf_vblank-interruptible > > + > > +Runtime Configuration > > +- > > + > > +We want to be able to reconfigure vkms instance without having to reload > > the > > +module. Use/Test-cases: > > + > > +- Hotplug/hotremove connectors on the fly (to be able to test DP MST > > handling of > > + compositors). > > + > > +- Configure planes/crtcs/connectors (we'd need some code to have more than > > 1 of > > + them first). > > + > > +- Change output configuration: Plug/unplug screens, change EDID, allow > > changing > > + the refresh rate. > > + > > +The currently proposed solution is to expose vkms configuration through > > +configfs. All existing module options should be supported through > > configfs too. > > + > > +Add Plane Features > > +-- > > + > > +There's lots of plane features we could add support for: > > + > > +- Real overlay planes, not just cursor. > > + > > +- Full alpha blending on all planes. > > + > > +- Rotation, scaling. > > + > > +- Additional buffer formats, especially YUV formats for video like NV12. > > + Low/high bpp RGB formats would also be interesting. > > + > > +- Async updates (currently only possible on cursor plane using the legacy > > cursor > > + api). > > + > > +For all of these, we also want to review the igt test coverage and make > > sure all > > +relevant igt testcases work on vkms. > > + > > +Writeback support > > +- > > + > > +Currently vkms only computes a CRC for each frame. Once we have additional > > plane > > +features, we could write back the entire composited frame, and expose it > > as: > > + > > +- Writeback connector. This is useful for testing compositors if you don't > > have > > + hardware with writeback support. > > + > > +- As a v4l device. This is useful for debugging compositors on special vkms > > + configurations, so that developers see what's really going on. > > + > > +Prime Buffer Sharing > > + > > + > > +We already have vgem, which is a gem driver for testing rendering, similar > > to > > +how vkms is for testing the modeset side. Adding buffer sharing support to > > vkms > > +allows us to test them together, to test synchronization and lots of other > > +features. Also, this allows compositors to test whether they work > > correctly on > > +SoC chips, where the display and rendering is very often split between 2 > > +drivers. > > + > > +Output Features > > +--- > > + > > +- Variable refresh rate/freesync support. This probably needs prime buffer > > + sharing support, so that we can use vgem fences to simulate rendering in > > + testing. Also needs support to specify the EDID. > > + > > +- Add support for link status, so that compositors can validate their > > runtime > > + fallbacks when e.g. a Display Port link goes bad. > > + > > +- All the hotplug handling describe under "Runtime Configuration". > > + > > +Atomic Check using eBPF > > +--- > > + > > +Atomic drivers have lots of restrictions which are not exposed to > > userspace in > > +any explicit form through e.g. possible property values. Userspace can only > > +inquiry about these limits through the atomic IOCTL, possibly using the > > +TEST_ONLY flag. Trying to add configurable code for all these limits, to > > allow > > +compositors to be tested against them, would be rather futile exercise. > > Instead > > +we could add support for eBPF to validate any kind of
[Bug 201015] [amdgpu] BUG: unable to handle kernel NULL pointer dereference on resume with 2 monitors (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201015 --- Comment #10 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- After recent updates, the issue went away. But I'm not sure what exactly has changed. I tried reverting the kernel (to 4.19-rc3) and libdrm, but still can't trigger it anymore. -- 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: [Intel-gfx] [PATCH v2 3/3] drm/i915: Clean up early plane debugs
On Wed, Oct 03, 2018 at 05:50:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Print the plane hw state readout results in the common format
> we already use for pipes and encoders. Also print some clearer
> debug messages when we disable planes during the early phases
> of state readout/sanitization.
>
> v2: Rebase
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f0d004641b0d..24fe3b1fb2a9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2768,10 +2768,6 @@ intel_set_plane_visible(struct intel_crtc_state
> *crtc_state,
> crtc_state->base.plane_mask |= drm_plane_mask(>base);
> else
> crtc_state->base.plane_mask &= ~drm_plane_mask(>base);
> -
> - DRM_DEBUG_KMS("%s active planes 0x%x\n",
> - crtc_state->base.crtc->name,
> - crtc_state->active_planes);
> }
>
> static void fixup_active_planes(struct intel_crtc_state *crtc_state)
> @@ -2799,6 +2795,10 @@ static void intel_plane_disable_noatomic(struct
> intel_crtc *crtc,
> struct intel_plane_state *plane_state =
> to_intel_plane_state(plane->base.state);
>
> + DRM_DEBUG_KMS("Disabling [PLANE:%d:%s] on [CRTC:%d:%s]\n",
> + plane->base.base.id, plane->base.name,
> + crtc->base.base.id, crtc->base.name);
> +
> intel_set_plane_visible(crtc_state, plane_state, false);
> fixup_active_planes(crtc_state);
>
> @@ -15523,8 +15523,8 @@ intel_sanitize_plane_mapping(struct drm_i915_private
> *dev_priv)
> if (pipe == crtc->pipe)
> continue;
>
> - DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling
> plane\n",
> - plane->base.name);
> + DRM_DEBUG_KMS("[PLANE:%d:%s] attached to the wrong pipe,
> disabling plane\n",
> + plane->base.base.id, plane->base.name);
>
> plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> intel_plane_disable_noatomic(plane_crtc, plane);
> @@ -15713,6 +15713,10 @@ static void readout_plane_state(struct
> drm_i915_private *dev_priv)
> crtc_state = to_intel_crtc_state(crtc->base.state);
>
> intel_set_plane_visible(crtc_state, plane_state, visible);
> +
> + DRM_DEBUG_KMS("[PLANE:%d:%s] hw state readout: %s, pipe %c\n",
> + plane->base.base.id, plane->base.name,
> + enableddisabled(visible), pipe_name(pipe));
> }
>
> for_each_intel_crtc(_priv->drm, crtc) {
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
>
>
> Den 02.10.2018 22.58, skrev Arnd Bergmann:
> > The variable is now referenced unconditionally, but still
> > declared in an #ifdef:
> >
> > drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
> > drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth'
> > undeclared (first use in this function); did you mean 'lockdep_depth'?
> >
> > Remove the #ifdef so it can always be accessed.
> >
> > Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
> > Signed-off-by: Arnd Bergmann
> > ---
>
> I've already applied the previous one you sent:
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
>
> Not sure when it reaches linux-next now that we are past rc6.
Only once we're past -rc1.
-Daniel
>
> Noralf.
>
> > drivers/gpu/drm/imx/imx-drm-core.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index a70f3131a377..0e6942f21a4e 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -35,10 +35,8 @@
> > #define MAX_CRTC 4
> > -#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
> > static int legacyfb_depth = 16;
> > module_param(legacyfb_depth, int, 0444);
> > -#endif
> > DEFINE_DRM_GEM_CMA_FOPS(imx_drm_driver_fops);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping
On Wed, Oct 03, 2018 at 05:50:17PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> When we decide that a plane is attached to the wrong pipe we try
> to turn off said plane. However we are passing around the crtc we
> think that the plane is supposed to be using rather than the crtc
> it is currently using. That doesn't work all that well because
> we may have to do vblank waits etc. and the other pipe might
> not even be enabled here. So let's pass the plane's current crtc to
> intel_plane_disable_noatomic() so that it can its job correctly.
>
> To do that semi-cleanly we also have to change the plane readout
> to record the plane's visibility into the bitmasks of the crtc
> where the plane is currently enabled rather than to the crtc
> we want to use for the plane.
>
> One caveat here is that our active_planes bitmask will get confused
> if both planes are enabled on the same pipe. Fortunately we can use
> plane_mask to reconstruct active_planes sufficiently since
> plane_mask still has the same meaning (is the plane visible?)
> during readout. We also have to do the same during the initial
> plane readout as the second plane could clear the active_planes
> bit the first plane had already set.
>
> v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
> Add Daniel's proposed comment to better document why we do this
> Drop the redundant intel_set_plane_visible() call
>
> Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have
> plane->get_hw_state() return the current pipe
> Cc: sta...@vger.kernel.org
> Cc: Dennis
> Cc: Daniel Vetter
> Tested-by: Dennis
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
> Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
> Signed-off-by: Ville Syrjälä
I have the illusion of understanding this stuff now.
Reviewed-by: Daniel Vetter
But let's see whether testers and CI agree :-)
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 78
> +---
> 1 file changed, 46 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d2828159f6c8..f0d004641b0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state
> *crtc_state,
>
> plane_state->base.visible = visible;
>
> - /* FIXME pre-g4x don't work like this */
> - if (visible) {
> + if (visible)
> crtc_state->base.plane_mask |= drm_plane_mask(>base);
> - crtc_state->active_planes |= BIT(plane->id);
> - } else {
> + else
> crtc_state->base.plane_mask &= ~drm_plane_mask(>base);
> - crtc_state->active_planes &= ~BIT(plane->id);
> - }
>
> DRM_DEBUG_KMS("%s active planes 0x%x\n",
> crtc_state->base.crtc->name,
> crtc_state->active_planes);
> }
>
> +static void fixup_active_planes(struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> + struct drm_plane *plane;
> +
> + /*
> + * Active_planes aliases if multiple "primary" or cursor planes
> + * have been used on the same (or wrong) pipe. plane_mask uses
> + * unique ids, hence we can use that to reconstruct active_planes.
> + */
> + crtc_state->active_planes = 0;
> +
> + drm_for_each_plane_mask(plane, _priv->drm,
> + crtc_state->base.plane_mask)
> + crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
> +}
> +
> static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
>struct intel_plane *plane)
> {
> @@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct
> intel_crtc *crtc,
> to_intel_plane_state(plane->base.state);
>
> intel_set_plane_visible(crtc_state, plane_state, false);
> + fixup_active_planes(crtc_state);
>
> if (plane->id == PLANE_PRIMARY)
> intel_pre_disable_primary_noatomic(>base);
> @@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> struct drm_i915_gem_object *obj;
> struct drm_plane *primary = intel_crtc->base.primary;
> struct drm_plane_state *plane_state = primary->state;
> - struct drm_crtc_state *crtc_state = intel_crtc->base.state;
> struct intel_plane *intel_plane = to_intel_plane(primary);
> struct intel_plane_state *intel_state =
> to_intel_plane_state(plane_state);
> @@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc
> *intel_crtc,
> plane_state->fb = fb;
> plane_state->crtc = _crtc->base;
>
> - intel_set_plane_visible(to_intel_crtc_state(crtc_state),
> - to_intel_plane_state(plane_state),
> -
[Bug 201163] amdgpu: carrizo: Stalls using vaapi encoder
https://bugzilla.kernel.org/show_bug.cgi?id=201163 Ricardo Ribalda (ricardo.riba...@gmail.com) changed: What|Removed |Added Hardware|All |x86-64 -- 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] drm: fb-helper: Validate requested pixel format against bpp
On Wed, Oct 03, 2018 at 05:29:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 3, 2018 at 4:30 PM Eugeniy Paltsev
> wrote:
> >
> > On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> > > On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> > > > wrote:
> > > > >
> > > > > Validate requested pixel format against bits_per_pixel to reject
> > > > > invalid formats with subcomponents length sum is greater than
> > > > > requested
> > > > > bits_per_pixel.
> > > > >
> > > > > weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
> > > > > format without bits_per_pixel updating. So it can request
> > > > > x8r8g8b8 with 16 bpp which is obviously incorrect and should be
> > > > > rejected.
> > > > >
> > > > > Cc: sta...@vger.kernel.org
> > > > > Signed-off-by: Eugeniy Paltsev
> > > >
> > > > drm fbdev emulation doesn't support changing the pixel format at all.
> > > > I think we should reject all such request, not just the invalid ones.
> > > > Can you pls respin?
> > >
> > > FYI I once posted a patch to tighten up the fb-helper pixel format
> > > stuff:
> > > https://patchwork.freedesktop.org/patch/203189/
> >
> >
> > Hi Daniel,
> >
> > will you take Ville's patch or should I create the new one which is only
> > related
> > to new pixel format validation in drm_fb_helper_check_var() ?
>
> Ville's patch isn't the bugfix we're looking for, but a draft version
> of what adding proper format support in drm's fbdev emulation could
> look like. With lots of open questions.
Actually it does pretty much what you seem to be asking for.
Ie. reject any attempt to change the pixel format. Not really
sure how to do it much more minimally.
Hmm. Oh there is a more minimal way actually. I mistakenly remembered
that fbdev clobbers info->var already before check_var(), but actually
it only does that before set_par(). So I guess all we really need is
to compare the fb_bitfields/bits_per_pixel/etc. between info->var
and the passed in var.
> Not anywhere near ready
> for merging, and definitely not stable backport material.
>
> So yes, still want the minimal bugfix.
> -Daniel
>
> >
> >
> > > > Thanks, Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_fb_helper.c | 7 +++
> > > > > 1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > > index 16ec93b75dbf..4f39da07f053 100644
> > > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > > @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct
> > > > > fb_var_screeninfo *var,
> > > > > return -EINVAL;
> > > > > }
> > > > >
> > > > > + if ((var->green.length + var->blue.length + var->red.length +
> > > > > + var->transp.length) > var->bits_per_pixel) {
> > > > > + DRM_DEBUG("fb requested pixel format can't fit in %d
> > > > > bpp\n",
> > > > > + var->bits_per_pixel);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > switch (var->bits_per_pixel) {
> > > > > case 16:
> > > > > depth = (var->green.length == 6) ? 16 : 15;
> > > > > --
> > > > > 2.14.4
> > > > >
> > > > > ___
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN
> > > > > 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > +41 (0) 79 365 57 48 -
> > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.ffwll.ch=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1MriPUTkBKCrPSx67
> > > > GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=Vt8OX9s9ljSK6GDgbnwsF-Yd35fbBUfe8SBV2jPnVaQ=
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1M
> > > > riPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
> > >
> > >
> > --
> > Eugeniy Paltsev
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: move 'legacyfb_depth' definition out of #ifdef
Den 02.10.2018 22.58, skrev Arnd Bergmann:
The variable is now referenced unconditionally, but still
declared in an #ifdef:
drivers/gpu/drm/imx/imx-drm-core.c: In function 'imx_drm_bind':
drivers/gpu/drm/imx/imx-drm-core.c:264:6: error: 'legacyfb_depth' undeclared
(first use in this function); did you mean 'lockdep_depth'?
Remove the #ifdef so it can always be accessed.
Fixes: f53705fd9803 ("drm/imx: Use drm_fbdev_generic_setup()")
Signed-off-by: Arnd Bergmann
---
I've already applied the previous one you sent:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=064b06bbf117f8b5e64a5143e970d5a1cf602fd6
Not sure when it reaches linux-next now that we are past rc6.
Noralf.
drivers/gpu/drm/imx/imx-drm-core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index a70f3131a377..0e6942f21a4e 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -35,10 +35,8 @@
#define MAX_CRTC 4
-#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
static int legacyfb_depth = 16;
module_param(legacyfb_depth, int, 0444);
-#endif
DEFINE_DRM_GEM_CMA_FOPS(imx_drm_driver_fops);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 --- Comment #21 from Shmerl --- I tested it with Intel GPU recently, and it doesn't crash. So it's amdgpu specific. -- 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: fb-helper: Validate requested pixel format against bpp
On Wed, Oct 3, 2018 at 4:30 PM Eugeniy Paltsev
wrote:
>
> On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> > On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > > On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> > > wrote:
> > > >
> > > > Validate requested pixel format against bits_per_pixel to reject
> > > > invalid formats with subcomponents length sum is greater than requested
> > > > bits_per_pixel.
> > > >
> > > > weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
> > > > format without bits_per_pixel updating. So it can request
> > > > x8r8g8b8 with 16 bpp which is obviously incorrect and should be
> > > > rejected.
> > > >
> > > > Cc: sta...@vger.kernel.org
> > > > Signed-off-by: Eugeniy Paltsev
> > >
> > > drm fbdev emulation doesn't support changing the pixel format at all.
> > > I think we should reject all such request, not just the invalid ones.
> > > Can you pls respin?
> >
> > FYI I once posted a patch to tighten up the fb-helper pixel format
> > stuff:
> > https://patchwork.freedesktop.org/patch/203189/
>
>
> Hi Daniel,
>
> will you take Ville's patch or should I create the new one which is only
> related
> to new pixel format validation in drm_fb_helper_check_var() ?
Ville's patch isn't the bugfix we're looking for, but a draft version
of what adding proper format support in drm's fbdev emulation could
look like. With lots of open questions. Not anywhere near ready
for merging, and definitely not stable backport material.
So yes, still want the minimal bugfix.
-Daniel
>
>
> > > Thanks, Daniel
> > >
> > > > ---
> > > > drivers/gpu/drm/drm_fb_helper.c | 7 +++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > > b/drivers/gpu/drm/drm_fb_helper.c
> > > > index 16ec93b75dbf..4f39da07f053 100644
> > > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > > @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct
> > > > fb_var_screeninfo *var,
> > > > return -EINVAL;
> > > > }
> > > >
> > > > + if ((var->green.length + var->blue.length + var->red.length +
> > > > + var->transp.length) > var->bits_per_pixel) {
> > > > + DRM_DEBUG("fb requested pixel format can't fit in %d
> > > > bpp\n",
> > > > + var->bits_per_pixel);
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > switch (var->bits_per_pixel) {
> > > > case 16:
> > > > depth = (var->green.length == 6) ? 16 : 15;
> > > > --
> > > > 2.14.4
> > > >
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN
> > > > 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 -
> > > https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.ffwll.ch=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1MriPUTkBKCrPSx67
> > > GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=Vt8OX9s9ljSK6GDgbnwsF-Yd35fbBUfe8SBV2jPnVaQ=
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1M
> > > riPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
> >
> >
> --
> Eugeniy Paltsev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/i915: Clean up early plane debugs
From: Ville Syrjälä
Print the plane hw state readout results in the common format
we already use for pipes and encoders. Also print some clearer
debug messages when we disable planes during the early phases
of state readout/sanitization.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0d004641b0d..24fe3b1fb2a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2768,10 +2768,6 @@ intel_set_plane_visible(struct intel_crtc_state
*crtc_state,
crtc_state->base.plane_mask |= drm_plane_mask(>base);
else
crtc_state->base.plane_mask &= ~drm_plane_mask(>base);
-
- DRM_DEBUG_KMS("%s active planes 0x%x\n",
- crtc_state->base.crtc->name,
- crtc_state->active_planes);
}
static void fixup_active_planes(struct intel_crtc_state *crtc_state)
@@ -2799,6 +2795,10 @@ static void intel_plane_disable_noatomic(struct
intel_crtc *crtc,
struct intel_plane_state *plane_state =
to_intel_plane_state(plane->base.state);
+ DRM_DEBUG_KMS("Disabling [PLANE:%d:%s] on [CRTC:%d:%s]\n",
+ plane->base.base.id, plane->base.name,
+ crtc->base.base.id, crtc->base.name);
+
intel_set_plane_visible(crtc_state, plane_state, false);
fixup_active_planes(crtc_state);
@@ -15523,8 +15523,8 @@ intel_sanitize_plane_mapping(struct drm_i915_private
*dev_priv)
if (pipe == crtc->pipe)
continue;
- DRM_DEBUG_KMS("%s attached to the wrong pipe, disabling
plane\n",
- plane->base.name);
+ DRM_DEBUG_KMS("[PLANE:%d:%s] attached to the wrong pipe,
disabling plane\n",
+ plane->base.base.id, plane->base.name);
plane_crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
intel_plane_disable_noatomic(plane_crtc, plane);
@@ -15713,6 +15713,10 @@ static void readout_plane_state(struct
drm_i915_private *dev_priv)
crtc_state = to_intel_crtc_state(crtc->base.state);
intel_set_plane_visible(crtc_state, plane_state, visible);
+
+ DRM_DEBUG_KMS("[PLANE:%d:%s] hw state readout: %s, pipe %c\n",
+ plane->base.base.id, plane->base.name,
+ enableddisabled(visible), pipe_name(pipe));
}
for_each_intel_crtc(_priv->drm, crtc) {
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping
From: Ville Syrjälä
When we decide that a plane is attached to the wrong pipe we try
to turn off said plane. However we are passing around the crtc we
think that the plane is supposed to be using rather than the crtc
it is currently using. That doesn't work all that well because
we may have to do vblank waits etc. and the other pipe might
not even be enabled here. So let's pass the plane's current crtc to
intel_plane_disable_noatomic() so that it can its job correctly.
To do that semi-cleanly we also have to change the plane readout
to record the plane's visibility into the bitmasks of the crtc
where the plane is currently enabled rather than to the crtc
we want to use for the plane.
One caveat here is that our active_planes bitmask will get confused
if both planes are enabled on the same pipe. Fortunately we can use
plane_mask to reconstruct active_planes sufficiently since
plane_mask still has the same meaning (is the plane visible?)
during readout. We also have to do the same during the initial
plane readout as the second plane could clear the active_planes
bit the first plane had already set.
v2: Rely on fixup_active_planes() to populate active_planes fully (Daniel)
Add Daniel's proposed comment to better document why we do this
Drop the redundant intel_set_plane_visible() call
Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have plane->get_hw_state()
return the current pipe
Cc: sta...@vger.kernel.org
Cc: Dennis
Cc: Daniel Vetter
Tested-by: Dennis
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 78 +---
1 file changed, 46 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d2828159f6c8..f0d004641b0d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2764,20 +2764,33 @@ intel_set_plane_visible(struct intel_crtc_state
*crtc_state,
plane_state->base.visible = visible;
- /* FIXME pre-g4x don't work like this */
- if (visible) {
+ if (visible)
crtc_state->base.plane_mask |= drm_plane_mask(>base);
- crtc_state->active_planes |= BIT(plane->id);
- } else {
+ else
crtc_state->base.plane_mask &= ~drm_plane_mask(>base);
- crtc_state->active_planes &= ~BIT(plane->id);
- }
DRM_DEBUG_KMS("%s active planes 0x%x\n",
crtc_state->base.crtc->name,
crtc_state->active_planes);
}
+static void fixup_active_planes(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+ struct drm_plane *plane;
+
+ /*
+* Active_planes aliases if multiple "primary" or cursor planes
+* have been used on the same (or wrong) pipe. plane_mask uses
+* unique ids, hence we can use that to reconstruct active_planes.
+*/
+ crtc_state->active_planes = 0;
+
+ drm_for_each_plane_mask(plane, _priv->drm,
+ crtc_state->base.plane_mask)
+ crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
+}
+
static void intel_plane_disable_noatomic(struct intel_crtc *crtc,
struct intel_plane *plane)
{
@@ -2787,6 +2800,7 @@ static void intel_plane_disable_noatomic(struct
intel_crtc *crtc,
to_intel_plane_state(plane->base.state);
intel_set_plane_visible(crtc_state, plane_state, false);
+ fixup_active_planes(crtc_state);
if (plane->id == PLANE_PRIMARY)
intel_pre_disable_primary_noatomic(>base);
@@ -2805,7 +2819,6 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
- struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
struct intel_plane_state *intel_state =
to_intel_plane_state(plane_state);
@@ -2900,10 +2913,6 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
plane_state->fb = fb;
plane_state->crtc = _crtc->base;
- intel_set_plane_visible(to_intel_crtc_state(crtc_state),
- to_intel_plane_state(plane_state),
- true);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
>frontbuffer_bits);
}
@@ -15494,17 +15503,6 @@ void i830_disable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
POSTING_READ(DPLL(pipe));
}
-static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
-
[PATCH v2 1/3] drm/i915: Restore vblank interrupts earlier
From: Ville Syrjälä
Plane sanitation needs vblank interrupts (on account of CxSR disable).
So let's restore vblank interrupts earlier.
v2: Make it actually build
v3: Add comment to explain why we need this (Daniel)
Cc: sta...@vger.kernel.org
Cc: Dennis
Tested-by: Dennis
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 36434c5359b1..d2828159f6c8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15570,13 +15570,9 @@ static void intel_sanitize_crtc(struct intel_crtc
*crtc,
I915_READ(reg) & ~PIPECONF_FRAME_START_DELAY_MASK);
}
- /* restore vblank interrupts to correct state */
- drm_crtc_vblank_reset(>base);
if (crtc->active) {
struct intel_plane *plane;
- drm_crtc_vblank_on(>base);
-
/* Disable everything but the primary plane */
for_each_intel_plane_on_crtc(dev, crtc, plane) {
const struct intel_plane_state *plane_state =
@@ -15918,7 +15914,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- enum pipe pipe;
struct intel_crtc *crtc;
struct intel_encoder *encoder;
int i;
@@ -15931,15 +15926,23 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
/* HW state is read out, now we need to sanitize this mess. */
get_encoder_power_domains(dev_priv);
- intel_sanitize_plane_mapping(dev_priv);
+ /*
+* intel_sanitize_plane_mapping() may need to do vblank
+* waits, so we need vblank interrupts restored beforehand.
+*/
+ for_each_intel_crtc(_priv->drm, crtc) {
+ drm_crtc_vblank_reset(>base);
- for_each_intel_encoder(dev, encoder) {
- intel_sanitize_encoder(encoder);
+ if (crtc->active)
+ drm_crtc_vblank_on(>base);
}
- for_each_pipe(dev_priv, pipe) {
- crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ intel_sanitize_plane_mapping(dev_priv);
+ for_each_intel_encoder(dev, encoder)
+ intel_sanitize_encoder(encoder);
+
+ for_each_intel_crtc(_priv->drm, crtc) {
intel_sanitize_crtc(crtc, ctx);
intel_dump_pipe_config(crtc, crtc->config,
"[setup_hw_state]");
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 2/2] amdgpu/test: Fix deadlock tests for AI and RV v2
Thanks for keeping working on this.
Series is Reviewed-by: Christian König as well.
Do you now have commit rights?
Christian.
Am 02.10.2018 um 22:47 schrieb Marek Olšák:
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Sep 28, 2018 at 10:46 AM Andrey Grodzovsky
wrote:
Seems like AI and RV requires uncashed memory mapping to be able
to pickup value written to memory by CPU after the WAIT_REG_MEM
command was already launched.
.
Enable the test for AI and RV.
v2:
Update commit description.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index 304482d..292ec4e 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -80,6 +80,8 @@ static uint32_t minor_version;
static pthread_t stress_thread;
static uint32_t *ptr;
+int use_uc_mtype = 0;
+
static void amdgpu_deadlock_helper(unsigned ip_type);
static void amdgpu_deadlock_gfx(void);
static void amdgpu_deadlock_compute(void);
@@ -92,13 +94,14 @@ CU_BOOL suite_deadlock_tests_enable(void)
_version, _handle))
return CU_FALSE;
- if (device_handle->info.family_id == AMDGPU_FAMILY_AI ||
- device_handle->info.family_id == AMDGPU_FAMILY_SI ||
- device_handle->info.family_id == AMDGPU_FAMILY_RV) {
+ if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
printf("\n\nCurrently hangs the CP on this ASIC, deadlock suite
disabled\n");
enable = CU_FALSE;
}
+ if (device_handle->info.family_id >= AMDGPU_FAMILY_AI)
+ use_uc_mtype = 1;
+
if (amdgpu_device_deinitialize(device_handle))
return CU_FALSE;
@@ -183,8 +186,8 @@ static void amdgpu_deadlock_helper(unsigned ip_type)
r = amdgpu_cs_ctx_create(device_handle, _handle);
CU_ASSERT_EQUAL(r, 0);
- r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
- AMDGPU_GEM_DOMAIN_GTT, 0,
+ r = amdgpu_bo_alloc_and_map_raw(device_handle, 4096, 4096,
+ AMDGPU_GEM_DOMAIN_GTT, 0, use_uc_mtype ?
AMDGPU_VM_MTYPE_UC : 0,
_result_handle,
_result_cpu,
_result_mc_address,
_handle);
CU_ASSERT_EQUAL(r, 0);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping
On Wed, Oct 03, 2018 at 10:53:11AM +0200, Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 05:21:36PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 02:11:34PM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 01, 2018 at 05:31:20PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > When we decide that a plane is attached to the wrong pipe we try
> > > > to turn off said plane. However we are passing around the crtc we
> > > > think that the plane is supposed to be using rather than the crtc
> > > > it is currently using. That doesn't work all that well because
> > > > we may have to do vblank waits etc. and the other pipe might
> > > > not even be enabled here. So let's pass the plane's current crtc to
> > > > intel_plane_disable_noatomic() so that it can its job correctly.
> > > >
> > > > To do that semi-cleanly we also have to change the plane readout
> > > > to record the plane's visibility into the bitmasks of the crtc
> > > > where the plane is currently enabled rather than to the crtc
> > > > we want to use for the plane.
> > > >
> > > > One caveat here is that our active_planes bitmask will get confused
> > > > if both planes are enabled on the same pipe. Fortunately we can use
> > > > plane_mask to reconstruct active_planes sufficiently since
> > > > plane_mask still has the same meaning (is the plane visible?)
> > > > during readout. We also have to do the same during the initial
> > > > plane readout as the second plane could clear the active_planes
> > > > bit the first plane had already set.
> > >
> > > How often have we broken this :-/
> > >
> > > Unfortunately I still don't have a good idea how to best CI this, since we
> > > shut down everything on module unload. Maybe we should have a special mode
> > > for module unload to leave the hw on, so that we can start testing various
> > > fastboot scenarios ...
> >
> > Yeah, that might be nice. Though wouldn't directly help here since
> > we'd still have to move the plane to the other pipe. But we could
> > of course make the driver unload do that for us as well.
> >
> > Oh and to hit this bug we'd also need to make sure cxsr is enabled
> > when we unload as that's what leads to the vblank wait. That's actually
> > the reason I didn't catch this bug originally. None of my machines
> > have a VBIOS that enables cxsr.
>
> Well that should be easy, as long as i915.ko enables cxsr ...
>
> Just pondered this since with Hans' work fedora is now using fastbook, so
> constantly breaking this stuff is kinda no longer a good option. But
> definitely future work.
>
> > > Some questions below.
> > >
> > > > Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have
> > > > plane->get_hw_state() return the current pipe
> > > > Cc: sta...@vger.kernel.org
> > > > Cc: Dennis
> > > > Tested-by: Dennis
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
> > > > Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 63
> > > > +++-
> > > > 1 file changed, 47 insertions(+), 16 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index e018b37bed39..c72be8cd1f54 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -15475,15 +15475,16 @@ void i830_disable_pipe(struct
> > > > drm_i915_private *dev_priv, enum pipe pipe)
> > > > POSTING_READ(DPLL(pipe));
> > > > }
> > > >
> > > > -static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
> > > > - struct intel_plane *plane)
> > > > +static void fixup_active_planes(struct intel_crtc *crtc)
> > > > {
> > > > - enum pipe pipe;
> > > > -
> > > > - if (!plane->get_hw_state(plane, ))
> > > > - return true;
> > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > + struct intel_crtc_state *crtc_state =
> > > > + to_intel_crtc_state(crtc->base.state);
> > > > + struct drm_plane *plane;
> > > >
> > > > - return pipe == crtc->pipe;
> > > > + drm_for_each_plane_mask(plane, _priv->drm,
> > > > + crtc_state->base.plane_mask)
> > > > + crtc_state->active_planes |=
> > > > BIT(to_intel_plane(plane)->id);
> > >
> > > I think we need to also update plane_mask here.
> >
> > plane_mask will be correct since each plane has a unique bit there.
> > And in fact we use plane_mask to reconstruct active_planes.
> >
> > What we could do is set active_planes=0 before the loop, as the loop
> > will populate it fully anyway.
>
> That + comment explaining why we don't need to reconstruct plane_mask
> would be good. Since I completely missed that. Something like:
>
> /* active_planes aliases if mutliple
Re: [PATCH] drm: fb-helper: Validate requested pixel format against bpp
On Wed, 2018-10-03 at 15:30 +0300, Ville Syrjälä wrote:
> On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> > wrote:
> > >
> > > Validate requested pixel format against bits_per_pixel to reject
> > > invalid formats with subcomponents length sum is greater than requested
> > > bits_per_pixel.
> > >
> > > weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
> > > format without bits_per_pixel updating. So it can request
> > > x8r8g8b8 with 16 bpp which is obviously incorrect and should be
> > > rejected.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Eugeniy Paltsev
> >
> > drm fbdev emulation doesn't support changing the pixel format at all.
> > I think we should reject all such request, not just the invalid ones.
> > Can you pls respin?
>
> FYI I once posted a patch to tighten up the fb-helper pixel format
> stuff:
> https://patchwork.freedesktop.org/patch/203189/
Hi Daniel,
will you take Ville's patch or should I create the new one which is only related
to new pixel format validation in drm_fb_helper_check_var() ?
> > Thanks, Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 16ec93b75dbf..4f39da07f053 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct
> > > fb_var_screeninfo *var,
> > > return -EINVAL;
> > > }
> > >
> > > + if ((var->green.length + var->blue.length + var->red.length +
> > > + var->transp.length) > var->bits_per_pixel) {
> > > + DRM_DEBUG("fb requested pixel format can't fit in %d
> > > bpp\n",
> > > + var->bits_per_pixel);
> > > + return -EINVAL;
> > > + }
> > > +
> > > switch (var->bits_per_pixel) {
> > > case 16:
> > > depth = (var->green.length == 6) ? 16 : 15;
> > > --
> > > 2.14.4
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN
> > > 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 -
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.ffwll.ch=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1MriPUTkBKCrPSx67
> > GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=Vt8OX9s9ljSK6GDgbnwsF-Yd35fbBUfe8SBV2jPnVaQ=
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIDAw=DPL6_X_6JkXFx7AXWqB0tg=ZlJN1M
> > riPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=f12ZyEESIeavtqCUKutiZ9F6xtRFC2UUvdqnM4ywBx8=CPS8taMiYbIgXo-fxhqErOJXvO6PMTzmr-BNnGJIoy0=
>
>
--
Eugeniy Paltsev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.
Signed-off-by: Giulio Benetti
---
Changes V1->V2:
* correct same bug for all same occurences in drm/sun4i folder
drivers/gpu/drm/sun4i/sun4i_lvds.c | 4 ++--
drivers/gpu/drm/sun4i/sun4i_rgb.c | 4 ++--
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index af7dcb6da351..e7eb0d1e17be 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -75,7 +75,7 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder
*encoder)
DRM_DEBUG_DRIVER("Enabling LVDS output\n");
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -88,7 +88,7 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder
*encoder)
DRM_DEBUG_DRIVER("Disabling LVDS output\n");
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index bf068da6b12e..f4a22689eb54 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -135,7 +135,7 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder
*encoder)
DRM_DEBUG_DRIVER("Enabling RGB output\n");
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
drm_panel_prepare(tcon->panel);
drm_panel_enable(tcon->panel);
}
@@ -148,7 +148,7 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder
*encoder)
DRM_DEBUG_DRIVER("Disabling RGB output\n");
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
drm_panel_disable(tcon->panel);
drm_panel_unprepare(tcon->panel);
}
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
* Following code is a way to avoid quirks all around TCON
* and DOTCLOCK drivers.
*/
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null
If using tcon with VGA, tcon->panel will be null(0), this will cause
segmentation fault when trying to dereference tcon->panel->connector.
Add tcon->panel null check before calling
sun4i_tcon0_mode_set_dithering().
Signed-off-by: Giulio Benetti
Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
RGB565/RGB666 LCD panels")
Reviewed-by: Chen-Yu Tsai
---
Changes V1->V2:
* none
drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index e4b3bd0307ef..f949287d926c 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -491,7 +491,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
/* Set dithering if needed */
- sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+ if (tcon->panel)
+ sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCIe P2P access to GPU memory
Am 03.10.2018 um 11:06 schrieb Daniel Vetter: On Wed, Oct 03, 2018 at 08:54:44AM +, Koenig, Christian wrote: Am 03.10.2018 um 09:14 schrieb Daniel Vetter: On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian wrote: This is work in progress. I published patches to enable DMA_buf P2P a few months ago, but now I'm waiting for the PCI subsystem to pick up core support for this. I can prepare you a branch based on current upstream kernel next week if you want to test this. Thread hijack, since I just read the lwn article on p2p for storage folks: https://lwn.net/Articles/767281/ Totally doesn't match what I remember of your dma-buf p2p work. Do we need to rework, or is this some kind of higher-level interface on top of the raw p2p pci stuff? Or do I misremember. The P2P from the storage folks are some mix of raw p2p capability detection for PCI and higher level interface. I'm actually waiting for that stuff to land to extract the p2p capability detection and use it for this DMA-buf stuff as well. Alternative would be to convince Logan to extract the capability detection in his patch set as well, but so far he wasn't very keen about that. So no plan to make dma-buf some kind of orchestrator and use the p2p map_sg stuff? Not sure about that yet. Didn't had time to take a closer look. Christian. That seems to be the new/additional bits I haven't seen yet, and I'm wondered how we should fit dma-buf into that picture. -Daniel Christian. Thanks, Daniel Regards, Christian. Am 29.09.2018 09:01 schrieb Dirk Eibach : I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with mainline drivers. I can acquire a dmabuf from the GPU and pass it to my PCIe framegrabber. But I don't see a way to get the PCIe bus address of the video memory which I need for the P2P transfer. Is there already any infrastructure in place for doing this? If not, what would be the right way to implement this? Add another callback to the dmabuf struct? Cheers Dirk ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Extend todo
On 10/03, Daniel Vetter wrote: > Typed up all the items Rodrigo capture at the vkms workshop at > xdc2018: > > https://etherpad.net/p/vkms_todo > > v2: Review from Rodrigo. > - Add eBPF for atomic check, I forgot it. > - Improve spelling. > > Signed-off-by: Daniel Vetter > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: Haneen Mohammed > Cc: Rodrigo Siqueira > --- > Documentation/gpu/vkms.rst | 101 - > 1 file changed, 99 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > index 0a6ea6216e41..7dfc349a4508 100644 > --- a/Documentation/gpu/vkms.rst > +++ b/Documentation/gpu/vkms.rst > @@ -10,8 +10,8 @@ > TODO > > > -CRC API > > +CRC API Improvements > + > > - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` > > @@ -22,3 +22,100 @@ CRC API > > - Add igt test to check extreme alpha values i.e. fully opaque and fully >transparent (intermediate values are affected by hw-specific rounding > modes). > + > +Vblank issues > +- > + > +Some IGT test cases are failing. Need to analyze why and fix the issues: > + > +- plain-flip-fb-recreate > +- plain-flip-ts-check > +- flip-vs-blocking-wf-vblank > +- plain-flip-fb-recreate-interruptible > +- flip-vs-wf_vblank-interruptible > + > +Runtime Configuration > +- > + > +We want to be able to reconfigure vkms instance without having to reload the > +module. Use/Test-cases: > + > +- Hotplug/hotremove connectors on the fly (to be able to test DP MST > handling of > + compositors). > + > +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 > of > + them first). > + > +- Change output configuration: Plug/unplug screens, change EDID, allow > changing > + the refresh rate. > + > +The currently proposed solution is to expose vkms configuration through > +configfs. All existing module options should be supported through configfs > too. > + > +Add Plane Features > +-- > + > +There's lots of plane features we could add support for: > + > +- Real overlay planes, not just cursor. > + > +- Full alpha blending on all planes. > + > +- Rotation, scaling. > + > +- Additional buffer formats, especially YUV formats for video like NV12. > + Low/high bpp RGB formats would also be interesting. > + > +- Async updates (currently only possible on cursor plane using the legacy > cursor > + api). > + > +For all of these, we also want to review the igt test coverage and make sure > all > +relevant igt testcases work on vkms. > + > +Writeback support > +- > + > +Currently vkms only computes a CRC for each frame. Once we have additional > plane > +features, we could write back the entire composited frame, and expose it as: > + > +- Writeback connector. This is useful for testing compositors if you don't > have > + hardware with writeback support. > + > +- As a v4l device. This is useful for debugging compositors on special vkms > + configurations, so that developers see what's really going on. > + > +Prime Buffer Sharing > + > + > +We already have vgem, which is a gem driver for testing rendering, similar to > +how vkms is for testing the modeset side. Adding buffer sharing support to > vkms > +allows us to test them together, to test synchronization and lots of other > +features. Also, this allows compositors to test whether they work correctly > on > +SoC chips, where the display and rendering is very often split between 2 > +drivers. > + > +Output Features > +--- > + > +- Variable refresh rate/freesync support. This probably needs prime buffer > + sharing support, so that we can use vgem fences to simulate rendering in > + testing. Also needs support to specify the EDID. > + > +- Add support for link status, so that compositors can validate their runtime > + fallbacks when e.g. a Display Port link goes bad. > + > +- All the hotplug handling describe under "Runtime Configuration". > + > +Atomic Check using eBPF > +--- > + > +Atomic drivers have lots of restrictions which are not exposed to userspace > in > +any explicit form through e.g. possible property values. Userspace can only > +inquiry about these limits through the atomic IOCTL, possibly using the > +TEST_ONLY flag. Trying to add configurable code for all these limits, to > allow > +compositors to be tested against them, would be rather futile exercise. > Instead > +we could add support for eBPF to validate any kind of atomic state, and > +implement a library of different restrictions. > + > +This needs a bunch of features (plane compositing, multiple outputs, ...) > +enabled already to make sense. > -- > 2.19.0.rc2 > Reviewed-by: Rodrigo Siqueira -- Rodrigo Siqueira http://siqueira.tech Graduate Student Department of Computer Science University of São Paulo
Re: [PATCH] drm/vkms: Extend todo
On Wed, Oct 03, 2018 at 09:57:15AM -0300, Rodrigo Siqueira wrote: > Hi, > > I just added some minor reviews below. > > Also, did you give up to add the eBPF task? I forgot to add that. Will fix. > > Best Regards > > Allow Berkeley Packet Filter (BPF), use cases for atomic check: > > On 10/03, Daniel Vetter wrote: > > Typed up all the items Rodrigo capture at the vkms workshop at > > xdc2018: > > > > https://etherpad.net/p/vkms_todo > > > > Signed-off-by: Daniel Vetter > > Cc: Gustavo Padovan > > Cc: Maarten Lankhorst > > Cc: Sean Paul > > Cc: Haneen Mohammed > > Cc: Rodrigo Siqueira > > --- > > Documentation/gpu/vkms.rst | 87 +- > > 1 file changed, 85 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > > index 0a6ea6216e41..80cbe0759d3c 100644 > > --- a/Documentation/gpu/vkms.rst > > +++ b/Documentation/gpu/vkms.rst > > @@ -10,8 +10,8 @@ > > TODO > > > > > > -CRC API > > > > +CRC API Improvements > > + > > > > - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` > > > > @@ -22,3 +22,86 @@ CRC API > > > > - Add igt test to check extreme alpha values i.e. fully opaque and fully > >transparent (intermediate values are affected by hw-specific rounding > > modes). > > + > > +Vblank issues > > +- > > + > > +Some IGT testcases are failing. Need to analyze why and fix the issues: > > + > > test cases > > > +- plain-flip-fb-recreate > > +- plain-flip-ts-check > > +- flip-vs-blocking-wf-vblank > > +- plain-flip-fb-recreate-interruptible > > +- flip-vs-wf_vblank-interruptible > > + > > +Runtime Configuration > > +- > > + > > +We want to be able to reconfigure vkms instance without having to reload > > the > > +module. Use/Test-cases: > > + > > +- Hotplug/hotremove connectors on the fly (to be able to test DP MST > > handling of > > + compositors). > > + > > +- Configure planes/crtcs/connectors (we'd need some code to have more than > > 1 of > > + them first). > > + > > +- Change output configuration: Plug/unplug screens, change EDID, allow > > changing > > + the refresh rate. > > + > > +Currently proposed solution is to expose vkms configuration through > > configfs. > > +All existing module options should be supported through configfs too. > > The currently proposed > > > +Add Plane Features > > +-- > > + > > +There's lots of plane features we could add support fort: > > for > > > + > > +- Real overlay planes, not just cursor. > > + > > +- Full alpha blending on all planes. > > + > > +- Rotation, scaling. > > + > > +- Additional buffer formats, especially YUV formats for video like NV12. > > + Low/high bpp RGB formats would also be interesting. > > + > > +- Async updates (currently only possible on cursor plane using the legacy > > cursor > > + api). > > + > > +For all of these we also want to review the igt test coverage and make > > sure all > > +relevant igt testcases work on vkms. > > + > > "For all of these, we" > > > +Writeback support > > +- > > + > > +Currently vkms only computes a CRC for each frame. Once we have additional > > plane > > +features, we could write back the entire composited frame, and expose it > > as: > > + > > +- Writeback connector. This is useful for testing compositors if you don't > > have > > + hardware with writeback support. > > + > > +- As a v4l device. This is useful for debugging compositors on special vkms > > + configurations, so that developers see what's really going on. > > + > > +Prime Buffer Sharing > > + > > + > > +We already have vgem, which is a gem driver for testing rendering, similar > > to > > +how vkms is for testing the modeset side. Adding buffer sharing support to > > vkms > > +allows us to test them together, to test synchronization and lots of other > > +features. Also, this allows compositors to test whether they work > > correctly on > > +SoC chips, where the display and rendering is very often split between 2 > > +drivers. > > + > > +Output Features > > +--- > > + > > +- Variable refresh rate/freesync support. This probably needs prime buffer > > + sharing support, so that we can use vgem fences to simulate rendering in > > + testing. Also needs support to specify the EDID. > > + > > +- Add support for link status, so that compositors can validate their > > runtime > > + fallbacks when e.g. a Display Port link goes bad. > > + > > +- All the hotplug handling describe under "Runtime Configuration". > > -- > > 2.19.0.rc2 > > > > -- > Rodrigo Siqueira > http://siqueira.tech > Graduate Student > Department of Computer Science > University of São Paulo -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCH] drm/vkms: Extend todo
Typed up all the items Rodrigo capture at the vkms workshop at xdc2018: https://etherpad.net/p/vkms_todo v2: Review from Rodrigo. - Add eBPF for atomic check, I forgot it. - Improve spelling. Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: Haneen Mohammed Cc: Rodrigo Siqueira --- Documentation/gpu/vkms.rst | 101 - 1 file changed, 99 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO -CRC API +CRC API Improvements + - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` @@ -22,3 +22,100 @@ CRC API - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +- + +Some IGT test cases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too. + +Add Plane Features +-- + +There's lots of plane features we could add support for: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing + + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". + +Atomic Check using eBPF +--- + +Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions. + +This needs a bunch of features (plane compositing, multiple outputs, ...) +enabled already to make sense. -- 2.19.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 18/18] drm: Unexport primary plane helpers
On Wed, Oct 03, 2018 at 11:18:27AM +0200, Daniel Vetter wrote:
> Well except the destroy helper, which isn't really a primary helper
> but generally useful, if mislabelled.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 85 --
> include/drm/drm_plane_helper.h | 10
> 2 files changed, 11 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index 33b3e6892787..0fff72dcd06d 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -42,11 +42,8 @@
> * primary plane support on top of the normal CRTC configuration interface.
> * Since the legacy _mode_config_funcs.set_config interface ties the
> primary
> * plane together with the CRTC state this does not allow userspace to
> disable
> - * the primary plane itself. To avoid too much duplicated code use
> - * drm_plane_helper_check_update() which can be used to enforce the same
> - * restrictions as primary planes had thus. The default primary plane only
> - * expose XRBG and ARGB as valid pixel formats for the attached
> - * framebuffer.
> + * the primary plane itself. The default primary plane only expose XRBG
> and
> + * ARGB as valid pixel formats for the attached framebuffer.
> *
> * Drivers are highly recommended to implement proper support for primary
> * planes, and newly merged drivers must not rely upon these transitional
> @@ -148,50 +145,13 @@ static int drm_plane_helper_check_update(struct
> drm_plane *plane,
> return 0;
> }
>
> -/**
> - * drm_primary_helper_update() - Helper for primary plane update
> - * @plane: plane object to update
> - * @crtc: owning CRTC of owning plane
> - * @fb: framebuffer to flip onto plane
> - * @crtc_x: x offset of primary plane on crtc
> - * @crtc_y: y offset of primary plane on crtc
> - * @crtc_w: width of primary plane rectangle on crtc
> - * @crtc_h: height of primary plane rectangle on crtc
> - * @src_x: x offset of @fb for panning
> - * @src_y: y offset of @fb for panning
> - * @src_w: width of source rectangle in @fb
> - * @src_h: height of source rectangle in @fb
> - * @ctx: lock acquire context, not used here
> - *
> - * Provides a default plane update handler for primary planes. This is
> handler
> - * is called in response to a userspace SetPlane operation on the plane with
> a
> - * non-NULL framebuffer. We call the driver's modeset handler to update the
> - * framebuffer.
> - *
> - * SetPlane() on a primary plane of a disabled CRTC is not supported, and
> will
> - * return an error.
> - *
> - * Note that we make some assumptions about hardware limitations that may
> not be
> - * true for all hardware --
> - *
> - * 1. Primary plane cannot be repositioned.
> - * 2. Primary plane cannot be scaled.
> - * 3. Primary plane must cover the entire CRTC.
> - * 4. Subpixel positioning is not supported.
> - *
> - * Drivers for hardware that don't have these restrictions can provide their
> - * own implementation rather than using this helper.
> - *
> - * RETURNS:
> - * Zero on success, error code on failure
> - */
> -int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - int crtc_x, int crtc_y,
> - unsigned int crtc_w, unsigned int crtc_h,
> - uint32_t src_x, uint32_t src_y,
> - uint32_t src_w, uint32_t src_h,
> - struct drm_modeset_acquire_ctx *ctx)
> +static int drm_primary_helper_update(struct drm_plane *plane, struct
> drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> + uint32_t src_x, uint32_t src_y,
> + uint32_t src_w, uint32_t src_h,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_mode_set set = {
> .crtc = crtc,
> @@ -258,35 +218,12 @@ int drm_primary_helper_update(struct drm_plane *plane,
> struct drm_crtc *crtc,
> kfree(connector_list);
> return ret;
> }
> -EXPORT_SYMBOL(drm_primary_helper_update);
>
> -/**
> - * drm_primary_helper_disable() - Helper for primary plane disable
> - * @plane: plane to disable
> - * @ctx: lock acquire context, not used here
> - *
> - * Provides a default plane disable handler for primary planes. This is
> handler
> - * is called in response to a userspace SetPlane operation on the plane with
> a
> - * NULL framebuffer parameter. It unconditionally fails the disable call
> with
> - * -EINVAL the only way to disable the primary plane without driver support
> is
> - * to disable the entire CRTC. Which does not match the
Re: [PATCH 16/18] drm/vmwgfx: Fix vmw_du_cursor_plane_atomic_check
On Wed, Oct 03, 2018 at 11:18:25AM +0200, Daniel Vetter wrote:
> From: Thomas Hellstrom
>
> Use the correct helper and also return early on helper
> success rather than on helper failure.
>
> Also explicitly return 0 in the case of no fb.
>
> v2: Check for !fb after updating state->visible (Ville).
>
> Signed-off-by: Thomas Hellstrom (v1)
> Reported-by: Dan Carpenter
> Reported-by: Daniel Vetter
> Cc: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 1b2a406b7742..8e3e262b6ef4 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -493,24 +493,24 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane
> *plane,
>struct drm_plane_state *new_state)
> {
> int ret = 0;
> + struct drm_crtc_state *crtc_state = NULL;
> struct vmw_surface *surface = NULL;
> struct drm_framebuffer *fb = new_state->fb;
>
> - struct drm_rect src = drm_plane_state_src(new_state);
> - struct drm_rect dest = drm_plane_state_dest(new_state);
> + if (new_state->crtc)
> + crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
> +new_state->crtc);
>
> - /* Turning off */
> - if (!fb)
> + ret = drm_atomic_helper_check_plane_state(new_state, crtc_state,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + true, true);
> + if (ret)
> return ret;
>
> - ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
> - , ,
> - DRM_MODE_ROTATE_0,
> - DRM_PLANE_HELPER_NO_SCALING,
> - DRM_PLANE_HELPER_NO_SCALING,
> - true, true, _state->visible);
> - if (!ret)
> - return ret;
> + /* Turning off */
> + if (!fb)
> + return 0;
Yep, now ->visible should be up to date.
Reviewed-by: Ville Syrjälä
>
> /* A lot of the code assumes this */
> if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
> --
> 2.19.0.rc2
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 15/18] drm: Remove transitional helpers
On Wed, Oct 03, 2018 at 11:18:24AM +0200, Daniel Vetter wrote:
> With armada the last bigger driver that realistically needed these to
> convert from legacy kms to atomic is converted. These helpers have
> been broken more often than not the past 2 years, and as this little
> patch series shows, tricked a bunch of people into using the wrong
> helpers for their functions.
>
> Aside: I think a lot more drivers should be using the device-level
> drm_atomic_helper_shutdown/suspend/resume helpers and related
> functions. In almost all the cases they get things exactly right.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 115 -
> drivers/gpu/drm/drm_plane_helper.c | 197 -
> include/drm/drm_crtc_helper.h | 6 -
> include/drm/drm_plane_helper.h | 14 --
> 4 files changed, 332 deletions(-)
Pretty nice diffstat.
Reviewed-by: Ville Syrjälä
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index ce75e9506e85..a3c81850e755 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -984,118 +984,3 @@ void drm_helper_resume_force_mode(struct drm_device
> *dev)
> drm_modeset_unlock_all(dev);
> }
> EXPORT_SYMBOL(drm_helper_resume_force_mode);
> -
> -/**
> - * drm_helper_crtc_mode_set - mode_set implementation for atomic plane
> helpers
> - * @crtc: DRM CRTC
> - * @mode: DRM display mode which userspace requested
> - * @adjusted_mode: DRM display mode adjusted by ->mode_fixup callbacks
> - * @x: x offset of the CRTC scanout area on the underlying framebuffer
> - * @y: y offset of the CRTC scanout area on the underlying framebuffer
> - * @old_fb: previous framebuffer
> - *
> - * This function implements a callback useable as the ->mode_set callback
> - * required by the CRTC helpers. Besides the atomic plane helper functions
> for
> - * the primary plane the driver must also provide the ->mode_set_nofb
> callback
> - * to set up the CRTC.
> - *
> - * This is a transitional helper useful for converting drivers to the atomic
> - * interfaces.
> - */
> -int drm_helper_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode
> *mode,
> - struct drm_display_mode *adjusted_mode, int x, int
> y,
> - struct drm_framebuffer *old_fb)
> -{
> - struct drm_crtc_state *crtc_state;
> - const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> - int ret;
> -
> - if (crtc->funcs->atomic_duplicate_state)
> - crtc_state = crtc->funcs->atomic_duplicate_state(crtc);
> - else {
> - if (!crtc->state)
> - drm_atomic_helper_crtc_reset(crtc);
> -
> - crtc_state = drm_atomic_helper_crtc_duplicate_state(crtc);
> - }
> -
> - if (!crtc_state)
> - return -ENOMEM;
> -
> - crtc_state->planes_changed = true;
> - crtc_state->mode_changed = true;
> - ret = drm_atomic_set_mode_for_crtc(crtc_state, mode);
> - if (ret)
> - goto out;
> - drm_mode_copy(_state->adjusted_mode, adjusted_mode);
> -
> - if (crtc_funcs->atomic_check) {
> - ret = crtc_funcs->atomic_check(crtc, crtc_state);
> - if (ret)
> - goto out;
> - }
> -
> - swap(crtc->state, crtc_state);
> -
> - crtc_funcs->mode_set_nofb(crtc);
> -
> - ret = drm_helper_crtc_mode_set_base(crtc, x, y, old_fb);
> -
> -out:
> - if (crtc_state) {
> - if (crtc->funcs->atomic_destroy_state)
> - crtc->funcs->atomic_destroy_state(crtc, crtc_state);
> - else
> - drm_atomic_helper_crtc_destroy_state(crtc, crtc_state);
> - }
> -
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_helper_crtc_mode_set);
> -
> -/**
> - * drm_helper_crtc_mode_set_base - mode_set_base implementation for atomic
> plane helpers
> - * @crtc: DRM CRTC
> - * @x: x offset of the CRTC scanout area on the underlying framebuffer
> - * @y: y offset of the CRTC scanout area on the underlying framebuffer
> - * @old_fb: previous framebuffer
> - *
> - * This function implements a callback useable as the ->mode_set_base used
> - * required by the CRTC helpers. The driver must provide the atomic plane
> helper
> - * functions for the primary plane.
> - *
> - * This is a transitional helper useful for converting drivers to the atomic
> - * interfaces.
> - */
> -int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> - struct drm_framebuffer *old_fb)
> -{
> - struct drm_plane_state *plane_state;
> - struct drm_plane *plane = crtc->primary;
> -
> - if (plane->funcs->atomic_duplicate_state)
> - plane_state = plane->funcs->atomic_duplicate_state(plane);
> - else {
> - if (!plane->state)
> - drm_atomic_helper_plane_reset(plane);
> -
> -
Re: [PATCH 14/18] drm/zte: Use drm_atomic_helper_shutdown
On Wed, Oct 03, 2018 at 11:18:23AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutdown() instead.
>
> Signed-off-by: Daniel Vetter
> Cc: Shawn Guo
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 1 +
> drivers/gpu/drm/zte/zx_plane.c | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 5b6f1eda52e0..f5ea32ae8600 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -124,6 +124,7 @@ static void zx_drm_unbind(struct device *dev)
>
> drm_dev_unregister(drm);
> drm_kms_helper_poll_fini(drm);
> + drm_atomic_helper_shutdown(drm);
> drm_mode_config_cleanup(drm);
Familiar pattern by now, so
Reviewed-by: Ville Syrjälä
> component_unbind_all(dev, drm);
> dev_set_drvdata(dev, NULL);
> diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
> index ae8c53b4b261..83d236fd893c 100644
> --- a/drivers/gpu/drm/zte/zx_plane.c
> +++ b/drivers/gpu/drm/zte/zx_plane.c
> @@ -446,7 +446,6 @@ static const struct drm_plane_helper_funcs
> zx_gl_plane_helper_funcs = {
>
> static void zx_plane_destroy(struct drm_plane *plane)
> {
> - drm_plane_helper_disable(plane, NULL);
> drm_plane_cleanup(plane);
> }
>
> --
> 2.19.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/18] drm/vc4: Use drm_atomic_helper_shutdown
On Wed, Oct 03, 2018 at 11:18:22AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutdown() instead.
>
> v2: Rebase.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
Looks correct to me.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
> drivers/gpu/drm/vc4/vc4_plane.c | 1 -
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 1f1780ccdbdf..f6f5cd80c04d 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
>
> #include "uapi/drm/vc4_drm.h"
> #include "vc4_drv.h"
> @@ -308,6 +309,8 @@ static void vc4_drm_unbind(struct device *dev)
>
> drm_dev_unregister(drm);
>
> + drm_atomic_helper_shutdown(drm);
> +
> drm_mode_config_cleanup(drm);
>
> drm_atomic_private_obj_fini(>ctm_manager);
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 9dc3fcbd290b..d04b3c3246ba 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -903,7 +903,6 @@ static const struct drm_plane_helper_funcs
> vc4_plane_helper_funcs = {
>
> static void vc4_plane_destroy(struct drm_plane *plane)
> {
> - drm_plane_helper_disable(plane, NULL);
> drm_plane_cleanup(plane);
> }
>
> --
> 2.19.0.rc2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 12/18] drm/sti: Use drm_atomic_helper_shutdown
On Wed, Oct 03, 2018 at 11:17:26AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutdown() instead.
>
> The sti cleanup code seems supremely confused:
> - In the load error path it calls drm_mode_config_cleanup before it
> stops various kms services like poll worker or fbdev emulation.
> That's going to oops.
> - The actual unload code doesn't even bother with the cleanup and just
> leaks.
>
> Try to fix this while at it.
>
> Signed-off-by: Daniel Vetter
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> ---
> drivers/gpu/drm/sti/sti_cursor.c | 1 -
> drivers/gpu/drm/sti/sti_drv.c| 6 +++---
> drivers/gpu/drm/sti/sti_gdp.c| 1 -
> drivers/gpu/drm/sti/sti_hqvdp.c | 1 -
> 4 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_cursor.c
> b/drivers/gpu/drm/sti/sti_cursor.c
> index 57b870e1e696..bc908453ffb3 100644
> --- a/drivers/gpu/drm/sti/sti_cursor.c
> +++ b/drivers/gpu/drm/sti/sti_cursor.c
> @@ -332,7 +332,6 @@ static void sti_cursor_destroy(struct drm_plane
> *drm_plane)
> {
> DRM_DEBUG_DRIVER("\n");
>
> - drm_plane_helper_disable(drm_plane, NULL);
> drm_plane_cleanup(drm_plane);
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 6dced8abcf16..ac54e0f9caea 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -206,6 +206,8 @@ static void sti_cleanup(struct drm_device *ddev)
> struct sti_private *private = ddev->dev_private;
>
> drm_kms_helper_poll_fini(ddev);
> + drm_atomic_helper_shutdown(ddev);
> + drm_mode_config_cleanup(ddev);
Looks like a more sane ordering. Not really sure how these component
based drivers work so probably not the best person to judge this,
but based on my weak understanding
Reviewed-by: Ville Syrjälä
> component_unbind_all(ddev->dev, ddev);
> kfree(private);
> ddev->dev_private = NULL;
> @@ -230,7 +232,7 @@ static int sti_bind(struct device *dev)
>
> ret = drm_dev_register(ddev, 0);
> if (ret)
> - goto err_register;
> + goto err_cleanup;
>
> drm_mode_config_reset(ddev);
>
> @@ -238,8 +240,6 @@ static int sti_bind(struct device *dev)
>
> return 0;
>
> -err_register:
> - drm_mode_config_cleanup(ddev);
> err_cleanup:
> sti_cleanup(ddev);
> err_drm_dev_put:
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index c32de6cbf061..3c19614d3f75 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -883,7 +883,6 @@ static void sti_gdp_destroy(struct drm_plane *drm_plane)
> {
> DRM_DEBUG_DRIVER("\n");
>
> - drm_plane_helper_disable(drm_plane, NULL);
> drm_plane_cleanup(drm_plane);
> }
>
> diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
> index 03ac3b4a4469..23565f52dd71 100644
> --- a/drivers/gpu/drm/sti/sti_hqvdp.c
> +++ b/drivers/gpu/drm/sti/sti_hqvdp.c
> @@ -1260,7 +1260,6 @@ static void sti_hqvdp_destroy(struct drm_plane
> *drm_plane)
> {
> DRM_DEBUG_DRIVER("\n");
>
> - drm_plane_helper_disable(drm_plane, NULL);
> drm_plane_cleanup(drm_plane);
> }
>
> --
> 2.19.0.rc2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/18] drm/msm: Use drm_atomic_helper_shutdown
On Wed, Oct 03, 2018 at 11:16:44AM +0200, Daniel Vetter wrote:
> drm_plane_helper_disable is a non-atomic drivers only function, and
> will blow up (since no one passes the locking context it needs).
>
> Atomic drivers which want to quiescent their hw on unload should
> use drm_atomic_helper_shutdown() instead.
lgtm
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Rajesh Yadav
> Cc: Chandan Uddaraju
> Cc: Archit Taneja
> Cc: Jeykumar Sankaran
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Cc: Sinclair Yeh
> Cc: "Ville Syrjälä"
> Cc: Russell King
> Cc: Gustavo Padovan
> Cc: Arnd Bergmann
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 --
> drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 1 -
> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 1 -
> drivers/gpu/drm/msm/msm_drv.c | 1 +
> 4 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 015341e2dd4c..ec959f847d5f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -1482,8 +1482,6 @@ static void dpu_plane_destroy(struct drm_plane *plane)
>
> mutex_destroy(>lock);
>
> - drm_plane_helper_disable(plane, NULL);
> -
> /* this will destroy the states as well */
> drm_plane_cleanup(plane);
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
> index 79ff653d8081..7a499731ce93 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
> @@ -68,7 +68,6 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
> {
> struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
>
> - drm_plane_helper_disable(plane, NULL);
> drm_plane_cleanup(plane);
>
> kfree(mdp4_plane);
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> index 7d306c5acd09..d5e4f0de321a 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
> @@ -46,7 +46,6 @@ static void mdp5_plane_destroy(struct drm_plane *plane)
> {
> struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
>
> - drm_plane_helper_disable(plane, NULL);
> drm_plane_cleanup(plane);
>
> kfree(mdp5_plane);
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c1abad8a8612..69dbdba183fe 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -312,6 +312,7 @@ static int msm_drm_uninit(struct device *dev)
> if (fbdev && priv->fbdev)
> msm_fbdev_free(ddev);
> #endif
> + drm_atomic_helper_shutdown(ddev);
> drm_mode_config_cleanup(ddev);
>
> pm_runtime_get_sync(dev);
> --
> 2.19.0.rc2
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Extend todo
Hi, I just added some minor reviews below. Also, did you give up to add the eBPF task? Best Regards Allow Berkeley Packet Filter (BPF), use cases for atomic check: On 10/03, Daniel Vetter wrote: > Typed up all the items Rodrigo capture at the vkms workshop at > xdc2018: > > https://etherpad.net/p/vkms_todo > > Signed-off-by: Daniel Vetter > Cc: Gustavo Padovan > Cc: Maarten Lankhorst > Cc: Sean Paul > Cc: Haneen Mohammed > Cc: Rodrigo Siqueira > --- > Documentation/gpu/vkms.rst | 87 +- > 1 file changed, 85 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst > index 0a6ea6216e41..80cbe0759d3c 100644 > --- a/Documentation/gpu/vkms.rst > +++ b/Documentation/gpu/vkms.rst > @@ -10,8 +10,8 @@ > TODO > > > -CRC API > > +CRC API Improvements > + > > - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` > > @@ -22,3 +22,86 @@ CRC API > > - Add igt test to check extreme alpha values i.e. fully opaque and fully >transparent (intermediate values are affected by hw-specific rounding > modes). > + > +Vblank issues > +- > + > +Some IGT testcases are failing. Need to analyze why and fix the issues: > + test cases > +- plain-flip-fb-recreate > +- plain-flip-ts-check > +- flip-vs-blocking-wf-vblank > +- plain-flip-fb-recreate-interruptible > +- flip-vs-wf_vblank-interruptible > + > +Runtime Configuration > +- > + > +We want to be able to reconfigure vkms instance without having to reload the > +module. Use/Test-cases: > + > +- Hotplug/hotremove connectors on the fly (to be able to test DP MST > handling of > + compositors). > + > +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 > of > + them first). > + > +- Change output configuration: Plug/unplug screens, change EDID, allow > changing > + the refresh rate. > + > +Currently proposed solution is to expose vkms configuration through configfs. > +All existing module options should be supported through configfs too. The currently proposed > +Add Plane Features > +-- > + > +There's lots of plane features we could add support fort: for > + > +- Real overlay planes, not just cursor. > + > +- Full alpha blending on all planes. > + > +- Rotation, scaling. > + > +- Additional buffer formats, especially YUV formats for video like NV12. > + Low/high bpp RGB formats would also be interesting. > + > +- Async updates (currently only possible on cursor plane using the legacy > cursor > + api). > + > +For all of these we also want to review the igt test coverage and make sure > all > +relevant igt testcases work on vkms. > + "For all of these, we" > +Writeback support > +- > + > +Currently vkms only computes a CRC for each frame. Once we have additional > plane > +features, we could write back the entire composited frame, and expose it as: > + > +- Writeback connector. This is useful for testing compositors if you don't > have > + hardware with writeback support. > + > +- As a v4l device. This is useful for debugging compositors on special vkms > + configurations, so that developers see what's really going on. > + > +Prime Buffer Sharing > + > + > +We already have vgem, which is a gem driver for testing rendering, similar to > +how vkms is for testing the modeset side. Adding buffer sharing support to > vkms > +allows us to test them together, to test synchronization and lots of other > +features. Also, this allows compositors to test whether they work correctly > on > +SoC chips, where the display and rendering is very often split between 2 > +drivers. > + > +Output Features > +--- > + > +- Variable refresh rate/freesync support. This probably needs prime buffer > + sharing support, so that we can use vgem fences to simulate rendering in > + testing. Also needs support to specify the EDID. > + > +- Add support for link status, so that compositors can validate their runtime > + fallbacks when e.g. a Display Port link goes bad. > + > +- All the hotplug handling describe under "Runtime Configuration". > -- > 2.19.0.rc2 > -- Rodrigo Siqueira http://siqueira.tech Graduate Student Department of Computer Science University of São Paulo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fb-helper: Validate requested pixel format against bpp
On Wed, Oct 03, 2018 at 01:36:00PM +0200, Daniel Vetter wrote:
> On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
> wrote:
> >
> > Validate requested pixel format against bits_per_pixel to reject
> > invalid formats with subcomponents length sum is greater than requested
> > bits_per_pixel.
> >
> > weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
> > format without bits_per_pixel updating. So it can request
> > x8r8g8b8 with 16 bpp which is obviously incorrect and should be
> > rejected.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eugeniy Paltsev
>
> drm fbdev emulation doesn't support changing the pixel format at all.
> I think we should reject all such request, not just the invalid ones.
> Can you pls respin?
FYI I once posted a patch to tighten up the fb-helper pixel format
stuff:
https://patchwork.freedesktop.org/patch/203189/
>
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 16ec93b75dbf..4f39da07f053 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> > *var,
> > return -EINVAL;
> > }
> >
> > + if ((var->green.length + var->blue.length + var->red.length +
> > + var->transp.length) > var->bits_per_pixel) {
> > + DRM_DEBUG("fb requested pixel format can't fit in %d bpp\n",
> > + var->bits_per_pixel);
> > + return -EINVAL;
> > + }
> > +
> > switch (var->bits_per_pixel) {
> > case 16:
> > depth = (var->green.length == 6) ? 16 : 15;
> > --
> > 2.14.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Extend todo
Typed up all the items Rodrigo capture at the vkms workshop at xdc2018: https://etherpad.net/p/vkms_todo Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul Cc: Haneen Mohammed Cc: Rodrigo Siqueira --- Documentation/gpu/vkms.rst | 87 +- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..80cbe0759d3c 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO -CRC API +CRC API Improvements + - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` @@ -22,3 +22,86 @@ CRC API - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +- + +Some IGT testcases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +Currently proposed solution is to expose vkms configuration through configfs. +All existing module options should be supported through configfs too. + +Add Plane Features +-- + +There's lots of plane features we could add support fort: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing + + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". -- 2.19.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer
Il 03/10/2018 11:43, Chen-Yu Tsai ha scritto:
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.
There's actually more than one occurance of this error:
drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c: if (!IS_ERR(tcon->panel)) {
These four are responsible for enabling and disabling the panel.
drivers/gpu/drm/sun4i/sun4i_tcon.c: if (!IS_ERR(tcon->panel)) {
All this looks like it was left over from commit ebc9446135671 ("drm: convert
drivers to use drm_of_find_panel_or_bridge"). We have checks against tcon->panel
in several places and not all of them were converted.
Then, I'm going to send a patchset to correct them.
Best regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fb-helper: Validate requested pixel format against bpp
On Wed, Oct 3, 2018 at 1:05 PM Eugeniy Paltsev
wrote:
>
> Validate requested pixel format against bits_per_pixel to reject
> invalid formats with subcomponents length sum is greater than requested
> bits_per_pixel.
>
> weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
> format without bits_per_pixel updating. So it can request
> x8r8g8b8 with 16 bpp which is obviously incorrect and should be
> rejected.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev
drm fbdev emulation doesn't support changing the pixel format at all.
I think we should reject all such request, not just the invalid ones.
Can you pls respin?
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_fb_helper.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 16ec93b75dbf..4f39da07f053 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
> *var,
> return -EINVAL;
> }
>
> + if ((var->green.length + var->blue.length + var->red.length +
> + var->transp.length) > var->bits_per_pixel) {
> + DRM_DEBUG("fb requested pixel format can't fit in %d bpp\n",
> + var->bits_per_pixel);
> + return -EINVAL;
> + }
> +
> switch (var->bits_per_pixel) {
> case 16:
> depth = (var->green.length == 6) ? 16 : 15;
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add P010, P012, P016 format definitions and fourcc
Hi Alex,
For my patches there seems limited interest to get them merged before
IGT support these modes..I'm not holding my breath for this.
https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html
/Juha-Pekka
On 02.10.2018 18:00, Alexandru-Cosmin Gheorghe wrote:
Hi,
How is this going on, anything holding it back from getting merged ?
I'm interested in adding/using P010, [1]
Thank you,
Alex Gheorghe
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186963.html
On Thu, Aug 30, 2018 at 03:41:11PM +0300, Juha-Pekka Heikkila wrote:
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First come Y plane [12:4]
followed by 2x2 subsampled Cr:Cb plane [12:4:12:4]
Add P016 definition, semi-planar yuv format where each component
is 16 bits. First come Y plane followed by 2x2 subsampled Cr:Cb
plane [16:16]
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/drm_fourcc.c | 3 +++
include/uapi/drm/drm_fourcc.h | 10 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 35c1e27..32e07a2 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,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, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2ed46e9..daaabb1 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -178,6 +178,16 @@ extern "C" {
#define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [15:0] Y little endian where Pxxx indicate
+ * component xxx msb Y [xxx:16-xxx]
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb little endian [xxx:16-xxx:xxx:16-xxx]
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cr:Cb plane, 10 bit per channel */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cr:Cb plane, 12 bit per channel */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane, 16 bit per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vc4: NULL pointer dereference in drm_client_dev_hotplug
Hi, > Andreas Färber hat am 2. Oktober 2018 um 16:33 geschrieben: > > > Hi Stefan and Daniel, > > Am 02.10.18 um 11:48 schrieb Stefan Wahren: > > Hi Daniel, > SNIP > > personally i didn't know this option before this issue, but i cannot > > speak for all the distributions. I checked Raspbian and they don't use > > this option. I had a better feeling to have at least the feedback from > > Peter and Andreas this isn't used in their distributions. > > For openSUSE kernel-source.git master branch I see: > > $ grep -r CONFIG_DRM_FBDEV_OVERALLOC config/ > config/armv7hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/armv7hl/lpae:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/ppc64le/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/i386/pae:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/ppc64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/x86_64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/armv6hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > config/arm64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 > > Similar to what Peter said, on the Raspberry Pi we would usually use vc4 > drm; but some users have run into issues with vc4 not working with > certain monitors, so they may blacklist vc4 and use efifb instead. thanks for clarification. > > Adding Alex and Petr in case more discussion is needed. > > Regards, > Andreas > > >> The new generic fbdev stuff has slightly more > >> strict error checking, and the overalloc thing is somewhat of a hack to > >> support mali blobs. If this goes boom now there's a good chance it didn't > >> work beforehand either. > >> -Daniel > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fb-helper: Validate requested pixel format against bpp
Validate requested pixel format against bits_per_pixel to reject
invalid formats with subcomponents length sum is greater than requested
bits_per_pixel.
weston 5.0.0 with fbdev backend tries to set up an ARGB x8r8g8b8 pixel
format without bits_per_pixel updating. So it can request
x8r8g8b8 with 16 bpp which is obviously incorrect and should be
rejected.
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeniy Paltsev
---
drivers/gpu/drm/drm_fb_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 16ec93b75dbf..4f39da07f053 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1610,6 +1610,13 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
return -EINVAL;
}
+ if ((var->green.length + var->blue.length + var->red.length +
+ var->transp.length) > var->bits_per_pixel) {
+ DRM_DEBUG("fb requested pixel format can't fit in %d bpp\n",
+ var->bits_per_pixel);
+ return -EINVAL;
+ }
+
switch (var->bits_per_pixel) {
case 16:
depth = (var->green.length == 6) ? 16 : 15;
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 06/13] drm/msm: Use kzalloc for submit struct allocation
On 10/1/2018 11:43 PM, Jordan Crouse wrote: On Mon, Oct 01, 2018 at 06:01:38PM +0530, Sharat Masetty wrote: This patch changes to kzalloc and avoids setting individual submit struct fields to zero manually. I don't think this one is worth it. There are so many members in submit and so few that get reset to 0 - I don't think the extra cycles are worth it in this fast path. The patch "drm/msm: Use the DRM common Scheduler" adds a few more fields to the bo struct, If not kzalloc, then I will have to run a loop or memset the bos area to 0 at least. Signed-off-by: Sharat Masetty --- drivers/gpu/drm/msm/msm_gem_submit.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index a7c8cbc..7931c2a 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -41,24 +41,19 @@ static struct msm_gem_submit *submit_create(struct drm_device *dev, if (sz > SIZE_MAX) return NULL; - submit = kmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY); + submit = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY); if (!submit) return NULL; submit->dev = dev; submit->gpu = gpu; submit->ctx = ctx; - submit->hw_fence = NULL; submit->out_fence_id = -1; submit->pid = get_pid(task_pid(current)); submit->cmd = (void *)>bos[nr_bos]; submit->queue = queue; submit->ring = gpu->rb[queue->prio]; - /* initially, until copy_from_user() and bo lookup succeeds: */ - submit->nr_bos = 0; - submit->nr_cmds = 0; - INIT_LIST_HEAD(>node); INIT_LIST_HEAD(>bo_list); ww_acquire_init(>ticket, _ww_class); -- 1.9.1 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mali-dp next
Hi Dave,
These are the latest changes I have for Mali DP. Please
note that due to drm-next lagging behind drm-fixes at this
moment, the first two patches ("drm: mali-dp: Call
drm_crtc_vblank_reset on device init" and "drm/malidp: Fix
writeback in NV12") will be skipped if you backport v4.19-rc6
into drm-next before pulling this.
Let me know if you prefer a pull request without those commits
or something based on v4.19-rc6 instead of drm-next.
Best regards,
Liviu
The following changes since commit 87c2ee740c07f1edae9eec8bc45cb9b32a68f323:
Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux
into drm-next (2018-09-28 09:48:40 +1000)
are available in the Git repository at:
git://linux-arm.org/linux-ld.git for-upstream/mali-dp
for you to fetch changes up to 3dae1c0919d8c46710187df4fa1a43622289a1f5:
drm/arm/malidp: Implemented the size validation for AFBC framebuffers
(2018-10-02 12:12:19 +0100)
Alexandru Gheorghe (3):
drm: mali-dp: Call drm_crtc_vblank_reset on device init
drm/malidp: Fix writeback in NV12
drm/malidp: Fix smart layer when doing pm_suspend/resume
Ayan Kumar Halder (1):
drm/arm/malidp: Implemented the size validation for AFBC framebuffers
Jamie Fox (1):
drm/malidp: Enable MMU prefetch on Mali-DP650
Liviu Dudau (1):
drm/arm/malidp: Validate rotations for compressed/uncompressed
framebuffers for each layer
Lowry Li (1):
drm/mali-dp: Implement plane alpha and pixel blend on malidp
drivers/gpu/drm/arm/malidp_crtc.c | 28 +--
drivers/gpu/drm/arm/malidp_drv.c| 129 +-
drivers/gpu/drm/arm/malidp_drv.h| 8 +
drivers/gpu/drm/arm/malidp_hw.c | 83 +++--
drivers/gpu/drm/arm/malidp_hw.h | 16 +-
drivers/gpu/drm/arm/malidp_mw.c | 25 ++-
drivers/gpu/drm/arm/malidp_planes.c | 347 +++-
drivers/gpu/drm/arm/malidp_regs.h | 13 ++
8 files changed, 569 insertions(+), 80 deletions(-)
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/13] drm/msm: Use the DRM common Scheduler
Thanks for the review comments Jordan. I tried to answer a few queries..
please check.
On 10/2/2018 12:32 AM, Jordan Crouse wrote:
On Mon, Oct 01, 2018 at 06:01:41PM +0530, Sharat Masetty wrote:
This patch hooks up the DRM gpu scheduler to the msm DRM driver. The
most noticeable changes to the driver are as follows. The submit path is
split into two parts, in the user context the submit(job) is created and
added to one of the entity's scheduler run queue. The scheduler then
tries to drain the queue by submitting the jobs the hardware to act upon.
The submit job sits on the scheduler queue until all the dependent
fences are waited upon successfully.
We have one scheduler instance per ring. The submitqueues will host a
scheduler entity object. This entity will be mapped to the scheduler's
default runqueue. This should be good for now, but in future it is possible
to extend the API to allow for scheduling amongst the submitqueues on the
same ring.
With this patch the role of the struct_mutex lock has been greatly reduced in
scope in the submit path, evidently when actually putting the job on the
ringbuffer. This should enable us with increased parallelism in the
driver which should translate to better performance overall hopefully.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/Kconfig | 1 +
drivers/gpu/drm/msm/Makefile | 3 +-
drivers/gpu/drm/msm/msm_drv.h | 3 +-
drivers/gpu/drm/msm/msm_gem.c | 8 +-
drivers/gpu/drm/msm/msm_gem.h | 6 +
drivers/gpu/drm/msm/msm_gem_submit.c | 138 +--
drivers/gpu/drm/msm/msm_gpu.c | 72 ++--
drivers/gpu/drm/msm/msm_gpu.h | 2 +
drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +
drivers/gpu/drm/msm/msm_ringbuffer.h | 3 +
drivers/gpu/drm/msm/msm_sched.c | 313 ++
drivers/gpu/drm/msm/msm_sched.h | 18 ++
drivers/gpu/drm/msm/msm_submitqueue.c | 18 +-
13 files changed, 507 insertions(+), 85 deletions(-)
create mode 100644 drivers/gpu/drm/msm/msm_sched.c
create mode 100644 drivers/gpu/drm/msm/msm_sched.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde9..0d01810 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -15,6 +15,7 @@ config DRM_MSM
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
+ select DRM_SCHED
default y
help
DRM/KMS driver for MSM/snapdragon.
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index cd40c05..71ed921 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -60,7 +60,8 @@ msm-y := \
msm_perf.o \
msm_rd.o \
msm_ringbuffer.o \
- msm_submitqueue.o
+ msm_submitqueue.o \
+ msm_sched.o
msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b2da1fb..e461a9c 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -213,8 +213,7 @@ struct drm_gem_object *msm_gem_prime_import_sg_table(struct
drm_device *dev,
int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive);
-void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, bool exclusive, struct dma_fence *fence);
+void msm_gem_move_to_active(struct drm_gem_object *obj, struct msm_gpu *gpu);
void msm_gem_move_to_inactive(struct drm_gem_object *obj);
int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t
*timeout);
int msm_gem_cpu_fini(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index f583bb4..7a12f30 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -663,16 +663,12 @@ int msm_gem_sync_object(struct drm_gem_object *obj,
return 0;
}
-void msm_gem_move_to_active(struct drm_gem_object *obj,
- struct msm_gpu *gpu, bool exclusive, struct dma_fence *fence)
+void msm_gem_move_to_active(struct drm_gem_object *obj, struct msm_gpu *gpu)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
msm_obj->gpu = gpu;
- if (exclusive)
- reservation_object_add_excl_fence(msm_obj->resv, fence);
- else
- reservation_object_add_shared_fence(msm_obj->resv, fence);
+
list_del_init(_obj->mm_list);
list_add_tail(_obj->mm_list, >active_list);
}
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index cae3aa5..8c6269f 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -20,6 +20,7 @@
#include
#include
+#include
#include "msm_drv.h"
/* Additional
Re: [PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
>
> At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
> has been used, but that macro doesn't check if tcon->panel pointer is
> null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
>
> Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
> condition to check if it's a pointer not null.
There's actually more than one occurance of this error:
drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_lvds.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c: if (!IS_ERR(tcon->panel)) {
drivers/gpu/drm/sun4i/sun4i_rgb.c: if (!IS_ERR(tcon->panel)) {
These four are responsible for enabling and disabling the panel.
drivers/gpu/drm/sun4i/sun4i_tcon.c: if (!IS_ERR(tcon->panel)) {
All this looks like it was left over from commit ebc9446135671 ("drm: convert
drivers to use drm_of_find_panel_or_bridge"). We have checks against tcon->panel
in several places and not all of them were converted.
ChenYu
> Signed-off-by: Giulio Benetti
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index c78cd35a1294..e4b3bd0307ef 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
> *tcon,
> * Following code is a way to avoid quirks all around TCON
> * and DOTCLOCK drivers.
> */
> - if (!IS_ERR(tcon->panel)) {
> + if (tcon->panel) {
> struct drm_panel *panel = tcon->panel;
> struct drm_connector *connector = panel->connector;
> struct drm_display_info display_info =
> connector->display_info;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: change resolution may cause screen blurred
On Wed, Oct 03, 2018 at 02:57:47PM +0800, Y.C. Chen wrote: > From: "Y.C. Chen" > > The value of pitches is not correct while calling mode_set. > The issue we found so far on following system: > - Debian8 with XFCE Desktop > - Ubuntu with KDE Desktop > - SUSE15 with KDE Desktop > > Signed-off-by: Y.C. Chen btw do you want commit rights for drm-misc for these ast patches? https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html Cheers, Daniel > --- > drivers/gpu/drm/ast/ast_mode.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 5e77d45..f06aae7 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -568,6 +568,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc, > } > ast_bo_unreserve(bo); > > + ast_set_offset_reg(crtc); > ast_set_start_address_crt1(crtc, (u32)gpu_addr); > > return 0; > -- > 1.8.3.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 08/18] drm/arcpgu: Drop transitional hooks
On Tue, Oct 02, 2018 at 06:34:39PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 03:35:16PM +0200, Daniel Vetter wrote:
> > These do absolutely nothing for atomic drivers.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Alexey Brodkin
> > ---
> > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > index 965cda48dc13..26cb2800f3ad 100644
> > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> > @@ -158,8 +158,6 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc
> > *crtc,
> >
> > static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
> > .mode_valid = arc_pgu_crtc_mode_valid,
> > - .mode_set = drm_helper_crtc_mode_set,
> > - .mode_set_base = drm_helper_crtc_mode_set_base,
> > .mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
> > .atomic_begin = arc_pgu_crtc_atomic_begin,
> > .atomic_enable = arc_pgu_crtc_atomic_enable,
>
> It's easy to get confused with all the hooks and helpers. But after
> staring at the code a bit this looks correct to me:
Hm, I guess I could write a patch that liberally sprinkles WARN_ON on all
the deprecated hooks if you're an atomic driver. But that's kinda for
another time.
> Reviewed-by: Ville Syrjälä
>
> > --
> > 2.19.0.rc2
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/18] drm/vmwgfx: Fix vmw_du_cursor_plane_atomic_check
From: Thomas Hellstrom
Use the correct helper and also return early on helper
success rather than on helper failure.
Also explicitly return 0 in the case of no fb.
v2: Check for !fb after updating state->visible (Ville).
Signed-off-by: Thomas Hellstrom (v1)
Reported-by: Dan Carpenter
Reported-by: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1b2a406b7742..8e3e262b6ef4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -493,24 +493,24 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane
*plane,
struct drm_plane_state *new_state)
{
int ret = 0;
+ struct drm_crtc_state *crtc_state = NULL;
struct vmw_surface *surface = NULL;
struct drm_framebuffer *fb = new_state->fb;
- struct drm_rect src = drm_plane_state_src(new_state);
- struct drm_rect dest = drm_plane_state_dest(new_state);
+ if (new_state->crtc)
+ crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
+ new_state->crtc);
- /* Turning off */
- if (!fb)
+ ret = drm_atomic_helper_check_plane_state(new_state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ true, true);
+ if (ret)
return ret;
- ret = drm_plane_helper_check_update(plane, new_state->crtc, fb,
- , ,
- DRM_MODE_ROTATE_0,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- true, true, _state->visible);
- if (!ret)
- return ret;
+ /* Turning off */
+ if (!fb)
+ return 0;
/* A lot of the code assumes this */
if (new_state->crtc_w != 64 || new_state->crtc_h != 64) {
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/18] drm: Remove transitional helpers
With armada the last bigger driver that realistically needed these to
convert from legacy kms to atomic is converted. These helpers have
been broken more often than not the past 2 years, and as this little
patch series shows, tricked a bunch of people into using the wrong
helpers for their functions.
Aside: I think a lot more drivers should be using the device-level
drm_atomic_helper_shutdown/suspend/resume helpers and related
functions. In almost all the cases they get things exactly right.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 115 -
drivers/gpu/drm/drm_plane_helper.c | 197 -
include/drm/drm_crtc_helper.h | 6 -
include/drm/drm_plane_helper.h | 14 --
4 files changed, 332 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ce75e9506e85..a3c81850e755 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -984,118 +984,3 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
drm_modeset_unlock_all(dev);
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
-
-/**
- * drm_helper_crtc_mode_set - mode_set implementation for atomic plane helpers
- * @crtc: DRM CRTC
- * @mode: DRM display mode which userspace requested
- * @adjusted_mode: DRM display mode adjusted by ->mode_fixup callbacks
- * @x: x offset of the CRTC scanout area on the underlying framebuffer
- * @y: y offset of the CRTC scanout area on the underlying framebuffer
- * @old_fb: previous framebuffer
- *
- * This function implements a callback useable as the ->mode_set callback
- * required by the CRTC helpers. Besides the atomic plane helper functions for
- * the primary plane the driver must also provide the ->mode_set_nofb callback
- * to set up the CRTC.
- *
- * This is a transitional helper useful for converting drivers to the atomic
- * interfaces.
- */
-int drm_helper_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode
*mode,
-struct drm_display_mode *adjusted_mode, int x, int
y,
-struct drm_framebuffer *old_fb)
-{
- struct drm_crtc_state *crtc_state;
- const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
- int ret;
-
- if (crtc->funcs->atomic_duplicate_state)
- crtc_state = crtc->funcs->atomic_duplicate_state(crtc);
- else {
- if (!crtc->state)
- drm_atomic_helper_crtc_reset(crtc);
-
- crtc_state = drm_atomic_helper_crtc_duplicate_state(crtc);
- }
-
- if (!crtc_state)
- return -ENOMEM;
-
- crtc_state->planes_changed = true;
- crtc_state->mode_changed = true;
- ret = drm_atomic_set_mode_for_crtc(crtc_state, mode);
- if (ret)
- goto out;
- drm_mode_copy(_state->adjusted_mode, adjusted_mode);
-
- if (crtc_funcs->atomic_check) {
- ret = crtc_funcs->atomic_check(crtc, crtc_state);
- if (ret)
- goto out;
- }
-
- swap(crtc->state, crtc_state);
-
- crtc_funcs->mode_set_nofb(crtc);
-
- ret = drm_helper_crtc_mode_set_base(crtc, x, y, old_fb);
-
-out:
- if (crtc_state) {
- if (crtc->funcs->atomic_destroy_state)
- crtc->funcs->atomic_destroy_state(crtc, crtc_state);
- else
- drm_atomic_helper_crtc_destroy_state(crtc, crtc_state);
- }
-
- return ret;
-}
-EXPORT_SYMBOL(drm_helper_crtc_mode_set);
-
-/**
- * drm_helper_crtc_mode_set_base - mode_set_base implementation for atomic
plane helpers
- * @crtc: DRM CRTC
- * @x: x offset of the CRTC scanout area on the underlying framebuffer
- * @y: y offset of the CRTC scanout area on the underlying framebuffer
- * @old_fb: previous framebuffer
- *
- * This function implements a callback useable as the ->mode_set_base used
- * required by the CRTC helpers. The driver must provide the atomic plane
helper
- * functions for the primary plane.
- *
- * This is a transitional helper useful for converting drivers to the atomic
- * interfaces.
- */
-int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
-{
- struct drm_plane_state *plane_state;
- struct drm_plane *plane = crtc->primary;
-
- if (plane->funcs->atomic_duplicate_state)
- plane_state = plane->funcs->atomic_duplicate_state(plane);
- else {
- if (!plane->state)
- drm_atomic_helper_plane_reset(plane);
-
- plane_state = drm_atomic_helper_plane_duplicate_state(plane);
- }
- if (!plane_state)
- return -ENOMEM;
- plane_state->plane = plane;
-
- plane_state->crtc = crtc;
- drm_atomic_set_fb_for_plane(plane_state, crtc->primary->fb);
-
[PATCH 13/18] drm/vc4: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
v2: Rebase.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
drivers/gpu/drm/vc4/vc4_plane.c | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 1f1780ccdbdf..f6f5cd80c04d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "uapi/drm/vc4_drm.h"
#include "vc4_drv.h"
@@ -308,6 +309,8 @@ static void vc4_drm_unbind(struct device *dev)
drm_dev_unregister(drm);
+ drm_atomic_helper_shutdown(drm);
+
drm_mode_config_cleanup(drm);
drm_atomic_private_obj_fini(>ctm_manager);
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 9dc3fcbd290b..d04b3c3246ba 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -903,7 +903,6 @@ static const struct drm_plane_helper_funcs
vc4_plane_helper_funcs = {
static void vc4_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/18] drm/zte: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Signed-off-by: Daniel Vetter
Cc: Shawn Guo
---
drivers/gpu/drm/zte/zx_drm_drv.c | 1 +
drivers/gpu/drm/zte/zx_plane.c | 1 -
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 5b6f1eda52e0..f5ea32ae8600 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -124,6 +124,7 @@ static void zx_drm_unbind(struct device *dev)
drm_dev_unregister(drm);
drm_kms_helper_poll_fini(drm);
+ drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
component_unbind_all(dev, drm);
dev_set_drvdata(dev, NULL);
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index ae8c53b4b261..83d236fd893c 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -446,7 +446,6 @@ static const struct drm_plane_helper_funcs
zx_gl_plane_helper_funcs = {
static void zx_plane_destroy(struct drm_plane *plane)
{
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/18] drm: Unexport primary plane helpers
Well except the destroy helper, which isn't really a primary helper
but generally useful, if mislabelled.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 85 --
include/drm/drm_plane_helper.h | 10
2 files changed, 11 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 33b3e6892787..0fff72dcd06d 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -42,11 +42,8 @@
* primary plane support on top of the normal CRTC configuration interface.
* Since the legacy _mode_config_funcs.set_config interface ties the
primary
* plane together with the CRTC state this does not allow userspace to disable
- * the primary plane itself. To avoid too much duplicated code use
- * drm_plane_helper_check_update() which can be used to enforce the same
- * restrictions as primary planes had thus. The default primary plane only
- * expose XRBG and ARGB as valid pixel formats for the attached
- * framebuffer.
+ * the primary plane itself. The default primary plane only expose XRBG and
+ * ARGB as valid pixel formats for the attached framebuffer.
*
* Drivers are highly recommended to implement proper support for primary
* planes, and newly merged drivers must not rely upon these transitional
@@ -148,50 +145,13 @@ static int drm_plane_helper_check_update(struct drm_plane
*plane,
return 0;
}
-/**
- * drm_primary_helper_update() - Helper for primary plane update
- * @plane: plane object to update
- * @crtc: owning CRTC of owning plane
- * @fb: framebuffer to flip onto plane
- * @crtc_x: x offset of primary plane on crtc
- * @crtc_y: y offset of primary plane on crtc
- * @crtc_w: width of primary plane rectangle on crtc
- * @crtc_h: height of primary plane rectangle on crtc
- * @src_x: x offset of @fb for panning
- * @src_y: y offset of @fb for panning
- * @src_w: width of source rectangle in @fb
- * @src_h: height of source rectangle in @fb
- * @ctx: lock acquire context, not used here
- *
- * Provides a default plane update handler for primary planes. This is handler
- * is called in response to a userspace SetPlane operation on the plane with a
- * non-NULL framebuffer. We call the driver's modeset handler to update the
- * framebuffer.
- *
- * SetPlane() on a primary plane of a disabled CRTC is not supported, and will
- * return an error.
- *
- * Note that we make some assumptions about hardware limitations that may not
be
- * true for all hardware --
- *
- * 1. Primary plane cannot be repositioned.
- * 2. Primary plane cannot be scaled.
- * 3. Primary plane must cover the entire CRTC.
- * 4. Subpixel positioning is not supported.
- *
- * Drivers for hardware that don't have these restrictions can provide their
- * own implementation rather than using this helper.
- *
- * RETURNS:
- * Zero on success, error code on failure
- */
-int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h,
- struct drm_modeset_acquire_ctx *ctx)
+static int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc
*crtc,
+struct drm_framebuffer *fb,
+int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h,
+struct drm_modeset_acquire_ctx *ctx)
{
struct drm_mode_set set = {
.crtc = crtc,
@@ -258,35 +218,12 @@ int drm_primary_helper_update(struct drm_plane *plane,
struct drm_crtc *crtc,
kfree(connector_list);
return ret;
}
-EXPORT_SYMBOL(drm_primary_helper_update);
-/**
- * drm_primary_helper_disable() - Helper for primary plane disable
- * @plane: plane to disable
- * @ctx: lock acquire context, not used here
- *
- * Provides a default plane disable handler for primary planes. This is
handler
- * is called in response to a userspace SetPlane operation on the plane with a
- * NULL framebuffer parameter. It unconditionally fails the disable call with
- * -EINVAL the only way to disable the primary plane without driver support is
- * to disable the entire CRTC. Which does not match the plane
- * _plane_funcs.disable_plane hook.
- *
- * Note that some hardware may be able to disable the primary plane without
- * disabling the whole CRTC. Drivers for such hardware should provide their
- * own disable handler that disables just the primary plane (and
[PATCH 17/18] drm: Unexport drm_plane_helper_check_update
It's for legacy drivers only (atomic ones should use
drm_atomic_helper_check_plane_state() instead), and there's no users
left except the one in the primary plane helpers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 49 +++---
include/drm/drm_plane_helper.h | 11 ---
2 files changed, 11 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 965286231600..33b3e6892787 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -100,43 +100,17 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
return count;
}
-/**
- * drm_plane_helper_check_update() - Check plane update for validity
- * @plane: plane object to update
- * @crtc: owning CRTC of owning plane
- * @fb: framebuffer to flip onto plane
- * @src: source coordinates in 16.16 fixed point
- * @dst: integer destination coordinates
- * @rotation: plane rotation
- * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
- * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
- * @can_position: is it legal to position the plane such that it
- *doesn't cover the entire crtc? This will generally
- *only be false for primary planes.
- * @can_update_disabled: can the plane be updated while the crtc
- * is disabled?
- * @visible: output parameter indicating whether plane is still visible after
- * clipping
- *
- * Checks that a desired plane update is valid. Drivers that provide
- * their own plane handling rather than helper-provided implementations may
- * still wish to call this function to avoid duplication of error checking
- * code.
- *
- * RETURNS:
- * Zero if update appears valid, error code on failure
- */
-int drm_plane_helper_check_update(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_rect *src,
- struct drm_rect *dst,
- unsigned int rotation,
- int min_scale,
- int max_scale,
- bool can_position,
- bool can_update_disabled,
- bool *visible)
+static int drm_plane_helper_check_update(struct drm_plane *plane,
+struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+struct drm_rect *src,
+struct drm_rect *dst,
+unsigned int rotation,
+int min_scale,
+int max_scale,
+bool can_position,
+bool can_update_disabled,
+bool *visible)
{
struct drm_plane_state plane_state = {
.plane = plane,
@@ -173,7 +147,6 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
return 0;
}
-EXPORT_SYMBOL(drm_plane_helper_check_update);
/**
* drm_primary_helper_update() - Helper for primary plane update
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 1999781781c7..7bff930b8b10 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -38,17 +38,6 @@
*/
#define DRM_PLANE_HELPER_NO_SCALING (1<<16)
-int drm_plane_helper_check_update(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_rect *src,
- struct drm_rect *dest,
- unsigned int rotation,
- int min_scale,
- int max_scale,
- bool can_position,
- bool can_update_disabled,
- bool *visible);
int drm_primary_helper_update(struct drm_plane *plane,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/18] drm/sti: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremely confused:
- In the load error path it calls drm_mode_config_cleanup before it
stops various kms services like poll worker or fbdev emulation.
That's going to oops.
- The actual unload code doesn't even bother with the cleanup and just
leaks.
Try to fix this while at it.
Signed-off-by: Daniel Vetter
Cc: Benjamin Gaignard
Cc: Vincent Abriou
---
drivers/gpu/drm/sti/sti_cursor.c | 1 -
drivers/gpu/drm/sti/sti_drv.c| 6 +++---
drivers/gpu/drm/sti/sti_gdp.c| 1 -
drivers/gpu/drm/sti/sti_hqvdp.c | 1 -
4 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index 57b870e1e696..bc908453ffb3 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -332,7 +332,6 @@ static void sti_cursor_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 6dced8abcf16..ac54e0f9caea 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -206,6 +206,8 @@ static void sti_cleanup(struct drm_device *ddev)
struct sti_private *private = ddev->dev_private;
drm_kms_helper_poll_fini(ddev);
+ drm_atomic_helper_shutdown(ddev);
+ drm_mode_config_cleanup(ddev);
component_unbind_all(ddev->dev, ddev);
kfree(private);
ddev->dev_private = NULL;
@@ -230,7 +232,7 @@ static int sti_bind(struct device *dev)
ret = drm_dev_register(ddev, 0);
if (ret)
- goto err_register;
+ goto err_cleanup;
drm_mode_config_reset(ddev);
@@ -238,8 +240,6 @@ static int sti_bind(struct device *dev)
return 0;
-err_register:
- drm_mode_config_cleanup(ddev);
err_cleanup:
sti_cleanup(ddev);
err_drm_dev_put:
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index c32de6cbf061..3c19614d3f75 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -883,7 +883,6 @@ static void sti_gdp_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 03ac3b4a4469..23565f52dd71 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1260,7 +1260,6 @@ static void sti_hqvdp_destroy(struct drm_plane *drm_plane)
{
DRM_DEBUG_DRIVER("\n");
- drm_plane_helper_disable(drm_plane, NULL);
drm_plane_cleanup(drm_plane);
}
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/18] drm/msm: Use drm_atomic_helper_shutdown
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Rajesh Yadav
Cc: Chandan Uddaraju
Cc: Archit Taneja
Cc: Jeykumar Sankaran
Cc: Sean Paul
Cc: Maarten Lankhorst
Cc: Sinclair Yeh
Cc: "Ville Syrjälä"
Cc: Russell King
Cc: Gustavo Padovan
Cc: Arnd Bergmann
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 1 -
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 1 -
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 015341e2dd4c..ec959f847d5f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1482,8 +1482,6 @@ static void dpu_plane_destroy(struct drm_plane *plane)
mutex_destroy(>lock);
- drm_plane_helper_disable(plane, NULL);
-
/* this will destroy the states as well */
drm_plane_cleanup(plane);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
index 79ff653d8081..7a499731ce93 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c
@@ -68,7 +68,6 @@ static void mdp4_plane_destroy(struct drm_plane *plane)
{
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
kfree(mdp4_plane);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index 7d306c5acd09..d5e4f0de321a 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -46,7 +46,6 @@ static void mdp5_plane_destroy(struct drm_plane *plane)
{
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
- drm_plane_helper_disable(plane, NULL);
drm_plane_cleanup(plane);
kfree(mdp5_plane);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c1abad8a8612..69dbdba183fe 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -312,6 +312,7 @@ static int msm_drm_uninit(struct device *dev)
if (fbdev && priv->fbdev)
msm_fbdev_free(ddev);
#endif
+ drm_atomic_helper_shutdown(ddev);
drm_mode_config_cleanup(ddev);
pm_runtime_get_sync(dev);
--
2.19.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
On Tue, Oct 02, 2018 at 11:29:11PM +0800, Kai-Heng Feng wrote:
> There's another panel that reports "DFP 1.x compliant TMDS" but it
> supports 6bpc instead of 8 bpc.
>
> Apply 6 bpc quirk for the panel to fix it.
>
> BugLink: https://bugs.launchpad.net/bugs/1794387
> Cc: # v4.8+
> Signed-off-by: Kai-Heng Feng
Applied to drm-misc-fixes, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3c9fc99648b7..1e2b9407c8d0 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -113,6 +113,9 @@ static const struct edid_quirk {
> /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
> { "AEO", 0, EDID_QUIRK_FORCE_6BPC },
>
> + /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
> panel */
> + { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC },
> +
> /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
> { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/18] drm/vmwgfx: Add FIXME comments for customer page_flip handlers
On Tue, Oct 02, 2018 at 04:49:30PM +, Thomas Hellstrom wrote: > Hi, Daniel, > > On 10/02/2018 03:35 PM, Daniel Vetter wrote: > > The idea behind allowing drivers to override legacy ioctls (instead of > > using the generic implementations unconditionally) is to handle bugs > > in old driver-specific userspace. Like e.g. vmw_kms_set_config does, > > to work around some vmwgfx userspace not clearing its ioctl structs > > properly. > > > > But you can't use it to augment semantics and put in additional > > checks, since from a correctly working userspace's pov there should > > not be any difference in behaviour between the legacy and the atomic > > paths. > > > > vmwgfx seems to be doing some strange things in its page_flip > > handlers. Since I'm not an expert of this codebase just wrap some > > FIXME comments around the potentially problematic code. > > > > We've got proper patches for these. Apparently they got lost in my -next > pull request, though. Yeah I wondered why this one here didn't conflict yet, I can carry it around a bit longer as a memo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 03/18] drm: Extract drm_atomic_state_helper.[hc]
On Tue, Oct 02, 2018 at 06:40:52PM +0300, Ville Syrjälä wrote: > On Tue, Oct 02, 2018 at 03:35:11PM +0200, Daniel Vetter wrote: > > We already have a separate overview doc for this, makes sense to > > untangle it from the overall atomic helpers. > > > > v2: Rebase > > > > v3: Rebase more. > > Hopefully the rebases didn't leave any code changes behind... I've redone the move on every rebase :-/ > Too lazy to read in full detail so > Acked-by: Ville Syrjälä Thanks, I'll pick this one right up (just need to double-check CI). -Daniel > > > > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-kms-helpers.rst | 19 +- > > drivers/gpu/drm/Makefile | 3 +- > > drivers/gpu/drm/drm_atomic_helper.c | 566 > > drivers/gpu/drm/drm_atomic_state_helper.c | 601 ++ > > include/drm/drm_atomic_helper.h | 44 +- > > include/drm/drm_atomic_state_helper.h | 80 +++ > > 6 files changed, 698 insertions(+), 615 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_atomic_state_helper.c > > create mode 100644 include/drm/drm_atomic_state_helper.h > > > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > > b/Documentation/gpu/drm-kms-helpers.rst > > index f9cfcdcdf024..4b4dc236ef6f 100644 > > --- a/Documentation/gpu/drm-kms-helpers.rst > > +++ b/Documentation/gpu/drm-kms-helpers.rst > > @@ -59,19 +59,28 @@ Implementing Asynchronous Atomic Commit > > .. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c > > :doc: implementing nonblocking commit > > > > +Helper Functions Reference > > +-- > > + > > +.. kernel-doc:: include/drm/drm_atomic_helper.h > > + :internal: > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c > > + :export: > > + > > Atomic State Reset and Initialization > > - > > > > -.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c > > +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c > > :doc: atomic state reset and initialization > > > > -Helper Functions Reference > > --- > > +Atomic State Helper Reference > > +- > > > > -.. kernel-doc:: include/drm/drm_atomic_helper.h > > +.. kernel-doc:: include/drm/drm_atomic_state_helper.h > > :internal: > > > > -.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c > > +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c > > :export: > > > > Simple KMS Helper Reference > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index bc6a16a3c36e..576ba985e138 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -36,7 +36,8 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > > drm_probe_helper.o \ > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \ > > drm_simple_kms_helper.o drm_modeset_helper.o \ > > - drm_scdc_helper.o drm_gem_framebuffer_helper.o > > + drm_scdc_helper.o drm_gem_framebuffer_helper.o \ > > + drm_atomic_state_helper.o > > > > drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o > > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index 8c93f33fe92f..a5edc8757056 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -3382,569 +3382,3 @@ int drm_atomic_helper_page_flip_target(struct > > drm_crtc *crtc, > > return ret; > > } > > EXPORT_SYMBOL(drm_atomic_helper_page_flip_target); > > - > > -/** > > - * DOC: atomic state reset and initialization > > - * > > - * Both the drm core and the atomic helpers assume that there is always > > the full > > - * and correct atomic software state for all connectors, CRTCs and planes > > - * available. Which is a bit a problem on driver load and also after system > > - * suspend. One way to solve this is to have a hardware state read-out > > - * infrastructure which reconstructs the full software state (e.g. the i915 > > - * driver). > > - * > > - * The simpler solution is to just reset the software state to everything > > off, > > - * which is easiest to do by calling drm_mode_config_reset(). To > > facilitate this > > - * the atomic helpers provide default reset implementations for all hooks. > > - * > > - * On the upside the precise state tracking of atomic simplifies system > > suspend > > - * and resume a lot. For drivers using drm_mode_config_reset() a complete > > recipe > > - * is implemented in drm_atomic_helper_suspend() and > > drm_atomic_helper_resume(). > > - * For other drivers the building blocks are split out, see the > > documentation > > - * for these functions. > > - */ > > - > > -/** > > - * drm_atomic_helper_crtc_reset - default _crtc_funcs.reset hook
Re: [PATCH 02/18] drm/atomic-helper: Unexport drm_atomic_helper_best_encoder
On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > It's the default. The exported version was kinda a transition state,
> > before we made this the default.
> >
> > To stop new atomic drivers from using it (instead of just relying on
> > the default) let's unexport it.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Gustavo Padovan
> > Cc: Maarten Lankhorst
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: VMware Graphics
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> > Cc: Archit Taneja
> > Cc: Neil Armstrong
> > Cc: Laurent Pinchart
> > Cc: Hans Verkuil
> > Cc: Daniel Vetter
> > Cc: Russell King
> > Cc: Jernej Skrabec
> > Cc: Jani Nikula
> > Cc: Pierre-Hugues Husson
> > Cc: Fabio Estevam
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 -
> > drivers/gpu/drm/drm_atomic_helper.c | 24 +++
> > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
> > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 -
> > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 1 -
> > include/drm/drm_atomic_helper.h | 2 --
> > 6 files changed, 7 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > ac37c50d6c4b..5ac979d3450b 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>
> [snip]
>
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c index f92b7cf4cbd7..8c93f33fe92f
> > 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -92,6 +92,13 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> > *state, }
> > }
> >
> > +static struct drm_encoder *
> > +drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > +{
> > + WARN_ON(connector->encoder_ids[1]);
>
> As you're removing the documentation, I would add a comment here to explain
> the WARN_ON. Something along the lines of "For connectors that support
> multiple encoders, the .atomic_best_encoder() or .atomic_encoder() operation
> must be implemented".
>
> You could also rename the function to make it more explicit that it's a
> default for the single encoder case.
So pick_single_encoder_for_connector()? I think that would avoid the need
for a comment. r-b: you with that fixed up?
Thanks, Daniel
>
> > + return drm_encoder_find(connector->dev, NULL,
> > connector->encoder_ids[0]);
> > +}
> > +
> > static int handle_conflicting_encoders(struct drm_atomic_state *state,
> >bool disable_conflicting_encoders)
> > {
> > @@ -3376,23 +3383,6 @@ int drm_atomic_helper_page_flip_target(struct
> > drm_crtc *crtc, }
> > EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> >
> > -/**
> > - * drm_atomic_helper_best_encoder - Helper for
> > - * _connector_helper_funcs.best_encoder callback
> > - * @connector: Connector control structure
> > - *
> > - * This is a _connector_helper_funcs.best_encoder callback helper for
> > - * connectors that support exactly 1 encoder, statically determined at
> > driver - * init time.
> > - */
> > -struct drm_encoder *
> > -drm_atomic_helper_best_encoder(struct drm_connector *connector)
> > -{
> > - WARN_ON(connector->encoder_ids[1]);
> > - return drm_encoder_find(connector->dev, NULL,
> > connector->encoder_ids[0]);
> > -}
> > -EXPORT_SYMBOL(drm_atomic_helper_best_encoder);
> > -
> > /**
> > * DOC: atomic state reset and initialization
> > *
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
--
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: PCIe P2P access to GPU memory
On Wed, Oct 03, 2018 at 08:54:44AM +, Koenig, Christian wrote: > Am 03.10.2018 um 09:14 schrieb Daniel Vetter: > > On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian > > wrote: > >> This is work in progress. > >> > >> I published patches to enable DMA_buf P2P a few months ago, but now I'm > >> waiting for the PCI subsystem to pick up core support for this. > >> > >> I can prepare you a branch based on current upstream kernel next week if > >> you want to test this. > > Thread hijack, since I just read the lwn article on p2p for storage folks: > > > > https://lwn.net/Articles/767281/ > > > > Totally doesn't match what I remember of your dma-buf p2p work. Do we > > need to rework, or is this some kind of higher-level interface on top > > of the raw p2p pci stuff? Or do I misremember. > > The P2P from the storage folks are some mix of raw p2p capability > detection for PCI and higher level interface. > > I'm actually waiting for that stuff to land to extract the p2p > capability detection and use it for this DMA-buf stuff as well. > > Alternative would be to convince Logan to extract the capability > detection in his patch set as well, but so far he wasn't very keen about > that. So no plan to make dma-buf some kind of orchestrator and use the p2p map_sg stuff? That seems to be the new/additional bits I haven't seen yet, and I'm wondered how we should fit dma-buf into that picture. -Daniel > > Christian. > > > > > Thanks, Daniel > > > >> Regards, > >> Christian. > >> > >> Am 29.09.2018 09:01 schrieb Dirk Eibach : > >> I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with > >> mainline drivers. > >> I can acquire a dmabuf from the GPU and pass it to my PCIe > >> framegrabber. But I don't see a way to get the PCIe bus address of the > >> video memory which I need for the P2P transfer. Is there already any > >> infrastructure in place for doing this? If not, what would be the > >> right way to implement this? Add another callback to the dmabuf > >> struct? > >> > >> Cheers > >> Dirk > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Access the intel graphic card via libdrm
On Tue, Oct 02, 2018 at 12:27:02PM +0200, Horst Balthasar wrote: > Hallo, > > as a software developer at the company "imed medical" in Neu-Ulm" I am > working with the intel graphics driver > > under Debian. > > The aim is to output continuous 2D images with the "libdrm" graphic library > on the screen. We use the Intel i915 driver. > > Since I'm not so familiar with the Intel graphics driver (framebuffer, DRM) > unter Debian, I would be verry happy about tips > > and examples to get familiar with this topic. > > I have already downloaded, compiled and installed the libdrm 2.4.94. I have > also implemented the examples from 'modeset' > > and I am able to display a png file on the screen. > > But to process the images afterwards, we need access to the GPU, maybe GEM > ??? Are there any examples or docs to help > > me get used it? For a simple bare-metal (i.e. no compositor/desktop environment like X, wayland or similar) look at kmscube. Contains everything you need for accelarated rendering with just the kernel. Plus mesa, but you really, really, really don't want to write your own rendering driver :-) https://github.com/robclark/kmscube Cheers, Daniel > > > Thank you very much. > > > Bests regards, > > > > Horst Balthasar > > > Horst Balthasar > Software-Entwickler Medizintechnik > > -- > imed medical GmbH > Friedrichshafener Strasse 7 > D-89079 Ulm > > Standort Neu-Ulm > Marlene-Dietrich-Strasse 5 > D-89231 Neu-Ulm > > Fon +49 (0)731 1411 179-6 > Fax +49 (0)731 1411 6513 > Zentrale +49 (0)731 1411 179-0 > Web www.imed-medical.de > > Sitz der Gesellschaft: Ulm Württemberg | Registergericht Ulm | HRB 730620 | > Geschäftsführer: Benedikt Schmalz, > Stefan Schmalz-Conrad > > Diese E-Mail ist vertraulich und enthält gesetzlich geschützte Informationen. > Wenn Sie NICHT der rechtmäßige Empfänger oder einer seiner Mitarbeiter sind, > dürfen Sie den Inhalt WEDER lesen, > kopieren, verbreiten NOCH nutzen. > Sollten Sie diese E-Mail versehentlich erhalten haben, senden Sie sie bitte > an uns zurück und löschen Sie > sie anschließend dauerhaft. Vielen Dank. > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCIe P2P access to GPU memory
Am 03.10.2018 um 09:14 schrieb Daniel Vetter: > On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian > wrote: >> This is work in progress. >> >> I published patches to enable DMA_buf P2P a few months ago, but now I'm >> waiting for the PCI subsystem to pick up core support for this. >> >> I can prepare you a branch based on current upstream kernel next week if you >> want to test this. > Thread hijack, since I just read the lwn article on p2p for storage folks: > > https://lwn.net/Articles/767281/ > > Totally doesn't match what I remember of your dma-buf p2p work. Do we > need to rework, or is this some kind of higher-level interface on top > of the raw p2p pci stuff? Or do I misremember. The P2P from the storage folks are some mix of raw p2p capability detection for PCI and higher level interface. I'm actually waiting for that stuff to land to extract the p2p capability detection and use it for this DMA-buf stuff as well. Alternative would be to convince Logan to extract the capability detection in his patch set as well, but so far he wasn't very keen about that. Christian. > > Thanks, Daniel > >> Regards, >> Christian. >> >> Am 29.09.2018 09:01 schrieb Dirk Eibach : >> I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with >> mainline drivers. >> I can acquire a dmabuf from the GPU and pass it to my PCIe >> framegrabber. But I don't see a way to get the PCIe bus address of the >> video memory which I need for the P2P transfer. Is there already any >> infrastructure in place for doing this? If not, what would be the >> right way to implement this? Add another callback to the dmabuf >> struct? >> >> Cheers >> Dirk >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use the correct crtc when sanitizing plane mapping
On Tue, Oct 02, 2018 at 05:21:36PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 02, 2018 at 02:11:34PM +0200, Daniel Vetter wrote:
> > On Mon, Oct 01, 2018 at 05:31:20PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > When we decide that a plane is attached to the wrong pipe we try
> > > to turn off said plane. However we are passing around the crtc we
> > > think that the plane is supposed to be using rather than the crtc
> > > it is currently using. That doesn't work all that well because
> > > we may have to do vblank waits etc. and the other pipe might
> > > not even be enabled here. So let's pass the plane's current crtc to
> > > intel_plane_disable_noatomic() so that it can its job correctly.
> > >
> > > To do that semi-cleanly we also have to change the plane readout
> > > to record the plane's visibility into the bitmasks of the crtc
> > > where the plane is currently enabled rather than to the crtc
> > > we want to use for the plane.
> > >
> > > One caveat here is that our active_planes bitmask will get confused
> > > if both planes are enabled on the same pipe. Fortunately we can use
> > > plane_mask to reconstruct active_planes sufficiently since
> > > plane_mask still has the same meaning (is the plane visible?)
> > > during readout. We also have to do the same during the initial
> > > plane readout as the second plane could clear the active_planes
> > > bit the first plane had already set.
> >
> > How often have we broken this :-/
> >
> > Unfortunately I still don't have a good idea how to best CI this, since we
> > shut down everything on module unload. Maybe we should have a special mode
> > for module unload to leave the hw on, so that we can start testing various
> > fastboot scenarios ...
>
> Yeah, that might be nice. Though wouldn't directly help here since
> we'd still have to move the plane to the other pipe. But we could
> of course make the driver unload do that for us as well.
>
> Oh and to hit this bug we'd also need to make sure cxsr is enabled
> when we unload as that's what leads to the vblank wait. That's actually
> the reason I didn't catch this bug originally. None of my machines
> have a VBIOS that enables cxsr.
Well that should be easy, as long as i915.ko enables cxsr ...
Just pondered this since with Hans' work fedora is now using fastbook, so
constantly breaking this stuff is kinda no longer a good option. But
definitely future work.
> > Some questions below.
> >
> > > Cc: sta...@vger.kernel.org # fcba862e8428 drm/i915: Have
> > > plane->get_hw_state() return the current pipe
> > > Cc: sta...@vger.kernel.org
> > > Cc: Dennis
> > > Tested-by: Dennis
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105637
> > > Fixes: b1e01595a66d ("drm/i915: Redo plane sanitation during readout")
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 63
> > > +++-
> > > 1 file changed, 47 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index e018b37bed39..c72be8cd1f54 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15475,15 +15475,16 @@ void i830_disable_pipe(struct drm_i915_private
> > > *dev_priv, enum pipe pipe)
> > > POSTING_READ(DPLL(pipe));
> > > }
> > >
> > > -static bool intel_plane_mapping_ok(struct intel_crtc *crtc,
> > > -struct intel_plane *plane)
> > > +static void fixup_active_planes(struct intel_crtc *crtc)
> > > {
> > > - enum pipe pipe;
> > > -
> > > - if (!plane->get_hw_state(plane, ))
> > > - return true;
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > + struct intel_crtc_state *crtc_state =
> > > + to_intel_crtc_state(crtc->base.state);
> > > + struct drm_plane *plane;
> > >
> > > - return pipe == crtc->pipe;
> > > + drm_for_each_plane_mask(plane, _priv->drm,
> > > + crtc_state->base.plane_mask)
> > > + crtc_state->active_planes |= BIT(to_intel_plane(plane)->id);
> >
> > I think we need to also update plane_mask here.
>
> plane_mask will be correct since each plane has a unique bit there.
> And in fact we use plane_mask to reconstruct active_planes.
>
> What we could do is set active_planes=0 before the loop, as the loop
> will populate it fully anyway.
That + comment explaining why we don't need to reconstruct plane_mask
would be good. Since I completely missed that. Something like:
/* active_planes aliases if mutliple "primary" planes have been
* used on the same (or wrong) pipe. plane_mask uses unique ids,
* hence we can use that to reconstruct active_planes. */
Hm, maybe we want to remove the active_planes updating from
intel_set_plane_visible then, since it's just garbage anyway? And with the
3rd caller removed, we always follow up with a call to
Re: [PATCH 05/18] drm: Add helper to implement legacy dirtyfb
On Tue, Oct 02, 2018 at 04:30:30PM +, Deepak Singh Rawat wrote:
> > On Thu, Sep 27, 2018 at 05:30:07PM -0700, Deepak Rawat wrote:
> > > From: Rob Clark
> > >
> > > Add an atomic helper to implement dirtyfb support. This is needed to
> > > support DSI command-mode panels with x11 userspace (ie. when we can't
> > > rely on pageflips to trigger a flush to the panel).
> > >
> > > v2: Modified the helper to use plane fb_damage_clips property and
> > > removed plane_state::dirty flag.
> > >
> > > v3:
> > > - Use uapi drm_mode_rect.
> > > - Support annotate flags.
> > >
> > > Cc: ville.syrj...@linux.intel.com
> > > Cc: Daniel Vetter
> > > Cc: Pekka Paalanen
> > > Signed-off-by: Rob Clark
> > > Signed-off-by: Deepak Rawat
> > > ---
> > > drivers/gpu/drm/drm_damage_helper.c | 121
> >
> > > include/drm/drm_damage_helper.h | 4 +
> > > 2 files changed, 125 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_damage_helper.c
> > b/drivers/gpu/drm/drm_damage_helper.c
> > > index bc734ddaf180..ecf26275543f 100644
> > > --- a/drivers/gpu/drm/drm_damage_helper.c
> > > +++ b/drivers/gpu/drm/drm_damage_helper.c
> > > @@ -26,6 +26,7 @@
> > > *
> > > * Authors:
> > > * Deepak Rawat
> > > + * Rob Clark
> > > *
> > >
> > **
> > /
> > >
> > > @@ -70,6 +71,21 @@
> > > * rectangles clipped to _plane_state.src.
> > > */
> > >
> > > +static void convert_clip_rect_to_rect(const struct drm_clip_rect *src,
> > > + struct drm_mode_rect *dest,
> > > + uint32_t num_clips, uint32_t src_inc)
> > > +{
> > > + while (num_clips > 0) {
> > > + dest->x1 = src->x1;
> > > + dest->y1 = src->y1;
> > > + dest->x2 = src->x2;
> > > + dest->y2 = src->y2;
> > > + src += src_inc;
> > > + dest++;
> > > + num_clips--;
> > > + }
> > > +}
> > > +
> > > /**
> > > * drm_plane_enable_fb_damage_clips - Enables plane fb damage clips
> > property.
> > > * @plane: Plane on which to enable damage clips property.
> > > @@ -123,6 +139,111 @@ void
> > drm_atomic_helper_check_plane_damage(struct drm_atomic_state *state,
> > > }
> > > EXPORT_SYMBOL(drm_atomic_helper_check_plane_damage);
> > >
> > > +/**
> > > + * drm_atomic_helper_dirtyfb - Helper for dirtyfb.
> > > + * @fb: DRM framebuffer.
> > > + * @file_priv: Drm file for the ioctl call.
> > > + * @flags: Dirty fb annotate flags.
> > > + * @color: Color for annotate fill.
> > > + * @clips: Dirty region.
> > > + * @num_clips: Count of clip in clips.
> > > + *
> > > + * A helper to implement _framebuffer_funcs::dirty using damage
> > interface
> > > + * during plane update. Similar to ioctl, this helper do a full plane
> > > update
> > > + * when no clips are provided.
> >
> > The above kerneldoc doesn't make sense to me ... we do have clips provided
> > here, it's just a different layout.
>
> Thanks Daniel for the review. I meant if clips are NULL, which is possible.
Ah right, I've forgotten that the dirty ioctl allows num_clips == 0 iff
clips == NULL. Might be good to document that, for people like me :-)
> > > + *
> > > + * Returns: Zero on success, negative errno on failure.
> > > + */
> > > +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
> > > + struct drm_file *file_priv, unsigned flags,
> > > + unsigned color, struct drm_clip_rect *clips,
> > > + unsigned num_clips)
> > > +{
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + struct drm_property_blob *damage = NULL;
> > > + struct drm_mode_rect *rects = NULL;
> > > + struct drm_atomic_state *state;
> > > + struct drm_plane *plane;
> > > + int ret = 0;
> > > +
> > > + /*
> > > + * When called from ioctl, we are interruptable, but not when called
> > > + * internally (ie. defio worker)
> > > + */
> > > + drm_modeset_acquire_init(,
> > > + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
> > > +
> > > + state = drm_atomic_state_alloc(fb->dev);
> > > + if (!state) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > + state->acquire_ctx =
> > > +
> > > + if (clips) {
> > > + uint32_t inc = 1;
> > > +
> > > + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY) {
> > > + inc = 2;
> > > + num_clips /= 2;
> > > + }
> > > +
> > > + rects = kcalloc(num_clips, sizeof(*rects), GFP_KERNEL);
> > > + if (!rects) {
> > > + ret = -ENOMEM;
> > > + goto out;
> > > + }
> > > +
> > > + convert_clip_rect_to_rect(clips, rects, num_clips, inc);
> > > + damage = drm_property_create_blob(fb->dev,
> > > + num_clips * sizeof(*rects),
> > > + rects);
> > > + if (IS_ERR(damage)) {
> > > + ret
Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote: > > > On 2018-10-01 03:15 AM, Daniel Vetter wrote: > > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote: > >> These patches are part of a proposed new interface for supporting variable > >> refresh rate via DRM properties. > >> > >> === Changes from v1 === > >> > >> For drm: > >> > >> * The variable_refresh_capable property is now flagged as > >> DRM_MODE_PROP_IMMUTABLE > >> > >> For drm/gpu/amd/display: > >> > >> * Patches no longer pull in IOCTL/FreeSync refactoring code > >> * FreeSync enable/disable behavior has been modified to reflect changes in > >> userspace behavior from xf86-video-amdgpu and mesa > >> > >> === Adaptive sync and variable refresh rate === > >> > >> Adaptive sync is part of the DisplayPort spec and allows for graphics > >> adapters to drive displays with varying frame timings. > >> > >> Variable refresh rate (VRR) is essentially the same, but defined for HDMI. > >> > >> === Use cases for variable refresh rate === > >> > >> Variable frame (flip) timings don't align well with fixed refresh rate > >> displays. This results in stuttering, tearing and/or input lag. By > >> adjusting the display refresh rate dynamically these issues can be reduced > >> or eliminated. > >> > >> However, not all content is suitable for dynamic refresh adaptation. > >> Content that is flipped infrequently or at random intervals tends to fair > >> poorly. Multiple clients trying to flip under the same screen can > >> similarly interfere with prediction. > >> > >> Userland needs a way to let the driver know when the content on the screen > >> is suitable for variable refresh rate and if the user wishes to have the > >> feature enabled. > >> > >> === DRM API to support variable refresh rates === > >> > >> This patch introduces a new API via atomic properties on the DRM connector > >> and CRTC. > >> > >> The connector has two new optional properties: > >> > >> * bool variable_refresh_capable - set by the driver if the hardware is > >> capable of supporting variable refresh tech > >> > >> * bool variable_refresh_enabled - set by the user to enable variable > >> refresh adjustment over the connector > >> > >> The CRTC has one additional default property: > >> > >> * bool variable_refresh - a content hint to the driver specifying that the > >> CRTC contents are suitable for variable refresh adjustment > >> > >> == Overview for DRM driver developers === > >> > >> Driver developers can attach the optional connector properties via > >> drm_connector_attach_variable_refresh_properties on connectors that > >> support variable refresh (typically DP or HDMI). > >> > >> The variable_refresh_capable property should be managed as the output on > >> the connector changes. The property is read only from userspace. > >> > >> The variable_refresh_enabled property is intended to be a property > >> controlled by userland as a global on/off switch for variable refresh > >> technology. It should be checked before enabling variable refresh rate. > >> > >> === Overview for Userland developers == > >> > >> The variable_refresh property on the CRTC should be set to true when the > >> CRTCs are suitable for variable refresh rate. In practice this is probably > >> an application like a game - a single window that covers the whole CRTC > >> surface and is the only client issuing flips. > >> > >> To demonstrate the suitability of the API for variable refresh and dynamic > >> adaptation there are additional patches using this API that implement > >> adaptive variable refresh across kernel and userland projects: > >> > >> * DRM (dri-devel) > >> * amdgpu DRM kernel driver (amd-gfx) > >> * xf86-video-amdgpu (amd-gfx) > >> * mesa (mesa-dev) > >> > >> These patches enable adaptive variable refresh on X for AMD hardware > >> provided that the user sets the variable_refresh_enabled property to true > >> on supported connectors (ie. using xrandr --set-prop). > >> > >> The patches have been tested as working on upstream userland with the > >> GNOME desktop environment under a single monitor setup. They also work on > >> KDE in single monitor setup if the compositor is disabled. > >> > >> The patches require that the application window can issue screen flips via > >> the Present extension to xf86-video-amdgpu. Due to Present extension > >> limitations some desktop environments and multi-monitor setups are > >> currently not compatible. > >> > >> Full implementation details for these changes can be reviewed in their > >> respective mailing lists. > >> > >> === Previous discussions === > >> > >> These patches are based upon feedback from patches and feedback from two > >> previous threads on the subject which are linked below for reference: > >> > >> https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html > >> https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html > >>
Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support
Hi I'm curious to know whether this will/could work over PRIME If the discrete card is rendering slower than the display's frequency could the frequency be dropped on integrated display? I think there are laptops that have freesync now Cheers Mike On Mon, 1 Oct 2018 at 08:15 Daniel Vetter wrote: > On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote: > > These patches are part of a proposed new interface for supporting > variable refresh rate via DRM properties. > > > > === Changes from v1 === > > > > For drm: > > > > * The variable_refresh_capable property is now flagged as > DRM_MODE_PROP_IMMUTABLE > > > > For drm/gpu/amd/display: > > > > * Patches no longer pull in IOCTL/FreeSync refactoring code > > * FreeSync enable/disable behavior has been modified to reflect changes > in userspace behavior from xf86-video-amdgpu and mesa > > > > === Adaptive sync and variable refresh rate === > > > > Adaptive sync is part of the DisplayPort spec and allows for graphics > adapters to drive displays with varying frame timings. > > > > Variable refresh rate (VRR) is essentially the same, but defined for > HDMI. > > > > === Use cases for variable refresh rate === > > > > Variable frame (flip) timings don't align well with fixed refresh rate > displays. This results in stuttering, tearing and/or input lag. By > adjusting the display refresh rate dynamically these issues can be reduced > or eliminated. > > > > However, not all content is suitable for dynamic refresh adaptation. > Content that is flipped infrequently or at random intervals tends to fair > poorly. Multiple clients trying to flip under the same screen can similarly > interfere with prediction. > > > > Userland needs a way to let the driver know when the content on the > screen is suitable for variable refresh rate and if the user wishes to have > the feature enabled. > > > > === DRM API to support variable refresh rates === > > > > This patch introduces a new API via atomic properties on the DRM > connector and CRTC. > > > > The connector has two new optional properties: > > > > * bool variable_refresh_capable - set by the driver if the hardware is > capable of supporting variable refresh tech > > > > * bool variable_refresh_enabled - set by the user to enable variable > refresh adjustment over the connector > > > > The CRTC has one additional default property: > > > > * bool variable_refresh - a content hint to the driver specifying that > the CRTC contents are suitable for variable refresh adjustment > > > > == Overview for DRM driver developers === > > > > Driver developers can attach the optional connector properties via > drm_connector_attach_variable_refresh_properties on connectors that support > variable refresh (typically DP or HDMI). > > > > The variable_refresh_capable property should be managed as the output on > the connector changes. The property is read only from userspace. > > > > The variable_refresh_enabled property is intended to be a property > controlled by userland as a global on/off switch for variable refresh > technology. It should be checked before enabling variable refresh rate. > > > > === Overview for Userland developers == > > > > The variable_refresh property on the CRTC should be set to true when the > CRTCs are suitable for variable refresh rate. In practice this is probably > an application like a game - a single window that covers the whole CRTC > surface and is the only client issuing flips. > > > > To demonstrate the suitability of the API for variable refresh and > dynamic adaptation there are additional patches using this API that > implement adaptive variable refresh across kernel and userland projects: > > > > * DRM (dri-devel) > > * amdgpu DRM kernel driver (amd-gfx) > > * xf86-video-amdgpu (amd-gfx) > > * mesa (mesa-dev) > > > > These patches enable adaptive variable refresh on X for AMD hardware > provided that the user sets the variable_refresh_enabled property to true > on supported connectors (ie. using xrandr --set-prop). > > > > The patches have been tested as working on upstream userland with the > GNOME desktop environment under a single monitor setup. They also work on > KDE in single monitor setup if the compositor is disabled. > > > > The patches require that the application window can issue screen flips > via the Present extension to xf86-video-amdgpu. Due to Present extension > limitations some desktop environments and multi-monitor setups are > currently not compatible. > > > > Full implementation details for these changes can be reviewed in their > respective mailing lists. > > > > === Previous discussions === > > > > These patches are based upon feedback from patches and feedback from two > previous threads on the subject which are linked below for reference: > > > > https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html > > > https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html > > >
Re: [PATCH v10 1/2] drm: Introduce new DRM_FORMAT_XYUV
On Wed, Oct 03, 2018 at 06:39:00AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2018-10-02 at 15:28 +, Alexandru-Cosmin Gheorghe wrote:
> > Hi,
> >
> > On Tue, Oct 02, 2018 at 02:15:42PM +0300, Stanislav Lisovskiy wrote:
> > > v5: This is YUV444 packed format same as AYUV, but without alpha,
> > > as supported by i915.
> > >
> > > v6: Removed unneeded initializer for new XYUV format.
> > >
> > > v7: Added is_yuv field initialization according to latest
> > > drm_fourcc format structure initialization changes.
> > >
> > > v8: Edited commit message to be more clear about skl+, renamed
> > > PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
> > > doesn't support per-pixel alpha. Fixed minor code issues.
> > >
> > > v9: Moved DRM format check to proper place in
> > > intel_framebuffer_init.
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> >
> > Reviewed-by: Alexandru Gheorghe
> >
> > I'm planning of sending a new version with my series[1], do you think
> > this patch will get merged soon, or is there anything else that needs
> > to be done.
> >
> > [1] https://lists.freedesktop.org/archives/dri-devel/2018-
> > August/186963.html
>
> Hi,
>
> I had to implement IGT test case and xf86-video-intel support for this
> new format(in order to check that it works with gstreamer as we have
> userspace requirement for this change), so currently I guess all the
> requirements are met. I might need to do some
> minor changes in those patches though, once I get some feedback.
A bit offtopic do we need userspace for adding a new fourcc as well,
I thought those are extempted from "must have userspace rule".
>
> >
> > > ---
> > > drivers/gpu/drm/drm_fourcc.c | 1 +
> > > include/uapi/drm/drm_fourcc.h | 1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fourcc.c
> > > b/drivers/gpu/drm/drm_fourcc.c
> > > index be1d6aaef651..60752d0be9d8 100644
> > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > @@ -190,6 +190,7 @@ 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,
> > > .is_yuv = true },
> > > { .format = DRM_FORMAT_VYUY,.depth
> > > = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1,
> > > .is_yuv = true },
> > > { .format = DRM_FORMAT_AYUV,.depth
> > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1,
> > > .has_alpha = true, .is_yuv = true },
> > > + { .format = DRM_FORMAT_XYUV,.depth
> > > = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1,
> > > .is_yuv = true },
> > > };
> > >
> > > unsigned int i;
> > > diff --git a/include/uapi/drm/drm_fourcc.h
> > > b/include/uapi/drm/drm_fourcc.h
> > > index 139632b87181..88d2e491f40c 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -151,6 +151,7 @@ extern "C" {
> > > #define DRM_FORMAT_VYUY fourcc_code('V', 'Y', 'U',
> > > 'Y') /* [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
> > >
> > > #define DRM_FORMAT_AYUV fourcc_code('A', 'Y', 'U',
> > > 'V') /* [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> > > +#define DRM_FORMAT_XYUV fourcc_code('X', 'Y', 'U',
> > > 'V') /* [31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
> > >
> > > /*
> > > * 2 plane RGB + A
> > > --
> > > 2.17.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> --
> Best Regards,
>
> Lisovskiy Stanislav
--
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if null
On Wed, Oct 3, 2018 at 5:59 AM Giulio Benetti
wrote:
>
> If using tcon with VGA, tcon->panel will be null(0), this will cause
> segmentation fault when trying to dereference tcon->panel->connector.
>
> Add tcon->panel null check before calling
> sun4i_tcon0_mode_set_dithering().
>
> Signed-off-by: Giulio Benetti
Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
RGB565/RGB666 LCD panels")
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/sun4i: tcon: fix check of tcon->panel null pointer
At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
has been used, but that macro doesn't check if tcon->panel pointer is
null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
Remove IS_ERR() from tcon->panel checking and let "if (tcon->panel)" as
condition to check if it's a pointer not null.
Signed-off-by: Giulio Benetti
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c78cd35a1294..e4b3bd0307ef 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -555,7 +555,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
* Following code is a way to avoid quirks all around TCON
* and DOTCLOCK drivers.
*/
- if (!IS_ERR(tcon->panel)) {
+ if (tcon->panel) {
struct drm_panel *panel = tcon->panel;
struct drm_connector *connector = panel->connector;
struct drm_display_info display_info = connector->display_info;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vc4: NULL pointer dereference in drm_client_dev_hotplug
Hi Stefan, > [add Peter and Andreas] > > > Am 02.10.2018 um 10:44 schrieb Daniel Vetter: > > On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote: > >> Hi, > >> > >>> Sergey Suloev hat am 1. Oktober 2018 um 12:17 > >>> geschrieben: > >>> > >>> > >>> Hi, Stefan, > >>> > >>> > >>> On 09/30/2018 10:38 PM, Stefan Wahren wrote: > Hi Sergey, > > > Sergey Suloev hat am 30. September 2018 um > > 15:24 geschrieben: > > > > > > Here is my log > > > > [2.868157] [drm:drm_setup_crtcs [drm_kms_helper]] connector 29 > > enabled? yes > > [2.868199] [drm:drm_setup_crtcs [drm_kms_helper]] connector 44 > > enabled? no > > [2.868234] [drm:drm_setup_crtcs [drm_kms_helper]] connector 50 > > enabled? yes > > [2.868271] [drm:drm_setup_crtcs [drm_kms_helper]] looking for > > cmdline mode on connector 29 > > [2.868308] [drm:drm_setup_crtcs [drm_kms_helper]] looking for > > preferred mode on connector 29 0 > > [2.868343] [drm:drm_setup_crtcs [drm_kms_helper]] found mode > > 1280x1024 > > [2.868381] [drm:drm_setup_crtcs [drm_kms_helper]] looking for > > cmdline mode on connector 50 > > [2.868417] [drm:drm_setup_crtcs [drm_kms_helper]] looking for > > preferred mode on connector 50 0 > > [2.868465] [drm:drm_setup_crtcs [drm_kms_helper]] found mode > > 1920x1440 > > [2.868500] [drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for > > 2048x2048 config > > [2.868561] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode > > 1280x1024 set on crtc 95 (0,0) > > [2.868673] [drm:drm_mode_object_get [drm]] OBJ ID: 29 (2) > > [2.868709] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode > > 1920x1440 set on crtc 74 (0,0) > > [2.868790] [drm:drm_mode_object_get [drm]] OBJ ID: 50 (2) > > [2.868832] [drm:drm_fb_helper_generic_probe [drm_kms_helper]] > > surface width(1920), height(2880) and bpp(32) > > [3.001470] [drm:drm_internal_framebuffer_create [drm]] bad > > framebuffer height 2880, should be >= 0 && <= 2048 > > [3.001650] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup > > [drm_kms_helper]] *ERROR* Failed to set fbdev configuration > > > does this config work with 4.18? > >>> I have checked with the tag v4.18 as per your request and I can confirm > >>> that the issue does not exists in 4.18. > >> i tried to follow the threads mentioned by Noralf, but it seems the > >> regression regarding CONFIG_DRM_FBDEV_OVERALLOC=200 hasn't been fixed yet. > >> > >> It would be nice to have this fixed in 4.19 LTS. > > Do you need this feature? > personally i didn't know this option before this issue, but i cannot > speak for all the distributions. I checked Raspbian and they don't use > this option. I had a better feeling to have at least the feedback from > Peter and Andreas this isn't used in their distributions. Looking at the config Fedora does have DRM_FBDEV_OVERALLOC=100 in our config, it's a generic across arches enabled option, but in general I'm moving away from fbdev on ARM in Fedora and for Raspberry Pi in particular we use the accelerated vc4 driver for basically everything rather than fbdev. Peter > > The new generic fbdev stuff has slightly more > > strict error checking, and the overalloc thing is somewhat of a hack to > > support mali blobs. If this goes boom now there's a good chance it didn't > > work beforehand either. > > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 07/12] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits
On Tuesday 02 October 2018 06:50 PM, Maxime Ripard wrote:
On Thu, Sep 27, 2018 at 11:15:50PM +0530, Jagan Teki wrote:
On Thu, Sep 27, 2018 at 10:28 PM Maxime Ripard
wrote:
On Thu, Sep 27, 2018 at 05:18:45PM +0530, Jagan Teki wrote:
TCON DRQ set bits for non-burst DSI mode can computed via
horizontal front porch instead of front porch + sync timings.
Since there no documentation for TCON_DRQ_REG(0x7c) register
this change is taken as reference from BPI-M64-bsp.
Detailing more what the issue is would be great.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 599284971ab6..9918fdb990ff 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -367,9 +367,9 @@ static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
struct mipi_dsi_device *device = dsi->device;
u32 val = 0;
The computation here is in the A64 driver:
if ((panel->lcd_ht - panel->lcd_x - panel->lcd_hbp) < 21) {
dsi_dev[sel]->dsi_tcon_drq.bits.drq_mode = 0;
} else {
dsi_dev[sel]->dsi_tcon_drq.bits.drq_set =
(panel->lcd_ht-panel->lcd_x-panel->lcd_hbp-20) *
dsi_pixel_bits[panel->lcd_dsi_format]/(8*4);
}
It is testing that the sync + front porch is smaller than 21, and
otherwise sets the drq.
- if ((mode->hsync_end - mode->hdisplay) > 20) {
My code here is testing that the difference between hsync_end and
hdisplay is superior to 20, and sets the DRQ if true. The condition is
reversed, but otherwise, that difference is the front porch plus the
sync length.
True, I understand this, but does drq setting here is specific to SoC?
I thought of finding DRQ in A31 BSP but I couldn't find the code. do
you have bsp somewhere in github?
+ if ((mode->hsync_start - mode->hdisplay) > 20) {
However, you are testing for just the front porch, unlike what your
commit log is saying, and unlike what allwinner's code is saying. So
this deserves some explanation.
but A64 is doing this, do you think it's completely A64 specific or
testing panel with front porch drq?
See the above code excerpt:
panel->lcd_ht - panel->lcd_x - panel->lcd_hbp
This is hsync + front porch. Not the sole front porch. So no, it's not
doing this.
=> panel->lcd_ht - panel->lcd_x - panel->lcd_hbp
from drivers/video/sunxi/disp2/disp/de/disp_lcd.c
timmings->hor_front_porch= panel_info->lcd_ht-panel_info->lcd_hbp -
panel_info->lcd_x;
=> (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x) -
panel->lcd_x - panel->hbp
=> timmings->hor_front_porch
=> mode->hsync_start - mode->hdisplay
This is simply a front porch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.
Il 01/10/2018 11:36, Dan Carpenter ha scritto:
Hello Giulio Benetti,
The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558 sun4i_tcon0_mode_set_rgb()
warn: 'tcon->panel' isn't an ERR_PTR
drivers/gpu/drm/sun4i/sun4i_tcon.c
481 const struct drm_display_mode
*mode)
482 {
483 unsigned int bp, hsync, vsync;
484 u8 clk_delay;
485 u32 val = 0;
486
487 WARN_ON(!tcon->quirks->has_channel_0);
488
489 tcon->dclk_min_div = 6;
490 tcon->dclk_max_div = 127;
491 sun4i_tcon0_mode_set_common(tcon, mode);
492
493 /* Set dithering if needed */
494 sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
^
Here there should be something like:
if (!tcon->panel) {
sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
}
495
496 /* Adjust clock delay */
497 clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
498 regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
499 SUN4I_TCON0_CTL_CLK_DELAY_MASK,
500 SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
501
502 /*
503 * This is called a backporch in the register documentation,
504 * but it really is the back porch + hsync
505 */
506 bp = mode->crtc_htotal - mode->crtc_hsync_start;
507 DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
508 mode->crtc_htotal, bp);
509
510 /* Set horizontal display timings */
511 regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
512 SUN4I_TCON0_BASIC1_H_TOTAL(mode->crtc_htotal) |
513 SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
514
515 /*
516 * This is called a backporch in the register documentation,
517 * but it really is the back porch + hsync
518 */
519 bp = mode->crtc_vtotal - mode->crtc_vsync_start;
520 DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
521 mode->crtc_vtotal, bp);
522
523 /* Set vertical display timings */
524 regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
525 SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2)
|
526 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
527
528 /* Set Hsync and Vsync length */
529 hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
530 vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
531 DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
532 regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
533 SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
534 SUN4I_TCON0_BASIC3_H_SYNC(hsync));
535
536 /* Setup the polarity of the various signals */
537 if (mode->flags & DRM_MODE_FLAG_PHSYNC)
538 val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
539
540 if (mode->flags & DRM_MODE_FLAG_PVSYNC)
541 val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
542
543 /*
544 * On A20 and similar SoCs, the only way to achieve Positive
Edge
545 * (Rising Edge), is setting dclk clock phase to 2/3(240°).
546 * By default TCON works in Negative Edge(Falling Edge),
547 * this is why phase is set to 0 in that case.
548 * Unfortunately there's no way to logically invert dclk
through
549 * IO_POL register.
550 * The only acceptable way to work, triple checked with scope,
551 * is using clock phase set to 0° for Negative Edge and set to
240°
552 * for Positive Edge.
553 * On A33 and similar SoCs there would be a 90° phase option,
554 * but it divides also dclk by 2.
555 * Following code is a way to avoid quirks all around TCON
556 * and DOTCLOCK drivers.
557 */
558 if (!IS_ERR(tcon->panel)) {
^^
Unpossible to be an error pointer!
So maybe I should use IS_ERR_OR_NULL() instead of IS_ERR(), or maybe simply:
if (!tcon->panel) {
Right?
Anyway I'm going to test it with "sparse".
Is it the same tool you've used for this?
Thanks
Kind regards
--
Giulio Benetti
CTO
MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale -
[PATCH] drm/ast: change resolution may cause screen blurred
From: "Y.C. Chen" The value of pitches is not correct while calling mode_set. The issue we found so far on following system: - Debian8 with XFCE Desktop - Ubuntu with KDE Desktop - SUSE15 with KDE Desktop Signed-off-by: Y.C. Chen --- drivers/gpu/drm/ast/ast_mode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 5e77d45..f06aae7 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -568,6 +568,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc, } ast_bo_unreserve(bo); + ast_set_offset_reg(crtc); ast_set_start_address_crt1(crtc, (u32)gpu_addr); return 0; -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: gma500: Replace 120ms mdelay calls in mdfld_dsi_pkg_sender.c
On Tue, Oct 02, 2018 at 09:52:51AM +0200, Patrik Jakobsson wrote: > Hi Phillip, > This is executed while holding a spinlock so we cannot sleep here. > This is true for send_pkg_done() as well. > > - Patrik Dear Patrik, Oops, sorry. I'll try and be more observant in future. Just picked up on these whilst grepping the source :-) Regards, Phil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/virtio: Use IDAs more efficiently
On Tue, Oct 02, 2018 at 01:43:28PM +0200, Gerd Hoffmann wrote: > On Wed, Sep 26, 2018 at 09:04:55AM -0700, Matthew Wilcox wrote: > > On Wed, Sep 26, 2018 at 09:00:31AM -0700, Matthew Wilcox wrote: > > > @@ -59,6 +59,7 @@ static int virtio_gpu_context_create(struct > > > virtio_gpu_device *vgdev, > > > > > > if (handle < 0) > > > return handle; > > > + handle++; > > > virtio_gpu_cmd_context_create(vgdev, handle, nlen, name); > > > return handle; > > > } > > > > Uh. This line is missing. > > > > - int handle = ida_alloc_min(>ctx_id_ida, 1, GFP_KERNEL); > > + int handle = ida_alloc(>ctx_id_ida, GFP_KERNEL); > > > > It'll be there in v2 ;-) > > I've touched the resource/object id handling too, see my "drm/virtio: > rework ttm resource handling" patch series > (https://patchwork.freedesktop.org/series/50382/). Which still needs a > review btw. Um, according to patchwork, you only posted it yesterday. Does DRM normally expect a review within 24 hours? > I think that series obsoletes patch 3/4 (object id fixes) of your > series. The other patches should rebase without too much trouble, you > could do that as well when preparing v2 ... It seems a little odd to me to expect a drive-by contributor (ie me) to rebase their patches on top of a patch series which wasn't even posted at the time they contributed their original patch. If it was already in -next, that'd be a reasonable request. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl
There's another panel that reports "DFP 1.x compliant TMDS" but it
supports 6bpc instead of 8 bpc.
Apply 6 bpc quirk for the panel to fix it.
BugLink: https://bugs.launchpad.net/bugs/1794387
Cc: # v4.8+
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3c9fc99648b7..1e2b9407c8d0 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -113,6 +113,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc
panel */
+ { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC },
+
/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
{ "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Access the intel graphic card via libdrm
Hallo, as a software developer at the company "imed medical" in Neu-Ulm" I am working with the intel graphics driver under Debian. The aim is to output continuous 2D images with the "libdrm" graphic library on the screen. We use the Intel i915 driver. Since I'm not so familiar with the Intel graphics driver (framebuffer, DRM) unter Debian, I would be verry happy about tips and examples to get familiar with this topic. I have already downloaded, compiled and installed the libdrm 2.4.94. I have also implemented the examples from 'modeset' and I am able to display a png file on the screen. But to process the images afterwards, we need access to the GPU, maybe GEM ??? Are there any examples or docs to help me get used it? Thank you very much. Bests regards, Horst Balthasar Horst Balthasar Software-Entwickler Medizintechnik -- imed medical GmbH Friedrichshafener Strasse 7 D-89079 Ulm Standort Neu-Ulm Marlene-Dietrich-Strasse 5 D-89231 Neu-Ulm Fon +49 (0)731 1411 179-6 Fax +49 (0)731 1411 6513 Zentrale +49 (0)731 1411 179-0 Web www.imed-medical.de Sitz der Gesellschaft: Ulm Württemberg | Registergericht Ulm | HRB 730620 | Geschäftsführer: Benedikt Schmalz, Stefan Schmalz-Conrad Diese E-Mail ist vertraulich und enthält gesetzlich geschützte Informationen. Wenn Sie NICHT der rechtmäßige Empfänger oder einer seiner Mitarbeiter sind, dürfen Sie den Inhalt WEDER lesen, kopieren, verbreiten NOCH nutzen. Sollten Sie diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns zurück und löschen Sie sie anschließend dauerhaft. Vielen Dank. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCIe P2P access to GPU memory
On Sat, Sep 29, 2018 at 9:27 AM Koenig, Christian wrote: > > This is work in progress. > > I published patches to enable DMA_buf P2P a few months ago, but now I'm > waiting for the PCI subsystem to pick up core support for this. > > I can prepare you a branch based on current upstream kernel next week if you > want to test this. Thread hijack, since I just read the lwn article on p2p for storage folks: https://lwn.net/Articles/767281/ Totally doesn't match what I remember of your dma-buf p2p work. Do we need to rework, or is this some kind of higher-level interface on top of the raw p2p pci stuff? Or do I misremember. Thanks, Daniel > > Regards, > Christian. > > Am 29.09.2018 09:01 schrieb Dirk Eibach : > I want to access GPU VRAM via PCIe P2P access, like DirectGMA but with > mainline drivers. > I can acquire a dmabuf from the GPU and pass it to my PCIe > framegrabber. But I don't see a way to get the PCIe bus address of the > video memory which I need for the P2P transfer. Is there already any > infrastructure in place for doing this? If not, what would be the > right way to implement this? Add another callback to the dmabuf > struct? > > Cheers > Dirk > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vc4: NULL pointer dereference in drm_client_dev_hotplug
Hi Stefan and Daniel, Am 02.10.18 um 11:48 schrieb Stefan Wahren: > Hi Daniel, > > [add Peter and Andreas] > > Am 02.10.2018 um 10:44 schrieb Daniel Vetter: >> On Mon, Oct 01, 2018 at 06:21:23PM +0200, Stefan Wahren wrote: Sergey Suloev hat am 1. Oktober 2018 um 12:17 geschrieben: On 09/30/2018 10:38 PM, Stefan Wahren wrote: >> Sergey Suloev hat am 30. September 2018 um 15:24 >> geschrieben: >> >> >> Here is my log >> >> [ 2.868157] [drm:drm_setup_crtcs [drm_kms_helper]] connector 29 >> enabled? yes >> [ 2.868199] [drm:drm_setup_crtcs [drm_kms_helper]] connector 44 >> enabled? no >> [ 2.868234] [drm:drm_setup_crtcs [drm_kms_helper]] connector 50 >> enabled? yes >> [ 2.868271] [drm:drm_setup_crtcs [drm_kms_helper]] looking for >> cmdline mode on connector 29 >> [ 2.868308] [drm:drm_setup_crtcs [drm_kms_helper]] looking for >> preferred mode on connector 29 0 >> [ 2.868343] [drm:drm_setup_crtcs [drm_kms_helper]] found mode >> 1280x1024 >> [ 2.868381] [drm:drm_setup_crtcs [drm_kms_helper]] looking for >> cmdline mode on connector 50 >> [ 2.868417] [drm:drm_setup_crtcs [drm_kms_helper]] looking for >> preferred mode on connector 50 0 >> [ 2.868465] [drm:drm_setup_crtcs [drm_kms_helper]] found mode >> 1920x1440 >> [ 2.868500] [drm:drm_setup_crtcs [drm_kms_helper]] picking CRTCs for >> 2048x2048 config >> [ 2.868561] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode >> 1280x1024 set on crtc 95 (0,0) >> [ 2.868673] [drm:drm_mode_object_get [drm]] OBJ ID: 29 (2) >> [ 2.868709] [drm:drm_setup_crtcs [drm_kms_helper]] desired mode >> 1920x1440 set on crtc 74 (0,0) >> [ 2.868790] [drm:drm_mode_object_get [drm]] OBJ ID: 50 (2) >> [ 2.868832] [drm:drm_fb_helper_generic_probe [drm_kms_helper]] >> surface width(1920), height(2880) and bpp(32) >> [ 3.001470] [drm:drm_internal_framebuffer_create [drm]] bad >> framebuffer height 2880, should be >= 0 && <= 2048 >> [ 3.001650] vc4-drm soc:gpu: [drm:drm_fb_helper_fbdev_setup >> [drm_kms_helper]] *ERROR* Failed to set fbdev configuration >> > does this config work with 4.18? I have checked with the tag v4.18 as per your request and I can confirm that the issue does not exists in 4.18. >>> i tried to follow the threads mentioned by Noralf, but it seems the >>> regression regarding CONFIG_DRM_FBDEV_OVERALLOC=200 hasn't been fixed yet. >>> >>> It would be nice to have this fixed in 4.19 LTS. >> Do you need this feature? > personally i didn't know this option before this issue, but i cannot > speak for all the distributions. I checked Raspbian and they don't use > this option. I had a better feeling to have at least the feedback from > Peter and Andreas this isn't used in their distributions. For openSUSE kernel-source.git master branch I see: $ grep -r CONFIG_DRM_FBDEV_OVERALLOC config/ config/armv7hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100 config/armv7hl/lpae:CONFIG_DRM_FBDEV_OVERALLOC=100 config/ppc64le/default:CONFIG_DRM_FBDEV_OVERALLOC=100 config/i386/pae:CONFIG_DRM_FBDEV_OVERALLOC=100 config/ppc64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 config/x86_64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 config/armv6hl/default:CONFIG_DRM_FBDEV_OVERALLOC=100 config/arm64/default:CONFIG_DRM_FBDEV_OVERALLOC=100 Similar to what Peter said, on the Raspberry Pi we would usually use vc4 drm; but some users have run into issues with vc4 not working with certain monitors, so they may blacklist vc4 and use efifb instead. Adding Alex and Petr in case more discussion is needed. Regards, Andreas >> The new generic fbdev stuff has slightly more >> strict error checking, and the overalloc thing is somewhat of a hack to >> support mali blobs. If this goes boom now there's a good chance it didn't >> work beforehand either. >> -Daniel -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE checking if panel is used.
Il 02/10/2018 15:26, Giulio Benetti ha scritto:
Il 01/10/2018 11:36, Dan Carpenter ha scritto:
Hello Giulio Benetti,
The patch 490cda5a3c82: "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
checking if panel is used." from Jul 18, 2018, leads to the following
static checker warning:
drivers/gpu/drm/sun4i/sun4i_tcon.c:558 sun4i_tcon0_mode_set_rgb()
warn: 'tcon->panel' isn't an ERR_PTR
drivers/gpu/drm/sun4i/sun4i_tcon.c
481 const struct drm_display_mode
*mode)
482 {
483 unsigned int bp, hsync, vsync;
484 u8 clk_delay;
485 u32 val = 0;
486
487 WARN_ON(!tcon->quirks->has_channel_0);
488
489 tcon->dclk_min_div = 6;
490 tcon->dclk_max_div = 127;
491 sun4i_tcon0_mode_set_common(tcon, mode);
492
493 /* Set dithering if needed */
494 sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
^
Here there should be something like:
if (!tcon->panel) {
sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
}
495
496 /* Adjust clock delay */
497 clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
498 regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
499 SUN4I_TCON0_CTL_CLK_DELAY_MASK,
500 SUN4I_TCON0_CTL_CLK_DELAY(clk_delay));
501
502 /*
503 * This is called a backporch in the register documentation,
504 * but it really is the back porch + hsync
505 */
506 bp = mode->crtc_htotal - mode->crtc_hsync_start;
507 DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch
%d\n",
508 mode->crtc_htotal, bp);
509
510 /* Set horizontal display timings */
511 regmap_write(tcon->regs, SUN4I_TCON0_BASIC1_REG,
512 SUN4I_TCON0_BASIC1_H_TOTAL(mode->crtc_htotal) |
513 SUN4I_TCON0_BASIC1_H_BACKPORCH(bp));
514
515 /*
516 * This is called a backporch in the register documentation,
517 * but it really is the back porch + hsync
518 */
519 bp = mode->crtc_vtotal - mode->crtc_vsync_start;
520 DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
521 mode->crtc_vtotal, bp);
522
523 /* Set vertical display timings */
524 regmap_write(tcon->regs, SUN4I_TCON0_BASIC2_REG,
525 SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal *
2) |
526 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
527
528 /* Set Hsync and Vsync length */
529 hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
530 vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
531 DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync,
vsync);
532 regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
533 SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
534 SUN4I_TCON0_BASIC3_H_SYNC(hsync));
535
536 /* Setup the polarity of the various signals */
537 if (mode->flags & DRM_MODE_FLAG_PHSYNC)
538 val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
539
540 if (mode->flags & DRM_MODE_FLAG_PVSYNC)
541 val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
542
543 /*
544 * On A20 and similar SoCs, the only way to achieve Positive
Edge
545 * (Rising Edge), is setting dclk clock phase to 2/3(240°).
546 * By default TCON works in Negative Edge(Falling Edge),
547 * this is why phase is set to 0 in that case.
548 * Unfortunately there's no way to logically invert dclk
through
549 * IO_POL register.
550 * The only acceptable way to work, triple checked with scope,
551 * is using clock phase set to 0° for Negative Edge and set
to 240°
552 * for Positive Edge.
553 * On A33 and similar SoCs there would be a 90° phase option,
554 * but it divides also dclk by 2.
555 * Following code is a way to avoid quirks all around TCON
556 * and DOTCLOCK drivers.
557 */
558 if (!IS_ERR(tcon->panel)) {
^^
Unpossible to be an error pointer!
So maybe I should use IS_ERR_OR_NULL() instead of IS_ERR(), or maybe simply:
if (!tcon->panel) {
Right?
Anyway I'm going to test it with "sparse".
Is it the same tool you've used for this?
You use "smatch", now
