[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #30 from mikhail.v.gavri...@gmail.com --- Created attachment 143908 --> https://bugs.freedesktop.org/attachment.cgi?id=143908=edit dmesg without patches Without patches backtrace are looks like initial deadlock backtrace. -- 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 110371] HP Dreamcolor display *Error* No EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=110371 Bug ID: 110371 Summary: HP Dreamcolor display *Error* No EDID read Product: DRI Version: unspecified Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: babblebo...@gmail.com My Tonga Firepro W7170M MXM GPU seems to have a bad reaction to kernels higher than Ubuntu's 4.18 on 18.10. I just tried a whole bunch of mainlines and Ubuntu 19.04 and nailed it down that any kernel higher than 4.18 is causing the GPU to no longer be able to get the EDID of my dreamcolor IPS display. Not sure how to best go about bisecting this... It uses a colorboard to convert what I can only assume to be horizontal signal and vertical signalling information to two separate channels of LVDS from a single eDP connector coming off the board. This results in the image shown on screen being completely unreadable with crazy scan wrapping from the channels getting mixed. May be related to: https://bugs.freedesktop.org/show_bug.cgi?id=108806 -- 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 109181] Mesa git causes AMDGPU hang, Tonga Firepro chip W7170M MXM
https://bugs.freedesktop.org/show_bug.cgi?id=109181 babblebo...@gmail.com changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from babblebo...@gmail.com --- Closing issue as I've resolved some of the silliness causing my issues. Will submit a more specific report. -- 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 fixes for 5.1
Hi Dave, Daniel: This include stable MT2701 HDMI, framebuffer device and some fixes for mediatek drm driver. Regards, CK The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git mediatek-drm-fixes-5.1 for you to fetch changes up to 9ee76098a1b8ae21cccac641b735ee4d3a77bccf: drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy (2019-04-09 17:47:01 +0800) CK Hu (2): drm/mediatek: Implement gem prime vmap/vunmap function drm/mediatek: Add Mediatek framebuffer device Dan Carpenter (1): drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata() Wangyan Wang (5): drm/mediatek: fix the rate and divder of hdmi phy for MT2701 drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phy drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phy drm/mediatek: using new factor for tvdpll for MT2701 hdmi phy drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy Wen Yang (1): drm/mediatek: fix possible object reference leak drivers/gpu/drm/mediatek/mtk_dpi.c | 8 ++--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 drivers/gpu/drm/mediatek/mtk_drm_gem.c | 46 drivers/gpu/drm/mediatek/mtk_drm_gem.h | 3 ++ drivers/gpu/drm/mediatek/mtk_hdmi.c| 2 +- drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 35 +++--- drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 5 +-- drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 49 ++ drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 9 files changed, 132 insertions(+), 46 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108879] [CIK] [regression] All opencl apps hangs indefinitely in si_create_context
https://bugs.freedesktop.org/show_bug.cgi?id=108879 --- Comment #11 from Steffen Klee --- cl-api-enqueue-copy-buffer passes when using the workaround. -- 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 v6 0/8] mmu notifier provide context informations
On Tue, 26 Mar 2019 12:47:39 -0400 jgli...@redhat.com wrote: > From: Jérôme Glisse > > (Andrew this apply on top of my HMM patchset as otherwise you will have > conflict with changes to mm/hmm.c) > > Changes since v5: > - drop KVM bits waiting for KVM people to express interest if they > do not then i will post patchset to remove change_pte_notify as > without the changes in v5 change_pte_notify is just useless (it > it is useless today upstream it is just wasting cpu cycles) > - rebase on top of lastest Linus tree > > Previous cover letter with minor update: > > > Here i am not posting users of this, they already have been posted to > appropriate mailing list [6] and will be merge through the appropriate > tree once this patchset is upstream. > > Note that this serie does not change any behavior for any existing > code. It just pass down more information to mmu notifier listener. > > The rational for this patchset: > > CPU page table update can happens for many reasons, not only as a > result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) > but also as a result of kernel activities (memory compression, reclaim, > migration, ...). > > This patch introduce a set of enums that can be associated with each > of the events triggering a mmu notifier: > > - UNMAP: munmap() or mremap() > - CLEAR: page table is cleared (migration, compaction, reclaim, ...) > - PROTECTION_VMA: change in access protections for the range > - PROTECTION_PAGE: change in access protections for page in the range > - SOFT_DIRTY: soft dirtyness tracking > > Being able to identify munmap() and mremap() from other reasons why the > page table is cleared is important to allow user of mmu notifier to > update their own internal tracking structure accordingly (on munmap or > mremap it is not longer needed to track range of virtual address as it > becomes invalid). Without this serie, driver are force to assume that > every notification is an munmap which triggers useless trashing within > drivers that associate structure with range of virtual address. Each > driver is force to free up its tracking structure and then restore it > on next device page fault. With this serie we can also optimize device > page table update [6]. > > More over this can also be use to optimize out some page table updates > like for KVM where we can update the secondary MMU directly from the > callback instead of clearing it. We seem to be rather short of review input on this patchset. ie: there is none. > ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395 OK, kind of ackish, but not a review. > ACKS RDMA https://lkml.org/lkml/2018/12/6/1473 This actually acks the infiniband part of a patch which isn't in this series. So we have some work to do, please. Who would be suitable reviewers? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] drm/panfrost: Add initial panfrost driver
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> This adds the initial driver for panfrost which supports Arm Mali
>> Midgard and Bifrost family of GPUs. Currently, only the T860 and
>> T760 Midgard GPUs have been tested.
>
>> +static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
>> +struct drm_file *file_priv)
>> +{
>> +struct drm_panfrost_get_bo_offset *args = data;
>> +struct drm_gem_object *gem_obj;
>> +struct panfrost_gem_object *bo;
>> +
>
> Missing check for pad == 0. With that fixed,
>
> Reviewed-by: Eric Anholt
I suppose you could also drop both flags and pad from uapi, since both
of them must be 0 filled and you could just add a new flags at the end
of the create struct if you ever need one.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] drm/panfrost: Add initial panfrost driver
Rob Herring writes:
> This adds the initial driver for panfrost which supports Arm Mali
> Midgard and Bifrost family of GPUs. Currently, only the T860 and
> T760 Midgard GPUs have been tested.
> +static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_panfrost_get_bo_offset *args = data;
> + struct drm_gem_object *gem_obj;
> + struct panfrost_gem_object *bo;
> +
Missing check for pad == 0. With that fixed,
Reviewed-by: Eric Anholt
> + gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> + if (!gem_obj) {
> + DRM_DEBUG("Failed to look up GEM BO %d\n", args->handle);
> + return -ENOENT;
> + }
> + bo = to_panfrost_bo(gem_obj);
> +
> + args->offset = bo->node.start << PAGE_SHIFT;
> +
> + drm_gem_object_put_unlocked(gem_obj);
> + return 0;
> +}
> +static void panfrost_job_timedout(struct drm_sched_job *sched_job)
> +{
> + struct panfrost_job *job = to_panfrost_job(sched_job);
> + struct panfrost_device *pfdev = job->pfdev;
> + int js = panfrost_job_get_slot(job);
> + int i;
> +
> + /*
> + * If the GPU managed to complete this jobs fence, the timeout is
> + * spurious. Bail out.
> + */
> + if (dma_fence_is_signaled(job->done_fence))
> + return;
Note: The scheduler calls cancel_delayed_work_sync() in
s_job->finish_work, so this is just reducing the race for the job
successfully completing near the timeout but finish_work being in the
workqueue across the timeout boundary. I dropped it from v3d.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page tables, but
have a few differences. Add a new format type to represent the format. The
input address size is 48-bits and the output address size is 40-bits (and
possibly less?). Note that the later bifrost GPUs follow the standard
64-bit stage 1 format.
The differences in the format compared to 64-bit stage 1 format are:
The 3rd level page entry bits are 0x1 instead of 0x3 for page entries.
The access flags are not read-only and unprivileged, but read and write.
This is similar to stage 2 entries, but the memory attributes field matches
stage 1 being an index.
The nG bit is not set by the vendor driver. This one didn't seem to matter,
but we'll keep it aligned to the vendor driver.
Cc: Will Deacon
Acked-by: Robin Murphy
Cc: Joerg Roedel
Cc: linux-arm-ker...@lists.infradead.org
Cc: io...@lists.linux-foundation.org
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
This is really v4 of the patch. v3 is the series version.
Joerg, please ack so we can take this via the drm tree.
v3:
- Incorporated refactoring from Robin
drivers/iommu/io-pgtable-arm.c | 91 ++
drivers/iommu/io-pgtable.c | 1 +
include/linux/io-pgtable.h | 7 +++
3 files changed, 77 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index d3700ec15cbd..4e21efbc4459 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -172,6 +172,10 @@
#define ARM_LPAE_MAIR_ATTR_IDX_CACHE 1
#define ARM_LPAE_MAIR_ATTR_IDX_DEV 2
+#define ARM_MALI_LPAE_TTBR_ADRMODE_TABLE (3u << 0)
+#define ARM_MALI_LPAE_TTBR_READ_INNER BIT(2)
+#define ARM_MALI_LPAE_TTBR_SHARE_OUTER BIT(4)
+
/* IOPTE accessors */
#define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
@@ -180,11 +184,6 @@
#define iopte_prot(pte)((pte) & ARM_LPAE_PTE_ATTR_MASK)
-#define iopte_leaf(pte,l) \
- (l == (ARM_LPAE_MAX_LEVELS - 1) ? \
- (iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_PAGE) : \
- (iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_BLOCK))
-
struct arm_lpae_io_pgtable {
struct io_pgtable iop;
@@ -198,6 +197,15 @@ struct arm_lpae_io_pgtable {
typedef u64 arm_lpae_iopte;
+static inline bool iopte_leaf(arm_lpae_iopte pte, int lvl,
+ enum io_pgtable_fmt fmt)
+{
+ if (lvl == (ARM_LPAE_MAX_LEVELS - 1) && fmt != ARM_MALI_LPAE)
+ return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_PAGE;
+
+ return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_BLOCK;
+}
+
static arm_lpae_iopte paddr_to_iopte(phys_addr_t paddr,
struct arm_lpae_io_pgtable *data)
{
@@ -303,12 +311,14 @@ static void __arm_lpae_init_pte(struct
arm_lpae_io_pgtable *data,
if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NS;
- if (lvl == ARM_LPAE_MAX_LEVELS - 1)
+ if (data->iop.fmt != ARM_MALI_LPAE && lvl == ARM_LPAE_MAX_LEVELS - 1)
pte |= ARM_LPAE_PTE_TYPE_PAGE;
else
pte |= ARM_LPAE_PTE_TYPE_BLOCK;
- pte |= ARM_LPAE_PTE_AF | ARM_LPAE_PTE_SH_IS;
+ if (data->iop.fmt != ARM_MALI_LPAE)
+ pte |= ARM_LPAE_PTE_AF;
+ pte |= ARM_LPAE_PTE_SH_IS;
pte |= paddr_to_iopte(paddr, data);
__arm_lpae_set_pte(ptep, pte, >iop.cfg);
@@ -321,7 +331,7 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable
*data,
{
arm_lpae_iopte pte = *ptep;
- if (iopte_leaf(pte, lvl)) {
+ if (iopte_leaf(pte, lvl, data->iop.fmt)) {
/* We require an unmap first */
WARN_ON(!selftest_running);
return -EEXIST;
@@ -409,7 +419,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data,
unsigned long iova,
__arm_lpae_sync_pte(ptep, cfg);
}
- if (pte && !iopte_leaf(pte, lvl)) {
+ if (pte && !iopte_leaf(pte, lvl, data->iop.fmt)) {
cptep = iopte_deref(pte, data);
} else if (pte) {
/* We require an unmap first */
@@ -429,31 +439,37 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
if (data->iop.fmt == ARM_64_LPAE_S1 ||
data->iop.fmt == ARM_32_LPAE_S1) {
pte = ARM_LPAE_PTE_nG;
-
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
-
if (!(prot & IOMMU_PRIV))
pte |= ARM_LPAE_PTE_AP_UNPRIV;
-
- if (prot & IOMMU_MMIO)
- pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
- << ARM_LPAE_PTE_ATTRINDX_SHIFT);
- else if (prot & IOMMU_CACHE)
- pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
- <<
[PATCH v3 2/3] drm: Add a drm_gem_objects_lookup helper
Similar to the single handle drm_gem_object_lookup(),
drm_gem_objects_lookup() takes an array of handles and returns an array
of GEM objects.
v2:
- Take the userspace pointer directly and allocate the array.
- Expand the function documentation.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_gem.c | 93 ++-
include/drm/drm_gem.h | 2 +
2 files changed, 85 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 388b3742e562..faa2718e85e8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -663,6 +663,85 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
page **pages,
}
EXPORT_SYMBOL(drm_gem_put_pages);
+static int objects_lookup(struct drm_file *filp, u32 *handle, int count,
+ struct drm_gem_object **objs)
+{
+ int i, ret = 0;
+ struct drm_gem_object *obj;
+
+ spin_lock(>table_lock);
+
+ for (i = 0; i < count; i++) {
+ /* Check if we currently have a reference on the object */
+ obj = idr_find(>object_idr, handle[i]);
+ if (!obj) {
+ ret = -ENOENT;
+ break;
+ }
+ drm_gem_object_get(obj);
+ objs[i] = obj;
+ }
+ spin_unlock(>table_lock);
+
+ return ret;
+}
+
+/**
+ * drm_gem_objects_lookup - look up GEM objects from an array of handles
+ * @filp: DRM file private date
+ * @bo_handles: user pointer to array of userspace handle
+ * @count: size of handle array
+ * @objs_out: returned pointer to array of drm_gem_object pointers
+ *
+ * Takes an array of userspace handles and returns a newly allocated array of
+ * GEM objects.
+ *
+ * For a single handle lookup, use drm_gem_object_lookup().
+ *
+ * Returns:
+ *
+ * @objs filled in with GEM object pointers. Returned GEM objects need to be
+ * released with drm_gem_object_put(). -ENOENT is returned on a lookup
+ * failure. 0 is returned on success.
+ *
+ */
+int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
+ int count, struct drm_gem_object ***objs_out)
+{
+ int ret;
+ u32 *handles;
+ struct drm_gem_object **objs;
+
+ if (!count)
+ return 0;
+
+ objs = kvmalloc_array(count, sizeof(struct drm_gem_object *),
+GFP_KERNEL | __GFP_ZERO);
+ if (!objs)
+ return -ENOMEM;
+
+ handles = kvmalloc_array(count, sizeof(u32), GFP_KERNEL);
+ if (!handles) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (copy_from_user(handles, bo_handles, count * sizeof(u32))) {
+ ret = -EFAULT;
+ DRM_DEBUG("Failed to copy in GEM handles\n");
+ goto out;
+ }
+
+ ret = objects_lookup(filp, handles, count, objs);
+ *objs_out = objs;
+
+out:
+ kvfree(handles);
+ return ret;
+
+}
+EXPORT_SYMBOL(drm_gem_objects_lookup);
+
/**
* drm_gem_object_lookup - look up a GEM object from its handle
* @filp: DRM file private date
@@ -672,21 +751,15 @@ EXPORT_SYMBOL(drm_gem_put_pages);
*
* A reference to the object named by the handle if such exists on @filp, NULL
* otherwise.
+ *
+ * If looking up an array of handles, use drm_gem_objects_lookup().
*/
struct drm_gem_object *
drm_gem_object_lookup(struct drm_file *filp, u32 handle)
{
- struct drm_gem_object *obj;
-
- spin_lock(>table_lock);
-
- /* Check if we currently have a reference on the object */
- obj = idr_find(>object_idr, handle);
- if (obj)
- drm_gem_object_get(obj);
-
- spin_unlock(>table_lock);
+ struct drm_gem_object *obj = NULL;
+ objects_lookup(filp, , 1, );
return obj;
}
EXPORT_SYMBOL(drm_gem_object_lookup);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 2955aaab3dca..5ee85c9eaa9d 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -381,6 +381,8 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj);
void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
bool dirty, bool accessed);
+int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
+ int count, struct drm_gem_object ***objs_out);
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
long drm_gem_reservation_object_wait(struct drm_file *filep, u32 handle,
bool wait_all, unsigned long timeout);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] Initial Panfrost driver
Here's v3 of the panfrost driver. Lot's of changes from review comments and further testing. Details are in each patch. Of note, a problem with MMU page faults has been addressed improving the stability. In the process, the TLB invalidate has been optimized which Tomeu says has improved the performance some. Several dependencies have been applied already, but the first 2 patches are the remaining dependencies. We need to take the iommu change via drm-misc or we need a stable branch. I'm hoping this is the last version. I'm hoping to apply this to drm-misc this week before -rc5 cutoff. A git branch is here[1]. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git panfrost-rebase-v3 Rob Herring (3): iommu: io-pgtable: Add ARM Mali midgard MMU page table format drm: Add a drm_gem_objects_lookup helper drm/panfrost: Add initial panfrost driver MAINTAINERS | 9 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_gem.c| 93 ++- drivers/gpu/drm/panfrost/Kconfig | 14 + drivers/gpu/drm/panfrost/Makefile| 12 + drivers/gpu/drm/panfrost/TODO| 27 + drivers/gpu/drm/panfrost/panfrost_devfreq.c | 218 drivers/gpu/drm/panfrost/panfrost_devfreq.h | 14 + drivers/gpu/drm/panfrost/panfrost_device.c | 252 + drivers/gpu/drm/panfrost/panfrost_device.h | 124 drivers/gpu/drm/panfrost/panfrost_drv.c | 460 +++ drivers/gpu/drm/panfrost/panfrost_features.h | 309 ++ drivers/gpu/drm/panfrost/panfrost_gem.c | 95 drivers/gpu/drm/panfrost/panfrost_gem.h | 29 + drivers/gpu/drm/panfrost/panfrost_gpu.c | 362 drivers/gpu/drm/panfrost/panfrost_gpu.h | 19 + drivers/gpu/drm/panfrost/panfrost_issues.h | 176 ++ drivers/gpu/drm/panfrost/panfrost_job.c | 560 +++ drivers/gpu/drm/panfrost/panfrost_job.h | 51 ++ drivers/gpu/drm/panfrost/panfrost_mmu.c | 369 drivers/gpu/drm/panfrost/panfrost_mmu.h | 17 + drivers/gpu/drm/panfrost/panfrost_regs.h | 298 ++ drivers/iommu/io-pgtable-arm.c | 91 ++- drivers/iommu/io-pgtable.c | 1 + include/drm/drm_gem.h| 2 + include/linux/io-pgtable.h | 7 + include/uapi/drm/panfrost_drm.h | 142 + 28 files changed, 3722 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/drm/panfrost/Kconfig create mode 100644 drivers/gpu/drm/panfrost/Makefile create mode 100644 drivers/gpu/drm/panfrost/TODO create mode 100644 drivers/gpu/drm/panfrost/panfrost_devfreq.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_devfreq.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_device.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_device.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_drv.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_features.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_gem.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_gem.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_gpu.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_gpu.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_issues.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_job.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_job.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_mmu.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_mmu.h create mode 100644 drivers/gpu/drm/panfrost/panfrost_regs.h create mode 100644 include/uapi/drm/panfrost_drm.h -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/nouveau/i2c: Disable i2c bus access after ->fini()
For a while, we've had the problem of i2c bus access not grabbing
a runtime PM ref when it's being used in userspace by i2c-dev, resulting
in nouveau spamming the kernel log with errors if anything attempts to
access the i2c bus while the GPU is in runtime suspend. An example:
[ 130.078386] nouveau :01:00.0: i2c: aux 000d: begin idle timeout
Since the GPU is in runtime suspend, the MMIO region that the i2c bus is
on isn't accessible. On x86, the standard behavior for accessing an
unavailable MMIO region is to just return ~0.
Except, that turned out to be a lie. While computers with a clean
concious will return ~0 in this scenario, some machines will actually
completely hang a CPU on certian bad MMIO accesses. This was witnessed
with someone's Lenovo ThinkPad P50, where sensors-detect attempting to
access the i2c bus while the GPU was suspended would result in a CPU
hang:
CPU: 5 PID: 12438 Comm: sensors-detect Not tainted
5.0.0-0.rc4.git3.1.fc30.x86_64 #1
Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017
RIP: 0010:ioread32+0x2b/0x30
Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3
48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 0f 1f
40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48
RSP: 0018:aac3c5007b48 EFLAGS: 0292 ORIG_RAX: ff13
RAX: 0000 RBX: 0000 RCX: 043017a97186
RDX: 0aaa RSI: 0005 RDI: aac3c400e4e4
RBP: 9e6443902c00 R08: aac3c400e4e4 R09: aac3c5007be7
R10: 0004 R11: 0001 R12: 9e6445dd
R13: e4e4 R14: 03c4 R15:
FS: 7f253155a740() GS:9e644f60() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 5630d1500358 CR3: 000417c44006 CR4: 003606e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
g94_i2c_aux_xfer+0x326/0x850 [nouveau]
nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau]
__i2c_transfer+0x14b/0x620
i2c_smbus_xfer_emulated+0x159/0x680
? _raw_spin_unlock_irqrestore+0x1/0x60
? rt_mutex_slowlock.constprop.0+0x13d/0x1e0
? __lock_is_held+0x59/0xa0
__i2c_smbus_xfer+0x138/0x5a0
i2c_smbus_xfer+0x4f/0x80
i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev]
i2cdev_ioctl+0x1db/0x2c0 [i2c_dev]
do_vfs_ioctl+0x408/0x750
ksys_ioctl+0x5e/0x90
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x60/0x1e0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f25317f546b
Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff
ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48
RSP: 002b:7ffc88caab68 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 5630d0fe7260 RCX: 7f25317f546b
RDX: 5630d1598e80 RSI: 0720 RDI: 0003
RBP: 5630d155b968 R08: 0001 R09: 5630d15a1da0
R10: 0070 R11: 0246 R12: 5630d1598e80
R13: 5630d12f3d28 R14: 0720 R15: 5630d12f3ce0
watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438]
Yikes! While I wanted to try to make it so that accessing an i2c bus on
nouveau would wake up the GPU as needed, airlied pointed out that pretty
much any usecase for userspace accessing an i2c bus on a GPU (mainly for
the DDC brightness control that some displays have) is going to only be
useful while there's at least one display enabled on the GPU anyway, and
the GPU never sleeps while there's displays running.
Since teaching the i2c bus to wake up the GPU on userspace accesses is a
good deal more difficult than it might seem, mostly due to the fact that
we have to use the i2c bus during runtime resume of the GPU, we instead
opt for the easiest solution: don't let userspace access i2c busses on
the GPU at all while it's in runtime suspend.
Changes since v1:
* Also disable i2c busses that run over DP AUX
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
.../gpu/drm/nouveau/include/nvkm/subdev/i2c.h | 2 ++
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 26 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h | 2 ++
.../gpu/drm/nouveau/nvkm/subdev/i2c/base.c| 15 +++
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 21 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h | 1 +
6 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
index eef54e9b5d77..7957eafa5f0e 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h
@@ -38,6 +38,7 @@ struct nvkm_i2c_bus {
struct mutex mutex;
[GIT PULL] drm/vmwgfx: vmwgfx-next
Hi Daniel/Dave, The vmwgfx-next changes for 5.2: Resource dirtying improvement by Thomas, user-space error logging improvement and some other minor fixes. The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f: Merge tag 'drm-misc-next-2019-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-04-05 11:38:02 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/drawat/linux.git vmwgfx-next for you to fetch changes up to c601b12fb634e2d0c2669706b38dba98a3c3a832: drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth' (2019-04-08 10:29:05 -0700) Chengguang Xu (1): drm/vmwgfx: remove redundant unlikely annotation Deepak Rawat (8): drm/vmwgfx: Use preprocessor macro to get valid context node drm/vmwgfx: Use preprocessor macro for cmd struct drm/vmwgfx: Add a new define for vmwgfx user-space debugging drm/vmwgfx: Print message when command verifier returns with error drm/vmwgfx: Clean up some debug messages in vmwgfx_execbuf.c drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer errors drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c drm/vmwgfx: Use preprocessor macro for FIFO allocation Nathan Chancellor (1): drm/vmwgfx: Zero initialize handle in vmw_execbuf_process Thomas Hellstrom (1): drm/vmwgfx: Be more restrictive when dirtying resources YueHaibing (2): drm/vmwgfx: Remove set but not used variable 'restart' drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth' drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 98 + drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 + drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 24 ++- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 59 ++ drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 23 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 29 ++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505 +++--- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |4 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 27 +-- drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 ++- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 25 +-- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c| 28 ++- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 23 +-- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 44 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 45 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_so.h |1 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 47 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 80 +++- drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 61 -- drivers/gpu/drm/vmwgfx/vmwgfx_validation.h |7 + 25 files changed, 972 insertions(+), 1231 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 07:15:20PM +, Jim Zhang wrote: > Ville: > > Yes, if this patch is needed by kernel 3.10.61, please get somebody to > review it. What do I need do to speed up the review process? > Please generate a patch against kernel 3.10.61 if possible. 3.10 is so ancient I don't even remember what it contains. I have a feeling it's pre-atomic, in which case there is no point in even thinking about a backport. It would simply be too painful. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Jim Zhang > Sent: Tuesday, April 9, 2019 10:18 AM > To: 'Ville Syrjälä' > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: RE: [Intel-gfx] colorkey support for intel i915 gpu driver > > If I go with pre-configured colorkey, do I need port your kernel patch to > i915 driver at kernel 3.10.61 ? > > Thanks, > > Jim > > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 10:02 AM > To: Jim Zhang > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote: > > What about if I disable interrupt when changing the colorkey? This > > will solve the atomic issue. I think we only change colorkey or > > enable/disable colorkey once a while. If disabling interrupt work, I > > will disable interrupt and change colorkey. That performance affection > > could be acceptable > > Interrupts don't matter for this. > > > > > Thanks > > > > Jim > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 9, 2019 9:19 AM > > To: Jim Zhang > > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > > > Once I pre-configure the colorkey, am I able to enable and disable it? > > > If colorkey can be enabled/disabled after that might meet my > > > requirement > > > > Not atomically with other updates. > > > > > > > > Thanks, > > > > > > Jim > > > > > > > > > Caterpillar: Confidential Green > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, April 9, 2019 8:57 AM > > > To: Jim Zhang > > > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > > > Villie: > > > > > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any > > > > > plan to review and release? > > > > > > > > There is no real plan at this time. But if you have a use case for > > > > it I can try to harass people until someone reviews it :) > > > > > > > > > If I go with custom ioctl, and my custom ioctl will only used in > > > > > Baytrail product, could it be atomic for Baytrail only? > > > > > > > > No. We would need to define a new api for it. > > > > > > I should clarify that you can pre-configure the colorkey before turning > > > on the sprite plane(s). So unless you really need to change the colorkey > > > while the sprite plane(s) are already enabled you may not even need an > > > atomic api for this. > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jim > > > > > > > > > > > > > > > Caterpillar: Confidential Green > > > > > > > > > > -Original Message- > > > > > From: Ville Syrjälä > > > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > > > To: Jim Zhang > > > > > Cc: dri-devel@lists.freedesktop.org; > > > > > intel-...@lists.freedesktop.org > > > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > > > Hi Sir/Madam: > > > > > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > > > > > Linux kernel version 3.10.61: > > > > > > Libdrm package: 2.4.97 > > > > > > > > > > > > When calling function > > > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > > > > > This property is: > > > > > > property->name = "rotation", property->prop_id =4 It looks > > > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > > > > > There are two problems currently: > > > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > > > patches for it but they have not been reviewed by anyone: > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.f > > > > > re > > > > > ed > > > > >
Re: [PATCH 2/4] drm: use convert_lines() in xrgb8888_to_rgb565 helpers.
Den 09.04.2019 13.59, skrev Gerd Hoffmann:
> Also add two conversion functions for the swab / not swab cases.
> That way we have to check the swab flag only once.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/drm_format_helper.c | 117 +++-
> 1 file changed, 62 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_format_helper.c
> b/drivers/gpu/drm/drm_format_helper.c
> index f32e0173600c..b8d17cd0a9f8 100644
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -38,6 +38,46 @@ static struct drm_format_convert convert_swab16 = {
> .func = convert_swab16_fn,
> };
>
> +static void convert_xrgb_to_rgb565_fn(void *dst, void *src, u32 pixels)
> +{
> + u32 *sbuf = src;
> + u16 *dbuf = dst;
> + u32 x;
> +
> + for (x = 0; x < pixels; x++) {
> + dbuf[x] = ((sbuf[x] & 0x00F8) >> 8) |
> + ((sbuf[x] & 0xFC00) >> 5) |
> + ((sbuf[x] & 0x00F8) >> 3);
> + }
> +}
> +
> +static struct drm_format_convert convert_xrgb_to_rgb565 = {
> + .dst_cpp = 2,
> + .src_cpp = 4,
> + .func = convert_xrgb_to_rgb565_fn,
> +};
> +
> +static void convert_xrgb_to_rgb565_swab_fn(void *dst, void *src, u32
> pixels)
> +{
> + u32 *sbuf = src;
> + u16 *dbuf = dst;
> + u16 val16;
> + u32 x;
> +
> + for (x = 0; x < pixels; x++) {
> + val16 = ((sbuf[x] & 0x00F8) >> 8) |
> + ((sbuf[x] & 0xFC00) >> 5) |
> + ((sbuf[x] & 0x00F8) >> 3);
> + dbuf[x] = swab16(val16);
> + }
> +}
> +
> +static struct drm_format_convert convert_xrgb_to_rgb565_swap = {
> + .dst_cpp = 2,
> + .src_cpp = 4,
> + .func = convert_xrgb_to_rgb565_swab_fn,
> +};
> +
I find that drm_format_convert makes the code more difficult to read.
The only shared code is the xrgb to rgb565 conversion.
Can we do something like this instead:
static void drm_fb_xrgb_to_rgb565_line(u16 *dst, u32 *src, unsigned
int width, bool swap)
{
unsigned int x;
for (x = 0; x < width; x++) {
u16 val = ((*src & 0x00F8) >> 8) |
((*src & 0xFC00) >> 5) |
((*src & 0x00F8) >> 3);
src++;
if (swap)
*dst++ = swab16(val);
else
*dst++ = val;
}
}
void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
void *src = vaddr + clip_offset(clip, fb->pitches[0], 4);
unsigned width = clip->x2 - clip->x1;
unsigned height = clip->y2 - clip->y1;
size_t src_clip_pitch = width * 4;
size_t dst_clip_pitch = width * 2;
unsigned int y;
void *sbuf;
/*
* The cma memory is write-combined so reads are uncached.
* Speed up by fetching one line at a time.
*/
sbuf = kmalloc(src_clip_pitch, GFP_KERNEL);
if (!sbuf)
return;
for (y = 0; y < height; y++) {
memcpy(sbuf, src, src_clip_pitch);
drm_fb_xrgb_to_rgb565_line(dst, sbuf, width, swap);
src += fb->pitches[0];
dst += dst_clip_pitch;
}
kfree(sbuf);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
void drm_fb_xrgb_to_rgb565_dstclip(void __iomem *dst,
unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
void *src = vaddr + clip_offset(clip, fb->pitches[0], 4);
unsigned width = clip->x2 - clip->x1;
unsigned height = clip->y2 - clip->y1;
size_t dst_clip_pitch = width * 2;
unsigned int y;
void *dbuf;
dst += clip_offset(clip, dst_pitch, 2);
dbuf = kmalloc(dst_clip_pitch, GFP_KERNEL);
if (!dbuf)
return;
for (y = 0; y < height; y++) {
drm_fb_xrgb_to_rgb565_line(dbuf, src, width, swap);
memcpy_toio(dst, dbuf, dst_clip_pitch);
src += fb->pitches[0];
dst += dst_pitch;
}
kfree(dbuf);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_dstclip);
Other things I noticed:
drm_fb_memcpy() is just a wrapper around drm_fb_memcpy_lines() and
drm_fb_memcpy_dstclip() around drm_fb_memcpy_lines_toio(). They can be
merged.
checkpatch gave this:
WARNING: Use #include instead of
#50: FILE: drivers/gpu/drm/drm_format_helper.c:14:
+#include
Noralf.
> static void convert_lines(void *dst, unsigned int dst_pitch,
> void *src, unsigned int src_pitch,
> unsigned int
[Bug 110347] pp_od_clk_voltage mV cap ignored
https://bugs.freedesktop.org/show_bug.cgi?id=110347 --- Comment #4 from bednarczyk.pa...@outlook.com --- For whatever reason the below configuration works fine: OD_SCLK: 0:852Mhz800mV 1:979Mhz825mV 2: 1106Mhz850mV 3: 1233Mhz875mV 4: 1360Mhz900mV 5: 1485Mhz925mV 6: 1575Mhz 1000mV 7: 1631Mhz 1050mV OD_MCLK: 0:167Mhz800mV 1:500Mhz825mV 2:800Mhz865mV 3: 1000Mhz 1000mV Note, I am never hitting P7. Oddly enough, if I leave everything else constant and change memory state 3 from 3: 1000Mhz 1000mV to 3: 1025Mhz 1000mV, I am hitting the same issue with memory pstate getting stuck @ 0 (167Mhz). -- 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 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #34 from Talha Khan --- (In reply to Alex Deucher from comment #33) > (In reply to Talha Khan from comment #31) > > I moved the raven_dcmu.bin file to another directory, but unfortunately I am > > still unable to boot any kernel newer 4.20. For me at least, I get a black > > screen with a horizontal line near the bottom of orange pixels. I will > > attach the journalctl output from my last boot into kernel 5.0.5. > > Make sure you update your initrd if you move the file, otherwise, the driver > will pick it up from the initrd at load time. Thanks Alex. This time after I moved the raven_dcmu.bin file, I ran the following to update the initramfs image as root: dracut --kver 5.0.6-200.fc29.x86_64 --force This time: 1. The black screen with the horizontal line of pixels appeared, but for a split second, and then things started working like normal. 2. I was able to log into KDE Plasma like normal. I did a quick suspend/resume and that worked also (although there was a split second of scrambled pixels). Does this mean that there's something wrong with the raven_dcmu.bin file? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm: Add a drm_gem_objects_lookup helper
Rob Herring writes:
> On Mon, Apr 1, 2019 at 10:43 AM Eric Anholt wrote:
>>
>> Chris Wilson writes:
>>
>> > Quoting Daniel Vetter (2019-04-01 14:06:48)
>> >> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring wrote:
>> >> > +{
>> >> > + int i, ret = 0;
>> >> > + struct drm_gem_object *obj;
>> >> > +
>> >> > + spin_lock(>table_lock);
>> >> > +
>> >> > + for (i = 0; i < count; i++) {
>> >> > + /* Check if we currently have a reference on the object
>> >> > */
>> >> > + obj = idr_find(>object_idr, handle[i]);
>> >> > + if (!obj) {
>> >> > + ret = -ENOENT;
>> >
>> > Unwind previous drm_gem_object_get(), the caller has no idea how many
>> > were processed before the error.
>>
>> I had the same thought, but the pattern we have is that you're loading
>> into a refcounted struct that will free the BOs when you're done,
>> anyway.
>
> The real bug here is if allocation of the array fails. The BO array
> may be NULL when the count is not. So this V3D cleanup hunk:
>
> for (i = 0; i < exec->bo_count; i++)
> drm_gem_object_put_unlocked(>bo[i]->base.base);
> kvfree(exec->bo);
>
> Needs to be wrapped with 'if (exec->bo)'. We have a similar problem
> with fence arrays too.
Yeah, seems legit. Not really going to write new patches when I've got
month-old critical patches I can't get acked, though. :/
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amdgpu: Avoid HW reset if guilty job already signaled.
On 4/9/19 10:50 AM, Christian König wrote:
> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
>> Also reject TDRs if another one already running.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94
>> +-
>> 1 file changed, 67 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index aabd043..4446892 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3327,10 +3327,12 @@ bool amdgpu_device_should_recover_gpu(struct
>> amdgpu_device *adev)
>> static int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>> struct amdgpu_job *job,
>> - bool *need_full_reset_arg)
>> + bool *need_full_reset_arg,
>> + bool *job_signaled)
>> {
>> int i, r = 0;
>> bool need_full_reset = *need_full_reset_arg;
>> + struct amdgpu_ring *job_ring = job ?
>> to_amdgpu_ring(job->base.sched) : NULL;
>> /* block all schedulers and reset given job's ring */
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> @@ -3341,6 +3343,17 @@ static int amdgpu_device_pre_asic_reset(struct
>> amdgpu_device *adev,
>> drm_sched_stop(>sched, >base);
>> + /*
>> + * Must check guilty signal here since after this point all old
>> + * HW fences are force signaled.
>> + *
>> + * job->base holds a reference to parent fence
>> + */
>> + if (job_signaled && job && ring == job_ring &&
>> + job->base.s_fence->parent &&
>> + dma_fence_is_signaled(job->base.s_fence->parent))
>> + *job_signaled = true;
>> +
>
> That won't work correctly. See when the guilty job is not on the first
> scheduler, you would already have force completed some before getting
> here.
>
> Better to stop all schedulers first and then do the check.
>
> Christian.
What do you mean by first scheduler ? There is one scheduler object per
ring so I am not clear what 'first' means here.
Andrey
>
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
>> @@ -3358,7 +3371,8 @@ static int amdgpu_device_pre_asic_reset(struct
>> amdgpu_device *adev,
>> - if (!amdgpu_sriov_vf(adev)) {
>> + /* Don't suspend on bare metal if we are not going to HW reset
>> the ASIC */
>> + if (!amdgpu_sriov_vf(adev) && !(*job_signaled)) {
>> if (!need_full_reset)
>> need_full_reset = amdgpu_device_ip_need_full_reset(adev);
>> @@ -3495,7 +3509,7 @@ static int amdgpu_do_asic_reset(struct
>> amdgpu_hive_info *hive,
>> return r;
>> }
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> +static void amdgpu_device_post_asic_reset(struct amdgpu_device
>> *adev, bool job_signaled)
>> {
>> int i;
>> @@ -3505,7 +3519,8 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> if (!ring || !ring->sched.thread)
>> continue;
>> - if (!adev->asic_reset_res)
>> + /* No point to resubmit jobs if we didn't HW reset*/
>> + if (!adev->asic_reset_res && !job_signaled)
>> drm_sched_resubmit_jobs(>sched);
>> drm_sched_start(>sched, !adev->asic_reset_res);
>> @@ -3518,14 +3533,21 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> adev->asic_reset_res = 0;
>> }
>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool
>> trylock)
>> {
>> - mutex_lock(>lock_reset);
>> + if (trylock) {
>> + if (!mutex_trylock(>lock_reset))
>> + return false;
>> + } else
>> + mutex_lock(>lock_reset);
>> +
>> atomic_inc(>gpu_reset_counter);
>> adev->in_gpu_reset = 1;
>> /* Block kfd: SRIOV would do it separately */
>> if (!amdgpu_sriov_vf(adev))
>> amdgpu_amdkfd_pre_reset(adev);
>> +
>> + return true;
>> }
>> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>> @@ -3555,29 +3577,44 @@ int amdgpu_device_gpu_recover(struct
>> amdgpu_device *adev,
>> {
>> int r;
>> struct amdgpu_hive_info *hive = NULL;
>> - bool need_full_reset = false;
>> struct amdgpu_device *tmp_adev = NULL;
>> struct list_head device_list, *device_list_handle = NULL;
>> + bool xgmi_topology_present, need_full_reset, job_signaled;
>> + need_full_reset = job_signaled = false;
>> INIT_LIST_HEAD(_list);
>> dev_info(adev->dev, "GPU reset begin!\n");
>> + hive = amdgpu_get_xgmi_hive(adev, 0);
>> + xgmi_topology_present = hive &&
>> adev->gmc.xgmi.num_physical_nodes > 1;
>> +
>> /*
>> -
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #29 from Andrey Grodzovsky --- (In reply to mikhail.v.gavrilov from comment #28) > And again deadlock occurred. Yea, looks like another annoying regression. Try first of all to revert all the 3 patches i uploaded here and see if you are back to the original deadlock or this issue is still there masking our problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Fix with pm_runtime synchronization on DSI
Hoegeun Kwon writes: > On 4/2/19 2:48 AM, Eric Anholt wrote: >> Hoegeun Kwon writes: >> >>> There is a problem when often dpms goes from off to on. pm idle is not >>> in sync and the problem occurs. Modify pm_runtime_put from >>> asynchronous to synchronous. >> Why would we need the power domain to go to off before we try to come >> back? Any idea? Also, please specify what "the problem" is. > > Hi Eric, > > > First thank you for your review. > > There is a problem failed to runtime PM enable on DSI when often dpms What do you mean by "failed to runtime PM enable"? The pm_runtime_enable() returned an error? Have you investigated the source that error, if so? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 10/10] drm/i915: Added DRM Infoframe handling for BYT/CHT
BYT/CHT doesn't support DRM Infoframe. This caused a WARN_ON due to a missing CASE while executing intel_hdmi_infoframes_enabled function. This patch fixes the same. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 56a36b5..34f9805 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -122,6 +122,8 @@ static u32 g4x_infoframe_enable(unsigned int type) return VIDEO_DIP_ENABLE_SPD; case HDMI_INFOFRAME_TYPE_VENDOR: return VIDEO_DIP_ENABLE_VENDOR; + case HDMI_INFOFRAME_TYPE_DRM: + return 0; default: MISSING_CASE(type); return 0; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 03/10] drm: Enable HDR infoframe support
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Added the const version of infoframe for DRM metadata
for HDR.
v2: Rebase and added Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments and merged the
patch making drm infoframe function arguments as constant.
v5: Rebase
v6: Fixed checkpatch warnings with --strict option. Addressed
Shashank's review comments and added his RB.
v7: Addressed Brian Starkey's review comments. Merged 2 patches
into one.
v8: Addressed Jonas Karlman review comments.
Signed-off-by: Uma Shankar
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 48
drivers/video/hdmi.c | 186 +
include/drm/drm_edid.h | 5 ++
include/linux/hdmi.h | 27 +++
4 files changed, 266 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1fc371b..9b71a64 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4884,6 +4884,54 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
}
/**
+ * drm_hdmi_infoframe_set_hdr_metadata() - fill an HDMI AVI infoframe with
+ * HDR metadata from userspace
+ * @frame: HDMI AVI infoframe
+ * @hdr_source_metadata: hdr_source_metadata info from userspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_infoframe_set_hdr_metadata(struct hdmi_drm_infoframe *frame,
+ struct hdr_output_metadata *hdr_metadata)
+{
+ int err;
+
+ if (!frame || !hdr_metadata)
+ return true;
+
+ err = hdmi_drm_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ DRM_DEBUG_KMS("type = %x\n", frame->type);
+
+ frame->length = sizeof(struct hdr_metadata_infoframe);
+
+ frame->eotf = hdr_metadata->hdmi_metadata_type1.eotf;
+ frame->metadata_type = hdr_metadata->hdmi_metadata_type1.metadata_type;
+
+ memcpy(>display_primaries,
+ _metadata->hdmi_metadata_type1.display_primaries, 12);
+
+ memcpy(>white_point,
+ _metadata->hdmi_metadata_type1.white_point, 4);
+
+ frame->max_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.max_display_mastering_luminance;
+ frame->min_display_mastering_luminance =
+
hdr_metadata->hdmi_metadata_type1.min_display_mastering_luminance;
+ frame->max_fall = hdr_metadata->hdmi_metadata_type1.max_fall;
+ frame->max_cll = hdr_metadata->hdmi_metadata_type1.max_cll;
+
+ hdmi_infoframe_log(KERN_CRIT, NULL,
+ (union hdmi_infoframe *)frame);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
+
+/**
* drm_hdmi_avi_infoframe_from_display_mode() - fill an HDMI AVI infoframe with
* data from a DRM display mode
* @frame: HDMI AVI infoframe
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 799ae49..717ed7fb 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -650,6 +650,146 @@ ssize_t hdmi_vendor_infoframe_pack(struct
hdmi_vendor_infoframe *frame,
return 0;
}
+/**
+ * hdmi_drm_infoframe_init() - initialize an HDMI Dynaminc Range and
+ * mastering infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_init(struct hdmi_drm_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_DRM;
+ frame->version = 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_init);
+
+static int hdmi_drm_infoframe_check_only(const struct hdmi_drm_infoframe
*frame)
+{
+ if (frame->type != HDMI_INFOFRAME_TYPE_DRM ||
+ frame->version != 1)
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * hdmi_drm_infoframe_check() - check a HDMI DRM infoframe
+ * @frame: HDMI DRM infoframe
+ *
+ * Validates that the infoframe is consistent.
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_drm_infoframe_check(struct hdmi_drm_infoframe *frame)
+{
+ return hdmi_drm_infoframe_check_only(frame);
+}
+EXPORT_SYMBOL(hdmi_drm_infoframe_check);
+
+/**
+ * hdmi_drm_infoframe_pack() - write HDMI DRM infoframe to binary buffer
+ * @frame: HDMI DRM infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI
[v8 04/10] drm/i915: Attach HDR metadata property to connector
Attach HDR metadata property to connector object. v2: Rebase v3: Updated the property name as per updated name while creating hdr metadata property Signed-off-by: Uma Shankar Reviewed-by: Shashank Sharma --- drivers/gpu/drm/i915/intel_hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e1005d7..d9851da 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2730,6 +2730,8 @@ static void intel_hdmi_destroy(struct drm_connector *connector) drm_connector_attach_content_type_property(connector); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; + drm_object_attach_property(>base, + connector->dev->mode_config.hdr_output_metadata_property, 0); if (!HAS_GMCH(dev_priv)) drm_connector_attach_max_bpc_property(connector, 8, 12); -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 07/10] drm/i915: Enable infoframes on GLK+ for HDR
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 22 +-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c206e8..6cd250d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4692,6 +4692,7 @@ enum {
#define VIDEO_DIP_FREQ_MASK (3 << 16)
/* HSW and later: */
#define DRM_DIP_ENABLE (1 << 28)
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
#define PSR_VSC_BIT_7_SET(1 << 27)
#define VSC_SELECT_MASK (0x3 << 25)
#define VSC_SELECT_SHIFT 25
@@ -8143,6 +8144,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_A 0x602A0
#define _HSW_VIDEO_DIP_GMP_DATA_A 0x602E0
#define _HSW_VIDEO_DIP_VSC_DATA_A 0x60320
+#define _GLK_VIDEO_DIP_DRM_DATA_A 0x60440
#define _HSW_VIDEO_DIP_AVI_ECC_A 0x60240
#define _HSW_VIDEO_DIP_VS_ECC_A0x60280
#define _HSW_VIDEO_DIP_SPD_ECC_A 0x602C0
@@ -8156,6 +8158,7 @@ enum {
#define _HSW_VIDEO_DIP_SPD_DATA_B 0x612A0
#define _HSW_VIDEO_DIP_GMP_DATA_B 0x612E0
#define _HSW_VIDEO_DIP_VSC_DATA_B 0x61320
+#define _GLK_VIDEO_DIP_DRM_DATA_B 0x61440
#define _HSW_VIDEO_DIP_BVI_ECC_B 0x61240
#define _HSW_VIDEO_DIP_VS_ECC_B0x61280
#define _HSW_VIDEO_DIP_SPD_ECC_B 0x612C0
@@ -8181,6 +8184,7 @@ enum {
#define HSW_TVIDEO_DIP_SPD_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_SPD_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_GMP_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_GMP_DATA_A + (i) * 4)
#define HSW_TVIDEO_DIP_VSC_DATA(trans, i) _MMIO_TRANS2(trans,
_HSW_VIDEO_DIP_VSC_DATA_A + (i) * 4)
+#define GLK_TVIDEO_DIP_DRM_DATA(trans, i) _MMIO_TRANS2(trans,
_GLK_VIDEO_DIP_DRM_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_DATA(trans, i) _MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_DATA_A + (i) * 4)
#define ICL_VIDEO_DIP_PPS_ECC(trans, i)_MMIO_TRANS2(trans,
_ICL_VIDEO_DIP_PPS_ECC_A + (i) * 4)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 40d55b0..0ecfda0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -145,6 +145,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return VIDEO_DIP_ENABLE_SPD_HSW;
case HDMI_INFOFRAME_TYPE_VENDOR:
return VIDEO_DIP_ENABLE_VS_HSW;
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return VIDEO_DIP_ENABLE_DRM_GLK;
default:
MISSING_CASE(type);
return 0;
@@ -170,6 +172,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_VENDOR:
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
+ case HDMI_INFOFRAME_TYPE_DRM:
+ return GLK_TVIDEO_DIP_DRM_DATA(cpu_transcoder, i);
default:
MISSING_CASE(type);
return INVALID_MMIO_REG;
@@ -553,10 +557,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 val = I915_READ(HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
+ u32 mask;
- return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
- VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
- VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+ mask = (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
+ VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
+ VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ mask |= VIDEO_DIP_ENABLE_DRM_GLK;
+
+ return val & mask;
}
static const u8 infoframe_type_to_idx[] = {
@@ -1188,7 +1198,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
-VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
+VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW |
+VIDEO_DIP_ENABLE_DRM_GLK);
if (!enable) {
I915_WRITE(reg, val);
@@ -1217,7 +1228,8 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
* ToDo: Gen9 also can support HDR with LSPCON.
* Support for the same to be enabled later.
[v8 09/10] drm/i915: Set Infoframe for non modeset case for HDR
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_hdmi.c | 7 +--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ab3a8a..49b384d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3545,6 +3545,10 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *intel_dig_port =
+ enc_to_dig_port(>base);
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
@@ -3554,6 +3558,15 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
else if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
intel_hdcp_disable(to_intel_connector(conn_state->connector));
+
+ /* Set the infoframe for NON modeset cases as well */
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ if ((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+ conn_state->hdr_metadata_changed)
+ intel_dig_port->set_infoframes(encoder,
+
crtc_state->has_infoframe,
+ crtc_state, conn_state);
+ }
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 85333a7..56a36b5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1219,8 +1219,11 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 val = I915_READ(reg);
- assert_hdmi_transcoder_func_disabled(dev_priv,
-crtc_state->cpu_transcoder);
+ /* DRM Infoframe can be send with transcoder enabled */
+ if (!((INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) &&
+ conn_state->hdr_metadata_changed))
+ assert_hdmi_transcoder_func_disabled(dev_priv,
+
crtc_state->cpu_transcoder);
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 02/10] drm: Parse HDR metadata info from EDID
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman review comments.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2c22ea4..1fc371b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2830,6 +2830,7 @@ static int drm_cvt_modes(struct drm_connector *connector,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
#define EXT_VIDEO_DATA_BLOCK_420 0x0E
@@ -3577,6 +3578,12 @@ static int add_3d_struct_modes(struct drm_connector
*connector, u16 structure,
}
static int
+cea_db_payload_len_ext(const u8 *db)
+{
+ return (db[0] & 0x1f) - 1;
+}
+
+static int
cea_db_extended_tag(const u8 *db)
{
return db[1];
@@ -3812,6 +3819,49 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ return false;
+
+ return true;
+}
+
+static uint8_t eotf_supported(const u8 *edid_ext)
+{
+ return edid_ext[2] &
+ (BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
+BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
+BIT(HDMI_EOTF_SMPTE_ST2084));
+}
+
+static uint8_t hdr_metadata_type(const u8 *edid_ext)
+{
+ return edid_ext[3] &
+ BIT(HDMI_STATIC_METADATA_TYPE1);
+}
+
+static void
+drm_parse_hdr_metadata_block(struct drm_connector *connector, const u8 *db)
+{
+ u16 len;
+
+ len = cea_db_payload_len_ext(db);
+ connector->hdr_sink_metadata.hdmi_type1.eotf = eotf_supported(db);
+ connector->hdr_sink_metadata.hdmi_type1.metadata_type =
+ hdr_metadata_type(db);
+
+ if (len >= 4)
+ connector->hdr_sink_metadata.hdmi_type1.max_cll = db[4];
+ if (len >= 5)
+ connector->hdr_sink_metadata.hdmi_type1.max_fall = db[5];
+ if (len >= 6)
+ connector->hdr_sink_metadata.hdmi_type1.min_cll = db[6];
+}
+
static void
drm_parse_hdmi_vsdb_audio(struct drm_connector *connector, const u8 *db)
{
@@ -4439,6 +4489,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
drm_parse_vcdb(connector, db);
+ if (cea_db_is_hdmi_hdr_metadata_block(db))
+ drm_parse_hdr_metadata_block(connector, db);
}
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 00/10] Add HDR Metadata Parsing and handling in DRM layer
This patch series enables HDR support in drm. It basically defines HDR metadata structures, property to pass content (after blending) metadata from user space compositors to driver. Dynamic Range and Mastering infoframe creation and sending. ToDo: 1. We need to get the color framework in place for all planes which support HDR content in hardware. This is already in progres and patches are out for review in mailing list. 2. UserSpace/Compositors: Blending policies and metadata blob creation and passing to driver. Work is already in progress by Intel's middleware teams on wayland and the patches for the same are in review. Please review and share your feedbacks/suggestions. Note: The intention for these patches is to get a design feedback on the uapi changes, generic property design and infoframe handling. This cannot get merged as of now without the userspace support in place. A POC has already been developed by Ville based on wayland. Please refer below link to see the component interactions and usage: https://lists.freedesktop.org/archives/wayland-devel/2017-December/036403.html v2: Updated Ville's POC changes to the patch series.Incorporated cleanups and fixes from Ville. Rebase on latest drm-tip. v3: Fixed a warning causing builds to break on CI. No major change. v4: Addressed Shashank's review comments. v5: Rebase on top of Ville's infoframe refactoring changes. Fixed non modeset case for HDR metadata update. Dropped a redundant patch. v6: Addressed Shashank's review comments and added RB's received. v7: Squashed 2 patches, dropped 1 change and addressed Brian Starkey's and Shashank's review comments. v8: Addressed Jonas Karlman review comments. Added Shashank's RB to the series, fixed a WARN_ON on BYT/CHT. Note: Media driver and VAAPI changes for HDR are already out, with compositors changes also expected to land soon. Weston changes already floated and reviews started in community and is in active development along with GL efforts. Uma Shankar (8): drm: Add HDR source metadata property drm: Parse HDR metadata info from EDID drm: Enable HDR infoframe support drm/i915: Attach HDR metadata property to connector drm/i915: Write HDR infoframe and send to panel drm/i915:Enabled Modeset when HDR Infoframe changes drm/i915: Set Infoframe for non modeset case for HDR drm/i915: Added DRM Infoframe handling for BYT/CHT Ville Syrjälä (2): drm/i915: Add HLG EOTF drm/i915: Enable infoframes on GLK+ for HDR drivers/gpu/drm/drm_atomic.c| 2 + drivers/gpu/drm/drm_atomic_uapi.c | 13 +++ drivers/gpu/drm/drm_connector.c | 6 ++ drivers/gpu/drm/drm_edid.c | 101 drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_atomic.c | 14 ++- drivers/gpu/drm/i915/intel_ddi.c| 13 +++ drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 105 ++-- drivers/video/hdmi.c| 186 include/drm/drm_connector.h | 11 +++ include/drm/drm_edid.h | 5 + include/drm/drm_mode_config.h | 6 ++ include/linux/hdmi.h| 38 include/uapi/drm/drm_mode.h | 39 15 files changed, 537 insertions(+), 7 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 06/10] drm/i915: Add HLG EOTF
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a logarithmic curve.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 3 ++-
include/linux/hdmi.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9b71a64..f88c0c7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3835,7 +3835,8 @@ static uint8_t eotf_supported(const u8 *edid_ext)
return edid_ext[2] &
(BIT(HDMI_EOTF_TRADITIONAL_GAMMA_SDR) |
BIT(HDMI_EOTF_TRADITIONAL_GAMMA_HDR) |
-BIT(HDMI_EOTF_SMPTE_ST2084));
+BIT(HDMI_EOTF_SMPTE_ST2084) |
+BIT(HDMI_EOTF_BT_2100_HLG));
}
static uint8_t hdr_metadata_type(const u8 *edid_ext)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 3927d88..daf7a37 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -161,6 +161,7 @@ enum hdmi_eotf {
HDMI_EOTF_TRADITIONAL_GAMMA_SDR,
HDMI_EOTF_TRADITIONAL_GAMMA_HDR,
HDMI_EOTF_SMPTE_ST2084,
+ HDMI_EOTF_BT_2100_HLG,
};
struct hdmi_avi_infoframe {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 08/10] drm/i915:Enabled Modeset when HDR Infoframe changes
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
drivers/gpu/drm/i915/intel_hdmi.c | 26 ++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 8c8fae3..e8b5f84 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -104,6 +104,16 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return -EINVAL;
}
+static bool blob_equal(const struct drm_property_blob *a,
+ const struct drm_property_blob *b)
+{
+ if (a && b)
+ return a->length == b->length &&
+ !memcmp(a->data, b->data, a->length);
+
+ return !a == !b;
+}
+
int intel_digital_connector_atomic_check(struct drm_connector *conn,
struct drm_connector_state *new_state)
{
@@ -131,7 +141,9 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
- new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
+ new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ !blob_equal(new_conn_state->base.hdr_output_metadata_blob_ptr,
+ old_conn_state->base.hdr_output_metadata_blob_ptr))
crtc_state->mode_changed = true;
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0ecfda0..85333a7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -799,6 +799,20 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool is_eotf_supported(u8 output_eotf, u8 sink_eotf)
+{
+ if (output_eotf == 0)
+ return (sink_eotf & (1 << 0));
+ if (output_eotf == 1)
+ return (sink_eotf & (1 << 1));
+ if (output_eotf == 2)
+ return (sink_eotf & (1 << 2));
+ if (output_eotf == 3)
+ return (sink_eotf & (1 << 3));
+
+ return false;
+}
+
static bool
intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -806,11 +820,23 @@ void intel_read_infoframe(struct intel_encoder *encoder,
{
struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
struct hdr_output_metadata *hdr_metadata;
+ struct drm_connector *connector = conn_state->connector;
int ret;
+ if (!conn_state->hdr_output_metadata_blob_ptr ||
+ conn_state->hdr_output_metadata_blob_ptr->length == 0)
+ return true;
+
hdr_metadata = (struct hdr_output_metadata *)
conn_state->hdr_output_metadata_blob_ptr->data;
+ /* Sink EOTF is Bit map while infoframe is absolute values */
+ if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
+ connector->hdr_sink_metadata.hdmi_type1.eotf)) {
+ DRM_ERROR("EOTF Not Supported\n");
+ return true;
+ }
+
ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
if (ret < 0) {
DRM_ERROR("couldn't set HDR metadata in infoframe\n");
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 05/10] drm/i915: Write HDR infoframe and send to panel
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation in compute config.
v6: Addressed Shashank's review comment. Added HDR metadata
support from GEN10 onwards as per Shashank's recommendation.
v7: Addressed Shashank's review comments
v8: Added Shashank's RB.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 48 +++
2 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a38b9cf..6a9d132 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1051,6 +1051,7 @@ struct intel_crtc_state {
union hdmi_infoframe avi;
union hdmi_infoframe spd;
union hdmi_infoframe hdmi;
+ union hdmi_infoframe drm;
} infoframes;
/* HDMI scrambling status */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index d9851da..40d55b0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -566,6 +566,7 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
*encoder,
HDMI_INFOFRAME_TYPE_AVI,
HDMI_INFOFRAME_TYPE_SPD,
HDMI_INFOFRAME_TYPE_VENDOR,
+ HDMI_INFOFRAME_TYPE_DRM,
};
u32 intel_hdmi_infoframe_enable(unsigned int type)
@@ -788,6 +789,30 @@ void intel_read_infoframe(struct intel_encoder *encoder,
return true;
}
+static bool
+intel_hdmi_compute_drm_infoframe(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct hdmi_drm_infoframe *frame = _state->infoframes.drm.drm;
+ struct hdr_output_metadata *hdr_metadata;
+ int ret;
+
+ hdr_metadata = (struct hdr_output_metadata *)
+ conn_state->hdr_output_metadata_blob_ptr->data;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(frame, hdr_metadata);
+ if (ret < 0) {
+ DRM_ERROR("couldn't set HDR metadata in infoframe\n");
+ return false;
+ }
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_DRM);
+
+ return true;
+}
+
static void g4x_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
@@ -1186,6 +1211,16 @@ static void hsw_set_infoframes(struct intel_encoder
*encoder,
intel_write_infoframe(encoder, crtc_state,
HDMI_INFOFRAME_TYPE_VENDOR,
_state->infoframes.hdmi);
+
+ /*
+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+ if (INTEL_GEN(dev_priv) >= 10)
+ intel_write_infoframe(encoder, crtc_state,
+ HDMI_INFOFRAME_TYPE_DRM,
+ _state->infoframes.drm);
}
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
@@ -2392,6 +2427,19 @@ int intel_hdmi_compute_config(struct intel_encoder
*encoder,
return -EINVAL;
}
+ /*
+* Support HDR Metadata from Gen10 onwards
+* ToDo: Gen9 also can support HDR with LSPCON.
+* Support for the same to be enabled later.
+*/
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ if (!intel_hdmi_compute_drm_infoframe(encoder, pipe_config,
+ conn_state)) {
+ DRM_DEBUG_KMS("bad DRM infoframe\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v8 01/10] drm: Add HDR source metadata property
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is returned as blob in get
property call to userspace.
v2: Rebase and modified the metadata structure elements
as per Ville's POC changes.
v3: No Change
v4: Addressed Shashank's review comments
v5: Rebase.
v6: Addressed Brian Starkey's review comments, defined
new structure with header for dynamic metadata scalability.
Merge get/set property functions for metadata in this patch.
v7: Addressed Jonas Karlman review comments and defined separate
structure for infoframe to better align with CTA 861.G spec. Added
Shashank's RB.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atomic_uapi.c | 13 +
drivers/gpu/drm/drm_connector.c | 6 ++
include/drm/drm_connector.h | 11 +++
include/drm/drm_mode_config.h | 6 ++
include/linux/hdmi.h | 10 ++
include/uapi/drm/drm_mode.h | 39 +++
7 files changed, 87 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5eb4013..8b9c126 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -881,6 +881,8 @@ static void drm_atomic_connector_print_state(struct
drm_printer *p,
drm_printf(p, "connector[%u]: %s\n", connector->base.id,
connector->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
"(null)");
+ drm_printf(p, "\thdr_metadata_changed=%d\n",
+ state->hdr_metadata_changed);
if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index ea797d4..6d0d161 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -673,6 +673,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
{
struct drm_device *dev = connector->dev;
struct drm_mode_config *config = >mode_config;
+ bool replaced = false;
+ int ret;
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val);
@@ -721,6 +723,14 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+ } else if (property == config->hdr_output_metadata_property) {
+ ret = drm_atomic_replace_property_blob_from_id(dev,
+ >hdr_output_metadata_blob_ptr,
+ val,
+ -1, sizeof(struct hdr_output_metadata),
+ );
+ state->hdr_metadata_changed |= replaced;
+ return ret;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
@@ -807,6 +817,9 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+ } else if (property == config->hdr_output_metadata_property) {
+ *val = (state->hdr_output_metadata_blob_ptr) ?
+ state->hdr_output_metadata_blob_ptr->base.id : 0;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124..0bdae90 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
+ "HDR_OUTPUT_METADATA", 0);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.hdr_output_metadata_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 02a1312..5343f60 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -599,6 +599,13 @@ struct drm_connector_state {
* and the connector bpc limitations obtained from edid.
*/
u8 max_bpc;
+
+ /**
+
RE: [v7 1/9] drm: Add HDR source metadata property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Jonas
>Karlman
>Sent: Monday, April 8, 2019 3:51 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: seanp...@chromium.org; emil.l.veli...@gmail.com; dcasta...@chromium.org;
>Lankhorst, Maarten ; Syrjala, Ville
>
>Subject: Re: [v7 1/9] drm: Add HDR source metadata property
>
>On 2019-04-02 22:20, Uma Shankar wrote:
>> This patch adds a blob property to get HDR metadata information from
>> userspace. This will be send as part of AVI Infoframe to panel.
>>
>> It also implements get() and set() functions for HDR output metadata
>> property.The blob data is received from userspace and saved in
>> connector state, the same is returned as blob in get property call to
>> userspace.
>>
>> v2: Rebase and modified the metadata structure elements as per Ville's
>> POC changes.
>>
>> v3: No Change
>>
>> v4: Addressed Shashank's review comments
>>
>> v5: Rebase.
>>
>> v6: Addressed Brian Starkey's review comments, defined new structure
>> with header for dynamic metadata scalability.
>> Merge get/set property functions for metadata in this patch.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_atomic.c | 2 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 13 +
>> drivers/gpu/drm/drm_connector.c | 6 ++
>> include/drm/drm_connector.h | 10 ++
>> include/drm/drm_mode_config.h | 6 ++
>> include/linux/hdmi.h | 10 ++
>> include/uapi/drm/drm_mode.h | 22 ++
>> 7 files changed, 69 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c
>> b/drivers/gpu/drm/drm_atomic.c index 5eb4013..8b9c126 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -881,6 +881,8 @@ static void
>> drm_atomic_connector_print_state(struct drm_printer *p,
>>
>> drm_printf(p, "connector[%u]: %s\n", connector->base.id, connector-
>>name);
>> drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name :
>> "(null)");
>> +drm_printf(p, "\thdr_metadata_changed=%d\n",
>> + state->hdr_metadata_changed);
>>
>> if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
>> if (state->writeback_job && state->writeback_job->fb) diff --git
>> a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index ea797d4..6d0d161 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -673,6 +673,8 @@ static int
>> drm_atomic_connector_set_property(struct drm_connector *connector, {
>> struct drm_device *dev = connector->dev;
>> struct drm_mode_config *config = >mode_config;
>> +bool replaced = false;
>> +int ret;
>>
>> if (property == config->prop_crtc_id) {
>> struct drm_crtc *crtc = drm_crtc_find(dev, NULL, val); @@ -721,6
>> +723,14 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>> */
>> if (state->link_status != DRM_LINK_STATUS_GOOD)
>> state->link_status = val;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +ret = drm_atomic_replace_property_blob_from_id(dev,
>> +>hdr_output_metadata_blob_ptr,
>> +val,
>> +-1, sizeof(struct hdr_output_metadata),
>> +);
>> +state->hdr_metadata_changed |= replaced;
>> +return ret;
>> } else if (property == config->aspect_ratio_property) {
>> state->picture_aspect_ratio = val;
>> } else if (property == config->content_type_property) { @@ -807,6
>> +817,9 @@ static int drm_atomic_connector_set_property(struct drm_connector
>*connector,
>> *val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> +} else if (property == config->hdr_output_metadata_property) {
>> +*val = (state->hdr_output_metadata_blob_ptr) ?
>> +state->hdr_output_metadata_blob_ptr->base.id : 0;
>> } else if (property == connector->content_protection_property) {
>> *val = state->content_protection;
>> } else if (property == config->writeback_fb_id_property) { diff
>> --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 2355124..0bdae90 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1058,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
>drm_device *dev)
>> return -ENOMEM;
>> dev->mode_config.non_desktop_property = prop;
>>
>> +prop = drm_property_create(dev, DRM_MODE_PROP_BLOB,
>> + "HDR_OUTPUT_METADATA", 0);
>> +if (!prop)
>> +return
Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver
On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso wrote:
>
> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
> >
> > On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> > >
> > > On 01/04/2019 08:47, Rob Herring wrote:
> > > > This adds the initial driver for panfrost which supports Arm Mali
> > > > Midgard and Bifrost family of GPUs. Currently, only the T860 and
> > > > T760 Midgard GPUs have been tested.
> >
> > [...]
> > > > +
> > > > + if (status & JOB_INT_MASK_ERR(j)) {
> > > > + job_write(pfdev, JS_COMMAND_NEXT(j),
> > > > JS_COMMAND_NOP);
> > > > + job_write(pfdev, JS_COMMAND(j),
> > > > JS_COMMAND_HARD_STOP_0);
> > >
> > > Hard-stopping an already completed job isn't likely to do very much :)
> > > Also you are using the "_0" version which is only valid when "job chain
> > > disambiguation" is present.
>
> Yeah, guess that can be removed.
Steven, TBC, are you suggesting removing both lines or leaving
JS_COMMAND_NOP? I don't think we can ever have a pending job at this
point as there's no queuing. So the NOP probably isn't needed, but
doesn't hurt to have it either.
> > > I suspect in this case you should also be signalling the fence? At the
> > > moment you rely on the GPU timeout recovering from the fault.
> >
> > I'll defer to Tomeu who wrote this (IIRC).
>
> Yes, that would be an improvement.
Actually, I think that would break recovery because the job timeout
will bail out if the done fence is signaled already. Perhaps we want
to timeout immediately if that is possible with the scheduler.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108879] [CIK] [regression] All opencl apps hangs indefinitely in si_create_context
https://bugs.freedesktop.org/show_bug.cgi?id=108879 --- Comment #10 from Jan Vesely --- (In reply to Steffen Klee from comment #9) > AMD R9 390 (Linux 4.14, LLVM 8.0.0, AMDGPU kernel driver, Mesa 19.0.1) > > Also experiencing hangs when running clinfo and other OpenCL software. > Applying mentioned patches results in segfaults when starting graphical > applications as well as OpenCL software. > > However, when just applying the workaround in duplicate bug 108572, comment > 6, clinfo and other OpenCL software start working again. Thanks for the update. Can you try running piglit cl-api-enqueue-copy-buffer after applying the workaround? It might be just an early initialization issue rather than a problem with compute shader clears in general. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver
On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> >
> > On 01/04/2019 08:47, Rob Herring wrote:
> > > This adds the initial driver for panfrost which supports Arm Mali
> > > Midgard and Bifrost family of GPUs. Currently, only the T860 and
> > > T760 Midgard GPUs have been tested.
>
> [...]
> > > +
> > > + if (status & JOB_INT_MASK_ERR(j)) {
> > > + job_write(pfdev, JS_COMMAND_NEXT(j),
> > > JS_COMMAND_NOP);
> > > + job_write(pfdev, JS_COMMAND(j),
> > > JS_COMMAND_HARD_STOP_0);
> >
> > Hard-stopping an already completed job isn't likely to do very much :)
> > Also you are using the "_0" version which is only valid when "job chain
> > disambiguation" is present.
Yeah, guess that can be removed.
> > I suspect in this case you should also be signalling the fence? At the
> > moment you rely on the GPU timeout recovering from the fault.
>
> I'll defer to Tomeu who wrote this (IIRC).
Yes, that would be an improvement.
> > One issue that I haven't got to the bottom of is that I can trigger a
> > lockdep splat:
> >
> > -8<--
> > panfrost ffa3.gpu: js fault, js=1, status=JOB_CONFIG_FAULT,
> > head=0x0, tail=0x0
> > root@debian:~/ddk_panfrost# panfrost ffa3.gpu: gpu sched timeout,
> > js=1, status=0x40, head=0x0, tail=0x0, sched_job=12a94ba6
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 5.0.0+ #32 Not tainted
> > --
> > kworker/1:0/608 is trying to acquire lock:
> > 89b1e2d8 (&(>job_lock)->rlock){-.-.}, at:
> > dma_fence_remove_callback+0x14/0x50
> >
> > but task is already holding lock:
> > a887e4b2 (&(>job_list_lock)->rlock){-.-.}, at:
> > drm_sched_stop+0x24/0x10c
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #1 (&(>job_list_lock)->rlock){-.-.}:
> >drm_sched_process_job+0x60/0x208
> >dma_fence_signal+0x1dc/0x1fc
> >panfrost_job_irq_handler+0x160/0x194
> >__handle_irq_event_percpu+0x80/0x388
> >handle_irq_event_percpu+0x24/0x78
> >handle_irq_event+0x38/0x5c
> >handle_fasteoi_irq+0xb4/0x128
> >generic_handle_irq+0x18/0x28
> >__handle_domain_irq+0xa0/0xb4
> >gic_handle_irq+0x4c/0x78
> >__irq_svc+0x70/0x98
> >arch_cpu_idle+0x20/0x3c
> >arch_cpu_idle+0x20/0x3c
> >do_idle+0x11c/0x22c
> >cpu_startup_entry+0x18/0x20
> >start_kernel+0x398/0x420
> >
> > -> #0 (&(>job_lock)->rlock){-.-.}:
> >_raw_spin_lock_irqsave+0x50/0x64
> >dma_fence_remove_callback+0x14/0x50
> >drm_sched_stop+0x5c/0x10c
> >panfrost_job_timedout+0xd0/0x180
> >drm_sched_job_timedout+0x34/0x5c
> >process_one_work+0x2ac/0x6a4
> >worker_thread+0x28c/0x3fc
> >kthread+0x13c/0x158
> >ret_from_fork+0x14/0x20
> > (null)
> >
> > other info that might help us debug this:
> >
> > Possible unsafe locking scenario:
> >
> >CPU0CPU1
> >
> > lock(&(>job_list_lock)->rlock);
> >lock(&(>job_lock)->rlock);
> >lock(&(>job_list_lock)->rlock);
> > lock(&(>job_lock)->rlock);
> >
> > *** DEADLOCK ***
> >
> > 3 locks held by kworker/1:0/608:
> > #0: 9b350627 ((wq_completion)"events"){+.+.}, at:
> > process_one_work+0x1f8/0x6a4
> > #1: a802aa2d ((work_completion)(&(>work_tdr)->work)){+.+.}, at:
> > process_one_work+0x1f8/0x6a4
> > #2: a887e4b2 (&(>job_list_lock)->rlock){-.-.}, at:
> > drm_sched_stop+0x24/0x10c
> >
> > stack backtrace:
> > CPU: 1 PID: 608 Comm: kworker/1:0 Not tainted 5.0.0+ #32
> > Hardware name: Rockchip (Device Tree)
> > Workqueue: events drm_sched_job_timedout
> > [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> > [] (show_stack) from [] (dump_stack+0x9c/0xd4)
> > [] (dump_stack) from []
> > (print_circular_bug.constprop.15+0x1fc/0x2cc)
> > [] (print_circular_bug.constprop.15) from []
> > (__lock_acquire+0xe5c/0x167c)
> > [] (__lock_acquire) from [] (lock_acquire+0xc4/0x210)
> > [] (lock_acquire) from []
> > (_raw_spin_lock_irqsave+0x50/0x64)
> > [] (_raw_spin_lock_irqsave) from []
> > (dma_fence_remove_callback+0x14/0x50)
> > [] (dma_fence_remove_callback) from []
> > (drm_sched_stop+0x5c/0x10c)
> > [] (drm_sched_stop) from []
> > (panfrost_job_timedout+0xd0/0x180)
> > [] (panfrost_job_timedout) from []
> > (drm_sched_job_timedout+0x34/0x5c)
> > [] (drm_sched_job_timedout) from []
> > (process_one_work+0x2ac/0x6a4)
> > [] (process_one_work) from []
> > (worker_thread+0x28c/0x3fc)
> > [] (worker_thread) from [] (kthread+0x13c/0x158)
> > [] (kthread) from [] (ret_from_fork+0x14/0x20)
> > Exception stack(0xeebd7fb0 to 0xeebd7ff8)
> > 7fa0:
[Bug 203201] New: [mgag200] Unable to do mmap call on mgadrmfb device - Returns -EINVAL
https://bugzilla.kernel.org/show_bug.cgi?id=203201 Bug ID: 203201 Summary: [mgag200] Unable to do mmap call on mgadrmfb device - Returns -EINVAL Product: Drivers Version: 2.5 Kernel Version: 4.4 LTS Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: oliv...@bonhomme.io Regression: No Hello dear kernel maintainers, I'm trying to map memory on the frame buffer device fb0 provided by the mgag200 driver. However, that mmap call always returns -EINVAL code while the same mmmap call works with other drivers (uvesafb for example). After some investigations, I discovered that a patch which resolves that problem has been produced by SuSe guys. The patch is available here : https://lists.freedesktop.org/archives/dri-devel/2017-July/147650.html I tested that patch on my 4.4.150 kernel and it resolved the problem. I checked in the GIT kernel tree and it seems that this patch hasn't been included in 4.4 branch nor in the current kernel branch while the same kind of patch has been done for ast driver (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ast?h=linux-4.4.y=28fb4cb7fa6f63dc2fbdb5f2564dcbead8e3eee0) It would be nice if that patch for mgag200 would be imported in the kernel source tree. Thanks Regards, Olivier Bonhomme -- 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] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote: > What about if I disable interrupt when changing the colorkey? This will > solve the atomic issue. I think we only change colorkey or enable/disable > colorkey once a while. If disabling interrupt work, I will disable interrupt > and change colorkey. That performance affection could be acceptable Interrupts don't matter for this. > > Thanks > > Jim > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 9:19 AM > To: Jim Zhang > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > > Once I pre-configure the colorkey, am I able to enable and disable it? > > If colorkey can be enabled/disabled after that might meet my > > requirement > > Not atomically with other updates. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 9, 2019 8:57 AM > > To: Jim Zhang > > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > > Villie: > > > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > > to review and release? > > > > > > There is no real plan at this time. But if you have a use case for > > > it I can try to harass people until someone reviews it :) > > > > > > > If I go with custom ioctl, and my custom ioctl will only used in > > > > Baytrail product, could it be atomic for Baytrail only? > > > > > > No. We would need to define a new api for it. > > > > I should clarify that you can pre-configure the colorkey before turning on > > the sprite plane(s). So unless you really need to change the colorkey while > > the sprite plane(s) are already enabled you may not even need an atomic api > > for this. > > > > > > > > > > > > > Thanks, > > > > > > > > Jim > > > > > > > > > > > > Caterpillar: Confidential Green > > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > > To: Jim Zhang > > > > Cc: dri-devel@lists.freedesktop.org; > > > > intel-...@lists.freedesktop.org > > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > > Hi Sir/Madam: > > > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > > > Linux kernel version 3.10.61: > > > > > Libdrm package: 2.4.97 > > > > > > > > > > When calling function > > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > > > This property is: > > > > > property->name = "rotation", property->prop_id =4 It looks > > > > > like that the Baytrail gpu drm driver does not support colorkey. > > > > > > > > There are two problems currently: > > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > > patches for it but they have not been reviewed by anyone: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.fre > > > > ed > > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg > > > > -s > > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUC > > > > y9 > > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo > > > > 50 > > > > PX79myDO5gEYA= > > > > - Colorkey can only be set via a custom i915 specific ioctl > > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > > a generic property based API that never really went anywhere. It's > > > > a rather difficult problem making this generic as each hardware has > > > > its own peculiar way of specifying colorkeying. The main problem > > > > with the custom ioctl is that it's not atomic with other screen > > > > updates. > > > > > > > > So, what kind of use case do you have in mind? > > > > > > > > -- > > > > Ville Syrjälä > > > > Intel > > > > > > -- > > > Ville Syrjälä > > > Intel > > > ___ > > > Intel-gfx mailing list > > > intel-...@lists.freedesktop.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedeskt > > > op > > > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r > > > 4m > > > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=O > > > yn > > > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzN > > > PQ > > > cu3xTPSCqb5Dnpwk= > > > > -- > > Ville Syrjälä > > Intel > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel
Re: [PATCH 3/3] drm/amdgpu: Avoid HW reset if guilty job already signaled.
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
Also reject TDRs if another one already running.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94 +-
1 file changed, 67 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index aabd043..4446892 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3327,10 +3327,12 @@ bool amdgpu_device_should_recover_gpu(struct
amdgpu_device *adev)
static int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
struct amdgpu_job *job,
- bool *need_full_reset_arg)
+ bool *need_full_reset_arg,
+ bool *job_signaled)
{
int i, r = 0;
bool need_full_reset = *need_full_reset_arg;
+ struct amdgpu_ring *job_ring = job ? to_amdgpu_ring(job->base.sched) :
NULL;
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
@@ -3341,6 +3343,17 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
drm_sched_stop(>sched, >base);
+ /*
+* Must check guilty signal here since after this point all old
+* HW fences are force signaled.
+*
+* job->base holds a reference to parent fence
+*/
+ if (job_signaled && job && ring == job_ring &&
+ job->base.s_fence->parent &&
+ dma_fence_is_signaled(job->base.s_fence->parent))
+ *job_signaled = true;
+
That won't work correctly. See when the guilty job is not on the first
scheduler, you would already have force completed some before getting here.
Better to stop all schedulers first and then do the check.
Christian.
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3358,7 +3371,8 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
- if (!amdgpu_sriov_vf(adev)) {
+ /* Don't suspend on bare metal if we are not going to HW reset the ASIC
*/
+ if (!amdgpu_sriov_vf(adev) && !(*job_signaled)) {
if (!need_full_reset)
need_full_reset =
amdgpu_device_ip_need_full_reset(adev);
@@ -3495,7 +3509,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
*hive,
return r;
}
-static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
+static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev, bool
job_signaled)
{
int i;
@@ -3505,7 +3519,8 @@ static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
if (!ring || !ring->sched.thread)
continue;
- if (!adev->asic_reset_res)
+ /* No point to resubmit jobs if we didn't HW reset*/
+ if (!adev->asic_reset_res && !job_signaled)
drm_sched_resubmit_jobs(>sched);
drm_sched_start(>sched, !adev->asic_reset_res);
@@ -3518,14 +3533,21 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev)
adev->asic_reset_res = 0;
}
-static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
+static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool trylock)
{
- mutex_lock(>lock_reset);
+ if (trylock) {
+ if (!mutex_trylock(>lock_reset))
+ return false;
+ } else
+ mutex_lock(>lock_reset);
+
atomic_inc(>gpu_reset_counter);
adev->in_gpu_reset = 1;
/* Block kfd: SRIOV would do it separately */
if (!amdgpu_sriov_vf(adev))
amdgpu_amdkfd_pre_reset(adev);
+
+ return true;
}
static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
@@ -3555,29 +3577,44 @@ int amdgpu_device_gpu_recover(struct amdgpu_device
*adev,
{
int r;
struct amdgpu_hive_info *hive = NULL;
- bool need_full_reset = false;
struct amdgpu_device *tmp_adev = NULL;
struct list_head device_list, *device_list_handle = NULL;
+ bool xgmi_topology_present, need_full_reset, job_signaled;
+ need_full_reset = job_signaled = false;
INIT_LIST_HEAD(_list);
dev_info(adev->dev, "GPU reset begin!\n");
+ hive = amdgpu_get_xgmi_hive(adev, 0);
+ xgmi_topology_present = hive && adev->gmc.xgmi.num_physical_nodes > 1;
+
/*
-* In case of XGMI hive disallow concurrent resets to be triggered
-* by different nodes. No point also since the one node already
executing
-* reset will also reset all the other nodes in the hive.
+* Here we
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
Hi,
On 09-04-19 14:05, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
Hi,
On 09-04-19 11:47, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.
This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.
Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?
I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.
According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html
The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.
I agree that we should try to fix a broken default but are you sure
this will only affect the n5550? IIUC Milstead / Granite Well is an
Intel product / board name and perhaps some of those use LVDS.
Milstead is the name of Intel's NAS reference design:
https://www.hardwarezone.com.my/tech-news-intel-unveils-milstead-platform-nas-devices
I seriously doubt that any NAS-es have a LVDS (laptop/tablet) LCD panel.
Also, if the pre-installed OS solves this on the cmdline then it's
only a problem if the user is trying to install a custom OS on the
device. I would expect such a user to be able to change bios settings.
I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?
No there are no better DMI strings to match against I'm afraid.
Regards,
Hans
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..268643af114c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
return false;
}
+static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
+ {
+ /* Thecus N2800 and N5550 family NAS-es */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead Platform"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
+ /* BIOS version is CDV_T X64 */
+ DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
+ },
+ },
+ {}
+};
+
/**
* cdv_intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
+ /*
+* Check blacklist for machines with BIOSes that list an LVDS panel
+* without actually having one.
+*/
+ if (dmi_check_system(cdv_intel_lvds_blacklist)) {
+ dev_info(>pdev->dev, "System is on LVDS blacklist, skipping
LVDS panel detection\n");
+ return;
+ }
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, )) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/sched: Keep s_fence->parent pointer
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
For later driver's reference to see if the fence is signaled.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index c215cde..5bb4368 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -191,8 +191,6 @@ EXPORT_SYMBOL(drm_sched_dependency_optimized);
*/
static void drm_sched_start_timeout(struct drm_gpu_scheduler *sched)
{
- unsigned long flags;
-
I think this actually belongs into patch #1.
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_empty(>ring_mirror_list))
schedule_delayed_work(>work_tdr, sched->timeout);
@@ -371,7 +369,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
dma_fence_remove_callback(s_job->s_fence->parent,
_job->cb)) {
dma_fence_put(s_job->s_fence->parent);
- s_job->s_fence->parent = NULL;
How about also moving the dma_fence_put() into
drm_sched_resubmit_jobs(), right before we re-assign s_job->s_fence->parent?
I think that would be cleaner, but not sure if that wouldn't have any
ugly side effects.
Christian.
atomic_dec(>hw_rq_count);
} else {
/*
@@ -398,6 +395,14 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
sched->ops->free_job(s_job);
}
}
+
+ /*
+* Stop pending timer in flight as we rearm it in drm_sched_start. This
+* avoids the pending timeout work in progress to fire right away after
+* this TDR finished and before the newly restarted jobs had a
+* chance to complete.
+*/
+ cancel_delayed_work(>work_tdr);
}
EXPORT_SYMBOL(drm_sched_stop);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110360] AMD system hits AMD-Vi: Completion-Wait loop timed out on Acer Squirtle_SR laptop
https://bugs.freedesktop.org/show_bug.cgi?id=110360 --- Comment #2 from Alex Deucher --- Does booting with amdgpu.runpm=0 on the kernel command line in grub help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] mmu notifier provide context informations
Andrew anything blocking this for 5.2 ? Should i ask people (ie the end user of this) to re-ack v6 (it is the same as previous version just rebase and dropped kvm bits). On Tue, Mar 26, 2019 at 12:47:39PM -0400, jgli...@redhat.com wrote: > From: Jérôme Glisse > > (Andrew this apply on top of my HMM patchset as otherwise you will have > conflict with changes to mm/hmm.c) > > Changes since v5: > - drop KVM bits waiting for KVM people to express interest if they > do not then i will post patchset to remove change_pte_notify as > without the changes in v5 change_pte_notify is just useless (it > it is useless today upstream it is just wasting cpu cycles) > - rebase on top of lastest Linus tree > > Previous cover letter with minor update: > > > Here i am not posting users of this, they already have been posted to > appropriate mailing list [6] and will be merge through the appropriate > tree once this patchset is upstream. > > Note that this serie does not change any behavior for any existing > code. It just pass down more information to mmu notifier listener. > > The rational for this patchset: > > CPU page table update can happens for many reasons, not only as a > result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) > but also as a result of kernel activities (memory compression, reclaim, > migration, ...). > > This patch introduce a set of enums that can be associated with each > of the events triggering a mmu notifier: > > - UNMAP: munmap() or mremap() > - CLEAR: page table is cleared (migration, compaction, reclaim, ...) > - PROTECTION_VMA: change in access protections for the range > - PROTECTION_PAGE: change in access protections for page in the range > - SOFT_DIRTY: soft dirtyness tracking > > Being able to identify munmap() and mremap() from other reasons why the > page table is cleared is important to allow user of mmu notifier to > update their own internal tracking structure accordingly (on munmap or > mremap it is not longer needed to track range of virtual address as it > becomes invalid). Without this serie, driver are force to assume that > every notification is an munmap which triggers useless trashing within > drivers that associate structure with range of virtual address. Each > driver is force to free up its tracking structure and then restore it > on next device page fault. With this serie we can also optimize device > page table update [6]. > > More over this can also be use to optimize out some page table updates > like for KVM where we can update the secondary MMU directly from the > callback instead of clearing it. > > ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395 > ACKS RDMA https://lkml.org/lkml/2018/12/6/1473 > > Cheers, > Jérôme > > [1] v1 https://lkml.org/lkml/2018/3/23/1049 > [2] v2 https://lkml.org/lkml/2018/12/5/10 > [3] v3 https://lkml.org/lkml/2018/12/13/620 > [4] v4 https://lkml.org/lkml/2019/1/23/838 > [5] v5 https://lkml.org/lkml/2019/2/19/752 > [6] patches to use this: > https://lkml.org/lkml/2019/1/23/833 > https://lkml.org/lkml/2019/1/23/834 > https://lkml.org/lkml/2019/1/23/832 > https://lkml.org/lkml/2019/1/23/831 > > Cc: Andrew Morton > Cc: linux...@kvack.org > Cc: Christian König > Cc: Joonas Lahtinen > Cc: Jani Nikula > Cc: Rodrigo Vivi > Cc: Jan Kara > Cc: Andrea Arcangeli > Cc: Peter Xu > Cc: Felix Kuehling > Cc: Jason Gunthorpe > Cc: Ross Zwisler > Cc: Dan Williams > Cc: Paolo Bonzini > Cc: Alex Deucher > Cc: Radim Krčmář > Cc: Michal Hocko > Cc: Christian Koenig > Cc: Ben Skeggs > Cc: Ralph Campbell > Cc: John Hubbard > Cc: k...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-r...@vger.kernel.org > Cc: Arnd Bergmann > > Jérôme Glisse (8): > mm/mmu_notifier: helper to test if a range invalidation is blockable > mm/mmu_notifier: convert user range->blockable to helper function > mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags > mm/mmu_notifier: contextual information for event enums > mm/mmu_notifier: contextual information for event triggering > invalidation v2 > mm/mmu_notifier: use correct mmu_notifier events for each invalidation > mm/mmu_notifier: pass down vma and reasons why mmu notifier is > happening v2 > mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper > > drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 8 ++-- > drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +- > drivers/gpu/drm/radeon/radeon_mn.c | 4 +- > drivers/infiniband/core/umem_odp.c | 5 +- > drivers/xen/gntdev.c| 6 +-- > fs/proc/task_mmu.c | 3 +- > include/linux/mmu_notifier.h| 63 +++-- > kernel/events/uprobes.c | 3 +- > mm/hmm.c| 6 +-- > mm/huge_memory.c| 14 +++--- > mm/hugetlb.c| 12 +++-- >
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote: > Once I pre-configure the colorkey, am I able to enable and disable it? If > colorkey can be enabled/disabled after that might meet my requirement Not atomically with other updates. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 8:57 AM > To: Jim Zhang > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > Villie: > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > to review and release? > > > > There is no real plan at this time. But if you have a use case for it > > I can try to harass people until someone reviews it :) > > > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > > product, could it be atomic for Baytrail only? > > > > No. We would need to define a new api for it. > > I should clarify that you can pre-configure the colorkey before turning on > the sprite plane(s). So unless you really need to change the colorkey while > the sprite plane(s) are already enabled you may not even need an atomic api > for this. > > > > > > > > > Thanks, > > > > > > Jim > > > > > > > > > Caterpillar: Confidential Green > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > To: Jim Zhang > > > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > Hi Sir/Madam: > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > Linux kernel version 3.10.61: > > > > Libdrm package: 2.4.97 > > > > > > > > When calling function > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > This property is: > > > > property->name = "rotation", property->prop_id =4 It looks like > > > > that the Baytrail gpu drm driver does not support colorkey. > > > > > > There are two problems currently: > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > patches for it but they have not been reviewed by anyone: > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freed > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-s > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9 > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50 > > > PX79myDO5gEYA= > > > - Colorkey can only be set via a custom i915 specific ioctl > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > a generic property based API that never really went anywhere. It's > > > a rather difficult problem making this generic as each hardware has > > > its own peculiar way of specifying colorkeying. The main problem > > > with the custom ioctl is that it's not atomic with other screen > > > updates. > > > > > > So, what kind of use case do you have in mind? > > > > > > -- > > > Ville Syrjälä > > > Intel > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop > > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m > > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=Oyn > > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzNPQ > > cu3xTPSCqb5Dnpwk= > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 01:59:21PM +, Jim Zhang wrote: > Nice, do you have any sample code for it? https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/sna/sna_video_sprite.c is the only userspace code we have that uses the colorkey. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 9, 2019 8:57 AM > To: Jim Zhang > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: Re: [Intel-gfx] colorkey support for intel i915 gpu driver > > On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > > Villie: > > > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan > > > to review and release? > > > > There is no real plan at this time. But if you have a use case for it > > I can try to harass people until someone reviews it :) > > > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > > product, could it be atomic for Baytrail only? > > > > No. We would need to define a new api for it. > > I should clarify that you can pre-configure the colorkey before turning on > the sprite plane(s). So unless you really need to change the colorkey while > the sprite plane(s) are already enabled you may not even need an atomic api > for this. > > > > > > > > > Thanks, > > > > > > Jim > > > > > > > > > Caterpillar: Confidential Green > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, April 2, 2019 7:32 AM > > > To: Jim Zhang > > > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > > > Subject: Re: colorkey support for intel i915 gpu driver > > > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > > Hi Sir/Madam: > > > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > > > Linux kernel version 3.10.61: > > > > Libdrm package: 2.4.97 > > > > > > > > When calling function > > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > > > This property is: > > > > property->name = "rotation", property->prop_id =4 It looks like > > > > that the Baytrail gpu drm driver does not support colorkey. > > > > > > There are two problems currently: > > > - Destination colorkey is not implemented on BYT/CHV. I have > > > patches for it but they have not been reviewed by anyone: > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freed > > > esktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-s > > > Ep8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9 > > > ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50 > > > PX79myDO5gEYA= > > > - Colorkey can only be set via a custom i915 specific ioctl > > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > > a generic property based API that never really went anywhere. It's > > > a rather difficult problem making this generic as each hardware has > > > its own peculiar way of specifying colorkeying. The main problem > > > with the custom ioctl is that it's not atomic with other screen > > > updates. > > > > > > So, what kind of use case do you have in mind? > > > > > > -- > > > Ville Syrjälä > > > Intel > > > > -- > > Ville Syrjälä > > Intel > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop > > .org_mailman_listinfo_intel-2Dgfx=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m > > 9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=Oyn > > sqGRzmnTMX2pxog1nBd_nnCa413-CM6loSIjLXXo=fjXVFmFDB_LEKe_W5PHzmzkzNPQ > > cu3xTPSCqb5Dnpwk= > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110360] AMD system hits AMD-Vi: Completion-Wait loop timed out on Acer Squirtle_SR laptop
https://bugs.freedesktop.org/show_bug.cgi?id=110360 Alex Deucher changed: What|Removed |Added Attachment #143905|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote: > On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > > Villie: > > > > What is Intel's plan for the colorkey patch? Does Intel have any plan to > > review and release? > > There is no real plan at this time. But if you have a use case > for it I can try to harass people until someone reviews it :) > > > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > > product, could it be atomic for Baytrail only? > > No. We would need to define a new api for it. I should clarify that you can pre-configure the colorkey before turning on the sprite plane(s). So unless you really need to change the colorkey while the sprite plane(s) are already enabled you may not even need an atomic api for this. > > > > > Thanks, > > > > Jim > > > > > > Caterpillar: Confidential Green > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, April 2, 2019 7:32 AM > > To: Jim Zhang > > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > > Subject: Re: colorkey support for intel i915 gpu driver > > > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > > Hi Sir/Madam: > > > > > > I am using the open source Baytrail gpu drm driver. > > > > > > Linux kernel version 3.10.61: > > > Libdrm package: 2.4.97 > > > > > > When calling function > > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > > > This property is: > > > property->name = "rotation", property->prop_id =4 It looks like that > > > the Baytrail gpu drm driver does not support colorkey. > > > > There are two problems currently: > > - Destination colorkey is not implemented on BYT/CHV. I have > > patches for it but they have not been reviewed by anyone: > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50PX79myDO5gEYA= > > - Colorkey can only be set via a custom i915 specific ioctl > > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > > a generic property based API that never really went anywhere. It's > > a rather difficult problem making this generic as each hardware has > > its own peculiar way of specifying colorkeying. The main problem > > with the custom ioctl is that it's not atomic with other screen > > updates. > > > > So, what kind of use case do you have in mind? > > > > -- > > Ville Syrjälä > > Intel > > -- > Ville Syrjälä > Intel > ___ > 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: colorkey support for intel i915 gpu driver
On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote: > Villie: > > What is Intel's plan for the colorkey patch? Does Intel have any plan to > review and release? There is no real plan at this time. But if you have a use case for it I can try to harass people until someone reviews it :) > If I go with custom ioctl, and my custom ioctl will only used in Baytrail > product, could it be atomic for Baytrail only? No. We would need to define a new api for it. > > Thanks, > > Jim > > > Caterpillar: Confidential Green > > -Original Message- > From: Ville Syrjälä > Sent: Tuesday, April 2, 2019 7:32 AM > To: Jim Zhang > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > Subject: Re: colorkey support for intel i915 gpu driver > > On Mon, Apr 01, 2019 at 08:18:13PM +, Jim Zhang wrote: > > Hi Sir/Madam: > > > > I am using the open source Baytrail gpu drm driver. > > > > Linux kernel version 3.10.61: > > Libdrm package: 2.4.97 > > > > When calling function > > properties = drmModeObjectGetProperties(drmfd, plane_id, > > DRM_MODE_OBJECT_PLANE); it only returns only one property: > > > > This property is: > > property->name = "rotation", property->prop_id =4 It looks like that > > the Baytrail gpu drm driver does not support colorkey. > > There are two problems currently: > - Destination colorkey is not implemented on BYT/CHV. I have > patches for it but they have not been reviewed by anyone: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_series_43902_=DwIDAw=p0oa49nxxGtbbM2qgM-GB4r4m9OlGg-sEp8sXylY2aQ=kszNssoSc2KF2GeTYwo7za6kdvLoemctuEIYtXbA4PI=ztfgUCy9ePzHa0zagoDF75AfJJVbElfjXUWmbpBRM58=aXK10RLMgC4i_nBRGS6Jzzbv3pXo50PX79myDO5gEYA= > - Colorkey can only be set via a custom i915 specific ioctl > (DRM_I915_SET_SPRITE_COLORKEY). There have been a few attempts at > a generic property based API that never really went anywhere. It's > a rather difficult problem making this generic as each hardware has > its own peculiar way of specifying colorkeying. The main problem > with the custom ioctl is that it's not atomic with other screen > updates. > > So, what kind of use case do you have in mind? > > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Am 08.04.19 um 13:59 schrieb Thomas Zimmermann: [SNIP] > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Since everybody vital seems to be on this mail thread anyway, let's use it a bit for brain storming what a possible replacement for TTM should look like. Well for simple drivers like qemu/bochs and cirrus the answer is to not use it at all. E.g. VRAM is only used for scanout and unprivileged userspace should not mess with it at all. In this case we don't need dynamic eviction and so also don't need TTM. That leaves us with the more complex drivers, like radeon, amdgpu, nouveu and maybe some of the ARM based stuff, with vmwgfx being a bit special here. Now I can summarize the requirements for at least the amdgpu in the following way: 1. We need to be able to allocate memory objects in different locations. 2. We need to be able to move around memory objects between different locations. 3. We need some LRU component which tells us what to evict when memory in a location becomes to tight. Now for lessons learned we should at least avoid the following design pitfalls: A) DON'T make it a layered design! Layers are for making cake, not software. B) DON'T make it a "Eierlegende Wollmilchsau" (German saying). E.g. don't try to solve every single corner cases in one piece of software. Let's make components which solve one specific problem. C) Pipeline everything! E.g. the hardware we deal with is asynchronous by design. Blocking for the hardware to finish in the common components itself is an absolutely no-go. If a driver wants to do something synchronous it should wait itself. Those comments where not really intended for you Thomas, but I had to write them down somewhere :) Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110370] Rendering artifacts in Enter The Gungeon on Both RX 590 and Radeon 7
https://bugs.freedesktop.org/show_bug.cgi?id=110370 --- Comment #1 from Ryan Houdek --- Some additional information. If you change their lighting model from High to Low in the video settings then the corruption goes away, but this is obviously less than ideal. Definitely something to do with that shading pass though. -- 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: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
Hi Ondřej Jirman, On Tue, Apr 9, 2019 at 5:01 PM Ondřej Jirman wrote: > > Hi Jagan, > > On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote: > > Based on the conversation about using common dtsi from this thread[1], > > I'm commenting here to make show the diff directly on the nodes, > > giving comments on each node so-that we can see the diff globally. > > Thanks for the suggestions below. It mostly repeats the differences and > commonalities I already stated in the previous discussion. > > I don't have much to add to what I already said previously, though, because > you > didn't address my concerns there. But I can restate and expand on those > concerns. > > Previously I already agreed it's possible to base orangepi-3.dts on > orangepi.dtsi, and proposed a maintainable way forward, and why to follow it > (to > quote myself): > > Schematics allow for high amount of variability in the power tree (see all > the > NC (not connected) / 0R resistors) in the schematic around AXP805. Every > board > based on this Xunlong design can be subtly different. Well, how about defining them in required dts file and group it common regulators in dtsi? The idea of all these 3 H6 OPI boards are evaluated in the same design consideration by adding new IP's in new boards design by keeping the core things common like lite2 has wifi, one plus has emac and 3 has PCIe etc. This is what I got from Steven(OrangePI). > > I already suggested a maintainable solution, below. Where base dtsi has > empty > config for regulators and every board based on that just defines it > completely > for itself. > > A few regulators (for CPU/GPU) will most probably have the same meaning on > every derived board, so these can probably be kept in dtsi without causing > too > much annoyance. > > It's unpleasant to have wrong regulator setup defined in an underlying dtsi, > and then trying to override it by removing/adding random properties in the > board dts for the new boards based on that, so that it fits. If we manage them properly by moving common things in dtsi and rest in dts, we may avoid these underlying issues. > > The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can > be > shared (as of now). > > My suggestion was this: > > So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd > have > to first move some things out of the base dtsi to the OrangePi Lite2 and One > Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe > HW that is *really* shared by these 2 boards and Orange Pi 3. > > If I do that, I'd undefine all the axp805 regulator nodes and move the > configurations to each of the 3 board files. That will probably end up being > the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for > what I mean. > > You seem to be suggesting a solution where every time we add an OrangePi H6 > based board, the person adding it will have to go through the base dtsi and > all > the other boards based on it, status disable or otherwise change regulators in > the base dtsi, patch all the other boards to re-enable it. > > It would be already unpleasant just adding a third board based on this > approach. > And when the fourth board is added, with another small differences in the > regulator use/meanings, the person will be looking at patching 4 dts files > + adding one for his own board. For what benefit, to save some bytes right > now? > > I think maintainability, ease of adding new boards is more important, than > having a dtsi that tries to maximally cover all the commonalities between the > existing boards right now, without regards for the future. That's why > I suggested an approach like in axp81x.dtsi lines 86-144. True, if the boards indeed are different but we can maintain easily if the boards are from same family of design based my experience and few boards do share common things in dtsi already. Anyway, thanks for inputs. Seems like patch is applied already may be we can move into dtsi if require in future. Thanks, Jagan. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110137] drirc adaptive sync, vrr, freesync blacklisting documentation
https://bugs.freedesktop.org/show_bug.cgi?id=110137 --- Comment #3 from Nicholas Kazlauskas --- I suppose that the issue with using realpath is while it's good at stripping args from chromium based browsers it'll have issues with programs run under script interpreters. Maybe the drirc needs a more advanced app path or name matching method to deal with cases like that. -- 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 110370] Rendering artifacts in Enter The Gungeon on Both RX 590 and Radeon 7
https://bugs.freedesktop.org/show_bug.cgi?id=110370 Bug ID: 110370 Summary: Rendering artifacts in Enter The Gungeon on Both RX 590 and Radeon 7 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: sonicadvan...@gmail.com QA Contact: dri-devel@lists.freedesktop.org I have rendering artifacts in Enter the Gungeon with RadeonSI. Bug was reproduced on both a Radeon 7 and an RX590 using Mesa git versions The game rendering is fairly simple and may not be too hard to track down. The rendering artifact is the shimmering around texture edges in the video I will provide. I've also attached a renderdoc capture of a frame in the game where the artifacting is occurring. Additionally the game is running very slowly due to massive amounts of futex usages, but I can trace back if those are coming game side or driver side. Video: https://drive.google.com/file/d/1NNA_lCY5FqzxpYtf1DIreZ8i7BKATTn9/view?usp=sharing RenderDoc capture: https://drive.google.com/file/d/1P1Dr2g4L8LpC7CBfVmriWX8X7F-mLx0w/view?usp=sharing -- 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 libdrm] headers: Sync with drm-next
On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > Generated using make headers_install from the drm-next
> > tree - git://anongit.freedesktop.org/drm/drm
> > branch - drm-next
> > commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
> >
> > The changes were as follows :-
> >
> > core: (drm.h, drm_fourcc.h, drm_mode.h)
> > - Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait'
> > and 'struct drm_syncobj_timeline_array'
> > - Added various DRM_IOCTL_SYNCOBJ_ ioctls
> > - Added some new RGB and YUV formats
> > - Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
> > - Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
> > - Added 'struct drm_mode_rect'
> >
> > i915:
> > - Added struct 'struct i915_user_extension' and various 'struct
> > drm_i915_gem_context_'
> > - Added different modes of per-process Graphics Translation Table
> >
> > msm:
> > - Added various get or set GEM buffer info flags
> > - Added some MSM_SUBMIT_BO_ macros
> > - Modified 'struct drm_msm_gem_info'
> >
> > Signed-off-by: Ayan Kumar halder
>
> This looks sane, and applies cleanly :)
> Acked-by: Eric Engestrom
Actually, revoking that, as this patch breaks the build; see below.
>
> > ---
> > include/drm/drm.h| 36 +++
> > include/drm/drm_fourcc.h | 136 +++
> > include/drm/drm_mode.h | 23 -
> > include/drm/i915_drm.h | 237
> > ---
> > include/drm/msm_drm.h| 25 +++--
> > 5 files changed, 415 insertions(+), 42 deletions(-)
> >
[snip]
> > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > index c06d0a5..91a16b3 100644
> > --- a/include/drm/msm_drm.h
> > +++ b/include/drm/msm_drm.h
> > @@ -105,14 +105,24 @@ struct drm_msm_gem_new {
> > __u32 handle; /* out */
> > };
> >
> > -#define MSM_INFO_IOVA 0x01
> > -
> > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > +/* Get or set GEM buffer info. The requested value can be passed
> > + * directly in 'value', or for data larger than 64b 'value' is a
> > + * pointer to userspace buffer, with 'len' specifying the number of
> > + * bytes copied into that buffer. For info returned by pointer,
> > + * calling the GEM_INFO ioctl with null 'value' will return the
> > + * required buffer size in 'len'
> > + */
> > +#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset, returned
> > by value */
> > +#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
> > +#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer) */
> > +#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by pointer */
> >
> > struct drm_msm_gem_info {
> > __u32 handle; /* in */
> > - __u32 flags; /* in - combination of MSM_INFO_* flags */
> > - __u64 offset; /* out, mmap() offset or iova */
> > + __u32 info; /* in - one of MSM_INFO_* */
> > + __u64 value; /* in or out */
> > + __u32 len;/* in or out */
> > + __u32 pad;
freedreno/msm/msm_bo.c needs to be updated to reflect those changes.
> > };
> >
> > #define MSM_PREP_READ0x01
> > @@ -188,8 +198,11 @@ struct drm_msm_gem_submit_cmd {
> > */
> > #define MSM_SUBMIT_BO_READ 0x0001
> > #define MSM_SUBMIT_BO_WRITE0x0002
> > +#define MSM_SUBMIT_BO_DUMP 0x0004
> >
> > -#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ |
> > MSM_SUBMIT_BO_WRITE)
> > +#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
> > + MSM_SUBMIT_BO_WRITE | \
> > + MSM_SUBMIT_BO_DUMP)
> >
> > struct drm_msm_gem_submit_bo {
> > __u32 flags; /* in, mask of MSM_SUBMIT_BO_x */
> > --
> > 2.7.4
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
>
> Hi,
>
> On 09-04-19 11:47, Patrik Jakobsson wrote:
> > On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
> >>
> >> Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
> >> Specifically this happens on the Thecus N2800 / N5550 NAS models.
> >>
> >> This commit adds a LVDS blacklist to deal with this and adds an entry for
> >> the Thecus NAS-es.
> >
> > Hi Hans,
> > Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
> > check that it's not just a bad BIOS configuration first?
>
> I've asked the reporter to test, but even if there is a BIOS option it
> seems that the BIOS default setting is wrong and we cannot expect every
> user to go into the BIOS to fix a wrong BIOS setting.
>
> According to this blogpost, which is about the Linux the device ships with:
> https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html
>
> The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
> commandline, so this clearly seems to be a case where the system is just
> shipping with a broken BIOS or at least with default BIOS settings which
> is just as bad.
I agree that we should try to fix a broken default but are you sure
this will only affect the n5550? IIUC Milstead / Granite Well is an
Intel product / board name and perhaps some of those use LVDS.
Also, if the pre-installed OS solves this on the cmdline then it's
only a problem if the user is trying to install a custom OS on the
device. I would expect such a user to be able to change bios settings.
I'm not totally against this but not sure about the consequences. Is
there perhaps a better dmi string to match against?
>
> Regards,
>
> Hans
>
>
>
> >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> >> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> >> index de9531caaca0..268643af114c 100644
> >> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> >> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> >> @@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device
> >> *dev,
> >> return false;
> >> }
> >>
> >> +static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
> >> + {
> >> + /* Thecus N2800 and N5550 family NAS-es */
> >> + .matches = {
> >> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel
> >> Corporation"),
> >> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead
> >> Platform"),
> >> + DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
> >> + /* BIOS version is CDV_T X64 */
> >> + DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
> >> + },
> >> + },
> >> + {}
> >> +};
> >> +
> >> /**
> >>* cdv_intel_lvds_init - setup LVDS connectors on this device
> >>* @dev: drm device
> >> @@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
> >> int pipe;
> >> u8 pin;
> >>
> >> + /*
> >> +* Check blacklist for machines with BIOSes that list an LVDS panel
> >> +* without actually having one.
> >> +*/
> >> + if (dmi_check_system(cdv_intel_lvds_blacklist)) {
> >> + dev_info(>pdev->dev, "System is on LVDS blacklist,
> >> skipping LVDS panel detection\n");
> >> + return;
> >> + }
> >> +
> >> pin = GMBUS_PORT_PANEL;
> >> if (!lvds_is_present_in_vbt(dev, )) {
> >> DRM_DEBUG_KMS("LVDS is not present in VBT\n");
> >> --
> >> 2.21.0
> >>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Tue, Apr 09, 2019 at 11:33:04AM +0200, Ondřej Jirman wrote:
> On Tue, Apr 09, 2019 at 10:12:30AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 02:24:41AM +0200, meg...@megous.com wrote:
> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins>;
> >
> > Since 5 minutes ago, that's now the default.
>
> Ah. :)
>
> > > + {
> > > + /*
> > > + * Beware that this board will not automatically disconnect
> > > + * VBUS from DCIN, when self-powered and used as a peripheral.
> > > + */
> > > + dr_mode = "otg";
> > > + status = "okay";
> > > +};
> >
> > As we were discussing, I guess leaving it as host is the safest
> > option.
> >
> > I can fix both issues while applying if that's ok for you.
>
> It's ok with me. Thank you.
Done, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: add convert_lines_toio() variant, fix cirrus builds on powerpc.
The __io_virt() macro is not available on all architectures, so cirrus
can't simply pass a pointer to io memory down to the format conversion
helpers. The format conversion helpers must use memcpy_toio() instead.
Add a convert_lines_toio() variant which does just that. Switch the
drm_fb_*_dstclip() functions used by cirrus to accept a __iomem pointer
as destination and pass that down to convert_lines_toio(). Fix the
calls in the cirrus driver to not use __io_virt() any more.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_format_helper.h | 9 ++--
drivers/gpu/drm/cirrus/cirrus.c | 6 +--
drivers/gpu/drm/drm_format_helper.c | 74 ++---
3 files changed, 67 insertions(+), 22 deletions(-)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 6f84380757ee..3532b76c2340 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -15,17 +15,20 @@ struct drm_rect;
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
-void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct drm_framebuffer *fb,
+void drm_fb_memcpy_dstclip(void __iomem *dst, void *vaddr,
+ struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap);
-void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned int dst_pitch,
+void drm_fb_xrgb_to_rgb565_dstclip(void __iomem *dst,
+ unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap);
-void drm_fb_xrgb_to_rgb888_dstclip(void *dst, unsigned int dst_pitch,
+void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst,
+ unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
index 5095b8ce52c2..be4ea370ba31 100644
--- a/drivers/gpu/drm/cirrus/cirrus.c
+++ b/drivers/gpu/drm/cirrus/cirrus.c
@@ -307,16 +307,16 @@ static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
return -ENOMEM;
if (cirrus->cpp == fb->format->cpp[0])
- drm_fb_memcpy_dstclip(__io_virt(cirrus->vram),
+ drm_fb_memcpy_dstclip(cirrus->vram,
vmap, fb, rect);
else if (fb->format->cpp[0] == 4 && cirrus->cpp == 2)
- drm_fb_xrgb_to_rgb565_dstclip(__io_virt(cirrus->vram),
+ drm_fb_xrgb_to_rgb565_dstclip(cirrus->vram,
cirrus->pitch,
vmap, fb, rect, false);
else if (fb->format->cpp[0] == 4 && cirrus->cpp == 3)
- drm_fb_xrgb_to_rgb888_dstclip(__io_virt(cirrus->vram),
+ drm_fb_xrgb_to_rgb888_dstclip(cirrus->vram,
cirrus->pitch,
vmap, fb, rect);
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 01d9ea134618..6a759cbaa263 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -11,6 +11,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -125,6 +127,30 @@ static void convert_lines(void *dst, unsigned int
dst_pitch,
kfree(sbuf);
}
+static void convert_lines_toio(void __iomem *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int pixels,
+ unsigned int lines,
+ struct drm_format_convert *conv)
+{
+ u32 dst_linelength = pixels * conv->dst_cpp;
+ u32 y;
+ void *dbuf;
+
+ dbuf = kmalloc(dst_linelength, GFP_KERNEL);
+ if (!dbuf)
+ return;
+
+ for (y = 0; y < lines; y++) {
+ conv->func(dbuf, src, pixels);
+ memcpy_toio(dst, dbuf, dst_linelength);
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+
+ kfree(dbuf);
+}
+
static u32 clip_offset(struct drm_rect *clip, u32 pitch, u32 cpp)
{
return (clip->y1 * pitch) + (clip->x1 * cpp);
@@ -143,6 +169,19 @@ static void drm_fb_memcpy_lines(void *dst, unsigned int
dst_pitch,
}
}
+static
Re: [PATCH libdrm] headers: Sync with drm-next
On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> Generated using make headers_install from the drm-next
> tree - git://anongit.freedesktop.org/drm/drm
> branch - drm-next
> commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
>
> The changes were as follows :-
>
> core: (drm.h, drm_fourcc.h, drm_mode.h)
> - Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
> 'struct drm_syncobj_timeline_array'
> - Added various DRM_IOCTL_SYNCOBJ_ ioctls
> - Added some new RGB and YUV formats
> - Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
> - Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
> - Added 'struct drm_mode_rect'
>
> i915:
> - Added struct 'struct i915_user_extension' and various 'struct
> drm_i915_gem_context_'
> - Added different modes of per-process Graphics Translation Table
>
> msm:
> - Added various get or set GEM buffer info flags
> - Added some MSM_SUBMIT_BO_ macros
> - Modified 'struct drm_msm_gem_info'
>
> Signed-off-by: Ayan Kumar halder
This looks sane, and applies cleanly :)
Acked-by: Eric Engestrom
> ---
> include/drm/drm.h| 36 +++
> include/drm/drm_fourcc.h | 136 +++
> include/drm/drm_mode.h | 23 -
> include/drm/i915_drm.h | 237
> ---
> include/drm/msm_drm.h| 25 +++--
> 5 files changed, 415 insertions(+), 42 deletions(-)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 85c685a..c893f3b 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -729,8 +729,18 @@ struct drm_syncobj_handle {
> __u32 pad;
> };
>
> +struct drm_syncobj_transfer {
> + __u32 src_handle;
> + __u32 dst_handle;
> + __u64 src_point;
> + __u64 dst_point;
> + __u32 flags;
> + __u32 pad;
> +};
> +
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
> #define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
> +#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time
> point to become available */
> struct drm_syncobj_wait {
> __u64 handles;
> /* absolute timeout */
> @@ -741,12 +751,33 @@ struct drm_syncobj_wait {
> __u32 pad;
> };
>
> +struct drm_syncobj_timeline_wait {
> + __u64 handles;
> + /* wait on specific timeline point for every handles*/
> + __u64 points;
> + /* absolute timeout */
> + __s64 timeout_nsec;
> + __u32 count_handles;
> + __u32 flags;
> + __u32 first_signaled; /* only valid when not waiting all */
> + __u32 pad;
> +};
> +
> +
> struct drm_syncobj_array {
> __u64 handles;
> __u32 count_handles;
> __u32 pad;
> };
>
> +struct drm_syncobj_timeline_array {
> + __u64 handles;
> + __u64 points;
> + __u32 count_handles;
> + __u32 pad;
> +};
> +
> +
> /* Query current scanout sequence number */
> struct drm_crtc_get_sequence {
> __u32 crtc_id; /* requested crtc_id */
> @@ -903,6 +934,11 @@ extern "C" {
> #define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
> drm_mode_get_lease)
> #define DRM_IOCTL_MODE_REVOKE_LEASE DRM_IOWR(0xC9, struct
> drm_mode_revoke_lease)
>
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
> drm_syncobj_timeline_wait)
> +#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
> drm_syncobj_timeline_array)
> +#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
> drm_syncobj_transfer)
> +#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct
> drm_syncobj_timeline_array)
> +
> /**
> * Device specific ioctls should only be in their respective headers
> * The device specific ioctl range is from 0x40 to 0x9f.
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 139632b..3feeaa3 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -144,6 +144,17 @@ extern "C" {
> #define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /*
> [31:0] R:G:B:A 10:10:10:2 little endian */
> #define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /*
> [31:0] B:G:R:A 10:10:10:2 little endian */
>
> +/*
> + * Floating point 64bpp RGB
> + * IEEE 754-2008 binary16 half-precision float
> + * [15:0] sign:exponent:mantissa 1:5:10
> + */
> +#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
> x:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
> x:B:G:R 16:16:16:16 little endian */
> +
> +#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> +#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0
[PATCH 3/4] drm: use convert_lines() in xrgb8888_to_rgb565 helpers.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 66 +
1 file changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index b8d17cd0a9f8..01d9ea134618 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -78,6 +78,25 @@ static struct drm_format_convert
convert_xrgb_to_rgb565_swap = {
.func = convert_xrgb_to_rgb565_swab_fn,
};
+static void convert_xrgb_to_rgb888_fn(void *dst, void *src, u32 pixels)
+{
+ u32 *sbuf = src;
+ u8 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 0;
+ *dbuf++ = (sbuf[x] & 0xFF00) >> 8;
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 16;
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb888 = {
+ .dst_cpp = 3,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb888_fn,
+};
+
static void convert_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int pixels,
@@ -259,35 +278,6 @@ void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned
int dst_pitch,
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_dstclip);
-static void drm_fb_xrgb_to_rgb888_lines(void *dst, unsigned int dst_pitch,
- void *src, unsigned int src_pitch,
- unsigned int src_linelength,
- unsigned int lines)
-{
- unsigned int linepixels = src_linelength / 3;
- unsigned int x, y;
- u32 *sbuf;
- u8 *dbuf;
-
- sbuf = kmalloc(src_linelength, GFP_KERNEL);
- if (!sbuf)
- return;
-
- for (y = 0; y < lines; y++) {
- memcpy(sbuf, src, src_linelength);
- dbuf = dst;
- for (x = 0; x < linepixels; x++) {
- *dbuf++ = (sbuf[x] & 0x00FF) >> 0;
- *dbuf++ = (sbuf[x] & 0xFF00) >> 8;
- *dbuf++ = (sbuf[x] & 0x00FF) >> 16;
- }
- src += src_pitch;
- dst += dst_pitch;
- }
-
- kfree(sbuf);
-}
-
/**
* drm_fb_xrgb_to_rgb888_dstclip - Convert XRGB to RGB888 clip buffer
* @dst: RGB565 destination buffer
@@ -307,15 +297,17 @@ void drm_fb_xrgb_to_rgb888_dstclip(void *dst,
unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
- unsigned int src_offset = (clip->y1 * fb->pitches[0])
- + (clip->x1 * sizeof(u32));
- unsigned int dst_offset = (clip->y1 * dst_pitch)
- + (clip->x1 * 3);
- size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
+ struct drm_format_convert *conv = _xrgb_to_rgb888;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ unsigned int dst_offset =
+ clip_offset(clip, dst_pitch, conv->dst_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- drm_fb_xrgb_to_rgb888_lines(dst + dst_offset, dst_pitch,
- vaddr + src_offset, fb->pitches[0],
- src_len, clip->y2 - clip->y1);
+ convert_lines(dst + dst_offset, dst_pitch,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: add generic convert_lines() function for format conversions.
Introduce some infrastructure to handle format conversions:
* New struct drm_format_convert containing the cpp for src
and dst with a function pointer to actually convert a
single scanline.
* generic convert_lines() function which uses a struct
drm_format_convert pointer to convert a rectangle.
drm_fb_swab16() has been switched over to the new
convert_lines() function as showcase.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 84 +
1 file changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 00d716f14173..f32e0173600c 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -16,6 +16,61 @@
#include
#include
+struct drm_format_convert {
+ u32 dst_cpp;
+ u32 src_cpp;
+ void (*func)(void *dst, void *src, u32 pixels);
+};
+
+static void convert_swab16_fn(void *dst, void *src, u32 pixels)
+{
+ u16 *sbuf = src;
+ u16 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++)
+ dbuf[x] = swab16(sbuf[16]);
+}
+
+static struct drm_format_convert convert_swab16 = {
+ .dst_cpp = 2,
+ .src_cpp = 2,
+ .func = convert_swab16_fn,
+};
+
+static void convert_lines(void *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int pixels,
+ unsigned int lines,
+ struct drm_format_convert *conv)
+{
+ u32 src_linelength = pixels * conv->src_cpp;
+ u32 y;
+ void *sbuf;
+
+ /*
+* The cma memory is write-combined so reads are uncached.
+* Speed up by fetching one line at a time.
+*/
+ sbuf = kmalloc(src_linelength, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ for (y = 0; y < lines; y++) {
+ memcpy(sbuf, src, src_linelength);
+ conv->func(dst, sbuf, pixels);
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+
+ kfree(sbuf);
+}
+
+static u32 clip_offset(struct drm_rect *clip, u32 pitch, u32 cpp)
+{
+ return (clip->y1 * pitch) + (clip->x1 * cpp);
+}
+
static void drm_fb_memcpy_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int linelength, unsigned int lines)
@@ -85,28 +140,15 @@ EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
- size_t len = (clip->x2 - clip->x1) * sizeof(u16);
- unsigned int x, y;
- u16 *src, *buf;
+ struct drm_format_convert *conv = _swab16;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
- buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return;
-
- for (y = clip->y1; y < clip->y2; y++) {
- src = vaddr + (y * fb->pitches[0]);
- src += clip->x1;
- memcpy(buf, src, len);
- src = buf;
- for (x = clip->x1; x < clip->x2; x++)
- *dst++ = swab16(*src++);
- }
-
- kfree(buf);
+ convert_lines(dst, pixels * conv->dst_cpp,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_swab16);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: fix cirrus build failure on powerpc
Turned out to be a bit more difficuilt than just adding the "asm/io.h" header files. Not all architectures actually have a __io_virt() macro, so cirrus can't depend on that. The drm format helpers have to call memcpy_toio instead. So this little series add support for that. Gerd Hoffmann (4): drm: add generic convert_lines() function for format conversions. drm: use convert_lines() in xrgb_to_rgb565 helpers. drm: use convert_lines() in xrgb_to_rgb565 helpers. drm: add convert_lines_toio() variant, fix cirrus builds on powerpc. include/drm/drm_format_helper.h | 9 +- drivers/gpu/drm/cirrus/cirrus.c | 6 +- drivers/gpu/drm/drm_format_helper.c | 329 +--- 3 files changed, 215 insertions(+), 129 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: use convert_lines() in xrgb8888_to_rgb565 helpers.
Also add two conversion functions for the swab / not swab cases.
That way we have to check the swab flag only once.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/drm_format_helper.c | 117 +++-
1 file changed, 62 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index f32e0173600c..b8d17cd0a9f8 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -38,6 +38,46 @@ static struct drm_format_convert convert_swab16 = {
.func = convert_swab16_fn,
};
+static void convert_xrgb_to_rgb565_fn(void *dst, void *src, u32 pixels)
+{
+ u32 *sbuf = src;
+ u16 *dbuf = dst;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ dbuf[x] = ((sbuf[x] & 0x00F8) >> 8) |
+ ((sbuf[x] & 0xFC00) >> 5) |
+ ((sbuf[x] & 0x00F8) >> 3);
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb565 = {
+ .dst_cpp = 2,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb565_fn,
+};
+
+static void convert_xrgb_to_rgb565_swab_fn(void *dst, void *src, u32
pixels)
+{
+ u32 *sbuf = src;
+ u16 *dbuf = dst;
+ u16 val16;
+ u32 x;
+
+ for (x = 0; x < pixels; x++) {
+ val16 = ((sbuf[x] & 0x00F8) >> 8) |
+ ((sbuf[x] & 0xFC00) >> 5) |
+ ((sbuf[x] & 0x00F8) >> 3);
+ dbuf[x] = swab16(val16);
+ }
+}
+
+static struct drm_format_convert convert_xrgb_to_rgb565_swap = {
+ .dst_cpp = 2,
+ .src_cpp = 4,
+ .func = convert_xrgb_to_rgb565_swab_fn,
+};
+
static void convert_lines(void *dst, unsigned int dst_pitch,
void *src, unsigned int src_pitch,
unsigned int pixels,
@@ -152,44 +192,6 @@ void drm_fb_swab16(u16 *dst, void *vaddr, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_swab16);
-static void drm_fb_xrgb_to_rgb565_lines(void *dst, unsigned int dst_pitch,
- void *src, unsigned int src_pitch,
- unsigned int src_linelength,
- unsigned int lines,
- bool swap)
-{
- unsigned int linepixels = src_linelength / sizeof(u32);
- unsigned int x, y;
- u32 *sbuf;
- u16 *dbuf, val16;
-
- /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
- sbuf = kmalloc(src_linelength, GFP_KERNEL);
- if (!sbuf)
- return;
-
- for (y = 0; y < lines; y++) {
- memcpy(sbuf, src, src_linelength);
- dbuf = dst;
- for (x = 0; x < linepixels; x++) {
- val16 = ((sbuf[x] & 0x00F8) >> 8) |
- ((sbuf[x] & 0xFC00) >> 5) |
- ((sbuf[x] & 0x00F8) >> 3);
- if (swap)
- *dbuf++ = swab16(val16);
- else
- *dbuf++ = val16;
- }
- src += src_pitch;
- dst += dst_pitch;
- }
-
- kfree(sbuf);
-}
-
/**
* drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
* @dst: RGB565 destination buffer
@@ -208,15 +210,17 @@ void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
- unsigned int src_offset = (clip->y1 * fb->pitches[0])
- + (clip->x1 * sizeof(u32));
- size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
- size_t dst_len = (clip->x2 - clip->x1) * sizeof(u16);
+ struct drm_format_convert *conv = swap
+ ? _xrgb_to_rgb565_swap
+ : _xrgb_to_rgb565;
+ unsigned int src_offset =
+ clip_offset(clip, fb->pitches[0], conv->src_cpp);
+ size_t pixels = (clip->x2 - clip->x1);
+ size_t lines = (clip->y2 - clip->y1);
- drm_fb_xrgb_to_rgb565_lines(dst, dst_len,
- vaddr + src_offset, fb->pitches[0],
- src_len, clip->y2 - clip->y1,
- swap);
+ convert_lines(dst, pixels * conv->dst_cpp,
+ vaddr + src_offset, fb->pitches[0],
+ pixels, lines, conv);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565);
@@ -239,16 +243,19 @@ void drm_fb_xrgb_to_rgb565_dstclip(void *dst,
unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
-
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Am 09.04.19 um 10:29 schrieb kra...@redhat.com: Hi, The qemu stdvga (bochs driver) has 16 MB vram by default and can be configured to have up to 256 MB. Plenty of room even for multiple 4k framebuffers if needed. So for the bochs driver all the ttm bo migration logic is not needed, it could just store everything in vram. To clarify I assume you mean it doesn't need the migrate each bo logic, but it still needs the when VRAM fills up migrate stuff logic. I think even the "when vram fills up" logic isn't that important. The driver has no acceleration so there is nothing to store beside dumb framebuffers, and the vram size can easily be increased if needed. Yeah, cause in this particular case it is not even real VRAM. In this case VRAM is backed by system memory which in turn is stolen from the host system isn't it? So just have enough for a framebuffer and don't place anything else in there. Regards, Christian. cheers, Gerd ___ 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: Need a pair decrement for fence's refcount if ttm_bo_add_move_fence failed?
Am 09.04.19 um 10:21 schrieb 易林:
>
>
>
>> Am 07.04.19 um 13:44 schrieb 易林:
>>> Hi, all:
>>> when analyzing v5.1 source code, I notice that in
>>> ttm_bo_add_move_fence,
>>> when reservation_object_reserve_shared failed and return ENOMEM,
>>> the fence's refcount increased without a pair decrement even after return
>>> to ttm_bo_add_move_fence's caller ttm_bo_mem_force_space:
>>>
>>> static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo,
>>> struct ttm_mem_type_manager *man,
>>> struct ttm_mem_reg *mem)
>>> {
>>> ..
>>> fence = dma_fence_get(man->move);
>>> spin_unlock(>move_lock);
>>>
>>> if (fence) {
>>> reservation_object_add_shared_fence(bo->resv, fence);
>>>
>>> ret = reservation_object_reserve_shared(bo->resv, 1);
>>> if (unlikely(ret))
>>> return ret;
>>>
>>> dma_fence_put(bo->moving);
>>> bo->moving = fence;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> can this lead to the imbalance of the fence's refcount? though the ENOMEN
>>> almost won't be trigger.
>> Yeah, the fence is leaked in the error path. Feel free to provide a
>> patch to fix this.
>>
>> Otherwise I will provide one in the next merge window.
>>
>> Thanks,
>> Christian.
>>
>>> Best Regards
>>>
>>> Lin Yi
> when I git clone your maintained subsystem from
> 'git://people.freedesktop.org/~agd5f/linux' provided on Maintainer list, why
> all the commits is below 2011?
>
> so where can I get the newest subsystem version?
That URL looks correct to me. Our development branch is
amd-staging-drm-next. No idea why you only see old commits.
See here for example:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
Alex updates that one from an internal server every few days.
Regards,
Christian.
>
> Thanks,
> Lin Yi.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Tue, Apr 09, 2019 at 01:31:57PM +0200, Ondřej Jirman wrote: > Hi Jagan, > > On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote: > > Based on the conversation about using common dtsi from this thread[1], > > I'm commenting here to make show the diff directly on the nodes, > > giving comments on each node so-that we can see the diff globally. > > Thanks for the suggestions below. It mostly repeats the differences and > commonalities I already stated in the previous discussion. > > I don't have much to add to what I already said previously, though, because > you > didn't address my concerns there. But I can restate and expand on those > concerns. > > Previously I already agreed it's possible to base orangepi-3.dts on > orangepi.dtsi, and proposed a maintainable way forward, and why to follow it > (to > quote myself): > > Schematics allow for high amount of variability in the power tree (see all > the > NC (not connected) / 0R resistors) in the schematic around AXP805. Every > board > based on this Xunlong design can be subtly different. > > I already suggested a maintainable solution, below. Where base dtsi has > empty > config for regulators and every board based on that just defines it > completely > for itself. > > A few regulators (for CPU/GPU) will most probably have the same meaning on > every derived board, so these can probably be kept in dtsi without causing > too > much annoyance. > > It's unpleasant to have wrong regulator setup defined in an underlying dtsi, > and then trying to override it by removing/adding random properties in the > board dts for the new boards based on that, so that it fits. > > The rest of the current HW descriptions in the sun50i-h6-orangepi.dtsi can > be > shared (as of now). > > My suggestion was this: > > So to base Orange Pi 3 dts on top of existing sun50i-h6-orangepi.dtsi I'd > have > to first move some things out of the base dtsi to the OrangePi Lite2 and One > Plus board dts files, in order to have sun50i-h6-orangepi.dtsi only describe > HW that is *really* shared by these 2 boards and Orange Pi 3. > > If I do that, I'd undefine all the axp805 regulator nodes and move the > configurations to each of the 3 board files. That will probably end up being > the least confusing and most maintainable. See axp81x.dtsi lines 86-144 for > what I mean. > > You seem to be suggesting a solution where every time we add an OrangePi H6 > based board, the person adding it will have to go through the base dtsi and > all > the other boards based on it, status disable or otherwise change regulators in > the base dtsi, patch all the other boards to re-enable it. > > It would be already unpleasant just adding a third board based on this > approach. > And when the fourth board is added, with another small differences in the > regulator use/meanings, the person will be looking at patching 4 dts files > + adding one for his own board. For what benefit, to save some bytes right > now? > > I think maintainability, ease of adding new boards is more important, than > having a dtsi that tries to maximally cover all the commonalities between the > existing boards right now, without regards for the future. That's why > I suggested an approach like in axp81x.dtsi lines 86-144. I agree. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait' and
'struct drm_syncobj_timeline_array'
- Added various DRM_IOCTL_SYNCOBJ_ ioctls
- Added some new RGB and YUV formats
- Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
- Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
- Added 'struct drm_mode_rect'
i915:
- Added struct 'struct i915_user_extension' and various 'struct
drm_i915_gem_context_'
- Added different modes of per-process Graphics Translation Table
msm:
- Added various get or set GEM buffer info flags
- Added some MSM_SUBMIT_BO_ macros
- Modified 'struct drm_msm_gem_info'
Signed-off-by: Ayan Kumar halder
---
include/drm/drm.h| 36 +++
include/drm/drm_fourcc.h | 136 +++
include/drm/drm_mode.h | 23 -
include/drm/i915_drm.h | 237 ---
include/drm/msm_drm.h| 25 +++--
5 files changed, 415 insertions(+), 42 deletions(-)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a..c893f3b 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+ __u32 src_handle;
+ __u32 dst_handle;
+ __u64 src_point;
+ __u64 dst_point;
+ __u32 flags;
+ __u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2) /* wait for time point
to become available */
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,33 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+ __u64 handles;
+ /* wait on specific timeline point for every handles*/
+ __u64 points;
+ /* absolute timeout */
+ __s64 timeout_nsec;
+ __u32 count_handles;
+ __u32 flags;
+ __u32 first_signaled; /* only valid when not waiting all */
+ __u32 pad;
+};
+
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+ __u64 handles;
+ __u64 points;
+ __u32 count_handles;
+ __u32 pad;
+};
+
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +934,11 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAITDRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERYDRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 139632b..3feeaa3 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
@@ -151,6 +162,52 @@ extern "C" {
#define DRM_FORMAT_VYUYfourcc_code('V', 'Y', 'U', 'Y') /*
[31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian */
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XYUVfourcc_code('X',
[Bug 110249] IGT command line tools load redundant GUI libraries
https://bugs.freedesktop.org/show_bug.cgi?id=110249
--- Comment #7 from Eero Tamminen ---
Following tools still link libigt:
-
for i in intel*; do
echo $i;
readelf -d $i | grep libigt;
done 2>/dev/null | awk '
/^intel/ {
name=$1
}
/NEEDED.*libigt.so/ {
print "-", name
}
'
- intel_audio_dump
- intel_backlight
- intel_display_crc
- intel_display_poller
- intel_dp_compliance
- intel_error_decode
- intel_firmware_decode
- intel_forcewaked
- intel_gem_info
- intel_gpu_frequency
- intel_gpu_time
- intel_gtt
- intel_guc_logger
- intel_gvtg_test
- intel_infoframes
- intel_l3_parity
- intel_lid
- intel_panel_fitter
- intel_perf_counters
- intel_reg
- intel_reg_checker
- intel_residency
- intel_stepping
- intel_vbt_decode
- intel_watermark
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
> -Original Message-
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Monday, April 08, 2019 9:13 PM
> To: Zhang, Jerry ; Huang, Ray
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
>
> When ttm_put_pages() tries to figure out whether it's dealing with
> transparent hugepages, it just reads past the bounds of the pages array
> without a check.
>
> v2: simplify the test if enough pages are left in the array (Christian).
>
> Signed-off-by: Jann Horn
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> Fixes: 5c42c64f7d54 ("drm/ttm: fix the fix for huge compound pages")
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index f841accc2c00..f77c81db161b 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -730,7 +730,8 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> }
>
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> - if (!(flags & TTM_PAGE_FLAG_DMA32)) {
> + if (!(flags & TTM_PAGE_FLAG_DMA32) &&
> + (npages - i) >= HPAGE_PMD_NR) {
> for (j = 0; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
> @@ -759,7 +760,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> unsigned max_size, n2free;
>
> spin_lock_irqsave(>lock, irq_flags);
> - while (i < npages) {
> + while ((npages - i) >= HPAGE_PMD_NR) {
> struct page *p = pages[i];
> unsigned j;
>
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/ttm: fix start page for huge page check in ttm_put_pages()
> -Original Message-
> From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
> Sent: Monday, April 08, 2019 9:13 PM
> To: Zhang, Jerry ; Huang, Ray
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH 2/2] drm/ttm: fix start page for huge page check in
> ttm_put_pages()
>
> The first page entry is always the same with itself.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index f77c81db161b..c74147f0cbe3 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -732,7 +732,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags, #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> if (!(flags & TTM_PAGE_FLAG_DMA32) &&
> (npages - i) >= HPAGE_PMD_NR) {
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
>
> @@ -767,7 +767,7 @@ static void ttm_put_pages(struct page **pages,
> unsigned npages, int flags,
> if (!p)
> break;
>
> - for (j = 0; j < HPAGE_PMD_NR; ++j)
> + for (j = 1; j < HPAGE_PMD_NR; ++j)
> if (p++ != pages[i + j])
> break;
>
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/lima: include used header file explicitly
Pushed to drm-misc-next.
Thanks,
Qiang
On Tue, Apr 9, 2019 at 8:37 AM Qiang Yu wrote:
>
> To prevent build fail on some platform which does
> not have it in the include file chain.
>
> Cc: Neil Armstrong
> Suggested-by: Randy Dunlap
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/lima_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
> index 2d3cf96f6c58..1d69498bc17e 100644
> --- a/drivers/gpu/drm/lima/lima_gem.c
> +++ b/drivers/gpu/drm/lima/lima_gem.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0 OR MIT
> /* Copyright 2017-2019 Qiang Yu */
>
> +#include
> #include
> #include
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/lima: add missing Kconfig dependency
Modify comments and pushed to drm-misc-next.
Thanks,
Qiang
On Tue, Apr 9, 2019 at 8:36 AM Qiang Yu wrote:
>
> Current implementation does not support MMU-less
> plarforms.
>
> Cc: Randy Dunlap
> Cc: Neil Armstrong
> Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs")
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/lima/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> index f11314448093..bb4ddc6bb0a6 100644
> --- a/drivers/gpu/drm/lima/Kconfig
> +++ b/drivers/gpu/drm/lima/Kconfig
> @@ -5,6 +5,9 @@ config DRM_LIMA
> tristate "LIMA (DRM support for ARM Mali 400/450 GPU)"
> depends on DRM
> depends on ARM || ARM64 || COMPILE_TEST
> + depends on MMU
> + depends on COMMON_CLK
> + depends on OF
> select DRM_SCHED
> help
> DRM driver for ARM Mali 400/450 GPUs.
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
Hi,
On 09-04-19 11:47, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically this happens on the Thecus N2800 / N5550 NAS models.
This commit adds a LVDS blacklist to deal with this and adds an entry for
the Thecus NAS-es.
Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?
I've asked the reporter to test, but even if there is a BIOS option it
seems that the BIOS default setting is wrong and we cannot expect every
user to go into the BIOS to fix a wrong BIOS setting.
According to this blogpost, which is about the Linux the device ships with:
https://astroweasel.blogspot.com/2016/02/updating-thecus-n5550-nas-to-report.html
The pre-installed grub config includes 'video=LVDS-1:d' on the kernel
commandline, so this clearly seems to be a case where the system is just
shipping with a broken BIOS or at least with default BIOS settings which
is just as bad.
Regards,
Hans
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index de9531caaca0..268643af114c 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device *dev,
return false;
}
+static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
+ {
+ /* Thecus N2800 and N5550 family NAS-es */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead Platform"),
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
+ /* BIOS version is CDV_T X64 */
+ DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
+ },
+ },
+ {}
+};
+
/**
* cdv_intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
int pipe;
u8 pin;
+ /*
+* Check blacklist for machines with BIOSes that list an LVDS panel
+* without actually having one.
+*/
+ if (dmi_check_system(cdv_intel_lvds_blacklist)) {
+ dev_info(>pdev->dev, "System is on LVDS blacklist, skipping
LVDS panel detection\n");
+ return;
+ }
+
pin = GMBUS_PORT_PANEL;
if (!lvds_is_present_in_vbt(dev, )) {
DRM_DEBUG_KMS("LVDS is not present in VBT\n");
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V10 0/5] make mt7623 clock of hdmi stable
Hi, Wangyan:
This version still has alignment problem, but I've fixed it and for this
series,
Applied to mediatek-drm-fixes-5.1 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.1
Regards,
CK
On Tue, 2019-04-09 at 14:53 +0800, wangyan wang wrote:
> From: Wangyan Wang
>
> V10 adopt maintainer's suggestion.
> Here is the change list between V9 & V10
>
> 1. Align the first character to the right of '(' in
> mtk_hdmi_phy_clk_get_data() of "drm/mediatek: remove flag ..."
> 2. Align the first character to the right of '(' in
> mtk_hdmi_pll_recalc_rate() of "drm/mediatek: make implementation ..."
> 3. Align the first character to the right of '(' in
> mtk_hdmi_pll_round_rate() of "drm/mediatek: no change ..."
> 4. move patch " drm/mediatek: make implementation ..." before
> patch "drm/mediatek: no change parent ..."
> 5. To make MT2701 HDMI stable, TVDPLL should not be adjusted and
> it's the parent clock of HDMI phy, so HDMI phy could not adjust parent
> rate. there are 3 steps to make MT2701 HDMI stable.
> 1). remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate
> rate change to parent in "drm/mediatek: remove flag ...".
> 2). Using new factor for tvdpll in mt2701 to match divider of DPI in
> mt2701 in "drm/mediatek: using new...".
> 3). No change parent rate in round_rate() for mt2701 hdmi phy in
> "drm/mediatek: no change parent...".
>
> 6. Recalculate the rate of this clock, by querying hardware to
> make implementation of recalc_rate() to match the definition.
>
> Wangyan Wang (5):
> drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy
> drm/mediatek: fix the rate and divder of hdmi phy for MT2701
> drm/mediatek: using new factor for tvdpll in MT2701
> drm/mediatek: make implementation of recalc_rate() to match the definition
> drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
>
> 03_27_ck.diff | 91
> drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +--
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 35 ++
> drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 5 +-
> drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 50 --
> drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
> patch1.diff| 75
> patch_5_4.diff | 95
> ++
> remove_parent_flag.diff| 75
> 9 files changed, 412 insertions(+), 45 deletions(-)
> create mode 100644 03_27_ck.diff
> create mode 100644 patch1.diff
> create mode 100644 patch_5_4.diff
> create mode 100644 remove_parent_flag.diff
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108919] Parkitect (Unity Game) dispalys artifacts and black screens with Vega hardware
https://bugs.freedesktop.org/show_bug.cgi?id=108919 --- Comment #13 from andrew.m.mcma...@gmail.com --- I thought I'd try this one out as I always loved Bullfrog's Theme Park back on my AMIGA 500+ -- Parkitect 1.3 -- I've captured a more up-to-date trace: (1.8GB) https://drive.google.com/open?id=1DaekuBy9fBdQr4ceqskx_5w2m5BDt_CV > Debian Testing > Linux-drm-fixes-5.1 > Mesa 19.1.0 (4e802089) https://tinyurl.com/mesacommit > Device: AMD Radeon R9 200 Series (TONGA, DRM 3.30.0, 5.1.0-rc1+, LLVM 8.0.0) The game appears to be quite playable now. Ambient occlusion appears to be the main cause of some heavy graphical glitches - which I've shown in my trace by lowering the slider. Alien Isolation is another game that suffers from glitches with HDAO enabled but otherwise works fine with it turned off. -- 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/gma500: Add CedarView LVDS blacklist
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
>
> Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
> Specifically this happens on the Thecus N2800 / N5550 NAS models.
>
> This commit adds a LVDS blacklist to deal with this and adds an entry for
> the Thecus NAS-es.
Hi Hans,
Sometimes LVDS can be configured in the BIOS on CDV devices. Can you
check that it's not just a bad BIOS configuration first?
Thanks
Patrik
>
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1665766
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index de9531caaca0..268643af114c 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -572,6 +572,20 @@ static bool lvds_is_present_in_vbt(struct drm_device
> *dev,
> return false;
> }
>
> +static const struct dmi_system_id cdv_intel_lvds_blacklist[] = {
> + {
> + /* Thecus N2800 and N5550 family NAS-es */
> + .matches = {
> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
> + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Milstead
> Platform"),
> + DMI_EXACT_MATCH(DMI_BOARD_NAME, "Granite Well"),
> + /* BIOS version is CDV_T X64 */
> + DMI_MATCH(DMI_BIOS_VERSION, "CDV_T"),
> + },
> + },
> + {}
> +};
> +
> /**
> * cdv_intel_lvds_init - setup LVDS connectors on this device
> * @dev: drm device
> @@ -594,6 +608,15 @@ void cdv_intel_lvds_init(struct drm_device *dev,
> int pipe;
> u8 pin;
>
> + /*
> +* Check blacklist for machines with BIOSes that list an LVDS panel
> +* without actually having one.
> +*/
> + if (dmi_check_system(cdv_intel_lvds_blacklist)) {
> + dev_info(>pdev->dev, "System is on LVDS blacklist,
> skipping LVDS panel detection\n");
> + return;
> + }
> +
> pin = GMBUS_PORT_PANEL;
> if (!lvds_is_present_in_vbt(dev, )) {
> DRM_DEBUG_KMS("LVDS is not present in VBT\n");
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 2/5] drm/bridge: add encoder support to specify bridge input format
Hi Laurent,
On 29/03/2019 11:42, Neil Armstrong wrote:
> This patch adds a new format_set() callback to the bridge ops permitting
> the encoder to specify the new input format and encoding.
Is this something better ? This doesn't violate the layering anymore,
do you have any thoughts about this new API ?
Neil
>
> This allows supporting the very specific HDMI2.0 YUV420 output mode
> when the bridge cannot convert from RGB or YUV444 to YUV420.
>
> In this case, the encode must downsample before the bridge and must
> specify the bridge the new input bus format differs.
>
> This will also help supporting the YUV420 mode where the bridge cannot
> downsample, and also support 10bit, 12bit and 16bit output modes
> when the bridge cannot convert between different bit depths.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/drm_bridge.c | 35 +++
> include/drm/drm_bridge.h | 19 +++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 138b2711d389..b2ce2d3d070e 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -307,6 +307,41 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> }
> EXPORT_SYMBOL(drm_bridge_mode_set);
>
> +/**
> + * drm_bridge_format_set - setup with proposed input format and encoding for
> + * all bridges in the encoder chain
> + * @bridge: bridge control structure
> + * @input_bus_format: proposed input bus format for the bridge
> + * @input_encoding: proposed input encoding for this bridge
> + *
> + * Calls _bridge_funcs.format_set op for all the bridges in the
> + * encoder chain, starting from the first bridge to the last.
> + *
> + * Note: the bridge passed should be the one closest to the encoder
> + *
> + * RETURNS:
> + * true on success, false if one of the bridge cannot handle the format
> + */
> +bool drm_bridge_format_set(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding)
> +{
> + bool ret = true;
> +
> + if (!bridge)
> + return true;
> +
> + if (bridge->funcs->format_set)
> + ret = bridge->funcs->format_set(bridge, input_bus_format,
> + input_encoding);
> + if (ret)
> + return ret;
> +
> + return drm_bridge_format_set(bridge->next, input_bus_format,
> + input_encoding);
> +}
> +EXPORT_SYMBOL(drm_bridge_format_set);
> +
> /**
> * drm_bridge_pre_enable - prepares for enabling all
> * bridges in the encoder chain
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 9da8c93f7976..223253b15763 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -198,6 +198,22 @@ struct drm_bridge_funcs {
> void (*mode_set)(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>const struct drm_display_mode *adjusted_mode);
> +
> + /**
> + * @format_set:
> + *
> + * This callback should configure the bridge for the given input bus
> + * format and encoding. It is called after the @format_set callback
> + * for the preceding element in the display pipeline has been called
> + * already. If the bridge is the first element then this would be
> + * _encoder_helper_funcs.format_set. The display pipe (i.e.
> + * clocks and timing signals) is off when this function is called.
> + *
> + * @returns: true in success, false is a bridge refuses the format
> + */
> + bool (*format_set)(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding);
> /**
>* @pre_enable:
>*
> @@ -312,6 +328,9 @@ void drm_bridge_post_disable(struct drm_bridge *bridge);
> void drm_bridge_mode_set(struct drm_bridge *bridge,
>const struct drm_display_mode *mode,
>const struct drm_display_mode *adjusted_mode);
> +bool drm_bridge_format_set(struct drm_bridge *bridge,
> +const u32 input_bus_format,
> +const u32 input_encoding);
> void drm_bridge_pre_enable(struct drm_bridge *bridge);
> void drm_bridge_enable(struct drm_bridge *bridge);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110362] Need an option to set HDMI out to Full RGB 4:4:4
https://bugs.freedesktop.org/show_bug.cgi?id=110362 Michel Dänzer changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com Component|Driver/AMDgpu |DRM/AMDgpu Product|xorg|DRI --- Comment #1 from Michel Dänzer --- This needs to be supported by the kernel driver (first), reassigning. (In reply to Heiko Lechner from comment #0) > In X.Org log file I find "AMDGPU(0): Supported color encodings: RGB 4:4:4 > YCrCb 4:4:4" so it seems to be possible. That's just Xorg itself printing information from EDID. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm/meson: Add G12A Video Clock setup
On 09/04/2019 10:46, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> While switching to the Common Clock Framework is still Work In Progress,
>> this patch adds the corresponding G12A HDMI PLL setup to be on-par
>> with the other SoCs support.
>>
>> The G12A has only a single tweak about the high frequency setup,
>> where the HDMI PLL needs a specific setup to handle correctly the
>> 5.94GHz DCO frequency.
>>
>> Apart that, it handle correctly all the other HDMI frequencies
>> and can achieve even better DMT clock frequency precision with
>> the larger fractional dividier width.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_vclk.c | 119 ++---
>> 1 file changed, 108 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_vclk.c
>> b/drivers/gpu/drm/meson/meson_vclk.c
>> index c15a5a5df633..b39034745444 100644
>> --- a/drivers/gpu/drm/meson/meson_vclk.c
>> +++ b/drivers/gpu/drm/meson/meson_vclk.c
>> @@ -113,9 +113,12 @@
>> #define HHI_HDMI_PLL_CNTL4 0x32C /* 0xcb offset in data sheet */
>> #define HHI_HDMI_PLL_CNTL5 0x330 /* 0xcc offset in data sheet */
>> #define HHI_HDMI_PLL_CNTL6 0x334 /* 0xcd offset in data sheet */
>> +#define HHI_HDMI_PLL_CNTL7 0x338 /* 0xce offset in data sheet */
>>
>> #define HDMI_PLL_RESET BIT(28)
>> +#define HDMI_PLL_RESET_G12A BIT(29)
>> #define HDMI_PLL_LOCK BIT(31)
>> +#define HDMI_PLL_LOCK_G12A (3 << 30)
>
> GENMASK(31, 30) ?
Ack
>
>>
>> #define FREQ_1000_1001(_freq) DIV_ROUND_CLOSEST(_freq * 1000, 1001)
>>
>> @@ -257,6 +260,10 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x71486980);
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x0e55);
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x4800023d);
>> +
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> + (val & HDMI_PLL_LOCK), 10, 0);
>> } else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
>> regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x427b);
>> @@ -271,11 +278,26 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> HDMI_PLL_RESET, HDMI_PLL_RESET);
>> regmap_update_bits(priv->hhi, HHI_HDMI_PLL_CNTL,
>> HDMI_PLL_RESET, 0);
>> -}
>>
>> -/* Poll for lock bit */
>> -regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> - (val & HDMI_PLL_LOCK), 10, 0);
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> + (val & HDMI_PLL_LOCK), 10, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL2, 0x0001);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL3, 0x);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL4, 0x6a28dc00);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL5, 0x65771290);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL6, 0x39272000);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL7, 0x5654);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x3a0504f7);
>> +regmap_write(priv->hhi, HHI_HDMI_PLL_CNTL, 0x1a0504f7);
>> +
>> +/* Poll for lock bit */
>> +regmap_read_poll_timeout(priv->hhi, HHI_HDMI_PLL_CNTL, val,
>> +((val & HDMI_PLL_LOCK_G12A) == HDMI_PLL_LOCK_G12A),
>> +10, 0);
>> +}
>>
>> /* Disable VCLK2 */
>> regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, 0);
>> @@ -288,8 +310,13 @@ static void meson_venci_cvbs_clock_config(struct
>> meson_drm *priv)
>> VCLK2_DIV_MASK, (55 - 1));
>>
>> /* select vid_pll for vclk2 */
>> -regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> -VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> +VCLK2_SEL_MASK, (0 << VCLK2_SEL_SHIFT));
>> +else
>> +regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
>> +VCLK2_SEL_MASK, (4 << VCLK2_SEL_SHIFT));
>> +
>> /* enable vclk2 gate */
>> regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, VCLK2_EN);
>>
>> @@ -476,32 +503,80 @@ void meson_hdmi_pll_set_params(struct meson_drm *priv,
>>
Re: [PATCH 06/11] drm/meson: Add G12A Support for the Overlay video plane
On 09/04/2019 10:42, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> Amlogic G12A SoC supports the same set of Video Planes, but now
>> are handled by the new OSD plane blender module.
>>
>> This patch uses the same VD1 plane for G12A, using the exact same scaler
>> and VD11 setup registers, except using the new blender register to
>> disable the plane.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_overlay.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_overlay.c
>> b/drivers/gpu/drm/meson/meson_overlay.c
>> index b54a22e483b9..bdbf925ff3e8 100644
>> --- a/drivers/gpu/drm/meson/meson_overlay.c
>> +++ b/drivers/gpu/drm/meson/meson_overlay.c
>> @@ -516,8 +516,14 @@ static void meson_overlay_atomic_disable(struct
>> drm_plane *plane,
>> priv->viu.vd1_enabled = false;
>>
>> /* Disable VD1 */
>> -writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
>> -priv->io_base + _REG(VPP_MISC));
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +writel_relaxed(0, priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
>> +writel_relaxed(0, priv->io_base + _REG(VD2_BLEND_SRC_CTRL));
>> +writel_relaxed(0, priv->io_base + _REG(VD1_IF0_GEN_REG +
>> 0x17b0));
>> +writel_relaxed(0, priv->io_base + _REG(VD2_IF0_GEN_REG +
>> 0x17b0));
>
> Is it possible to add a comment explaining this 0x17b0 value ?
It's the same register shift as in crtc, will add a define.
>
>> +} else
>> +writel_bits_relaxed(VPP_VD1_POSTBLEND | VPP_VD1_PREBLEND, 0,
>> +priv->io_base + _REG(VPP_MISC));
>>
>> }
>>
>
>
Will fix in a follow-up patch,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/11] drm/meson: Add G12A Support for VIU setup
On 09/04/2019 10:42, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> Amlogic G12A SoC needs a different VIU setup code,
>> handle it.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_viu.c | 72 ---
>> 1 file changed, 67 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_viu.c
>> b/drivers/gpu/drm/meson/meson_viu.c
>> index ac0f3687e09a..0169c98b01c9 100644
>> --- a/drivers/gpu/drm/meson/meson_viu.c
>> +++ b/drivers/gpu/drm/meson/meson_viu.c
>> @@ -90,6 +90,34 @@ static int eotf_bypass_coeff[EOTF_COEFF_SIZE] = {
>> EOTF_COEFF_RIGHTSHIFT /* right shift */
>> };
>>
>> +void meson_viu_set_g12a_osd1_matrix(struct meson_drm *priv, int *m,
>> + bool csc_on)
>> +{
>> +/* VPP WRAP OSD1 matrix */
>> +writel(((m[0] & 0xfff) << 16) | (m[1] & 0xfff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET0_1));
>> +writel(m[2] & 0xfff,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_PRE_OFFSET2));
>> +writel(((m[3] & 0x1fff) << 16) | (m[4] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF00_01));
>> +writel(((m[5] & 0x1fff) << 16) | (m[6] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF02_10));
>> +writel(((m[7] & 0x1fff) << 16) | (m[8] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF11_12));
>> +writel(((m[9] & 0x1fff) << 16) | (m[10] & 0x1fff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF20_21));
>> +writel((m[11] & 0x1fff) << 16,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_COEF22));
>> +
>> +writel(((m[18] & 0xfff) << 16) | (m[19] & 0xfff),
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET0_1));
>
> Can you define some of the masks and shifts above ? possibly the same define
> for all the registers I suppose ... maybe using FIELD_PREP ?
Ack
>
>> +writel(m[20] & 0xfff,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_OFFSET2));
>> +
>> +writel_bits_relaxed(BIT(0), csc_on ? BIT(0) : 0,
>> +priv->io_base + _REG(VPP_WRAP_OSD1_MATRIX_EN_CTRL));
>> +}
>> +
>> void meson_viu_set_osd_matrix(struct meson_drm *priv,
>>enum viu_matrix_sel_e m_select,
>>int *m, bool csc_on)
>> @@ -336,14 +364,24 @@ void meson_viu_init(struct meson_drm *priv)
>> if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
>> meson_viu_load_matrix(priv);
>> +else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +meson_viu_set_g12a_osd1_matrix(priv, RGB709_to_YUV709l_coeff,
>> + true);
>>
>> /* Initialize OSD1 fifo control register */
>> reg = BIT(0) | /* Urgent DDR request priority */
>> - (4 << 5) | /* hold_fifo_lines */
>> - (3 << 10) | /* burst length 64 */
>> - (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> - (2 << 22) | /* 4 words in 1 burst */
>> - (2 << 24);
>> + (4 << 5); /* hold_fifo_lines */
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu"))
>> +reg |= (1 << 10) | /* burst length 32 */
>> + (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> + (2 << 22) | /* 4 words in 1 burst */
>> + (2 << 24) |
>> + (1 << 31);
>> +else
>> +reg |= (3 << 10) | /* burst length 64 */
>> + (32 << 12) | /* fifo_depth_val: 32*8=256 */
>> + (2 << 22) | /* 4 words in 1 burst */
>> + (2 << 24);
>
> Could you use the BIT() macro and add some defines ?
Ack
>
>> writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
>> writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
>>
>> @@ -369,6 +407,30 @@ void meson_viu_init(struct meson_drm *priv)
>> writel_relaxed(0x00FF00C0,
>> priv->io_base + _REG(VD2_IF0_LUMA_FIFO_SIZE));
>>
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +writel_relaxed(4 << 29 |
>> +1 << 27 |
>> +1 << 26 | /* blend_din0 input to blend0 */
>> +1 << 25 | /* blend1_dout to blend2 */
>> +1 << 24 | /* blend1_din3 input to blend1 */
>> +1 << 20 |
>> +0 << 16 |
>> +1,
>> +priv->io_base + _REG(VIU_OSD_BLEND_CTRL));
>> +writel_relaxed(3 << 8 |
>> +1 << 20,
>> +priv->io_base + _REG(OSD1_BLEND_SRC_CTRL));
>> +writel_relaxed(1 << 20,
>> +
Re: [PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer
On 09/04/2019 10:44, Jerome Brunet wrote: > On Tue, 2019-04-09 at 10:43 +0200, Jerome Brunet wrote: >> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote: >>> The Meson G12A SoCs uses the exact same CVBS encoder except a simple >>> CVBS DAC register offset and settings delta. >>> >>> Signed-off-by: Neil Armstrong >>> --- >>> drivers/gpu/drm/meson/meson_venc.c | 11 +-- >>> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++--- >>> 2 files changed, 27 insertions(+), 9 deletions(-) > > ... and there is a typo in the patch title. s/Encoer/Encoder > Thanks for pointing this, I'll fix while applying. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/11] drm/meson: Add G12A support for CVBS Encoer
On 09/04/2019 10:43, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> The Meson G12A SoCs uses the exact same CVBS encoder except a simple
>> CVBS DAC register offset and settings delta.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_venc.c | 11 +--
>> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++---
>> 2 files changed, 27 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_venc.c
>> b/drivers/gpu/drm/meson/meson_venc.c
>> index 66d73a932d19..6faca7313339 100644
>> --- a/drivers/gpu/drm/meson/meson_venc.c
>> +++ b/drivers/gpu/drm/meson/meson_venc.c
>> @@ -73,7 +73,9 @@
>> /* HHI Registers */
>> #define HHI_GCLK_MPEG2 0x148 /* 0x52 offset in data sheet */
>> #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
>> +#define HHI_VDAC_CNTL0_G12A 0x2EC /* 0xbd offset in data sheet */
>> #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
>> +#define HHI_VDAC_CNTL1_G12A 0x2F0 /* 0xbe offset in data sheet */
>> #define HHI_HDMI_PHY_CNTL0 0x3a0 /* 0xe8 offset in data sheet */
>>
>> struct meson_cvbs_enci_mode meson_cvbs_enci_pal = {
>> @@ -1675,8 +1677,13 @@ void meson_venc_disable_vsync(struct meson_drm *priv)
>> void meson_venc_init(struct meson_drm *priv)
>> {
>> /* Disable CVBS VDAC */
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 8);
>> +} else {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +}
>>
>> /* Power Down Dacs */
>> writel_relaxed(0xff, priv->io_base + _REG(VENC_VDAC_SETTING));
>> diff --git a/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> b/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> index d622d817b6df..2c5341c881c4 100644
>> --- a/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> +++ b/drivers/gpu/drm/meson/meson_venc_cvbs.c
>> @@ -37,7 +37,9 @@
>>
>> /* HHI VDAC Registers */
>> #define HHI_VDAC_CNTL0 0x2F4 /* 0xbd offset in data sheet */
>> +#define HHI_VDAC_CNTL0_G12A 0x2EC /* 0xbd offset in data sheet */
>> #define HHI_VDAC_CNTL1 0x2F8 /* 0xbe offset in data sheet */
>> +#define HHI_VDAC_CNTL1_G12A 0x2F0 /* 0xbe offset in data sheet */
>>
>> struct meson_venc_cvbs {
>> struct drm_encoder encoder;
>> @@ -166,8 +168,13 @@ static void meson_venc_cvbs_encoder_disable(struct
>> drm_encoder *encoder)
>> struct meson_drm *priv = meson_venc_cvbs->priv;
>>
>> /* Disable CVBS VDAC */
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
>> +} else {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 8);
>
> I imagine 8 stands for BIT(3) ? Could you add a define to explain (quickly)
> what it is ?
Ack
>
>> +}
>> }
>>
>> static void meson_venc_cvbs_encoder_enable(struct drm_encoder *encoder)
>> @@ -179,13 +186,17 @@ static void meson_venc_cvbs_encoder_enable(struct
>> drm_encoder *encoder)
>> /* VDAC0 source is not from ATV */
>> writel_bits_relaxed(BIT(5), 0, priv->io_base + _REG(VENC_VDAC_DACSEL0));
>>
>> -if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu"))
>> +if (meson_vpu_is_compatible(priv, "amlogic,meson-gxbb-vpu")) {
>> regmap_write(priv->hhi, HHI_VDAC_CNTL0, 1);
>> -else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> - meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu"))
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-gxm-vpu") ||
>> + meson_vpu_is_compatible(priv, "amlogic,meson-gxl-vpu")) {
>> regmap_write(priv->hhi, HHI_VDAC_CNTL0, 0xf0001);
>> -
>> -regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1, 0);
>> +} else if (meson_vpu_is_compatible(priv, "amlogic,meson-g12a-vpu")) {
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL0_G12A, 0x906001);
>> +regmap_write(priv->hhi, HHI_VDAC_CNTL1_G12A, 0);
>> +}
>
> Maybe the values above are just magics taken from the vendor kernel, but if
> you can, it would be nice to break them down to help us understand what is
> controlled in these CTNL registers.
It's pretty magic values, but I'll do my best.
>
>> }
>>
>> static void meson_venc_cvbs_encoder_mode_set(struct drm_encoder *encoder,
Re: [PATCH 07/11] drm/meson: Add G12A support for plane handling in CRTC driver
On 09/04/2019 10:43, Jerome Brunet wrote:
> On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote:
>> This patch adds support for the new OSD+VD Plane blending module
>> in the CRTC code by adding the G12A code to manage the blending
>> module and setting the right OSD1 & VD1 plane registers.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_crtc.c | 269 +++--
>> drivers/gpu/drm/meson/meson_drv.h | 4 +
>> 2 files changed, 221 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
>> b/drivers/gpu/drm/meson/meson_crtc.c
>> index 6d9311e254ef..5579f8ac3e3f 100644
>> --- a/drivers/gpu/drm/meson/meson_crtc.c
>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
>> @@ -39,12 +39,17 @@
>> #include "meson_viu.h"
>> #include "meson_registers.h"
>>
>> +#define MESON_G12A_VIU_OFFSET 0x5ec0
>> +
>> /* CRTC definition */
>>
>> struct meson_crtc {
>> struct drm_crtc base;
>> struct drm_pending_vblank_event *event;
>> struct meson_drm *priv;
>> +void (*enable_osd1)(struct meson_drm *priv);
>> +void (*enable_vd1)(struct meson_drm *priv);
>> +unsigned int viu_offset;
>> };
>> #define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
>>
>> @@ -80,6 +85,44 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
>>
>> };
>>
>> +static void meson_g12a_crtc_atomic_enable(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +{
>> +struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> +struct drm_crtc_state *crtc_state = crtc->state;
>> +struct meson_drm *priv = meson_crtc->priv;
>> +
>> +DRM_DEBUG_DRIVER("\n");
>> +
>> +if (!crtc_state) {
>> +DRM_ERROR("Invalid crtc_state\n");
>> +return;
>> +}
>> +
>> +/* VD1 Preblend vertical start/end */
>> +writel(FIELD_PREP(GENMASK(11, 0), 2303),
>
> Could could define this mask somewhere
> I don't know if the 2303 can be explained. I'd nice if it could
It's a width, I'll add a comment.
>
>> + priv->io_base + _REG(VPP_PREBLEND_VD1_V_START_END));
>> +
>> +/* Setup Blender */
>> +writel(crtc_state->mode.hdisplay |
>> + crtc_state->mode.vdisplay << 16,
>> + priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
>> +
>> +writel_relaxed(0 << 16 |
>
> this 16 shift seems to be used for hdisplay or something. Could
> define/document it a bit
Ack
>
>> +(crtc_state->mode.hdisplay - 1),
>> +priv->io_base + _REG(VPP_OSD1_BLD_H_SCOPE));
>> +writel_relaxed(0 << 16 |
>> +(crtc_state->mode.vdisplay - 1),
>> +priv->io_base + _REG(VPP_OSD1_BLD_V_SCOPE));
>> +writel_relaxed(crtc_state->mode.hdisplay << 16 |
>> +crtc_state->mode.vdisplay,
>> +priv->io_base + _REG(VPP_OUT_H_V_SIZE));
>> +
>> +drm_crtc_vblank_on(crtc);
>> +
>> +priv->viu.osd1_enabled = true;
>> +}
>> +
>> static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
>> struct drm_crtc_state *old_state)
>> {
>> @@ -110,6 +153,31 @@ static void meson_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> priv->viu.osd1_enabled = true;
>> }
>>
>> +static void meson_g12a_crtc_atomic_disable(struct drm_crtc *crtc,
>> + struct drm_crtc_state *old_state)
>> +{
>> +struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> +struct meson_drm *priv = meson_crtc->priv;
>> +
>> +DRM_DEBUG_DRIVER("\n");
>> +
>> +drm_crtc_vblank_off(crtc);
>> +
>> +priv->viu.osd1_enabled = false;
>> +priv->viu.osd1_commit = false;
>> +
>> +priv->viu.vd1_enabled = false;
>> +priv->viu.vd1_commit = false;
>> +
>> +if (crtc->state->event && !crtc->state->active) {
>> +spin_lock_irq(>dev->event_lock);
>> +drm_crtc_send_vblank_event(crtc, crtc->state->event);
>> +spin_unlock_irq(>dev->event_lock);
>> +
>> +crtc->state->event = NULL;
>> +}
>> +}
>> +
>> static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
>>struct drm_crtc_state *old_state)
>> {
>> @@ -173,6 +241,53 @@ static const struct drm_crtc_helper_funcs
>> meson_crtc_helper_funcs = {
>> .atomic_disable = meson_crtc_atomic_disable,
>> };
>>
>> +static const struct drm_crtc_helper_funcs meson_g12a_crtc_helper_funcs = {
>> +.atomic_begin = meson_crtc_atomic_begin,
>> +.atomic_flush = meson_crtc_atomic_flush,
>> +.atomic_enable = meson_g12a_crtc_atomic_enable,
>> +.atomic_disable = meson_g12a_crtc_atomic_disable,
>> +};
>> +
>> +static void meson_crtc_enable_osd1(struct meson_drm *priv)
>> +{
>> +writel_bits_relaxed(VPP_OSD1_POSTBLEND, VPP_OSD1_POSTBLEND,
>> +priv->io_base + _REG(VPP_MISC));
>> +}
>> +
>> +static void meson_g12a_crtc_enable_osd1(struct
[Bug 110137] drirc adaptive sync, vrr, freesync blacklisting documentation
https://bugs.freedesktop.org/show_bug.cgi?id=110137 --- Comment #2 from gr...@sub.red --- Neither qutebrowser nor QtWebEngineProcess worked. Now I've seen that qtbrowser is built on PyQt5, so the executable name has to be "python3", this works: I'd send in a patch for that, but I think this will block any python3-based app, which is not the goal here. -- 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 0/3] dt-bindings: meson: Add G12A display bindings
On 13/03/2019 15:10, Neil Armstrong wrote: > This patchset adds the G12A specific bindings for the Display VPU > and VPU Power Control. > > The Amlogic Meson G12A Display module is based on the Meson GXM SoC > with an updated Plane Blender, thus VPU architecture and interconnect > is the same. > > Implementation then DT nodes will come in a further patchsets. > > Neil Armstrong (3): > dt-bindings: display: amlogic,meson-vpu: Add G12A compatible and ports > dt-bindings: display: amlogic,meson-dw-hdmi: Add G12A compatible and > ports > dt-bindings: power: amlogic,meson-gx-pwrc: Add G12A compatible > > .../devicetree/bindings/display/amlogic,meson-dw-hdmi.txt | 4 > .../devicetree/bindings/display/amlogic,meson-vpu.txt | 4 > .../devicetree/bindings/power/amlogic,meson-gx-pwrc.txt | 4 +++- > 3 files changed, 11 insertions(+), 1 deletion(-) > Kevin, I applied Patches 1 & 2 to drm-misc-next, can you take Patch 3 along : - https://patchwork.kernel.org/patch/10879285/ - https://patchwork.kernel.org/patch/10879293/ Thanks ! Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 8/8] add syncobj timeline tests v3
v2: drop DRM_SYNCOBJ_CREATE_TYPE_TIMELINE, fix timeout calculation,
fix some warnings
v3: add export/import and cpu signal testing cases
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
tests/amdgpu/Makefile.am | 3 +-
tests/amdgpu/amdgpu_test.c | 11 ++
tests/amdgpu/amdgpu_test.h | 21 +++
tests/amdgpu/meson.build | 2 +-
tests/amdgpu/syncobj_tests.c | 290 +++
5 files changed, 325 insertions(+), 2 deletions(-)
create mode 100644 tests/amdgpu/syncobj_tests.c
diff --git a/tests/amdgpu/Makefile.am b/tests/amdgpu/Makefile.am
index 48278848..920882d0 100644
--- a/tests/amdgpu/Makefile.am
+++ b/tests/amdgpu/Makefile.am
@@ -34,4 +34,5 @@ amdgpu_test_SOURCES = \
uve_ib.h \
deadlock_tests.c \
vm_tests.c \
- ras_tests.c
+ ras_tests.c \
+ syncobj_tests.c
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 8fc7a0b9..214c7fce 100644
--- a/tests/amdgpu/amdgpu_test.c
+++ b/tests/amdgpu/amdgpu_test.c
@@ -57,6 +57,7 @@
#define DEADLOCK_TESTS_STR "Deadlock Tests"
#define VM_TESTS_STR "VM Tests"
#define RAS_TESTS_STR "RAS Tests"
+#define SYNCOBJ_TIMELINE_TESTS_STR "SYNCOBJ TIMELINE Tests"
/**
* Open handles for amdgpu devices
@@ -123,6 +124,12 @@ static CU_SuiteInfo suites[] = {
.pCleanupFunc = suite_ras_tests_clean,
.pTests = ras_tests,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pInitFunc = suite_syncobj_timeline_tests_init,
+ .pCleanupFunc = suite_syncobj_timeline_tests_clean,
+ .pTests = syncobj_timeline_tests,
+ },
CU_SUITE_INFO_NULL,
};
@@ -176,6 +183,10 @@ static Suites_Active_Status suites_active_stat[] = {
.pName = RAS_TESTS_STR,
.pActive = suite_ras_tests_enable,
},
+ {
+ .pName = SYNCOBJ_TIMELINE_TESTS_STR,
+ .pActive = suite_syncobj_timeline_tests_enable,
+ },
};
diff --git a/tests/amdgpu/amdgpu_test.h b/tests/amdgpu/amdgpu_test.h
index bcd0bc7e..36675ea3 100644
--- a/tests/amdgpu/amdgpu_test.h
+++ b/tests/amdgpu/amdgpu_test.h
@@ -216,6 +216,27 @@ CU_BOOL suite_ras_tests_enable(void);
extern CU_TestInfo ras_tests[];
+/**
+ * Initialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_init();
+
+/**
+ * Deinitialize syncobj timeline test suite
+ */
+int suite_syncobj_timeline_tests_clean();
+
+/**
+ * Decide if the suite is enabled by default or not.
+ */
+CU_BOOL suite_syncobj_timeline_tests_enable(void);
+
+/**
+ * Tests in syncobj timeline test suite
+ */
+extern CU_TestInfo syncobj_timeline_tests[];
+
+
/**
* Helper functions
*/
diff --git a/tests/amdgpu/meson.build b/tests/amdgpu/meson.build
index 95ed9305..1726cb43 100644
--- a/tests/amdgpu/meson.build
+++ b/tests/amdgpu/meson.build
@@ -24,7 +24,7 @@ if dep_cunit.found()
files(
'amdgpu_test.c', 'basic_tests.c', 'bo_tests.c', 'cs_tests.c',
'vce_tests.c', 'uvd_enc_tests.c', 'vcn_tests.c', 'deadlock_tests.c',
- 'vm_tests.c', 'ras_tests.c',
+ 'vm_tests.c', 'ras_tests.c', 'syncobj_tests.c',
),
dependencies : [dep_cunit, dep_threads],
include_directories : [inc_root, inc_drm,
include_directories('../../amdgpu')],
diff --git a/tests/amdgpu/syncobj_tests.c b/tests/amdgpu/syncobj_tests.c
new file mode 100644
index ..a0c627d7
--- /dev/null
+++ b/tests/amdgpu/syncobj_tests.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright 2017 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+*/
+
+#include "CUnit/Basic.h"
+
+#include "amdgpu_test.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+#include
+
+static amdgpu_device_handle device_handle;
+static uint32_t major_version;
+static uint32_t minor_version;
+
+static void
[PATCH libdrm 3/8] add timeline wait/query ioctl v2
v2: drop export/import
Signed-off-by: Chunming Zhou
---
xf86drm.c | 44
xf86drm.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 18ad7c58..66e0c985 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4279,3 +4279,47 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t
*handles,
ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_SIGNAL, );
return ret;
}
+
+drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t
*points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled)
+{
+struct drm_syncobj_timeline_wait args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.timeout_nsec = timeout_nsec;
+args.count_handles = num_handles;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, );
+if (ret < 0)
+return -errno;
+
+if (first_signaled)
+*first_signaled = args.first_signaled;
+return ret;
+}
+
+
+drm_public int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_QUERY, );
+if (ret)
+return ret;
+return 0;
+}
+
+
diff --git a/xf86drm.h b/xf86drm.h
index 887ecc76..60c7a84f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,6 +876,12 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
+ uint32_t handle_count);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 4/8] wrap syncobj timeline query/wait APIs for amdgpu v3
v2: symbos are stored in lexical order.
v3: drop export/import and extra query indirection
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
amdgpu/amdgpu-symbol-check | 2 ++
amdgpu/amdgpu.h| 39 ++
amdgpu/amdgpu_cs.c | 23 ++
3 files changed, 64 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 96a44b40..67ba3039 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -52,8 +52,10 @@ amdgpu_cs_submit_raw
amdgpu_cs_submit_raw2
amdgpu_cs_syncobj_export_sync_file
amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
amdgpu_cs_wait_semaphore
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index d6de3b8d..dcf662e9 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1521,6 +1521,45 @@ int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
+/**
+ * Wait for one or all sync objects on their points to signal.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [in] array of sync points to wait
+ * \param num_handles - \c [in] self-explanatory
+ * \param timeout_nsec - \c [in] self-explanatory
+ * \param flags - \c [in] a bitmask of DRM_SYNCOBJ_WAIT_FLAGS_*
+ * \param first_signaled - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned flags,
+ uint32_t *first_signaled);
+/**
+ * Query sync objects payloads.
+ *
+ * \param dev- \c [in] self-explanatory
+ * \param handles - \c [in] array of sync object handles
+ * \param points - \c [out] array of sync points returned, which presents
+ * syncobj payload.
+ * \param num_handles - \c [in] self-explanatory
+ *
+ * \return 0 on success\n
+ * -ETIME - Timeout
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles);
+
/**
* Export kernel sync object to shareable fd.
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 5bedf748..b8b0d566 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -661,6 +661,29 @@ drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle
dev,
flags, first_signaled);
}
+drm_public int amdgpu_cs_syncobj_timeline_wait(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t
*points,
+ unsigned num_handles,
+ int64_t timeout_nsec, unsigned
flags,
+ uint32_t *first_signaled)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineWait(dev->fd, handles, points, num_handles,
+ timeout_nsec, flags, first_signaled);
+}
+
+drm_public int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
+ uint32_t *handles, uint64_t *points,
+ unsigned num_handles)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjQuery(dev->fd, handles, points, num_handles);
+}
+
drm_public int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
uint32_t handle,
int *shared_fd)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/8] addr cs chunk for syncobj timeline
Signed-off-by: Chunming Zhou
---
include/drm/amdgpu_drm.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index e3a97da4..ab53f2e0 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -528,6 +528,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
#define AMDGPU_CHUNK_ID_BO_HANDLES 0x06
#define AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES 0x07
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT0x08
+#define AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL 0x09
struct drm_amdgpu_cs_chunk {
__u32 chunk_id;
@@ -608,6 +610,13 @@ struct drm_amdgpu_cs_chunk_sem {
__u32 handle;
};
+struct drm_amdgpu_cs_chunk_syncobj {
+ __u32 handle;
+ __u32 flags;
+ __u64 point;
+};
+
+
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ 0
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD 1
#define AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD2
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 6/8] expose timeline signal/export/import interfaces v2
v2: adapt to new one transfer ioctl
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu-symbol-check | 3 ++
amdgpu/amdgpu.h| 51
amdgpu/amdgpu_cs.c | 68 ++
3 files changed, 122 insertions(+)
diff --git a/amdgpu/amdgpu-symbol-check b/amdgpu/amdgpu-symbol-check
index 67ba3039..0cc54e5e 100755
--- a/amdgpu/amdgpu-symbol-check
+++ b/amdgpu/amdgpu-symbol-check
@@ -51,10 +51,13 @@ amdgpu_cs_submit
amdgpu_cs_submit_raw
amdgpu_cs_submit_raw2
amdgpu_cs_syncobj_export_sync_file
+amdgpu_cs_syncobj_export_sync_file2
amdgpu_cs_syncobj_import_sync_file
+amdgpu_cs_syncobj_import_sync_file2
amdgpu_cs_syncobj_query
amdgpu_cs_syncobj_reset
amdgpu_cs_syncobj_signal
+amdgpu_cs_syncobj_timeline_signal
amdgpu_cs_syncobj_timeline_wait
amdgpu_cs_syncobj_wait
amdgpu_cs_wait_fences
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index dcf662e9..b5bd3ed9 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1501,6 +1501,23 @@ int amdgpu_cs_syncobj_reset(amdgpu_device_handle dev,
int amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
const uint32_t *syncobjs, uint32_t syncobj_count);
+/**
+ * Signal kernel timeline sync objects.
+ *
+ * \param dev - \c [in] device handle
+ * \param syncobjs - \c [in] array of sync object handles
+ * \param points - \c [in] array of timeline points
+ * \param syncobj_count - \c [in] number of handles in syncobjs
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+ const uint32_t *syncobjs,
+ uint64_t *points,
+ uint32_t syncobj_count);
+
/**
* Wait for one or all sync objects to signal.
*
@@ -1618,7 +1635,41 @@ int
amdgpu_cs_syncobj_export_sync_file(amdgpu_device_handle dev,
int amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
uint32_t syncobj,
int sync_file_fd);
+/**
+ * Export kernel timeline sync object to a sync_file.
+ *
+ * \param dev- \c [in] device handle
+ * \param syncobj- \c [in] sync object handle
+ * \param point - \c [in] timeline point
+ * \param flags - \c [in] flags
+ * \param sync_file_fd - \c [out] sync_file file descriptor.
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ uint32_t flags,
+ int *sync_file_fd);
+/**
+ * Import kernel timeline sync object from a sync_file.
+ *
+ * \param dev- \c [in] device handle
+ * \param syncobj- \c [in] sync object handle
+ * \param point - \c [in] timeline point
+ * \param sync_file_fd - \c [in] sync_file file descriptor.
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ int sync_file_fd);
/**
* Export an amdgpu fence as a handle (syncobj or fd).
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index b8b0d566..1c02d16f 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -649,6 +649,18 @@ drm_public int
amdgpu_cs_syncobj_signal(amdgpu_device_handle dev,
return drmSyncobjSignal(dev->fd, syncobjs, syncobj_count);
}
+drm_public int amdgpu_cs_syncobj_timeline_signal(amdgpu_device_handle dev,
+const uint32_t *syncobjs,
+uint64_t *points,
+uint32_t syncobj_count)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTimelineSignal(dev->fd, syncobjs,
+ points, syncobj_count);
+}
+
drm_public int amdgpu_cs_syncobj_wait(amdgpu_device_handle dev,
uint32_t *handles, unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
@@ -724,6 +736,62 @@ drm_public int
amdgpu_cs_syncobj_import_sync_file(amdgpu_device_handle dev,
return drmSyncobjImportSyncFile(dev->fd, syncobj, sync_file_fd);
}
+drm_public int amdgpu_cs_syncobj_export_sync_file2(amdgpu_device_handle dev,
+ uint32_t syncobj,
+ uint64_t point,
+ uint32_t flags,
+
[PATCH libdrm 7/8] wrap transfer interfaces
Signed-off-by: Chunming Zhou
---
amdgpu/amdgpu.h| 22 ++
amdgpu/amdgpu_cs.c | 16
2 files changed, 38 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b5bd3ed9..2350835b 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1670,6 +1670,28 @@ int
amdgpu_cs_syncobj_import_sync_file2(amdgpu_device_handle dev,
uint32_t syncobj,
uint64_t point,
int sync_file_fd);
+
+/**
+ * transfer between syncbojs.
+ *
+ * \param dev- \c [in] device handle
+ * \param dst_handle - \c [in] sync object handle
+ * \param dst_point - \c [in] timeline point, 0 presents dst is binary
+ * \param src_handle - \c [in] sync object handle
+ * \param src_point - \c [in] timeline point, 0 presents src is binary
+ * \param flags - \c [in] flags
+ *
+ * \return 0 on success\n
+ * <0 - Negative POSIX Error code
+ *
+ */
+int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+ uint32_t dst_handle,
+ uint64_t dst_point,
+ uint32_t src_handle,
+ uint64_t src_point,
+ uint32_t flags);
+
/**
* Export an amdgpu fence as a handle (syncobj or fd).
*
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 1c02d16f..a1c1af55 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -792,6 +792,22 @@ out:
return ret;
}
+drm_public int amdgpu_cs_syncobj_transfer(amdgpu_device_handle dev,
+ uint32_t dst_handle,
+ uint64_t dst_point,
+ uint32_t src_handle,
+ uint64_t src_point,
+ uint32_t flags)
+{
+ if (NULL == dev)
+ return -EINVAL;
+
+ return drmSyncobjTransfer(dev->fd,
+ dst_handle, dst_point,
+ src_handle, src_point,
+ flags);
+}
+
drm_public int amdgpu_cs_submit_raw(amdgpu_device_handle dev,
amdgpu_context_handle context,
amdgpu_bo_list_handle bo_list_handle,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 5/8] add timeline signal/transfer ioctls v2
v2: use one transfer ioctl
Signed-off-by: Chunming Zhou
---
xf86drm.c | 33 +
xf86drm.h | 6 ++
2 files changed, 39 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 66e0c985..d57c4218 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -4280,6 +4280,21 @@ drm_public int drmSyncobjSignal(int fd, const uint32_t
*handles,
return ret;
}
+drm_public int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+ uint64_t *points, uint32_t handle_count)
+{
+struct drm_syncobj_timeline_array args;
+int ret;
+
+memclear(args);
+args.handles = (uintptr_t)handles;
+args.points = (uint64_t)(uintptr_t)points;
+args.count_handles = handle_count;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, );
+return ret;
+}
+
drm_public int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t
*points,
unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
@@ -4322,4 +4337,22 @@ drm_public int drmSyncobjQuery(int fd, uint32_t
*handles, uint64_t *points,
return 0;
}
+drm_public int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags)
+{
+struct drm_syncobj_transfer args;
+int ret;
+
+memclear(args);
+args.src_handle = src_handle;
+args.dst_handle = dst_handle;
+args.src_point = src_point;
+args.dst_point = dst_point;
+args.flags = flags;
+
+ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_TRANSFER, );
+return ret;
+}
diff --git a/xf86drm.h b/xf86drm.h
index 60c7a84f..3fb1d1ca 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -876,12 +876,18 @@ extern int drmSyncobjWait(int fd, uint32_t *handles,
unsigned num_handles,
uint32_t *first_signaled);
extern int drmSyncobjReset(int fd, const uint32_t *handles, uint32_t
handle_count);
extern int drmSyncobjSignal(int fd, const uint32_t *handles, uint32_t
handle_count);
+extern int drmSyncobjTimelineSignal(int fd, const uint32_t *handles,
+ uint64_t *points, uint32_t handle_count);
extern int drmSyncobjTimelineWait(int fd, uint32_t *handles, uint64_t *points,
unsigned num_handles,
int64_t timeout_nsec, unsigned flags,
uint32_t *first_signaled);
extern int drmSyncobjQuery(int fd, uint32_t *handles, uint64_t *points,
uint32_t handle_count);
+extern int drmSyncobjTransfer(int fd,
+ uint32_t dst_handle, uint64_t dst_point,
+ uint32_t src_handle, uint64_t src_point,
+ uint32_t flags);
#if defined(__cplusplus)
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/8] new syncobj extension v3
v2: drop not implemented IOCTLs and flags
v3: add transfer/signal ioctls
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
---
include/drm/drm.h | 35 +++
1 file changed, 35 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 85c685a2..26f51bca 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -729,8 +729,18 @@ struct drm_syncobj_handle {
__u32 pad;
};
+struct drm_syncobj_transfer {
+__u32 src_handle;
+__u32 dst_handle;
+__u64 src_point;
+__u64 dst_point;
+__u32 flags;
+__u32 pad;
+};
+
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL (1 << 0)
#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT (1 << 1)
+#define DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE (1 << 2)
struct drm_syncobj_wait {
__u64 handles;
/* absolute timeout */
@@ -741,12 +751,31 @@ struct drm_syncobj_wait {
__u32 pad;
};
+struct drm_syncobj_timeline_wait {
+__u64 handles;
+/* wait on specific timeline point for every handles*/
+__u64 points;
+/* absolute timeout */
+__s64 timeout_nsec;
+__u32 count_handles;
+__u32 flags;
+__u32 first_signaled; /* only valid when not waiting all */
+__u32 pad;
+};
+
struct drm_syncobj_array {
__u64 handles;
__u32 count_handles;
__u32 pad;
};
+struct drm_syncobj_timeline_array {
+__u64 handles;
+__u64 points;
+__u32 count_handles;
+__u32 pad;
+};
+
/* Query current scanout sequence number */
struct drm_crtc_get_sequence {
__u32 crtc_id; /* requested crtc_id */
@@ -903,6 +932,12 @@ extern "C" {
#define DRM_IOCTL_MODE_GET_LEASE DRM_IOWR(0xC8, struct
drm_mode_get_lease)
#define DRM_IOCTL_MODE_REVOKE_LEASEDRM_IOWR(0xC9, struct
drm_mode_revoke_lease)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT DRM_IOWR(0xCA, struct
drm_syncobj_timeline_wait)
+#define DRM_IOCTL_SYNCOBJ_QUERY DRM_IOWR(0xCB, struct
drm_syncobj_timeline_array)
+#define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
drm_syncobj_transfer)
+#define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL DRM_IOWR(0xCD, struct
drm_syncobj_timeline_array)
+
+
/**
* Device specific ioctls should only be in their respective headers
* The device specific ioctl range is from 0x40 to 0x9f.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/11] drm/meson: Add G12A Support
Hi, On 09/04/2019 10:42, Jerome Brunet wrote: > On Mon, 2019-03-25 at 15:18 +0100, Neil Armstrong wrote: >> The Amlogic G12A SoC offers very close Video Display >> functionnalities with it's older GXBB, GXL & GXM predecessors. >> >> The main differences are : >> - G12A Support now 3 "real" OSD planes with a new Blender module >> - Instead of having a single Scaler for OSD1, G12A has two scaler >> that can be applied to 2 out of the 3 OSD planes or on the outputs >> of the blender module. >> - The HDMI PHY now support RX-SENSE, Dynamic HDR and it's registers are >> now memory mapped instead of using an internal bus. >> - The VPU now support a DSI interface to connect a display, using >> the Synopsys DSI controller and a custom PHY >> >> The complex Blender routing, HDMI RX-SENSE, Dynamic HDR and DSI support >> are not handled in this patchset. >> >> This patchset implements on-par support with the currently support >> GXBB, GXL and GXM SoCs. There is no support delta with this patchset. >> >> patch 10 & 11 implements the bindings found at [1]. >> >> [1] https://lkml.kernel.org/r/20190313141030.5958-1-narmstr...@baylibre.com >> >> Neil Armstrong (11): >> drm/meson: Switch PLL to 5.94GHz base for 297Mhz pixel clock >> drm/meson: Add registers for G12A SoC >> drm/meson: Add G12A Support for VPP setup >> drm/meson: Add G12A Support for VIU setup >> drm/meson: Add G12A support for OSD1 Plane >> drm/meson: Add G12A Support for the Overlay video plane >> drm/meson: Add G12A support for plane handling in CRTC driver >> drm/meson: Add G12A support for CVBS Encoer >> drm/meson: Add G12A Video Clock setup >> drm/meson: Add G12A compatible >> drm/meson: Add G12A support for the DW-HDMI Glue >> >> drivers/gpu/drm/meson/meson_crtc.c | 269 +++- >> drivers/gpu/drm/meson/meson_drv.c | 1 + >> drivers/gpu/drm/meson/meson_drv.h | 4 + >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 163 +++--- >> drivers/gpu/drm/meson/meson_dw_hdmi.h | 32 ++- >> drivers/gpu/drm/meson/meson_overlay.c | 10 +- >> drivers/gpu/drm/meson/meson_plane.c | 15 +- >> drivers/gpu/drm/meson/meson_registers.h | 247 ++ >> drivers/gpu/drm/meson/meson_vclk.c | 123 +-- >> drivers/gpu/drm/meson/meson_venc.c | 11 +- >> drivers/gpu/drm/meson/meson_venc_cvbs.c | 25 ++- >> drivers/gpu/drm/meson/meson_viu.c | 72 ++- >> drivers/gpu/drm/meson/meson_vpp.c | 51 +++-- >> 13 files changed, 880 insertions(+), 143 deletions(-) >> > > on the u200 and sei510 > Tested-by: Jerome Brunet > > I can't pretend to have a deep understanding of this subsystem, but as far as > I can tell, there is nothing crazy in there. With the comments around the use > of constants and defines fixed, you can add > > Reviewed-by: Jerome Brunet > > As a possible future enhancement, it would be nice if you could trim the use > of *_is_compatible() functions. I think it would make the code easier to > follow and review. > Thanks for the overall review, I will do a complete fixup of the constants and defines in a follow-up patchset, since the already-merged code also needs a good cleanup. I'll do a more complete refactoring to get rid of the _is_compatible() stuff in a second time, it needs much more work to handle correctly the 4 SoC families. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: drop prime import/export callbacks
Hi, > > Should we add something like DRM_PRIME_CAP_SAME_DEVICE? > > Yeah I expect we need some sort of same device only capability, so > that dri3 userspace can work. > > If we just fail importing in these cases what happens? userspace just > gets confused, I know we used to print a backtrace if we hit the mmap > path, but if we didn't do that what happens? Well, we printed a backtrace and returned -EINVAL. So it looked a bit scary due to the backtrace which is usually printed for more serious problems. But we also returned a proper error code. Userspace was not happy. It was wayland (gnome-shell) which ran into it it, and it didn't came up with a working display. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/13] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
Hi,
On Tue, Apr 09, 2019 at 02:24:44AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> H6 has a different I/O voltage bias setting method than A80. Prepare
> existing code for using alternative bias voltage setting methods.
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c | 2 +-
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 41 +--
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 5 ++-
> 3 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> index da37d594a13d..3aa210079b18 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c
> @@ -722,7 +722,7 @@ static const struct sunxi_pinctrl_desc
> sun9i_a80_pinctrl_data = {
> .npins = ARRAY_SIZE(sun9i_a80_pins),
> .irq_banks = 5,
> .disable_strict_mode = true,
> - .has_io_bias_cfg = true,
> + .io_bias_cfg_variant = IO_BIAS_CFG_V1,
> };
>
> static int sun9i_a80_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 8dd25caea2cf..b8dd58ef33b7 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -610,7 +610,7 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
> u32 val, reg;
> int uV;
>
> - if (!pctl->desc->has_io_bias_cfg)
> + if (!pctl->desc->io_bias_cfg_variant)
> return 0;
>
> uV = regulator_get_voltage(supply);
> @@ -621,23 +621,28 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
> if (uV == 0)
> return 0;
>
> - /* Configured value must be equal or greater to actual voltage */
> - if (uV <= 180)
> - val = 0x0; /* 1.8V */
> - else if (uV <= 250)
> - val = 0x6; /* 2.5V */
> - else if (uV <= 280)
> - val = 0x9; /* 2.8V */
> - else if (uV <= 300)
> - val = 0xA; /* 3.0V */
> - else
> - val = 0xD; /* 3.3V */
> -
> - pin -= pctl->desc->pin_base;
> -
> - reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> - reg &= ~IO_BIAS_MASK;
> - writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + if (pctl->desc->io_bias_cfg_variant == IO_BIAS_CFG_V1) {
> + /*
> + * Configured value must be equal or greater to actual
> + * voltage.
> + */
> + if (uV <= 180)
> + val = 0x0; /* 1.8V */
> + else if (uV <= 250)
> + val = 0x6; /* 2.5V */
> + else if (uV <= 280)
> + val = 0x9; /* 2.8V */
> + else if (uV <= 300)
> + val = 0xA; /* 3.0V */
> + else
> + val = 0xD; /* 3.3V */
> +
> + pin -= pctl->desc->pin_base;
> +
> + reg = readl(pctl->membase + sunxi_grp_config_reg(pin));
> + reg &= ~IO_BIAS_MASK;
> + writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> + }
>
> return 0;
> }
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index ee15ab067b5f..642f667e99d2 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,6 +95,9 @@
> #define PINCTRL_SUN7I_A20BIT(7)
> #define PINCTRL_SUN8I_R40BIT(8)
>
> +/* Bias voltage configuration done via Pn_GRP_CONFIG registers. */
> +#define IO_BIAS_CFG_V1 1
> +
Can we turn this into an enum, and give them proper name? Mentionning
an example in the commit would be great too.
Something like:
enum sunxi_desc_bias_voltage {
/* Bias Voltage configuration is done through Pn_GRP_CONFIG registers,
as seen on the A83t */
BIAS_VOLTAGE_GRP_CONFIG,
};
etc.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v2 02/13] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
Based on the conversation about using common dtsi from this thread[1],
I'm commenting here to make show the diff directly on the nodes,
giving comments on each node so-that we can see the diff globally.
On Tue, Apr 9, 2019 at 5:55 AM megous via linux-sunxi
wrote:
>
> From: Ondrej Jirman
>
> Orange Pi 3 is a H6 based SBC made by Xulong, released in January 2019. It
> has the following features:
>
> - Allwinner H6 quad-core 64-bit ARM Cortex-A53
> - GPU Mali-T720
> - 1GB or 2GB LPDDR3 RAM
> - AXP805 PMIC
> - AP6256 Wifi/BT 5.0
> - USB 2.0 host port (A)
> - USB 2.0 micro usb, OTG
> - USB 3.0 Host + 4 port USB hub (GL3510)
> - Gigabit Ethernet (Realtek RTL8211E phy)
> - HDMI 2.0 port
> - soldered eMMC (optional)
> - 3x LED (one is on the bottom)
> - microphone
> - audio jack
> - PCIe
>
> Add basic support for the board.
>
> Signed-off-by: Ondrej Jirman
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../dts/allwinner/sun50i-h6-orangepi-3.dts| 216 ++
> 2 files changed, 217 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index e4dce2f6fa3a..285a7cb5135b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -20,6 +20,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> new file mode 100644
> index ..5fbc5e410883
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2019 Ondřej Jirman
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h6.dtsi"
> +
> +#include
> +
> +/ {
> + model = "OrangePi 3";
> + compatible = "xunlong,orangepi-3", "allwinner,sun50i-h6";
> +
> + aliases {
> + serial0 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <_pio 0 7 GPIO_ACTIVE_HIGH>; /* PL7 */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC jack */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +};
all above nodes are common to all h6 opi boards.
> +
> + {
> + cpu-supply = <_dcdca>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + vmmc-supply = <_cldo1>;
> + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
common to all h6 opi boards.
> +
> + {
> + vcc-pc-supply = <_bldo2>;
> + vcc-pd-supply = <_cldo1>;
> +};
> +
> +_i2c {
> + status = "okay";
> +
> + axp805: pmic@36 {
> + compatible = "x-powers,axp805", "x-powers,axp806";
> + reg = <0x36>;
> + interrupt-parent = <_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + x-powers,self-working-mode;
> + vina-supply = <_vcc5v>;
> + vinb-supply = <_vcc5v>;
> + vinc-supply = <_vcc5v>;
> + vind-supply = <_vcc5v>;
> + vine-supply = <_vcc5v>;
> + aldoin-supply = <_vcc5v>;
> + bldoin-supply = <_vcc5v>;
> + cldoin-supply = <_vcc5v>;
all these supply voltage regulators are common to h6 opi boards.
> +
> + regulators {
> + reg_aldo1: aldo1
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
Hi, > > The qemu stdvga (bochs driver) has 16 MB vram by default and can be > > configured to have up to 256 MB. Plenty of room even for multiple 4k > > framebuffers if needed. So for the bochs driver all the ttm bo > > migration logic is not needed, it could just store everything in vram. > > To clarify I assume you mean it doesn't need the migrate each bo > logic, but it still needs the when VRAM fills up migrate stuff logic. I think even the "when vram fills up" logic isn't that important. The driver has no acceleration so there is nothing to store beside dumb framebuffers, and the vram size can easily be increased if needed. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v4 0/9] mm: Use vm_map_pages() and vm_map_pages_zero() API
Hi Andrew/ Michal, On Mon, Apr 1, 2019 at 10:56 AM Souptick Joarder wrote: > > Hi Andrew, > > On Tue, Mar 19, 2019 at 7:47 AM Souptick Joarder wrote: > > > > Previouly drivers have their own way of mapping range of > > kernel pages/memory into user vma and this was done by > > invoking vm_insert_page() within a loop. > > > > As this pattern is common across different drivers, it can > > be generalized by creating new functions and use it across > > the drivers. > > > > vm_map_pages() is the API which could be used to map > > kernel memory/pages in drivers which has considered vm_pgoff. > > > > vm_map_pages_zero() is the API which could be used to map > > range of kernel memory/pages in drivers which has not considered > > vm_pgoff. vm_pgoff is passed default as 0 for those drivers. > > > > We _could_ then at a later "fix" these drivers which are using > > vm_map_pages_zero() to behave according to the normal vm_pgoff > > offsetting simply by removing the _zero suffix on the function > > name and if that causes regressions, it gives us an easy way to revert. > > > > Tested on Rockchip hardware and display is working fine, including talking > > to Lima via prime. > > > > v1 -> v2: > > Few Reviewed-by. > > > > Updated the change log in [8/9] > > > > In [7/9], vm_pgoff is treated in V4L2 API as a 'cookie' > > to select a buffer, not as a in-buffer offset by design > > and it always want to mmap a whole buffer from its beginning. > > Added additional changes after discussing with Marek and > > vm_map_pages() could be used instead of vm_map_pages_zero(). > > > > v2 -> v3: > > Corrected the documentation as per review comment. > > > > As suggested in v2, renaming the interfaces to - > > *vm_insert_range() -> vm_map_pages()* and > > *vm_insert_range_buggy() -> vm_map_pages_zero()*. > > As the interface is renamed, modified the code accordingly, > > updated the change logs and modified the subject lines to use the > > new interfaces. There is no other change apart from renaming and > > using the new interface. > > > > Patch[1/9] & [4/9], Tested on Rockchip hardware. > > > > v3 -> v4: > > Fixed build warnings on patch [8/9] reported by kbuild test robot. > > > > Souptick Joarder (9): > > mm: Introduce new vm_map_pages() and vm_map_pages_zero() API > > arm: mm: dma-mapping: Convert to use vm_map_pages() > > drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero() > > drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages() > > drm/xen/xen_drm_front_gem.c: Convert to use vm_map_pages() > > iommu/dma-iommu.c: Convert to use vm_map_pages() > > videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages() > > xen/gntdev.c: Convert to use vm_map_pages() > > xen/privcmd-buf.c: Convert to use vm_map_pages_zero() > > Is it fine to take these patches into mm tree for regression ? v4 of this series has not received any further comments/ kbuild error in last 8 weeks (including the previously posted v4). Any suggestion, if it safe to take these changes through mm tree ? or any other tree is preferred ? > > > > > arch/arm/mm/dma-mapping.c | 22 ++ > > drivers/firewire/core-iso.c| 15 +--- > > drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 17 + > > drivers/gpu/drm/xen/xen_drm_front_gem.c| 18 ++--- > > drivers/iommu/dma-iommu.c | 12 +--- > > drivers/media/common/videobuf2/videobuf2-core.c| 7 ++ > > .../media/common/videobuf2/videobuf2-dma-contig.c | 6 -- > > drivers/media/common/videobuf2/videobuf2-dma-sg.c | 22 ++ > > drivers/xen/gntdev.c | 11 ++- > > drivers/xen/privcmd-buf.c | 8 +-- > > include/linux/mm.h | 4 ++ > > mm/memory.c| 81 > > ++ > > mm/nommu.c | 14 > > 13 files changed, 134 insertions(+), 103 deletions(-) > > > > -- > > 1.9.1 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
- On Apr 8, 2019, at 10:22 AM, paulmck paul...@linux.ibm.com wrote: > On Mon, Apr 08, 2019 at 09:05:34AM -0400, Mathieu Desnoyers wrote: >> - On Apr 7, 2019, at 10:27 PM, paulmck paul...@linux.ibm.com wrote: >> >> > On Sun, Apr 07, 2019 at 09:07:18PM +, Joel Fernandes wrote: >> >> On Sun, Apr 07, 2019 at 04:41:36PM -0400, Mathieu Desnoyers wrote: >> >> > >> >> > - On Apr 7, 2019, at 3:32 PM, Joel Fernandes, Google >> >> > j...@joelfernandes.org >> >> > wrote: >> >> > >> >> > > On Sun, Apr 07, 2019 at 03:26:16PM -0400, Mathieu Desnoyers wrote: >> >> > >> - On Apr 7, 2019, at 9:59 AM, paulmck paul...@linux.ibm.com >> >> > >> wrote: >> >> > >> >> >> > >> > On Sun, Apr 07, 2019 at 06:39:41AM -0700, Paul E. McKenney wrote: >> >> > >> >> On Sat, Apr 06, 2019 at 07:06:13PM -0400, Joel Fernandes wrote: >> >> > >> > >> >> > >> > [ . . . ] >> >> > >> > >> >> > >> >> > > diff --git a/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > b/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > index f8f6f04c4453..c2d919a1566e 100644 >> >> > >> >> > > --- a/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > +++ b/include/asm-generic/vmlinux.lds.h >> >> > >> >> > > @@ -338,6 +338,10 @@ >> >> > >> >> > > KEEP(*(__tracepoints_ptrs)) /* Tracepoints: >> >> > >> >> > > pointer array */ \ >> >> > >> >> > > __stop___tracepoints_ptrs = .; >> >> > >> >> > > \ >> >> > >> >> > > *(__tracepoints_strings)/* Tracepoints: strings >> >> > >> >> > > */ \ >> >> > >> >> > > + . = ALIGN(8); >> >> > >> >> > > \ >> >> > >> >> > > + __start___srcu_struct = .; >> >> > >> >> > > \ >> >> > >> >> > > + *(___srcu_struct_ptrs) >> >> > >> >> > > \ >> >> > >> >> > > + __end___srcu_struct = .; >> >> > >> >> > > \ >> >> > >> >> > > } >> >> > >> >> > > \ >> >> > >> >> > >> >> > >> >> > This vmlinux linker modification is not needed. I tested >> >> > >> >> > without it and srcu >> >> > >> >> > torture works fine with rcutorture built as a module. Putting >> >> > >> >> > further prints >> >> > >> >> > in kernel/module.c verified that the kernel is able to find the >> >> > >> >> > srcu structs >> >> > >> >> > just fine. You could squash the below patch into this one or >> >> > >> >> > apply it on top >> >> > >> >> > of the dev branch. >> >> > >> >> >> >> > >> >> Good point, given that otherwise FORTRAN named common blocks >> >> > >> >> would not >> >> > >> >> work. >> >> > >> >> >> >> > >> >> But isn't one advantage of leaving that stuff in the >> >> > >> >> RO_DATA_SECTION() >> >> > >> >> macro that it can be mapped read-only? Or am I suffering from >> >> > >> >> excessive >> >> > >> >> optimism? >> >> > >> > >> >> > >> > And to answer the other question, in the case where I am suffering >> >> > >> > from >> >> > >> > excessive optimism, it should be a separate commit. Please see >> >> > >> > below >> >> > >> > for the updated original commit thus far. >> >> > >> > >> >> > >> > And may I have your Tested-by? >> >> > >> >> >> > >> Just to confirm: does the cleanup performed in the modules going >> >> > >> notifier end up acting as a barrier first before freeing the memory ? >> >> > >> If not, is it explicitly stated that a barrier must be issued before >> >> > >> module unload ? >> >> > >> >> >> > > >> >> > > You mean rcu_barrier? It is mentioned in the documentation that this >> >> > > is the >> >> > > responsibility of the module writer to prevent delays for all modules. >> >> > >> >> > It's a srcu barrier yes. Considering it would be a barrier specific to >> >> > the >> >> > srcu domain within that module, I don't see how it would cause delays >> >> > for >> >> > "all" modules if we implicitly issue the barrier on module unload. What >> >> > am I missing ? >> >> >> >> Yes you are right. I thought of this after I just sent my email. I think >> >> it >> >> makes sense for srcu case to do and could avoid a class of bugs. >> > >> > If there are call_srcu() callbacks outstanding, the module writer still >> > needs the srcu_barrier() because otherwise callbacks arrive after >> > the module text has gone, which will be disappoint the CPU when it >> > tries fetching instructions that are no longer mapped. If there are >> > no call_srcu() callbacks from that module, then there is no need for >> > srcu_barrier() either way. >> > >> > So if an srcu_barrier() is needed, the module developer needs to >> > supply it. >> >> When you say "callbacks arrive after the module text has gone", >> I think you assume that free_module() is invoked before the >> MODULE_STATE_GOING notifiers are called. But it's done in the >> opposite order: going notifiers are called first, and then >> free_module()
