[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 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 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: [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: [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 > > > > >
[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
- <<
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
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 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
[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
Re: [PATCH] drm/qxl: drop prime import/export callbacks
On Tue, Apr 9, 2019 at 4:03 PM Gerd Hoffmann wrote:
>
> On Tue, Apr 09, 2019 at 02:01:33PM +1000, Dave Airlie wrote:
> > On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
> > >
> > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> > > >
> > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > > > userspace.
> >
> > It's been pointed out to me that disables DRI3 for these devices, I'm
> > not sure that is the solution we actually wanted.
> >
> > any ideas?
>
> Well. Lets have a look at where we stand:
>
> * drm_gem_prime_export() works with qxl, you'll get a dma-buf handle.
>
> * Other drivers trying to map that dma-buf (drm_gem_map_dma_buf()
>callback) will not work, due to the ->gem_prime_get_sg_table()
>callback not being there.
>
> * drm_gem_prime_import() will work with buffers from the same qxl
>device, there is a shortcut for this special case. Otherwise it
>will not work, due to the ->gem_prime_import_sg_table() callback
>not being there.
>
> Bottom line: you can use prime to pass qxl object handles from one
> application to another. But you can't actually export/import qxl
> buffer objects from/to other devices.
>
> Problem is that we have no way to signal to userspace that prime can
> be used that way.
>
> Setting DRM_PRIME_CAP_{IMPORT,EXPORT} even though the driver can't
> do that leads to other problems. Userspace thinks it can have other
> devices (intel vgpu for example) handle the rendering, then import
> the rendered buffer into qxl for scanout.
>
> 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?
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/15] drm/vboxvideo: Convert vboxvideo driver to Simple TTM
Hi,
On 08-04-19 11:21, Thomas Zimmermann wrote:
Signed-off-by: Thomas Zimmermann
Patch looks good to me (although perhaps it needs a commit msg):
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig| 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.h | 6 +-
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
3 files changed, 12 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index c1ca87df81df..e29df360978d 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
select DRM_KMS_HELPER
select DRM_TTM
select DRM_GEM_TTM_HELPER
+ select DRM_SIMPLE_TTM_HELPER
select GENERIC_ALLOCATOR
help
This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index 7db4e961805d..d4cfcc6339ef 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -20,6 +20,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -78,9 +80,7 @@ struct vbox_private {
int fb_mtrr;
- struct {
- struct ttm_bo_device bdev;
- } ttm;
+ struct drm_simple_ttm ttm;
struct mutex hw_mutex; /* protects modeset and accel/vbva accesses */
struct work_struct hotplug_work;
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index a1d64e1ea90c..115ec44636ab 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
@@ -11,128 +11,25 @@
#include
#include "vbox_drv.h"
-static inline struct vbox_private *vbox_bdev(struct ttm_bo_device *bd)
-{
- return container_of(bd, struct vbox_private, ttm.bdev);
-}
-
-static int
-vbox_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
- struct ttm_mem_type_manager *man)
-{
- switch (type) {
- case TTM_PL_SYSTEM:
- man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case TTM_PL_VRAM:
- man->func = _bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static int vbox_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
- struct ttm_mem_reg *mem)
-{
- struct ttm_mem_type_manager *man = >man[mem->mem_type];
- struct vbox_private *vbox = vbox_bdev(bdev);
-
- mem->bus.addr = NULL;
- mem->bus.offset = 0;
- mem->bus.size = mem->num_pages << PAGE_SHIFT;
- mem->bus.base = 0;
- mem->bus.is_iomem = false;
- if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
- return -EINVAL;
- switch (mem->mem_type) {
- case TTM_PL_SYSTEM:
- /* system memory */
- return 0;
- case TTM_PL_VRAM:
- mem->bus.offset = mem->start << PAGE_SHIFT;
- mem->bus.base = pci_resource_start(vbox->ddev.pdev, 0);
- mem->bus.is_iomem = true;
- break;
- default:
- return -EINVAL;
- }
- return 0;
-}
-
-static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev,
-struct ttm_mem_reg *mem)
-{
-}
-
-static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
-{
- ttm_tt_fini(tt);
- kfree(tt);
-}
-
-static struct ttm_backend_func vbox_tt_backend_func = {
- .destroy = _ttm_backend_destroy,
-};
-
-static struct ttm_tt *vbox_ttm_tt_create(struct ttm_buffer_object *bo,
-u32 page_flags)
-{
- struct ttm_tt *tt;
-
- tt = kzalloc(sizeof(*tt), GFP_KERNEL);
- if (!tt)
- return NULL;
-
- tt->func = _tt_backend_func;
- if (ttm_tt_init(tt, bo, page_flags)) {
- kfree(tt);
- return NULL;
- }
-
- return tt;
-}
-
-static struct ttm_bo_driver vbox_bo_driver = {
- .ttm_tt_create = vbox_ttm_tt_create,
- .init_mem_type = vbox_bo_init_mem_type,
- .eviction_valuable = ttm_bo_eviction_valuable,
+static const struct drm_simple_ttm_funcs vbox_simple_ttm_funcs = {
.evict_flags = drm_gem_ttm_bo_driver_evict_flags,
- .verify_access = drm_gem_ttm_bo_driver_verify_access,
- .io_mem_reserve = _ttm_io_mem_reserve,
- .io_mem_free = _ttm_io_mem_free,
+ .verify_access =
Re: [PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
On Tue, Apr 09, 2019 at 02:24:40AM +0200, meg...@megous.com wrote: > From: Ondrej Jirman > > Add new Xunlong Orange Pi 3 board compatible string to the bindings > documentation. > > Signed-off-by: Ondrej Jirman Applied, 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: [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()
[PATCH v2 01/13] dt-bindings: sunxi: Add compatible for OrangePi 3 board
From: Ondrej Jirman Add new Xunlong Orange Pi 3 board compatible string to the bindings documentation. Signed-off-by: Ondrej Jirman --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 11563d3f7c65..b82db740125b 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -711,6 +711,11 @@ properties: - const: xunlong,orangepi-2 - const: allwinner,sun8i-h3 + - description: Xunlong OrangePi 3 +items: + - const: xunlong,orangepi-3 + - const: allwinner,sun50i-h6 + - description: Xunlong OrangePi Lite items: - const: xunlong,orangepi-lite -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
On 4/8/2019 8:28 AM, Wen Yang wrote:
The call to of_get_parent returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/rcar-du/rcar_du_of.c:235:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 216, but without a
corresponding object release within this function.
drivers/gpu/drm/rcar-du/rcar_du_of.c:236:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 209, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Suggested-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Kieran Bingham
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org (open list)
---
v2->v1: turn the return into a goto done.
drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
index afef696..782bfc7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -232,7 +232,7 @@ static void __init rcar_du_of_lvds_patch(const struct
of_device_id *of_ids)
lvds_node = of_find_compatible_node(NULL, NULL, compatible);
if (lvds_node) {
of_node_put(lvds_node);
- return;
+ goto done;
}
you might have to create multiple level to do handling it.. there are
unnecessary put being done on "done" which is not valid
for this case.
-Mukesh
/*
___
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] drm/qxl: drop prime import/export callbacks
On Tue, Apr 09, 2019 at 02:01:33PM +1000, Dave Airlie wrote:
> On Sat, 12 Jan 2019 at 07:13, Dave Airlie wrote:
> >
> > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann wrote:
> > >
> > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > > userspace.
>
> It's been pointed out to me that disables DRI3 for these devices, I'm
> not sure that is the solution we actually wanted.
>
> any ideas?
Well. Lets have a look at where we stand:
* drm_gem_prime_export() works with qxl, you'll get a dma-buf handle.
* Other drivers trying to map that dma-buf (drm_gem_map_dma_buf()
callback) will not work, due to the ->gem_prime_get_sg_table()
callback not being there.
* drm_gem_prime_import() will work with buffers from the same qxl
device, there is a shortcut for this special case. Otherwise it
will not work, due to the ->gem_prime_import_sg_table() callback
not being there.
Bottom line: you can use prime to pass qxl object handles from one
application to another. But you can't actually export/import qxl
buffer objects from/to other devices.
Problem is that we have no way to signal to userspace that prime can
be used that way.
Setting DRM_PRIME_CAP_{IMPORT,EXPORT} even though the driver can't
do that leads to other problems. Userspace thinks it can have other
devices (intel vgpu for example) handle the rendering, then import
the rendered buffer into qxl for scanout.
Should we add something like DRM_PRIME_CAP_SAME_DEVICE?
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Tue, Apr 09, 2019 at 01:22:32AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:09AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > > According to the phy datasheet, both regulators need to be enabled
> > > at the same time, but we can only specify a single phy-supply in
> > > the DT.
> > >
> > > This can be achieved by making one regulator depedning on the
> > > other via vin-supply. While it's not a technically correct
> > > description of the hardware, it achieves the purpose.
> > >
> > > All values of RX/TX delay were tested exhaustively and a middle
> > > one of the working values was chosen.
> > >
> > > Signed-off-by: Ondrej Jirman
> > > ---
> > > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
> > > 1 file changed, 44 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > index 644946749088..5270142527f5 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > > @@ -15,6 +15,7 @@
> > >
> > > aliases {
> > > serial0 =
> > > + ethernet0 =
> > > };
> > >
> > > chosen {
> > > @@ -64,6 +65,27 @@
> > > regulator-max-microvolt = <500>;
> > > regulator-always-on;
> > > };
> > > +
> > > + /*
> > > + * The board uses 2.5V RGMII signalling. Power sequence
> > > + * to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > > + * power rails at the same time and to wait 100ms.
> > > + */
> > > + reg_gmac_2v5: gmac-2v5 {
> > > +compatible = "regulator-fixed";
> > > +regulator-name = "gmac-2v5";
> > > +regulator-min-microvolt = <250>;
> > > +regulator-max-microvolt = <250>;
> > > +startup-delay-us = <10>;
> > > +enable-active-high;
> > > +gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> >
> > Is enable-active-high still needed? It's redundant with the
> > GPIO_ACTIVE_HIGH flag.
>
> Looking at the code, use/non-use of enable-active-high inhibits
> flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
> is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
> ignore it too and print a warning).
>
> So enable-active-high is still necessary here.
Too bad :/
> See comment in gpiolib-of.c where this is handled:
>
> /*
> * The regulator GPIO handles are specified such that the
> * presence or absence of "enable-active-high" solely controls
> * the polarity of the GPIO line. Any phandle flags must
> * be actively ignored.
> */
Thanks for digging this out
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-next: manual merge of the drm-misc tree with the drm tree
On Tue, Apr 09, 2019 at 11:34:10AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/cirrus/cirrus_drv.h
> drivers/gpu/drm/cirrus/cirrus_ttm.c
>
> between commits:
>
> aa8e2435b3d4 ("drm/ttm: Define a single DRM_FILE_PAGE_OFFSET constant")
> 7d1500f9fbfc ("drm/ttm: Remove file_page_offset parameter from
> ttm_bo_device_init()")
> bed2dd84212e ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()")
>
> from the drm tree and commit:
>
> ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver.")
>
> from the drm-misc tree.
>
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Ping drm-misc maintainers. Time to update drm-misc-next with a
backmerge I think?
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/15] drm/vboxvideo: Convert vboxvideo driver to Simple TTM
Hi
Am 09.04.19 um 09:09 schrieb Hans de Goede:
> Hi,
>
> On 08-04-19 11:21, Thomas Zimmermann wrote:
>> Signed-off-by: Thomas Zimmermann
>
> Patch looks good to me (although perhaps it needs a commit msg):
OK, thanks. I'll add that message here and to the other patches.
Best regards
Thomas
>
> Reviewed-by: Hans de Goede
>
> Regards,
>
> Hans
>
>
>
>> ---
>> drivers/gpu/drm/vboxvideo/Kconfig | 1 +
>> drivers/gpu/drm/vboxvideo/vbox_drv.h | 6 +-
>> drivers/gpu/drm/vboxvideo/vbox_ttm.c | 123 ++-
>> 3 files changed, 12 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
>> b/drivers/gpu/drm/vboxvideo/Kconfig
>> index c1ca87df81df..e29df360978d 100644
>> --- a/drivers/gpu/drm/vboxvideo/Kconfig
>> +++ b/drivers/gpu/drm/vboxvideo/Kconfig
>> @@ -4,6 +4,7 @@ config DRM_VBOXVIDEO
>> select DRM_KMS_HELPER
>> select DRM_TTM
>> select DRM_GEM_TTM_HELPER
>> + select DRM_SIMPLE_TTM_HELPER
>> select GENERIC_ALLOCATOR
>> help
>> This is a KMS driver for the virtual Graphics Card used in
>> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> b/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> index 7db4e961805d..d4cfcc6339ef 100644
>> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
>> @@ -20,6 +20,8 @@
>> #include
>> #include
>> +#include
>> +
>> #include
>> #include
>> #include
>> @@ -78,9 +80,7 @@ struct vbox_private {
>> int fb_mtrr;
>> - struct {
>> - struct ttm_bo_device bdev;
>> - } ttm;
>> + struct drm_simple_ttm ttm;
>> struct mutex hw_mutex; /* protects modeset and accel/vbva
>> accesses */
>> struct work_struct hotplug_work;
>> diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> index a1d64e1ea90c..115ec44636ab 100644
>> --- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> +++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
>> @@ -11,128 +11,25 @@
>> #include
>> #include "vbox_drv.h"
>> -static inline struct vbox_private *vbox_bdev(struct ttm_bo_device *bd)
>> -{
>> - return container_of(bd, struct vbox_private, ttm.bdev);
>> -}
>> -
>> -static int
>> -vbox_bo_init_mem_type(struct ttm_bo_device *bdev, u32 type,
>> - struct ttm_mem_type_manager *man)
>> -{
>> - switch (type) {
>> - case TTM_PL_SYSTEM:
>> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
>> - man->available_caching = TTM_PL_MASK_CACHING;
>> - man->default_caching = TTM_PL_FLAG_CACHED;
>> - break;
>> - case TTM_PL_VRAM:
>> - man->func = _bo_manager_func;
>> - man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
>> - man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
>> - man->default_caching = TTM_PL_FLAG_WC;
>> - break;
>> - default:
>> - DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
>> - return -EINVAL;
>> - }
>> -
>> - return 0;
>> -}
>> -
>> -static int vbox_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
>> - struct ttm_mem_reg *mem)
>> -{
>> - struct ttm_mem_type_manager *man = >man[mem->mem_type];
>> - struct vbox_private *vbox = vbox_bdev(bdev);
>> -
>> - mem->bus.addr = NULL;
>> - mem->bus.offset = 0;
>> - mem->bus.size = mem->num_pages << PAGE_SHIFT;
>> - mem->bus.base = 0;
>> - mem->bus.is_iomem = false;
>> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
>> - return -EINVAL;
>> - switch (mem->mem_type) {
>> - case TTM_PL_SYSTEM:
>> - /* system memory */
>> - return 0;
>> - case TTM_PL_VRAM:
>> - mem->bus.offset = mem->start << PAGE_SHIFT;
>> - mem->bus.base = pci_resource_start(vbox->ddev.pdev, 0);
>> - mem->bus.is_iomem = true;
>> - break;
>> - default:
>> - return -EINVAL;
>> - }
>> - return 0;
>> -}
>> -
>> -static void vbox_ttm_io_mem_free(struct ttm_bo_device *bdev,
>> - struct ttm_mem_reg *mem)
>> -{
>> -}
>> -
>> -static void vbox_ttm_backend_destroy(struct ttm_tt *tt)
>> -{
>> - ttm_tt_fini(tt);
>> - kfree(tt);
>> -}
>> -
>> -static struct ttm_backend_func vbox_tt_backend_func = {
>> - .destroy = _ttm_backend_destroy,
>> -};
>> -
>> -static struct ttm_tt *vbox_ttm_tt_create(struct ttm_buffer_object *bo,
>> - u32 page_flags)
>> -{
>> - struct ttm_tt *tt;
>> -
>> - tt = kzalloc(sizeof(*tt), GFP_KERNEL);
>> - if (!tt)
>> - return NULL;
>> -
>> - tt->func = _tt_backend_func;
>> - if (ttm_tt_init(tt, bo, page_flags)) {
>> - kfree(tt);
>> - return NULL;
>> - }
>> -
>> - return tt;
>> -}
>> -
>> -static struct ttm_bo_driver vbox_bo_driver = {
>> - .ttm_tt_create = vbox_ttm_tt_create,
>> - .init_mem_type = vbox_bo_init_mem_type,
>> - .eviction_valuable = ttm_bo_eviction_valuable,
>> +static const struct drm_simple_ttm_funcs
Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
On Mon, Apr 08, 2019 at 02:17:27PM +0200, Ondřej Jirman wrote: > On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote: > > On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote: > > > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard > > > wrote: > > > > > > > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote: > > > > > From: Ondrej Jirman > > > > > > > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO > > > > > connected > > > > > transistors, before it can be used. Model this as a power supply for > > > > > DDC > > > > > (via regulator framework). > > > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > > > The DDC bus itself is usually attached to the HDMI connector, so it > > > > would make sense to make the supply also a property of the connector. > > > > > > I believe these are separate things. What this patch covers is power for > > > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's > > > 5V supply to power the remote DDC chip is something else. And on the > > > Orange Pi 3 they are indeed separate supplies. > > > > Then maybe the endpoint link between the two would be the best place > > to put this? > > Interestingly node configures the DDC bus pins via pinctrl on the SoC > side, so I put this there too, because it's related to those pins. I'm not > sure > if that changes anything in the discussion. It's kind of different though. The DDC controller is within the HDMI controller, which is inside the SoC. Just like the pin muxer. As far as the hardware goes, even on your board, you don't need that supply so that the signal gets out of the SoC. If the regulator is to power up some component on the path between the SoC and the connector, then it should be attached there. 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: [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
[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 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 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 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
[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 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: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 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 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
Re: [PATCH 1/2] drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
On 4/8/19 9:13 PM, Christian König wrote:
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).
Series is Reviewed-by: Junwei Zhang
Regards,
Jerry
Signed-off-by: Jann Horn
Signed-off-by: Christian König
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;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
Hi Gerd, On Tue, 9 Apr 2019 09:22:18 +0200 Gerd Hoffmann wrote: > > On Tue, Apr 09, 2019 at 04:08:49PM +1000, Stephen Rothwell wrote: > > Hi all, > > > > After merging the drm-misc tree, today's linux-next build (powerpc > > allyesconfig) failed like this: > > > > drivers/gpu/drm/cirrus/cirrus.c: In function 'cirrus_fb_blit_rect': > > drivers/gpu/drm/cirrus/cirrus.c:310:25: error: implicit declaration of > > function '__io_virt'; did you mean '__do_irq'? > > [-Werror=implicit-function-declaration] > >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > > ^ > > __do_irq > > Probably just a missing arm/io.h include. I assume you meant asm/io.h? -- Cheers, Stephen Rothwell pgpZIh9G9GYtk.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Mon, Apr 08, 2019 at 11:41:38AM +0530, Jagan Teki wrote: > On Sat, Apr 6, 2019 at 5:15 AM wrote: > > > > From: Ondrej Jirman > > > > Orange Pi 3 has two regulators that power the Realtek RTL8211E. > > According to the phy datasheet, both regulators need to be enabled > > at the same time, but we can only specify a single phy-supply in > > the DT. > > > > This can be achieved by making one regulator depedning on the > > other via vin-supply. While it's not a technically correct > > description of the hardware, it achieves the purpose. > > > > All values of RX/TX delay were tested exhaustively and a middle > > one of the working values was chosen. > > > > Signed-off-by: Ondrej Jirman > > --- > > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++ > > 1 file changed, 44 insertions(+) > > This was in ML[1], I thought this change would already merged. I > remember Chen-Yu applied and revert due to emac node not mainlined at > that time. > > [1] https://patchwork.kernel.org/patch/10558281/ The patch was not merged at the time, and bitrotted a bit. Armbian folks were applying the bitortted patch out-of-the mainline and were experiencing NPEs. I fixed the patch, and it is also part of this series. It's patch 5. o. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 2/5] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: Wangyan Wang
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 67a814649e19..844e622f052c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -116,8 +116,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.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 Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote: > - 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
Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Mon, Apr 08, 2019 at 09:46:28AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:03AM +0200, meg...@megous.com 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| 212 ++
> > 2 files changed, 213 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 ..7a2424fcaed7
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -0,0 +1,212 @@
> > +// 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";
>
> As Clement pointed out, this should be documented in
> Documentation/devicetree/bindings/arm/sunxi.yaml
>
> It's part of sunxi/for-next only at this point, and it will go through
> a different branch than the H6 DTS, so it would be great to have it in
> a separate patch.
>
> > + 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;
> > + };
> > +};
> > +
> > + {
> > + cpu-supply = <_dcdca>;
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>;
> > + vmmc-supply = <_cldo1>;
> > + cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > + {
> > + 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>;
> > +
> > + regulators {
> > + reg_aldo1: aldo1 {
>
Re: [linux-sunxi] Re: [PATCH 02/12] drm: sun4i: Add support for enabling DDC I2C bus to dw_hdmi glue
On Mon, Apr 08, 2019 at 10:47:14AM +0200, Maxime Ripard wrote: > On Mon, Apr 08, 2019 at 03:28:24PM +0800, Chen-Yu Tsai wrote: > > On Mon, Apr 8, 2019 at 3:23 PM Maxime Ripard > > wrote: > > > > > > On Sat, Apr 06, 2019 at 01:45:04AM +0200, meg...@megous.com wrote: > > > > From: Ondrej Jirman > > > > > > > > Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected > > > > transistors, before it can be used. Model this as a power supply for DDC > > > > (via regulator framework). > > > > > > > > Signed-off-by: Ondrej Jirman > > > > > > The DDC bus itself is usually attached to the HDMI connector, so it > > > would make sense to make the supply also a property of the connector. > > > > I believe these are separate things. What this patch covers is power for > > a voltage shifter between the SoC and HDMI DDC pins. The HDMI connector's > > 5V supply to power the remote DDC chip is something else. And on the > > Orange Pi 3 they are indeed separate supplies. > > Then maybe the endpoint link between the two would be the best place > to put this? Interestingly node configures the DDC bus pins via pinctrl on the SoC side, so I put this there too, because it's related to those pins. I'm not sure if that changes anything in the discussion. regards, o. > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 0/5] make mt7623 clock of hdmi stable
From: Wangyan Wang
V9 adopt maintainer's suggestion.
Here is the change list between V8 & V9
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
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Hi, On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson wrote: > > Hi, > > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko wrote: > > > > Hi, > > > > The difference would be in this format just setting hfront-porch = 87 > > and vback-porch = 14. > > Anyways the point is: I support moving this mode info into the dts, > > and I'd like to know how if at all should i go about getting a > > 60Hz(ish) mode upstreamed? > > I'm a bit torn here. I like the idea of actually getting 60 Hz and > you also increase the vblank time by a little bit (which means that if > anyone ever gets DDRFreq upstream it will work better). ...but I'm > also slightly nervous changing something like this without a really > good motivation. As you said in your commit message the pixels clocks > claimed by the spec don't actually all work and thus, to some extent, > we can only rely on trial-and-error here. While your new mode works > well on your device (and you wisely gave it a bit of margin), it is > _possible_ that there could be devices out there where it doesn't work > (especially across various temperature extremes). All devices were > tested in the factory with the old timings and presumably have been > running fine for years like that... Re: the trial and error: it might be the case that the panels actually work at 1506 vtotal if you also adjust the sync length and/or back porch "accordingly", whatever that accordingly would be for this panel since the datasheet doesnt tell. I missed this point when i was doing my testing and just adjusted the variables with the most "adjustability" (bigger starting value) to them. > I will certainly admit that it's unlikely devices would be affected, > but at the same time I'd want to know how much of a difference going > from 58.3 Hz to 60 Hz made for you. Could you actually notice any > visible difference, or was it just nice to be at 60 Hz? Honestly I was just doing this because i really liked the idea of actually making it 60Hz and my eyes arent that good at noticing high-fps things - i think the one case where it might be visible to a keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..) frames a second if running at 58.3 Hz. But currently the C201 isnt doing a lot of that given i dont think i/we have a good software setup for it. That could be changing in the future with panfrost and the VPU hardware decoder support, etc. Anyways I'm thinking it would be prudent to first get this framework of device-tree modes in and then maybe adjust the mode later. Testing the 60Hz mode is simple enough: xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802 -HSync -VSync xrandr --addmode eDP-1 1366x768p60 xrandr --output eDP-1 --mode 1366x768p60 (The mode name can be anything...) So meanwhile I would appreciate it if we could get some test reports of the mode with other veyron chromebooks that have this panel :) -- Urja Rannikko ___ 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 11:46 AM, paulmck paul...@linux.ibm.com wrote: > On Mon, Apr 08, 2019 at 10:49:32AM -0400, Mathieu Desnoyers wrote: >> - 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
[PATCH V10 0/5] make mt7623 clock of hdmi stable
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
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
> > The call to of_get_parent returns a node pointer with refcount
> > incremented thus it must be explicitly decremented after the last
> > usage.
> >
> > Detected by coccinelle with the following warnings:
> > drivers/gpu/drm/rcar-du/rcar_du_of.c:235:2-8: ERROR: missing of_node_put;
> > acquired a node pointer with refcount incremented on line 216, but without
> > a corresponding object release within this function.
> > drivers/gpu/drm/rcar-du/rcar_du_of.c:236:2-8: ERROR: missing of_node_put;
> > acquired a node pointer with refcount incremented on line 209, but without
> > a corresponding object release within this function.
> >
> > Signed-off-by: Wen Yang
> > Suggested-by: Laurent Pinchart
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org (open list)
> > ---
> > v2->v1: turn the return into a goto done.
> >
> > drivers/gpu/drm/rcar-du/rcar_du_of.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > index afef696..782bfc7 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
> > @@ -232,7 +232,7 @@ static void __init rcar_du_of_lvds_patch(const struct
> > of_device_id *of_ids)
> > lvds_node = of_find_compatible_node(NULL, NULL, compatible);
> > if (lvds_node) {
> > of_node_put(lvds_node);
> > -return;
> > +goto done;
> > }
> >
>
>
> you might have to create multiple level to do handling it.. there are
> unnecessary put being done on "done" which is not valid
>
> for this case.
Hi Mukesh,
Thank you for your comments.
lvds_data has been initialized to 0,
so the put operation in the done tag may have no effect:
199 struct lvds_of_data lvds_data[2] = { };
...
309 done:
310 for (i = 0; i < info->num_lvds; ++i) {
311 of_node_put(lvds_data[i].clkspec.np);
312 of_node_put(lvds_data[i].local);
313 of_node_put(lvds_data[i].remote);
314 }
315
316 of_node_put(soc_node);
317 of_node_put(du_node);
---
Thanks and regards,
Wen___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 5/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
From: Wangyan Wang
This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 6 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 9e153e080739..e3a6b50e0cf2 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index d28b8d5ed2b4..2d8b3182470d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,8 +49,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b24ea6651db4..e3f05ad89b1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -106,6 +106,12 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(80, 100);
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+
+{
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 625739b4e938..78c638c29102 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -199,6 +199,20 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(100, 150);
}
+long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 4/5] drm/mediatek: make implementation of recalc_rate() to match the definition
From: Wangyan Wang
Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 8 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 39 +++---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 0879ce47d4c5..9e153e080739 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,14 +29,6 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 0045824c1be9..d28b8d5ed2b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -51,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 844e622f052c..b24ea6651db4 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
@@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
RG_HTPLL_IC_MASK);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
@@ -154,6 +153,40 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (readl(hdmi_phy->regs + HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (readl(hdmi_phy->regs + HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ return out_rate;
+}
+
Re: [PATCH v2] drm: rcar-du: fix possible object reference leak
> v2->v1: turn the return into a goto done. * The version identification can be shorter, can't it? * The expection handling should be completed for the implementation of the function “rcar_du_of_lvds_patch” in a different way. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rcar-du/rcar_du_of.c?id=ac5b84a1ffe93c9fb882c0f2bdfac1c33077b920#n195 How do you think about to add a few jump targets (at the end)? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 2/5] drm/mediatek: fix the rate and divder of hdmi phy for MT2701
From: Wangyan Wang
Due to a clerical error,there is one zero less for 1280.
Fix it for 12800
Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 67a814649e19..844e622f052c 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -116,8 +116,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (rate <= 6400)
pos_div = 3;
- else if (rate <= 1280)
- pos_div = 1;
+ else if (rate <= 12800)
+ pos_div = 2;
else
pos_div = 1;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 4/5] drm/mediatek: make implementation of recalc_rate() to match the definition
From: Wangyan Wang
Recalculate the rate of this clock, by querying hardware to
make implementation of recalc_rate() to match the definition.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 8 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 39 +++---
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 8 ++
4 files changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 0879ce47d4c5..9e153e080739 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,14 +29,6 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned
long rate,
return rate;
}
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- return hdmi_phy->pll_rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 0045824c1be9..d28b8d5ed2b4 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -51,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
- unsigned long parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 844e622f052c..b24ea6651db4 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
- mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
- mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
@@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
RG_HTPLL_IC_MASK);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
@@ -154,6 +153,40 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+ unsigned long out_rate, val;
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+ switch (val) {
+ case 0x00:
+ out_rate = parent_rate;
+ break;
+ case 0x01:
+ out_rate = parent_rate / 2;
+ break;
+ default:
+ out_rate = parent_rate / 4;
+ break;
+ }
+
+ val = (readl(hdmi_phy->regs + HDMI_CON6)
+ & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+ out_rate *= (val + 1) * 2;
+ val = (readl(hdmi_phy->regs + HDMI_CON2)
+ & RG_HDMITX_TX_POSDIV_MASK);
+
+ out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+ if (readl(hdmi_phy->regs + HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+ out_rate = out_rate / 5;
+
+ return out_rate;
+}
+
[PATCH V9 3/5] drm/mediatek: using new factor for tvdpll in MT2701
From: Wangyan Wang
This is the second step to make MT2701 HDMI stable.
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Test: search ok
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 3/5] drm/mediatek: using new factor for tvdpll in MT2701
From: Wangyan Wang
This is the second step to make MT2701 HDMI stable.
The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.
Test: search ok
Reviewed-by: CK Hu
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
static unsigned int mt2701_calculate_factor(int clock)
{
if (clock <= 64000)
- return 16;
- else if (clock <= 128000)
- return 8;
- else if (clock <= 256000)
return 4;
- else
+ else if (clock <= 128000)
return 2;
+ else
+ return 1;
}
static const struct mtk_dpi_conf mt8173_conf = {
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: simple: Add support for VXT VL050-8048NT-C01 panel
On Mon, Apr 1, 2019 at 12:21 PM Fabio Estevam wrote: > On Mon, Feb 18, 2019 at 9:27 PM Fabio Estevam wrote: > > > > Add support for the VXT VL050-8048NT-C01 800x480 panel to the > > panel-simple driver. > > > > This panel is used on some boards manufactured by TechNexion, such as > > imx7d-pico. > > > > Reviewed-by: Otavio Salvador > > Reviewed-by: Sam Ravnborg > > Signed-off-by: Fabio Estevam > > Any feedback, please? > > Trying to get this one upstreamed for four months already and hope to > get it to 5.2. Any news on this? It has been waiting for review for a while. Is there someone else who could review this? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Mon, Apr 08, 2019 at 09:40:42AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:09AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 has two regulators that power the Realtek RTL8211E.
> > According to the phy datasheet, both regulators need to be enabled
> > at the same time, but we can only specify a single phy-supply in
> > the DT.
> >
> > This can be achieved by making one regulator depedning on the
> > other via vin-supply. While it's not a technically correct
> > description of the hardware, it achieves the purpose.
> >
> > All values of RX/TX delay were tested exhaustively and a middle
> > one of the working values was chosen.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 44 +++
> > 1 file changed, 44 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > index 644946749088..5270142527f5 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
> > @@ -15,6 +15,7 @@
> >
> > aliases {
> > serial0 =
> > + ethernet0 =
> > };
> >
> > chosen {
> > @@ -64,6 +65,27 @@
> > regulator-max-microvolt = <500>;
> > regulator-always-on;
> > };
> > +
> > + /*
> > +* The board uses 2.5V RGMII signalling. Power sequence
> > +* to enable the phy is to enable GMAC-2V5 and GMAC-3V3 (aldo2)
> > +* power rails at the same time and to wait 100ms.
> > +*/
> > + reg_gmac_2v5: gmac-2v5 {
> > +compatible = "regulator-fixed";
> > +regulator-name = "gmac-2v5";
> > +regulator-min-microvolt = <250>;
> > +regulator-max-microvolt = <250>;
> > +startup-delay-us = <10>;
> > +enable-active-high;
> > +gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
>
> Is enable-active-high still needed? It's redundant with the
> GPIO_ACTIVE_HIGH flag.
Looking at the code, use/non-use of enable-active-high inhibits
flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag
is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would
ignore it too and print a warning).
So enable-active-high is still necessary here.
See comment in gpiolib-of.c where this is handled:
/*
* The regulator GPIO handles are specified such that the
* presence or absence of "enable-active-high" solely controls
* the polarity of the GPIO line. Any phandle flags must
* be actively ignored.
*/
regards,
o.
> The indentation is wrong here as well.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 1/5] drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate rate change to parent
From: Wangyan Wang
This is the first step to make MT2701 hdmi stable.
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13bbaf997819 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -110,13 +110,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+ struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -129,7 +127,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -167,7 +164,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, _init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
hdmi_phy->pll_hw.init = _init;
hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..0045824c1be9 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..67a814649e19 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -202,6 +202,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..f44066875dcd 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -309,6 +309,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 5/5] drm/mediatek: no change parent rate in round_rate() for mt2701 hdmi phy
From: Wangyan Wang
This is the third step to make MT2701 HDMI stable.
We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 2 --
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 6 ++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
4 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 9e153e080739..e3a6b50e0cf2 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
};
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
- struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
- hdmi_phy->pll_rate = rate;
- if (rate <= 7425)
- *parent_rate = rate;
- else
- *parent_rate = rate / 2;
-
- return rate;
-}
-
void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 bits)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index d28b8d5ed2b4..2d8b3182470d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -49,8 +49,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32
offset,
void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
u32 val, u32 mask);
struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
extern struct platform_driver mtk_hdmi_phy_driver;
extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b24ea6651db4..e3f05ad89b1e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -106,6 +106,12 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(80, 100);
}
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 625739b4e938..78c638c29102 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -199,6 +199,20 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
usleep_range(100, 150);
}
+long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+ hdmi_phy->pll_rate = rate;
+ if (rate <= 7425)
+ *parent_rate = rate;
+ else
+ *parent_rate = rate / 2;
+
+ return rate;
+}
+
static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V10 1/5] drm/mediatek: remove flag CLK_SET_RATE_PARENT for mt2701 hdmi phy to not propagate rate change to parent
From: Wangyan Wang
This is the first step to make MT2701 hdmi stable.
The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.
Signed-off-by: Wangyan Wang
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 1 +
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 1 +
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13bbaf997819 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -110,13 +110,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy
*hdmi_phy)
return NULL;
}
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+ struct clk_init_data *clk_init)
{
- if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
- *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
- else
- dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+ clk_init->flags = hdmi_phy->conf->flags;
+ clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
}
static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -129,7 +127,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
struct phy *phy;
@@ -167,7 +164,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
- mtk_hdmi_phy_clk_get_ops(hdmi_phy, _init.ops);
+ mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
hdmi_phy->pll_hw.init = _init;
hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..0045824c1be9 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
struct mtk_hdmi_phy_conf {
bool tz_disabled;
+ unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..67a814649e19 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -202,6 +202,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+ .flags = CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..f44066875dcd 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -309,6 +309,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy
*hdmi_phy)
}
struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> On Sat, Apr 06, 2019 at 01:45:10AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 91fecab58836..dccad79da90c 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -238,6 +238,15 @@
> > bias-pull-up;
> > };
> >
> > +
>
> Extra line
>
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2", "PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
>
> Is that the only muxing option?
I don't think so. I believe someone can use a 1-bit interface (bus-width = <1>),
and then some data pins will be free. This pinconfig is for 4-bit bus width
setup.
Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
4-bit config the default pinctrl for mmc1. To add to the confusion, on these
SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit) default.
This led to some confusion in the past.
So we can either:
- keep consistency with what is done elsewhere, and make this default, despite
not being the only option,
- or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make it
more explicit, and keep it non-default.
What do you think is better?
thank you and regards,
o.
> If so, then it should be assigned by default to mmc1
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: Need a pair decrement for fence's refcount if ttm_bo_add_move_fence failed?
> 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?
Thanks,
Lin Yi.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
On 05/04/2019 11:36, Steven Price wrote:
> On 05/04/2019 10:51, Robin Murphy wrote:
>> Hi Steve,
>>
>> On 05/04/2019 10:42, Steven Price wrote:
>>> First let me say congratulations to everyone working on Panfrost - it's
>>> an impressive achievement!
>>>
>>> Full disclosure: I used to work on the Mali kbase driver. And have been
>>> playing around with running the Mali user-space blob with the Panfrost
>>> kernel driver.
>>>
>>> On 01/04/2019 08:47, Rob Herring wrote:
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.
>>>
>>> The nG bit should be ignored by the hardware.
>>>
>>> The MMU in Midgard/Bifrost has a quirk similar to
>>> IO_PGTABLE_QUIRK_TLBI_ON_MAP - you must perform a cache flush for the
>>> GPU to (reliably) pick up new page table mappings.
>>>
>>> You may not have seen this because of the use of the JS_CONFIG_START_MMU
>>> bit - this effectively performs a cache flush and TLB invalidate before
>>> starting a job, however when using a GPU like T760 (e.g. on the Firefly
>>> RK3288) this bit isn't being set. In my testing on the Firefly board I
>>> saw GPU page faults because of this.
>>>
>>> There's two options for fixing this - a patch like below adds the quirk
>>> mode to the MMU. Or alternatively always set JS_CONFIG_START_MMU on
>>> jobs. In my testing both options solve the page faults.
>>>
>>> To be honest I don't know the reasoning behind kbase making the
>>> JS_CONFIG_START_MMU bit conditional - I'm not aware of any reason why it
>>> can't always be set. My guess is performance, but I haven't benchmarked
>>> the difference between this and JS_CONFIG_START_MMU.
>>>
>>> -8<--
>>> From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
>>> From: Steven Price
>>> Date: Thu, 4 Apr 2019 15:53:17 +0100
>>> Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE
>>>
>>> Midgard/Bifrost GPUs require a TLB invalidation when mapping pages,
>>> implement IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE iommu page table
>>> formats and add the quirk bit to Panfrost.
>>>
>>> Signed-off-by: Steven Price
>>> ---
>>> drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
>>> drivers/iommu/io-pgtable-arm.c | 11 +--
>>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> index f3aad8591cf4..094312074d66 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
>>> @@ -343,6 +343,7 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
>>> mmu_write(pfdev, MMU_INT_MASK, ~0);
>>>
>>> pfdev->mmu->pgtbl_cfg = (struct io_pgtable_cfg) {
>>> + .quirks = IO_PGTABLE_QUIRK_TLBI_ON_MAP,
>>> .pgsize_bitmap = SZ_4K, // | SZ_2M | SZ_1G),
>>> .ias = 48,
>>> .oas = 40, /* Should come from dma mask? */
>>> diff --git a/drivers/iommu/io-pgtable-arm.c
>>> b/drivers/iommu/io-pgtable-arm.c
>>> index 84beea1f47a7..45fd7bbdf9aa 100644
>>> --- a/drivers/iommu/io-pgtable-arm.c
>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>> @@ -505,7 +505,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops,
>>> unsigned long iova,
>>> * Synchronise all PTE updates for the new mapping before there's
>>> * a chance for anything to kick off a table walk for the new iova.
>>> */
>>> - wmb();
>>> + if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
>>> + io_pgtable_tlb_add_flush(>iop, iova, size,
>>> + ARM_LPAE_BLOCK_SIZE(2, data), false);
>>
>> For correctness (in case this ever ends up used for something with
>> VMSA-like invalidation behaviour), the granule would need to be "size"
>> here, rather than effectively hard-coded.
>
> Ah yes - I did rather just copy/paste this from io-pgtable-arm-v7s with
> minor fix-ups.
>
>> However, since Mali's invalidations appear to operate on arbitrary
>> ranges, it would probably be a lot more efficient for the driver to
>> handle this case directly, by just issuing a single big invalidation
>> after the for_each_sg() loop in panfrost_mmu_map().
>
> Yes - that would
Re: [PATCH v2] drm/meson: fix possible object reference leak
> > v2->v1: convert a if statement into a ternary statement.
>
> Would you like to omit the arrow in such version information?
Thank you for your comments
The information about the previous versions goes below the ---,
and only the reviewers can see it.
It does not appear in the git log log.
Thanks.
> > @@ -720,15 +720,10 @@ static bool meson_hdmi_connector_is_available(struct
> > device *dev)
> >
> > /* If the endpoint node exists, consider it enabled */
> > remote = of_graph_get_remote_port(ep);
> > -if (remote) {
> > -of_node_put(ep);
> > -return true;
> > -}
> > -
> > of_node_put(ep);
> > of_node_put(remote);
>
> Can a reordering of the passed variables be useful for such function calls?
>
> + of_node_put(remote);
> + of_node_put(ep);
>
Thank you.
But considering the multiprocessor concurrent execution,
the reverse of the order of these two statements may not have additional
benefits.
The previous code implementation also maintains this order,
and we will keep the original order unless we can prove that the reverse order
can indeed bring real benefits.
--
Regards,
Wen___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On Tue, Apr 09, 2019 at 06:08:55PM +1000, Stephen Rothwell wrote: > Hi Gerd, > > > >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > > > ^ > > > __do_irq > > > > Probably just a missing arm/io.h include. > > I assume you meant asm/io.h? Yes. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 00/12] Add support for Orange Pi 3
Hi Jagan, On Mon, Apr 08, 2019 at 11:31:22AM +0530, Jagan Teki wrote: > On Sun, Apr 7, 2019 at 8:02 PM 'Ondřej Jirman' via linux-sunxi > wrote: > > > > On Sun, Apr 07, 2019 at 03:36:21PM +0200, Clément Péron wrote: > > > Hi, > > > > > > On Sat, 6 Apr 2019 at 01:45, megous via linux-sunxi > > > wrote: > > > > > > > > From: Ondrej Jirman > > > > > > > > This series implements support for Xunlong Orange Pi 3 board. > > > > > > OrangePi 3 Lite2 and One Plus boards support has already been merged. > > > The support is not complete but you should rebase your patches on top > > > of sunxi/for-next > > > > Hi, > > > > OrangePi 3 is somewhat different from these two boards (mostly it has a > > differnt > > power tree). It doesn't use the AXP regulators that are defined in the > > sun50i-h6-orangepi.dtsi in the same way. > > > > For example: > > > > - bldo3 (is turned always on in sun50i-h6-orangepi.dtsi but unused for opi3) > > - cldo2 and cldo3 are unused on opi3 and have nothing to do with WiFi > > - aldo3 is not for dram > > - bldo1 on the other hand is for dram on opi3 > > - some other regulators are used for different/more functions and thus > > named differntly > > - USB id-det pin is differnt > > - ... > > Based on my communication with OrangePI, OPI-3 has PCIE, 4 USB-3.0 > ports and AV are the key differences and rest seems to be similar. but > if we have a diff or unused regulators may be we can't enable them in > dtsi (I never looked that close as of now) These regulators are not just disabled on Opi 3, they have different/no meaning. 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). thank you and regards, o. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/omap: fix possible object reference leak
On 4/8/2019 8:28 AM, Wen Yang wrote: The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Mukesh Ojha Cheers, -Mukesh Reviewed-by: Laurent Pinchart Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring --- v2->v1: add a jump target. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 2b41c75..13b3b4a 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -209,7 +209,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -234,6 +234,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/meson: fix possible object reference leak
> v2->v1: convert a if statement into a ternary statement.
Would you like to omit the arrow in such version information?
> @@ -720,15 +720,10 @@ static bool meson_hdmi_connector_is_available(struct
> device *dev)
>
> /* If the endpoint node exists, consider it enabled */
> remote = of_graph_get_remote_port(ep);
> - if (remote) {
> - of_node_put(ep);
> - return true;
> - }
> -
> of_node_put(ep);
> of_node_put(remote);
Can a reordering of the passed variables be useful for such function calls?
+ of_node_put(remote);
+ of_node_put(ep);
Regards,
Markus
___
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
[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
[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 #1 from jian-h...@endlessm.com --- The [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900] 01:00.0 Display controller [0380]: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1002:6900] (rev c3) Subsystem: Acer Incorporated [ALI] Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] [1025:1217] Physical Slot: 0 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d000 (64-bit, prefetchable) [size=2M] I/O ports at 3000 [size=256] Memory at d140 (32-bit, non-prefetchable) [size=256K] Expansion ROM at d144 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Capabilities: [270] #19 Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Kernel driver in use: amdgpu Kernel modules: amdgpu -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/cirrus/cirrus.c: In function 'cirrus_fb_blit_rect':
drivers/gpu/drm/cirrus/cirrus.c:310:25: error: implicit declaration of function
'__io_virt'; did you mean '__do_irq'? [-Werror=implicit-function-declaration]
drm_fb_memcpy_dstclip(__io_virt(cirrus->vram),
^
__do_irq
drivers/gpu/drm/cirrus/cirrus.c:310:25: warning: passing argument 1 of
'drm_fb_memcpy_dstclip' makes pointer from integer without a cast
[-Wint-conversion]
drm_fb_memcpy_dstclip(__io_virt(cirrus->vram),
^~~
In file included from drivers/gpu/drm/cirrus/cirrus.c:33:
include/drm/drm_format_helper.h:18:34: note: expected 'void *' but argument is
of type 'int'
void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct drm_framebuffer *fb,
~~^~~
drivers/gpu/drm/cirrus/cirrus.c:314:37: warning: passing argument 1 of
'drm_fb_xrgb_to_rgb565_dstclip' makes pointer from integer without a cast
[-Wint-conversion]
drm_fb_xrgb_to_rgb565_dstclip(__io_virt(cirrus->vram),
^~~
In file included from drivers/gpu/drm/cirrus/cirrus.c:33:
include/drm/drm_format_helper.h:25:46: note: expected 'void *' but argument is
of type 'int'
void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned int dst_pitch,
~~^~~
drivers/gpu/drm/cirrus/cirrus.c:319:37: warning: passing argument 1 of
'drm_fb_xrgb_to_rgb888_dstclip' makes pointer from integer without a cast
[-Wint-conversion]
drm_fb_xrgb_to_rgb888_dstclip(__io_virt(cirrus->vram),
^~~
In file included from drivers/gpu/drm/cirrus/cirrus.c:33:
include/drm/drm_format_helper.h:28:46: note: expected 'void *' but argument is
of type 'int'
void drm_fb_xrgb_to_rgb888_dstclip(void *dst, unsigned int dst_pitch,
~~^~~
Caused by commit
ab3e023b1b4c ("drm/cirrus: rewrite and modernize driver.")
I have marked that driver BROKEN for today.
--
Cheers,
Stephen Rothwell
pgpdJS8HZY6y3.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gma500: Add CedarView LVDS blacklist
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.
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 12/15] drm/vboxvideo: Convert vboxvideo driver to |struct drm_gem_ttm_object|
Hi,
On 08-04-19 11:21, Thomas Zimmermann wrote:
This patch replaces |struct vbox_bo| and its helpers with the generic
implementation of |struct drm_gem_ttm_object|. The only change in
semantics is that _bo_driver.verify_access() now does the actual
verification.
Signed-off-by: Thomas Zimmermann
Nice cleanup, thank you, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/Kconfig | 1 +
drivers/gpu/drm/vboxvideo/vbox_drv.c | 5 +-
drivers/gpu/drm/vboxvideo/vbox_drv.h | 58 +--
drivers/gpu/drm/vboxvideo/vbox_fb.c | 22 +--
drivers/gpu/drm/vboxvideo/vbox_main.c | 70 +---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 36 +++--
drivers/gpu/drm/vboxvideo/vbox_ttm.c | 223 +-
7 files changed, 45 insertions(+), 370 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/Kconfig
b/drivers/gpu/drm/vboxvideo/Kconfig
index 1f4182e2e980..c1ca87df81df 100644
--- a/drivers/gpu/drm/vboxvideo/Kconfig
+++ b/drivers/gpu/drm/vboxvideo/Kconfig
@@ -3,6 +3,7 @@ config DRM_VBOXVIDEO
depends on DRM && X86 && PCI
select DRM_KMS_HELPER
select DRM_TTM
+ select DRM_GEM_TTM_HELPER
select GENERIC_ALLOCATOR
help
This is a KMS driver for the virtual Graphics Card used in
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index fb6a0f0b8167..75b165386935 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -215,9 +215,10 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_free_object_unlocked = vbox_gem_free_object,
+ .gem_free_object_unlocked =
+ drm_gem_ttm_driver_gem_free_object_unlocked,
.dumb_create = vbox_dumb_create,
- .dumb_map_offset = vbox_dumb_mmap_offset,
+ .dumb_map_offset = drm_gem_ttm_driver_dumb_mmap_offset,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
b/drivers/gpu/drm/vboxvideo/vbox_drv.h
index ece31f395540..7db4e961805d 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
@@ -170,73 +171,16 @@ int vboxfb_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
void vbox_fbdev_fini(struct vbox_private *vbox);
-struct vbox_bo {
- struct ttm_buffer_object bo;
- struct ttm_placement placement;
- struct ttm_bo_kmap_obj kmap;
- struct drm_gem_object gem;
- struct ttm_place placements[3];
- int pin_count;
-};
-
-#define gem_to_vbox_bo(gobj) container_of((gobj), struct vbox_bo, gem)
-
-static inline struct vbox_bo *vbox_bo(struct ttm_buffer_object *bo)
-{
- return container_of(bo, struct vbox_bo, bo);
-}
-
-#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
-
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
- return bo->bo.offset;
-}
-
int vbox_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-void vbox_gem_free_object(struct drm_gem_object *obj);
-int vbox_dumb_mmap_offset(struct drm_file *file,
- struct drm_device *dev,
- u32 handle, u64 *offset);
-
int vbox_mm_init(struct vbox_private *vbox);
void vbox_mm_fini(struct vbox_private *vbox);
-int vbox_bo_create(struct vbox_private *vbox, int size, int align,
- u32 flags, struct vbox_bo **pvboxbo);
-
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
-int vbox_bo_unpin(struct vbox_bo *bo);
-
-static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
-{
- int ret;
-
- ret = ttm_bo_reserve(>bo, true, no_wait, NULL);
- if (ret) {
- if (ret != -ERESTARTSYS && ret != -EBUSY)
- DRM_ERROR("reserve failed %p\n", bo);
- return ret;
- }
- return 0;
-}
-
-static inline void vbox_bo_unreserve(struct vbox_bo *bo)
-{
- ttm_bo_unreserve(>bo);
-}
-
-void vbox_ttm_placement(struct vbox_bo *bo, int domain);
-int vbox_bo_push_sysram(struct vbox_bo *bo);
int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
-void *vbox_bo_kmap(struct vbox_bo *bo);
-void vbox_bo_kunmap(struct vbox_bo *bo);
/* vbox_prime.c */
int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_fb.c
b/drivers/gpu/drm/vboxvideo/vbox_fb.c
index b724fe7c0c30..1cf0c6bd58b9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_fb.c
+++
Re: [PATCH 1/2] drm/lima: add missing Kconfig dependency
On 09/04/2019 02:36, Qiang Yu wrote:
> Current implementation does not support MMU-less
> plarforms.
>
> Cc: Randy Dunlap
You could also add :
Suggested-by: Randy Dunlap
Like patch 2.
But you can fix it while applying it
> 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.
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/12] arm64: dts: allwinner: h6: Add Orange Pi 3 DTS
On Tue, Apr 09, 2019 at 12:58:51AM +0200, Ondřej Jirman wrote:
> > > + {
> > > + dr_mode = "host";
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + usb0_id_det-gpios = < 2 15 GPIO_ACTIVE_HIGH>; /* PC15 */
> > > + usb0_vbus-supply = <_vcc5v>;
> > > + usb3_vbus-supply = <_vcc5v>;
> > > + status = "okay";
> >
> > If we have an ID pin, then why is the OTG controller set to host?
>
> This board has fixed conenction between VBUS and DCIN, so if it is powered
> from DCIN and someone will try to connect it to the PC as a peripheral,
> they'll get PC's VBUS shorted to the power supply connected to DCIN.
>
> Depending on voltage difference between DCIN and PC's VBUS, you can get
> overcurrent condidion and PC's port shutdown.
>
> The board is not entirely foolproof in this regard.
>
> - It can be host powered when connected via microUSB
> - It can be self-powered and host an device on microUSB
> - It can be self-powered and serve as a peripheral if you modify
> a cable (cut VBUS) or the host is expecting this and has some
> VBUS detection logic (most hosts will not have this)
>
> I just didn't want to encourage use as a peripheral, because it's not
> very foolproof. But I guess, DTS file will not stop anyone anyway.
>
> I'll change it to otg, and maybe leave a small note.
Your solution was great actually. I guess making a comment explaining
what you just did would be better though, so that no one is confused.
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: [PATCH 2/2] drm/lima: include used header file explicitly
On 09/04/2019 02:36, 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
>
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: build failure after merge of the drm-misc tree
On Tue, Apr 09, 2019 at 04:08:49PM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the drm-misc tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > drivers/gpu/drm/cirrus/cirrus.c: In function 'cirrus_fb_blit_rect': > drivers/gpu/drm/cirrus/cirrus.c:310:25: error: implicit declaration of > function '__io_virt'; did you mean '__do_irq'? > [-Werror=implicit-function-declaration] >drm_fb_memcpy_dstclip(__io_virt(cirrus->vram), > ^ > __do_irq Probably just a missing arm/io.h include. Test build is running ... cheers, Gerd ___ 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
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.
> + {
> + /*
> + * 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.
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: [PATCH 09/12] pinctrl: sunxi: Prepare for alternative bias voltage setting methods
Hi Linus, On Mon, Apr 08, 2019 at 02:53:58PM +0200, Linus Walleij wrote: > On Sat, Apr 6, 2019 at 1:45 AM 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 | 38 --- > > drivers/pinctrl/sunxi/pinctrl-sunxi.h | 4 ++- > > I need Maxime's ACK on these patches to merge. > > Can the pinctrl parts be applied independently of the rest > of the changes when Maxime is happy with the patches? Yes, the two pinctrl patches are independent of the rest of the series. thank you, Ondrej > Yours, > Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] sync_file: Return reasonable timestamp when merging signaled fences
If all the sync points were signaled in both fences a and b,
there was only one sync point in merged fence which is a_fence[0].
The Fence structure in android framework might be confused about
timestamp if there were any sync points which were signaled after
a_fence[0]. It might be more reasonable to use timestamp of last signaled
sync point to represent the merged fence.
The issue can be found from EGL extension ANDROID_get_frame_timestamps.
Sometimes the return value of EGL_READS_DONE_TIME_ANDROID is head of
the return value of EGL_RENDERING_COMPLETE_TIME_ANDROID.
That means display/composition had been completed before rendering
was completed that is incorrect.
Some discussion can be found at:
https://android-review.googlesource.com/c/kernel/common/+/907009
Signed-off-by: Michael Yang
---
drivers/dma-buf/sync_file.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 4f6305c..d46bfe1 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -274,8 +274,29 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
for (; i_b < b_num_fences; i_b++)
add_fence(fences, , b_fences[i_b]);
- if (i == 0)
- fences[i++] = dma_fence_get(a_fences[0]);
+ /* If all the sync pts were signaled, then adding the sync_pt who
+* was the last signaled to the fence.
+*/
+ if (i == 0) {
+ struct dma_fence *last_signaled_sync_pt = a_fences[0];
+ int iter;
+
+ for (iter = 1; iter < a_num_fences; iter++) {
+ if (ktime_compare(last_signaled_sync_pt->timestamp,
+ a_fences[iter]->timestamp) < 0) {
+ last_signaled_sync_pt = a_fences[iter];
+ }
+ }
+
+ for (iter = 0; iter < b_num_fences; iter++) {
+ if (ktime_compare(last_signaled_sync_pt->timestamp,
+ b_fences[iter]->timestamp) < 0) {
+ last_signaled_sync_pt = b_fences[iter];
+ }
+ }
+
+ fences[i++] = dma_fence_get(last_signaled_sync_pt);
+ }
if (num_fences > i) {
nfences = krealloc(fences, i * sizeof(*fences),
--
2.7.4
___
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 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() is invoked. > > So AFAIU it would be safe to issue the srcu_barrier() from the module > going notifier. > > Or am I missing something ? We do seem to be talking past each other. ;-) This has
Re: [PATCH RFC tip/core/rcu 0/4] Forbid static SRCU use in modules
- 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() is invoked. So AFAIU it would be safe to issue the srcu_barrier() from the module going notifier. Or am I missing something ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] media: uapi: Add RGB bus formats for the GiantPlus GPM940B0 panel
Hi Thierry, Le mer. 3 avril 2019 à 18:32, Thierry Reding a écrit : On Thu, Mar 14, 2019 at 01:26:20PM +0100, Paul Cercueil wrote: The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components are transferred sequentially on a 8-bit bus. Signed-off-by: Paul Cercueil --- Notes: v2: New patch include/uapi/linux/media-bus-format.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Please make sure you Cc the media maintainers on this one when you send the next version. Adding them now. Oops. Will do. diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index d6a5a3bfe6c4..f31724d6cd40 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED 0x0001 -/* RGB - next is 0x101b */ +/* RGB - next is 0x101d */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -54,6 +54,8 @@ #define MEDIA_BUS_FMT_RGB888_1X24 0x100a #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c +#define MEDIA_BUS_FMT_RGB888_3X8_BE 0x101b +#define MEDIA_BUS_FMT_RGB888_3X8_LE 0x101c The list looks roughly sorted, but these are not. That said, there are others that don't seem like they are sorted either. To me it looks like it's sorted alphabetically, that's why I put the two new macros there. All the more important to get feedback from the media maintainers. Thierry ___ 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 00/15] Share TTM code among framebuffer drivers
Hi, > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Depends pretty much on the device. The cirrus is a display device with only 4 MB of vram. You can't fit much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% of the video memory already. Which is why the cirrus driver (before the rewrite) had to migrate buffers from/to vram on every page flip[1]. Which is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the vram any more. gem objects are managed with the shmem helpers instead and the active framebuffer is blitted to vram. 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. A set of drm_gem_vram_* helpers would do the job for bochs. I'd expect the same applies to the vbox driver. Dunno about the other drm drivers and the fbdev drivers you plan to migrate over. cheers, Gerd [1] Note: The page-flip migration logic is present in some of the other drivers too, not sure whenever they actually need that due to being low on vram too or whenever they just copied the old cirrus code ... [2] The other reason is that this allow to convert formats at blit time, which helps to deal with some cirrus hardware limitations. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/12] arm64: dts: allwinner: h6: Add MMC1 pins
Hi,
On Tue, Apr 09, 2019 at 12:41:05AM +0200, Ondřej Jirman wrote:
> On Mon, Apr 08, 2019 at 09:43:27AM +0200, Maxime Ripard wrote:
> > On Sat, Apr 06, 2019 at 01:45:10AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > index 91fecab58836..dccad79da90c 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > @@ -238,6 +238,15 @@
> > > bias-pull-up;
> > > };
> > >
> > > +
> >
> > Extra line
> >
> > > + mmc1_pins: mmc1-pins {
> > > + pins = "PG0", "PG1", "PG2", "PG3",
> > > +"PG4", "PG5";
> > > + function = "mmc1";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> >
> > Is that the only muxing option?
>
> I don't think so. I believe someone can use a 1-bit interface (bus-width =
> <1>),
> and then some data pins will be free. This pinconfig is for 4-bit bus width
> setup.
>
> Though other SoCs (ex. H3, A83T) don't consider this possibility and make the
> 4-bit config the default pinctrl for mmc1. To add to the confusion, on these
> SoCs 4-bit pinconf is the default, but 1bit bus-width is the (implicit)
> default.
> This led to some confusion in the past.
>
> So we can either:
> - keep consistency with what is done elsewhere, and make this default, despite
> not being the only option,
What is done elsewhere is that if it's the only option, just call it
$controller_pins and make that the default. If it isn't, then call it
$(controller)_$(bank)_pins, and put it at the board level.
If it's not the only muxing option, then your name should be called
mmc1-pg-pins
> - or perhaps I can rename this to mmc1_bus_width4_pins, or somesuch, to make
> it
> more explicit, and keep it non-default.
We haven't encountered a case where the 1-bit bus was actually used,
so there's no need to take care of that.
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: [PATCH 07/12] arm64: dts: allwinner: orange-pi-3: Enable ethernet
On Tue, Apr 9, 2019 at 1:22 AM Ondřej Jirman wrote: > > > +enable-active-high; > > > +gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */ > > > > Is enable-active-high still needed? It's redundant with the > > GPIO_ACTIVE_HIGH flag. > > Looking at the code, use/non-use of enable-active-high inhibits > flags specified in gpio property. So the GPIO_ACTIVE_HIGH flag > is ignored here (had GPIO_ACTIVE_LOW been used, the kernel would > ignore it too and print a warning). > > So enable-active-high is still necessary here. > > See comment in gpiolib-of.c where this is handled: > > /* > * The regulator GPIO handles are specified such that the > * presence or absence of "enable-active-high" solely controls > * the polarity of the GPIO line. Any phandle flags must > * be actively ignored. > */ Yeah this caused me special headache in the current merge window because of buggy code on my part. This is an effect of this flag being defined for powerpc ages before we properly implemented generic GPIO bindings. We just have to respect it. See: https://marc.info/?l=linux-gpio=155417774822532=2 Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 110363] done
https://bugs.freedesktop.org/show_bug.cgi?id=110363 rj changed: What|Removed |Added CC||rohanjhaveri...@gmail.com Assignee|dri-devel@lists.freedesktop |rohanjhaveri...@gmail.com |.org| --- Comment #1 from rj --- Created attachment 143907 --> https://bugs.freedesktop.org/attachment.cgi?id=143907=edit voucher validation not work -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/15] Share TTM code among framebuffer drivers
On Tue, 9 Apr 2019 at 17:12, kra...@redhat.com wrote: > > Hi, > > > If not for TTM, what would be the alternative? One VMA manager per > > memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% > of the video memory already. Which is why the cirrus driver (before the > rewrite) had to migrate buffers from/to vram on every page flip[1]. Which > is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the > vram any more. gem objects are managed with the shmem helpers instead > and the active framebuffer is blitted to vram. > > 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. Dave. ___ 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
Hi Am 09.04.19 um 09:12 schrieb kra...@redhat.com: > Hi, > >> If not for TTM, what would be the alternative? One VMA manager per >> memory region per device? > > Depends pretty much on the device. > > The cirrus is a display device with only 4 MB of vram. You can't fit > much in there. A single 1024x768 @ 24bpp framebuffer needs more 50% > of the video memory already. Which is why the cirrus driver (before the > rewrite) had to migrate buffers from/to vram on every page flip[1]. Which > is one[2] of the reasons why cirrus (after rewrite) doesn't ttm-manage the > vram any more. gem objects are managed with the shmem helpers instead > and the active framebuffer is blitted to vram. > > 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. > > A set of drm_gem_vram_* helpers would do the job for bochs. Thanks for clarifying. drm_gem_vram_* (and drm_vram_mm for Simple TTM) is probably a better name for the data structures. > I'd expect the same applies to the vbox driver. > > Dunno about the other drm drivers and the fbdev drivers you plan to > migrate over. The AST HW can support up to 512 MiB, but 32-64 MiB seems more realistic for a server. It's similar with mgag200 HW. The old fbdev-supported device are all somewhere in the range between cirrus and bochs. Some drivers would probably benefit from the cirrus approach, some could use VRAM directly. Best regards Thomas > > cheers, > Gerd > > [1] Note: The page-flip migration logic is present in some of the other > drivers too, not sure whenever they actually need that due to being low > on vram too or whenever they just copied the old cirrus code ... > > [2] The other reason is that this allow to convert formats at blit time, > which helps to deal with some cirrus hardware limitations. > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
