[PATCH] drm/amd/powerplay: fix struct init in renoir_print_clk_levels
drivers/gpu/drm/amd/powerplay/renoir_ppt.c:186:2: error: missing braces
around initializer [-Werror=missing-braces]
SmuMetrics_t metrics = {0};
^
Fixes: 8b8031703bd7 ("drm/amd/powerplay: implement sysfs for getting dpm clock")
Signed-off-by: Raul E Rangel
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
index e62bfba51562..e5283dafc414 100644
--- a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
@@ -183,11 +183,13 @@ static int renoir_print_clk_levels(struct smu_context
*smu,
int i, size = 0, ret = 0;
uint32_t cur_value = 0, value = 0, count = 0, min = 0, max = 0;
DpmClocks_t *clk_table = smu->smu_table.clocks_table;
- SmuMetrics_t metrics = {0};
+ SmuMetrics_t metrics;
if (!clk_table || clk_type >= SMU_CLK_COUNT)
return -EINVAL;
+ memset(, 0, sizeof(metrics));
+
ret = smu_update_table(smu, SMU_TABLE_SMU_METRICS, 0,
(void *), false);
if (ret)
--
2.24.0.rc1.363.gb1bccd3e3d-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel crash on 4.19.77-1-lts (Arch Linux / ThinkPad T470p)
Continuing to see crashes, most recently on 4.19.81-1-lts On Fri, Oct 11, 2019 at 11:33 AM John Maguire wrote: > > Just use Cc. We want all replies to go to the list(s) as well. > Sorry, I wasn't sure and wanted to err on the side of not spamming the > wrong people. > > > Oct 10 12:53:30 scorpion kernel: RIP: > 0010:dma_fence_signal_locked+0x30/0xe0 > > > > > Looks like it could be > > https://bugs.freedesktop.org/show_bug.cgi?id=111381 > > > > in which case you just need to upgrade to 4.19.78 and it should be > > fixed. > > Thanks a bunch, not sure how I missed there was a new LTS kernel out. I > have upgraded and will report back if I continue to see the issue. > > Thanks for the quick support, > John > > On Fri, Oct 11, 2019 at 6:12 AM Ville Syrjälä < > ville.syrj...@linux.intel.com> wrote: > >> On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote: >> > Hi there, >> > >> > I wasn't sure which mailing list to use so I BCC'd >> > intel-...@lists.freedesktop.org and dri-devel@lists.freedesktop.org >> >> Just use Cc. We want all replies to go to the list(s) as well. >> >> > >> > I'm using a Lenovo Thinkpad T470p and running the 4.19.77-1-lts kernel >> on >> > Arch Linux. Recently, I've started getting freezes each day. Audio can >> > still be heard, but video output stops. I was able to retrieve a call >> trace >> > from journald. >> > >> > I've attached the output of "sudo lspci -vvv" as well as the message >> from >> > journald (null pointer dereference). >> >> Oct 10 12:53:30 scorpion kernel: RIP: >> 0010:dma_fence_signal_locked+0x30/0xe0 >> >> >> Looks like it could be >> https://bugs.freedesktop.org/show_bug.cgi?id=111381 >> >> in which case you just need to upgrade to 4.19.78 and it should be >> fixed. >> >> -- >> Ville Syrjälä >> Intel >> > trace Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal to report GPU private memory allocations with sysfs nodes [plain text version]
Hi Daniel, > - The labels are currently free-form, baking them back into your structure > would mean we'd need to do lots of hot add/remove of sysfs directory > trees. Which sounds like a real bad idea :-/ Given the free form of that ioctl, what's the plan of using that and the reporting of the labeled BOs? Do you think upstream kernel need to have certain resource category based tracking for gpu private allocations? > - Buffer objects aren't attached to pids, but files. And files can be > shared. If we want to list this somewhere outside of debugfs, we need to > tie this into the files somehow (so proc), except the underlying files > are all anon inodes, so this gets really tricky I think to make work > well. So there isn't any gpu private allocations on the upstream side? How does upstream deal with duplicate accounting for the shared memory? Best, Yiwei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2 v2] drm/atomic: fix self-refresh helpers crtc state dereference
On Mon, Nov 4, 2019 at 9:39 AM Rob Clark wrote:
>
> From: Rob Clark
>
> drm_self_refresh_helper_update_avg_times() was incorrectly accessing the
> new incoming state after drm_atomic_helper_commit_hw_done(). But this
> state might have already been superceeded by an !nonblock atomic update
> resulting in dereferencing an already free'd crtc_state.
>
> TODO I *think* this will more or less do the right thing.. althought I'm
> not 100% sure if, for example, we enter psr in a nonblock commit, and
> then leave psr in a !nonblock commit that overtakes the completion of
> the nonblock commit. Not sure if this sort of scenario can happen in
> practice. But not crashing is better than crashing, so I guess we
> should either take this patch or rever the self-refresh helpers until
> Sean can figure out a better solution.
btw, I think we can drop this TODO para from the commit msg.. but
would be nice to get this (1/2) landed in v5.4-fixes as it fixes an
actual regressions..
patch 2/2 probably shouldn't be for v5.4, since according to kbuild
robot it is turning up some other problems.. but I still think it is
probably a good idea
BR,
-R
>
> Fixes: d4da4e33341c ("drm: Measure Self Refresh Entry/Exit times to avoid
> thrashing")
> Cc: Sean Paul
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 14 +-
> drivers/gpu/drm/drm_self_refresh_helper.c | 15 +--
> include/drm/drm_self_refresh_helper.h | 3 ++-
> 3 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3ef2ac52ce94..648494c813e5 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1581,8 +1581,11 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> const struct drm_mode_config_helper_funcs *funcs;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc *crtc;
> ktime_t start;
> s64 commit_time_ms;
> + unsigned i, new_self_refresh_mask = 0;
>
> funcs = dev->mode_config.helper_private;
>
> @@ -1602,6 +1605,14 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
>
> drm_atomic_helper_wait_for_dependencies(old_state);
>
> + /*
> +* We cannot safely access new_crtc_state after
> drm_atomic_helper_commit_hw_done()
> +* so figure out which crtc's have self-refresh active beforehand:
> +*/
> + for_each_new_crtc_in_state(old_state, crtc, new_crtc_state, i)
> + if (new_crtc_state->self_refresh_active)
> + new_self_refresh_mask |= BIT(i);
> +
> if (funcs && funcs->atomic_commit_tail)
> funcs->atomic_commit_tail(old_state);
> else
> @@ -1610,7 +1621,8 @@ static void commit_tail(struct drm_atomic_state
> *old_state)
> commit_time_ms = ktime_ms_delta(ktime_get(), start);
> if (commit_time_ms > 0)
> drm_self_refresh_helper_update_avg_times(old_state,
> -(unsigned
> long)commit_time_ms);
> +(unsigned
> long)commit_time_ms,
> +new_self_refresh_mask);
>
> drm_atomic_helper_commit_cleanup_done(old_state);
>
> diff --git a/drivers/gpu/drm/drm_self_refresh_helper.c
> b/drivers/gpu/drm/drm_self_refresh_helper.c
> index 68f4765a5896..011b8d5f7dd6 100644
> --- a/drivers/gpu/drm/drm_self_refresh_helper.c
> +++ b/drivers/gpu/drm/drm_self_refresh_helper.c
> @@ -133,6 +133,8 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> * drm_self_refresh_helper_update_avg_times - Updates a crtc's SR time
> averages
> * @state: the state which has just been applied to hardware
> * @commit_time_ms: the amount of time in ms that this commit took to
> complete
> + * @new_self_refresh_mask: bitmask of crtc's that have self_refresh_active in
> + *new state
> *
> * Called after _mode_config_funcs.atomic_commit_tail, this function will
> * update the average entry/exit self refresh times on self refresh
> transitions.
> @@ -140,22 +142,23 @@ static void drm_self_refresh_helper_entry_work(struct
> work_struct *work)
> * entering self refresh mode after activity.
> */
> void drm_self_refresh_helper_update_avg_times(struct drm_atomic_state *state,
> - unsigned int commit_time_ms)
> + unsigned int commit_time_ms,
> + unsigned int
> new_self_refresh_mask)
> {
> struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_crtc_state *old_crtc_state;
> int i;
>
> - for_each_oldnew_crtc_in_state(state, crtc,
[PATCH V9 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Acked-by: Cornelia Huck
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 10 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet.c | 686 +
4 files changed, 698 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4997957443df..6e9ad105a28f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17249,6 +17249,7 @@ F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
F: include/linux/mdev_virtio_ops.h
+F: samples/vfio-mdev/mvnet.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..13a2443e18e0 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET
+ tristate "Build VIRTIO net example mediated device sample code --
loadable modules only"
+ depends on VIRTIO_MDEV && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device. The device coopreates with virtio-mdev bus
+ driver to present an virtio ethernet driver for
+ kernel. It simply loopbacks all packets from its TX
+ virtqueue to its RX virtqueue.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..f34af90ed0a0 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
new file mode 100644
index ..a89aecfab68a
--- /dev/null
+++ b/samples/vfio-mdev/mvnet.c
@@ -0,0 +1,686 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet
+ * # cd /sys/devices/virtual/mvnet/mvnet/mdev_supported_types/mvnet-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet"
+#define MVNET_NAME "mvnet"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ /* spinlock to synchronize virtqueue state */
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex mdev_list_lock;
+static struct list_head mdev_devices_list;
+
+static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned int idx)
+{
+ struct mvnet_virtqueue
[PATCH V9 5/6] virtio: introduce a mdev based transport
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
device specific ops which is a part of mdev_parent_ops now.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 13 ++
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 406 +++
3 files changed, 420 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..558ac607d107 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV
+ tristate "MDEV driver for virtio devices"
+ depends on VFIO_MDEV && VIRTIO
+ default n
+ help
+ This driver provides support for virtio based paravirtual
+ device driver over MDEV bus. This requires your environemnt
+ has appropriate virtio mdev device implementation which may
+ operate on the physical device that the datapath of virtio
+ could be offloaded to hardware.
+
+ If unsure, say M
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..f2997b6c812f 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..9e12ef240493
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ u64 features;
+
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ /* List of virtio_mdev_vq_info */
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ if (ops->get_generation)
+ return ops->get_generation(mdev);
+
+ return 0;
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+
[PATCH V9 4/6] mdev: introduce virtio device and its device ops
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
MAINTAINERS | 1 +
drivers/vfio/mdev/mdev_core.c| 21 +
drivers/vfio/mdev/mdev_private.h | 2 +
include/linux/mdev.h | 6 ++
include/linux/mdev_virtio_ops.h | 147 +++
5 files changed, 177 insertions(+)
create mode 100644 include/linux/mdev_virtio_ops.h
diff --git a/MAINTAINERS b/MAINTAINERS
index f661d13344d6..4997957443df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17248,6 +17248,7 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: include/linux/mdev_virtio_ops.h
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 4e70f19ac145..c58253404ed5 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -78,6 +78,27 @@ const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct
mdev_device *mdev)
}
EXPORT_SYMBOL(mdev_get_vfio_ops);
+/*
+ * Specify the virtio device ops for the mdev device, this
+ * must be called during create() callback for virtio mdev device.
+ */
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops)
+{
+ mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
+ mdev->virtio_ops = virtio_ops;
+}
+EXPORT_SYMBOL(mdev_set_virtio_ops);
+
+/* Get the virtio device ops for the mdev device. */
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev)
+{
+ WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
+ return mdev->virtio_ops;
+}
+EXPORT_SYMBOL(mdev_get_virtio_ops);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return >dev;
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
index 411227373625..2c74dd032409 100644
--- a/drivers/vfio/mdev/mdev_private.h
+++ b/drivers/vfio/mdev/mdev_private.h
@@ -11,6 +11,7 @@
#define MDEV_PRIVATE_H
#include
+#include
int mdev_bus_register(void);
void mdev_bus_unregister(void);
@@ -38,6 +39,7 @@ struct mdev_device {
u16 class_id;
union {
const struct mdev_vfio_device_ops *vfio_ops;
+ const struct mdev_virtio_device_ops *virtio_ops;
};
};
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 9e37506d1987..f3d75a60c2b5 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -17,6 +17,7 @@
struct mdev_device;
struct mdev_vfio_device_ops;
+struct mdev_virtio_device_ops;
/*
* Called by the parent device driver to set the device which represents
@@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
void mdev_set_vfio_ops(struct mdev_device *mdev,
const struct mdev_vfio_device_ops *vfio_ops);
const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device *mdev);
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops);
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev);
extern struct bus_type mdev_bus_type;
@@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_CLASS_ID_VFIO = 1,
+ MDEV_CLASS_ID_VIRTIO = 2,
/* New entries must be added here */
};
diff --git a/include/linux/mdev_virtio_ops.h b/include/linux/mdev_virtio_ops.h
new file mode 100644
index ..8951331c6629
--- /dev/null
+++ b/include/linux/mdev_virtio_ops.h
@@ -0,0 +1,147 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ * Author: Jason Wang
+ */
+#ifndef MDEV_VIRTIO_OPS_H
+#define MDEV_VIRTIO_OPS_H
+
+#include
+#include
+#include
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *data);
+ void *private;
+};
+
+/**
+ * struct mdev_virtio_device_ops - Structure to be registered for each
+ * mdev device to register the device for virtio/vhost drivers.
+ *
+ * The callbacks are mandatory unless explicitly mentioned.
+ *
+ * @set_vq_address:Set the address of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+ * @desc_area: address of desc area
+ * @driver_area: address of driver area
+ * @device_area: address of device area
+ * Returns integer: success (0) or error (< 0)
+ * @set_vq_num:Set the size of virtqueue
+ * @mdev: mediated device
+ * @idx: virtqueue index
+
[PATCH V9 3/6] mdev: introduce device specific ops
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to be used by
vfio-mdev and virtio-mdev.
Reviewed-by: Parav Pandit
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 35 +
MAINTAINERS | 1 +
drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ---
drivers/s390/cio/vfio_ccw_ops.c | 18 ---
drivers/s390/crypto/vfio_ap_ops.c | 14 +++--
drivers/vfio/mdev/mdev_core.c | 24 -
drivers/vfio/mdev/mdev_private.h | 5 ++
drivers/vfio/mdev/vfio_mdev.c | 37 ++---
include/linux/mdev.h | 43 ---
include/linux/mdev_vfio_ops.h | 52 +++
samples/vfio-mdev/mbochs.c| 20 ---
samples/vfio-mdev/mdpy.c | 20 ---
samples/vfio-mdev/mtty.c | 18 ---
13 files changed, 206 insertions(+), 99 deletions(-)
create mode 100644 include/linux/mdev_vfio_ops.h
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 6709413bee29..04d56884c357 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -152,15 +152,6 @@ callbacks per mdev parent device, per mdev type, or any
other categorization.
Vendor drivers are expected to be fully asynchronous in this respect or
provide their own internal resource protection.)
-The callbacks in the mdev_parent_ops structure are as follows:
-
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
-* read : read emulation callback
-* write: write emulation callback
-* mmap: mmap emulation callback
-
A driver should use the mdev_parent_ops structure in the function call to
register itself with the mdev core driver::
@@ -172,10 +163,34 @@ that a driver should use to unregister itself with the
mdev core driver::
extern void mdev_unregister_device(struct device *dev);
-It is also required to specify the class_id in create() callback through::
+As multiple types of mediated devices may be supported, class id needs
+to be specified in the create() callback. This could be done
+explicitly for the device that interacts with the mdev device directly
+through::
int mdev_set_class(struct mdev_device *mdev, u16 id);
+For the device that uses the mdev bus for its operation, the class
+should provide helper function to set class id and device specific
+ops. E.g for vfio-mdev devices, the function to be called is::
+
+ int mdev_set_vfio_ops(struct mdev_device *mdev,
+ const struct mdev_vfio_device_ops *vfio_ops);
+
+The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to
+match a device with an mdev driver via its id table. The device
+specific callbacks (specified in *vfio_ops) are obtainable via
+mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev
+device (class id MDEV_CLASS_ID_VFIO) uses the following
+device-specific ops:
+
+* open: open callback of vfio mediated device
+* close: close callback of vfio mediated device
+* ioctl: ioctl callback of vfio mediated device
+* read : read emulation callback
+* write: write emulation callback
+* mmap: mmap emulation callback
+
Mediated Device Management Interface Through sysfs
==
diff --git a/MAINTAINERS b/MAINTAINERS
index cba1095547fd..f661d13344d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17121,6 +17121,7 @@ S: Maintained
F: Documentation/driver-api/vfio-mediated-device.rst
F: drivers/vfio/mdev/
F: include/linux/mdev.h
+F: include/linux/mdev_vfio_ops.h
F: samples/vfio-mdev/
VFIO PLATFORM DRIVER
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 6420f0dbd31b..662f3a672372 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
}
+static const struct mdev_vfio_device_ops intel_vfio_vgpu_dev_ops;
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -678,7 +681,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
- mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
+
[PATCH V9 2/6] modpost: add support for mdev class id
Add support to parse mdev class id table.
Reviewed-by: Parav Pandit
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 11 +++
3 files changed, 16 insertions(+)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 38431e9ef7f5..a6641cd8b5a3 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -125,6 +125,8 @@ static const struct mdev_class_id vfio_id_table[] = {
{ 0 },
};
+MODULE_DEVICE_TABLE(mdev, vfio_id_table);
+
static struct mdev_driver vfio_mdev_driver = {
.name = "vfio_mdev",
.probe = vfio_mdev_probe,
diff --git a/scripts/mod/devicetable-offsets.c
b/scripts/mod/devicetable-offsets.c
index 054405b90ba4..6cbb1062488a 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -231,5 +231,8 @@ int main(void)
DEVID(wmi_device_id);
DEVID_FIELD(wmi_device_id, guid_string);
+ DEVID(mdev_class_id);
+ DEVID_FIELD(mdev_class_id, id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index c91eba751804..45f1c22f49be 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1335,6 +1335,16 @@ static int do_wmi_entry(const char *filename, void
*symval, char *alias)
return 1;
}
+/* looks like: "mdev:cN" */
+static int do_mdev_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, mdev_class_id, id);
+
+ sprintf(alias, "mdev:c%02X", id);
+ add_wildcard(alias);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1407,6 +1417,7 @@ static const struct devtable devtable[] = {
{"typec", SIZE_typec_device_id, do_typec_entry},
{"tee", SIZE_tee_client_device_id, do_tee_entry},
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
+ {"mdev", SIZE_mdev_class_id, do_mdev_entry},
};
/* Create MODULE_ALIAS() statements.
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V9 1/6] mdev: class id support
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
So this patch adds id_table to mdev_driver and class_id for mdev
device with the match method for mdev bus.
Reviewed-by: Parav Pandit
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 5
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/mdev/mdev_core.c | 17 +
drivers/vfio/mdev/mdev_driver.c | 25 +++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 +
include/linux/mdev.h | 8 ++
include/linux/mod_devicetable.h | 8 ++
samples/vfio-mdev/mbochs.c| 1 +
samples/vfio-mdev/mdpy.c | 1 +
samples/vfio-mdev/mtty.c | 1 +
13 files changed, 76 insertions(+)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..6709413bee29 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
* @probe: called when new device created
* @remove: called when device removed
* @driver: device driver structure
+ * @id_table: the ids serviced by this driver
*/
struct mdev_driver {
const char *name;
int (*probe) (struct device *dev);
void (*remove) (struct device *dev);
struct device_driverdriver;
+const struct mdev_class_id *id_table;
};
A mediated bus driver for mdev should use this structure in the function calls
@@ -170,6 +172,9 @@ that a driver should use to unregister itself with the mdev
core driver::
extern void mdev_unregister_device(struct device *dev);
+It is also required to specify the class_id in create() callback through::
+
+ int mdev_set_class(struct mdev_device *mdev, u16 id);
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 343d79c1cb7e..6420f0dbd31b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
out:
return ret;
}
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f0d71ab77c50..cf2c013ae32f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
struct mdev_device *mdev)
private->sch->schid.ssid,
private->sch->schid.sch_no);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 5c0f53c6dde7..07c31070afeb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(_mdev->node, _dev->mdev_list);
mutex_unlock(_dev->lock);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..7bfa2e46e829 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -45,6 +45,17 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
}
EXPORT_SYMBOL(mdev_set_drvdata);
+/*
+ * Specify the class for the mdev device, this must be called during
+ * create() callback.
+ */
+void mdev_set_class(struct mdev_device *mdev, u16 id)
+{
+ WARN_ON(mdev->class_id);
+ mdev->class_id = id;
+}
+EXPORT_SYMBOL(mdev_set_class);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return >dev;
@@ -324,6 +335,12 @@ int mdev_device_create(struct kobject *kobj,
if (ret)
goto ops_create_fail;
+ if (!mdev->class_id) {
+ ret = -EINVAL;
+ dev_warn(dev, "mdev vendor driver failed to specify device
class\n");
+ goto add_fail;
+ }
+
ret = device_add(>dev);
if (ret)
goto add_fail;
diff
[PATCH V9 0/6] mdev based hardware virtio offloading support
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.
Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.
A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.
Also a real IFC VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.
Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through introducing class id to the device and pairing it with
id_talbe claimed by the driver. On top, this seris also decouple
device specific parents ops out of the common ones.
Pktgen test was done with virito-net + mvnet loop back device.
Please review.
[1] https://lkml.org/lkml/2019/11/5/424
[2] https://lkml.org/lkml/2019/11/5/227
Changes from V8:
- try silent checkpatch, some are still there becuase they were inherited
from virtio_config_ops which needs to be resolved in an independent series
- tweak on the comment and doc
- remove VIRTIO_MDEV_F_VERSION_1 completely
- rename CONFIG_VIRTIO_MDEV_DEVICE to CONFIG_VIRTIO_MDEV
Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes
Changes from V6:
- rename ops files and compile guard
Changes from V5:
- use dev_warn() instead of WARN(1) when class id is not set
- validate id_table before trying to do matching between device and
driver
- add wildcard for modpost script
- use unique name for id_table
- move get_mdev_features() to be the first member of virtio_device_ops
and more comments for it
- typo fixes for the comments above virtio_mdev_ops
Changes from V4:
- keep mdev_set_class() for the device that doesn't use device ops
- use union for device ops pointer in mdev_device
- introduce class specific helper for getting is device ops
- use WARN_ON instead of BUG_ON in mdev_set_virtio_ops
- explain details of get_mdev_features() and get_vendor_id()
- distinguish the optional virito device ops from mandatory ones and
make get_generation() optional
- rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to
virtio_mdev_ops.h
- don't abuse version fileds in virtio_mdev structure, use features
instead
- fix warning during device remove
- style & docs tweaks and typo fixes
Changes from V3:
- document that class id (device ops) must be specified in create()
- add WARN() when trying to set class_id when it has already set
- add WARN() when class_id is not specified in create() and correctly
return an error in this case
- correct the prototype of mdev_set_class() in the doc
- add documention of mdev_set_class()
- remove the unnecessary "class_id_fail" label when class id is not
specified in create()
- convert id_table in vfio_mdev to const
- move mdev_set_class and its friends after mdev_uuid()
- suqash the patch of bus uevent into patch of introducing class id
- tweak the words in the docs per Cornelia suggestion
- tie class_id and device ops through class specific initialization
routine like mdev_set_vfio_ops()
- typos fixes in the docs of virtio-mdev callbacks
- document the usage of virtqueues in struct virtio_mdev_device
- remove the useless vqs array in struct virtio_mdev_device
- rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX
Changes from V2:
- fail when class_id is not specified
- drop the vringh patch
- match the doc to the code
- tweak the commit log
- move device_ops from parent to mdev device
- remove the unused MDEV_ID_VHOST
Changes from V1:
- move virtio_mdev.c to drivers/virtio
- store class_id in mdev_device instead of mdev_parent
- store device_ops in mdev_device instead of mdev_parent
- reorder the patch, vringh fix comes first
- really silent compiling warnings
- really switch to use u16 for class_id
- uevent and modpost support for mdev class_id
- vraious tweaks per comments from Parav
Changes from RFC-V2:
- silent compile warnings on some specific configuration
- use u16 instead u8 for class id
- reseve MDEV_ID_VHOST for future vhost-mdev work
- introduce "virtio" type for mvnet and make "vhost" type for future
work
- add entries in MAINTAINER
- tweak and typos fixes in commit log
Changes from RFC-V1:
- rename device id to class id
- add docs for class id and device specific ops (device_ops)
- split device_ops into seperate headers
- drop the
[PATCH] drm/panel: seperate panel power control from panel prepare/unprepare
Some dsi panels require the dsi lanes keeping low before panel power
on. So seperate the panel power control and the communication with panel.
And put the power control in drm_panel_prepare_power and
drm_panel_unprepare_power. Put the communication with panel in
drm_panel_prepare and drm_panel_unprepare.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/drm_panel.c | 38 +
include/drm/drm_panel.h | 17 +
2 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 6b0bf42039cf..e57f6385d2cc 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -131,6 +131,24 @@ void drm_panel_detach(struct drm_panel *panel)
}
EXPORT_SYMBOL(drm_panel_detach);
+/**
+ * drm_panel_prepare_power - power on a panel's power
+ * @panel: DRM panel
+ *
+ * Calling this function will enable power and deassert any reset signals to
+ * the panel.
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_prepare_power(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->prepare_power)
+ return panel->funcs->prepare_power(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_prepare_power);
+
/**
* drm_panel_prepare - power on a panel
* @panel: DRM panel
@@ -170,6 +188,26 @@ int drm_panel_unprepare(struct drm_panel *panel)
}
EXPORT_SYMBOL(drm_panel_unprepare);
+/**
+ * drm_panel_unprepare_power - power off a panel
+ * @panel: DRM panel
+ *
+ * Calling this function will completely power off a panel (assert the panel's
+ * reset, turn off power supplies, ...). After this function has completed, it
+ * is usually no longer possible to communicate with the panel until another
+ * call to drm_panel_prepare_power and drm_panel_prepare().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_unprepare_power(struct drm_panel *panel)
+{
+ if (panel && panel->funcs && panel->funcs->unprepare_power)
+ return panel->funcs->unprepare_power(panel);
+
+ return panel ? -ENOSYS : -EINVAL;
+}
+EXPORT_SYMBOL(drm_panel_unprepare_power);
+
/**
* drm_panel_enable - enable a panel
* @panel: DRM panel
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 624bd15ecfab..0d8c4855405c 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -61,6 +61,13 @@ struct display_timing;
* the panel. This is the job of the .unprepare() function.
*/
struct drm_panel_funcs {
+ /**
+* @prepare_power:
+*
+* Turn on panel power.
+*/
+ int (*prepare_power)(struct drm_panel *panel);
+
/**
* @prepare:
*
@@ -89,6 +96,13 @@ struct drm_panel_funcs {
*/
int (*unprepare)(struct drm_panel *panel);
+ /**
+* @unprepare_power:
+*
+* Turn off panel_power.
+*/
+ int (*unprepare_power)(struct drm_panel *panel);
+
/**
* @get_modes:
*
@@ -155,6 +169,9 @@ void drm_panel_remove(struct drm_panel *panel);
int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector);
void drm_panel_detach(struct drm_panel *panel);
+int drm_panel_prepare_power(struct drm_panel *panel);
+int drm_panel_unprepare_power(struct drm_panel *panel);
+
int drm_panel_prepare(struct drm_panel *panel);
int drm_panel_unprepare(struct drm_panel *panel);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v15 5/5] kselftests: Add dma-heap test
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Sandeep Patil
Cc: Hillf Danton
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Sandeep Patil
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switched to use reworked dma-heap apis
v3:
* Add simple mmap
* Utilize dma-buf testdev to test importing
v4:
* Rework to use vgem
* Pass in fd_flags to match interface changes
* Skip . and .. dirs
v6:
* Number of style/cleanups suggested by Brian
v7:
* Whitespace fixup for checkpatch
v8:
* More checkpatch whitespace fixups
v9:
* Better handling error returns out to main, suggested
by Brian Starkey
* Switch to using snprintf, suggested by Brian
v14:
* Fix a missing return value
* Add calls to test the GET_FEATURES ioctl
* Build fix reported by kernel test robot
and fixed by Xiao Yang
* Minor Makefile cleanups
v15:
* Remove usage of dropped get_features ioctl
---
tools/testing/selftests/dmabuf-heaps/Makefile | 6 +
.../selftests/dmabuf-heaps/dmabuf-heap.c | 238 ++
2 files changed, 244 insertions(+)
create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile
create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile
b/tools/testing/selftests/dmabuf-heaps/Makefile
new file mode 100644
index ..607c2acd2082
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include
+
+TEST_GEN_PROGS = dmabuf-heap
+
+include ../lib.mk
diff --git a/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
new file mode 100644
index ..efca067ba96c
--- /dev/null
+++ b/tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "../../../../include/uapi/linux/dma-heap.h"
+
+#define DEVPATH "/dev/dma_heap"
+
+static int check_vgem(int fd)
+{
+ drm_version_t version = { 0 };
+ char name[5];
+ int ret;
+
+ version.name_len = 4;
+ version.name = name;
+
+ ret = ioctl(fd, DRM_IOCTL_VERSION, );
+ if (ret)
+ return 0;
+
+ return !strcmp(name, "vgem");
+}
+
+static int open_vgem(void)
+{
+ int i, fd;
+ const char *drmstr = "/dev/dri/card";
+
+ fd = -1;
+ for (i = 0; i < 16; i++) {
+ char name[80];
+
+ snprintf(name, 80, "%s%u", drmstr, i);
+
+ fd = open(name, O_RDWR);
+ if (fd < 0)
+ continue;
+
+ if (!check_vgem(fd)) {
+ close(fd);
+ fd = -1;
+ continue;
+ } else {
+ break;
+ }
+ }
+ return fd;
+}
+
+static int import_vgem_fd(int vgem_fd, int dma_buf_fd, uint32_t *handle)
+{
+ struct drm_prime_handle import_handle = {
+ .fd = dma_buf_fd,
+ .flags = 0,
+ .handle = 0,
+};
+ int ret;
+
+ ret = ioctl(vgem_fd, DRM_IOCTL_PRIME_FD_TO_HANDLE, _handle);
+ if (ret == 0)
+ *handle = import_handle.handle;
+ return ret;
+}
+
+static void close_handle(int vgem_fd, uint32_t handle)
+{
+ struct drm_gem_close close = {
+ .handle = handle,
+ };
+
+ ioctl(vgem_fd, DRM_IOCTL_GEM_CLOSE, );
+}
+
+static int dmabuf_heap_open(char *name)
+{
+ int ret, fd;
+ char buf[256];
+
+ ret = snprintf(buf, 256, "%s/%s", DEVPATH, name);
+ if (ret < 0) {
+ printf("snprintf failed!\n");
+ return ret;
+ }
+
+ fd = open(buf, O_RDWR);
+ if (fd < 0)
+ printf("open %s failed!\n", buf);
+ return fd;
+}
+
+static int dmabuf_heap_alloc(int fd, size_t len, unsigned int flags,
+int *dmabuf_fd)
+{
+ struct dma_heap_allocation_data data = {
+ .len = len,
+ .fd_flags = O_RDWR | O_CLOEXEC,
+ .heap_flags = flags,
+ };
+ int ret;
+
+ if (!dmabuf_fd)
+ return -EINVAL;
+
+ ret = ioctl(fd, DMA_HEAP_IOC_ALLOC, );
+ if (ret < 0)
+
[PATCH v15 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
NOTE: This patch only adds the default CMA heap. We will enable
selectively adding other CMA memory regions to the dmabuf heaps
interface with a later patch (which requires a dt binding)
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Sandeep Patil
Cc: Hillf Danton
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Sandeep Patil
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
v3:
* Switch to inline function for to_cma_heap()
* Minor cleanups suggested by Brian
* Fold in new registration style from Andrew
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Use the fd_flags when creating dmabuf fd (Suggested by
Benjamin)
* Use precalculated pagecount (Suggested by Andrew)
v6:
* Changed variable names to improve clarity, as suggested
by Brian
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops const (Suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Checkpatch whitespace fixups
v9:
* Removing needless check noted by Brian Starkey
* Rename dma_heap_get_data->dma_heap_get_drvdata suggested
by Hilf Danton
* Check signals after clearing memory pages to avoid doing
needless work if the task is killed as suggested by Hilf
v12:
* Rework to only add the default CMA heap
v15:
* Drop unused flags field from heap_helper_buffer as suggested
by Sandeep Patil
---
drivers/dma-buf/heaps/Kconfig| 8 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/cma_heap.c | 177 +++
3 files changed, 186 insertions(+)
create mode 100644 drivers/dma-buf/heaps/cma_heap.c
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 205052744169..a5eef06c4226 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_HEAPS_CMA
+ bool "DMA-BUF CMA Heap"
+ depends on DMABUF_HEAPS && DMA_CMA
+ help
+ Choose this option to enable dma-buf CMA heap. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index d1808eca2581..6e54cdec3da0 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
new file mode 100644
index ..626cf7fd033a
--- /dev/null
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF CMA heap exporter
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author: for ST-Ericsson.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct cma_heap {
+ struct dma_heap *heap;
+ struct cma *cma;
+};
+
+static void cma_heap_free(struct heap_helper_buffer *buffer)
+{
+ struct cma_heap *cma_heap = dma_heap_get_drvdata(buffer->heap);
+ unsigned long nr_pages = buffer->pagecount;
+ struct page *cma_pages = buffer->priv_virt;
+
+ /* free page list */
+ kfree(buffer->pages);
+ /* release memory */
+ cma_release(cma_heap->cma, cma_pages, nr_pages);
+ kfree(buffer);
+}
+
+/* dmabuf heap CMA operations functions */
+static int cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
+{
+ struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
+ struct heap_helper_buffer *helper_buffer;
+ struct page *cma_pages;
+ size_t size = PAGE_ALIGN(len);
+ unsigned long nr_pages = size >> PAGE_SHIFT;
[PATCH v15 1/5] dma-buf: Add dma-buf heaps framework
From: "Andrew F. Davis" This framework allows a unified userspace interface for dma-buf exporters, allowing userland to allocate specific types of memory for use in dma-buf sharing. Each heap is given its own device node, which a user can allocate a dma-buf fd from using the DMA_HEAP_IOC_ALLOC. This code is an evoluiton of the Android ION implementation, and a big thanks is due to its authors/maintainers over time for their effort: Rebecca Schultz Zavin, Colin Cross, Benjamin Gaignard, Laura Abbott, and many other contributors! Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Sandeep Patil Cc: Hillf Danton Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Reviewed-by: Brian Starkey Acked-by: Sandeep Patil Signed-off-by: Andrew F. Davis Signed-off-by: John Stultz --- v2: * Folded down fixes I had previously shared in implementing heaps * Make flags a u64 (Suggested by Laura) * Add PAGE_ALIGN() fix to the core alloc funciton * IOCTL fixups suggested by Brian * Added fixes suggested by Benjamin * Removed core stats mgmt, as that should be implemented by per-heap code * Changed alloc to return a dma-buf fd, rather than a buffer (as it simplifies error handling) v3: * Removed scare-quotes in MAINTAINERS email address * Get rid of .release function as it didn't do anything (from Christoph) * Renamed filp to file (suggested by Christoph) * Split out ioctl handling to separate function (suggested by Christoph) * Add comment documenting PAGE_ALIGN usage (suggested by Brian) * Switch from idr to Xarray (suggested by Brian) * Fixup cdev creation (suggested by Brian) * Avoid EXPORT_SYMBOL until we finalize modules (suggested by Brian) * Make struct dma_heap internal only (folded in from Andrew) * Small cleanups suggested by GregKH * Provide class->devnode callback to get consistent /dev/ subdirectory naming (Suggested by Bjorn) v4: * Folded down dma-heap.h change that was in a following patch * Added fd_flags entry to allocation structure and pass it through to heap code for use on dma-buf fd creation (suggested by Benjamin) v5: * Minor cleanups v6: * Improved error path handling, minor whitespace fixes, both suggested by Brian v7: * Longer Kconfig description to quiet checkpatch warnings * Re-add compat_ioctl bits (Hridya noticed 32bit userland wasn't working) v8: * Make struct dma_heap_ops consts (Suggested by Christoph) * Checkpatch whitespace fixups v9: * Minor cleanups suggested by Brian Starkey * Rename dma_heap_get_data->dma_heap_get_drvdata suggested by Hilf Danton v11: * Kconfig text improvements suggested by Randy Dunlap v12: * Add logic to prevent duplicately named heaps being added * Add symbol exports for heaps as modules v13: * Re-remove symbol exports per discussion w/ Brian. Will resubmit in a separte patch for review v14: * Reworked ioctl handler to zero fill any difference in structure size, similar to what the DRM core does, as suggested by Dave Airlie * Removed now unnecessary reserved bits in allocate_data * Added get_features ioctl as suggested by Dave Airlie * Removed pr_warn_once messages as requested by Dave Airlie v15: * Dropped the get_features ioctl as suggested by Brian Starkey and Daniel Vetter * Add listhead comment suggested by Sandeep Patil * Dropped minor value in struct dma_heap as suggested by Sandeep Patil * Fix grammar typo from Brian Starkey --- MAINTAINERS | 18 +++ drivers/dma-buf/Kconfig | 9 ++ drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-heap.c| 297 ++ include/linux/dma-heap.h | 59 +++ include/uapi/linux/dma-heap.h | 53 ++ 6 files changed, 437 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h diff --git a/MAINTAINERS b/MAINTAINERS index cba1095547fd..568f94172905 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4940,6 +4940,24 @@ F: include/linux/*fence.h F: Documentation/driver-api/dma-buf.rst T: git git://anongit.freedesktop.org/drm/drm-misc +DMA-BUF HEAPS FRAMEWORK +M: Sumit Semwal +R: Andrew F. Davis +R: Benjamin Gaignard +R: Liam Mark +R: Laura Abbott +R: Brian Starkey +R: John Stultz +S: Maintained +L: linux-me...@vger.kernel.org +L: dri-devel@lists.freedesktop.org +L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) +F: include/uapi/linux/dma-heap.h +F: include/linux/dma-heap.h +F: drivers/dma-buf/dma-heap.c +F: drivers/dma-buf/heaps/* +T: git git://anongit.freedesktop.org/drm/drm-misc + DMA GENERIC OFFLOAD ENGINE SUBSYSTEM M: Vinod Koul L: dmaeng...@vger.kernel.org diff --git
[PATCH v15 2/5] dma-buf: heaps: Add heap helpers
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Sandeep Patil
Cc: Hillf Danton
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Sandeep Patil
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Removed cache management performance hack that I had
accidentally folded in.
* Removed stats code that was in helpers
* Lots of checkpatch cleanups
v3:
* Uninline INIT_HEAP_HELPER_BUFFER (suggested by Christoph)
* Switch to WARN on buffer destroy failure (suggested by Brian)
* buffer->kmap_cnt decrementing cleanup (suggested by Christoph)
* Extra buffer->vaddr checking in dma_heap_dma_buf_kmap
(suggested by Brian)
* Switch to_helper_buffer from macro to inline function
(suggested by Benjamin)
* Rename kmap->vmap (folded in from Andrew)
* Use vmap for vmapping - not begin_cpu_access (folded in from
Andrew)
* Drop kmap for now, as its optional (folded in from Andrew)
* Fold dma_heap_map_user into the single caller (foled in from
Andrew)
* Folded in patch from Andrew to track page list per heap not
sglist, which simplifies the tracking logic
v4:
* Moved dma-heap.h change out to previous patch
v6:
* Minor cleanups and typo fixes suggested by Brian
v7:
* Removed stray ;
* Make init_heap_helper_buffer lowercase, as suggested by Christoph
* Add dmabuf export helper to reduce boilerplate code
v8:
* Remove unused private_flags value
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Fix indentation by using shorter argument names (suggested by
Christoph)
* Add flush_kernel_vmap_range/invalidate_kernel_vmap_range calls
(suggested by Christoph)
* Checkpatch whitespace fixups
v9:
* Minor cleanups suggested by Brian Starkey
v10:
* Fix missing vmalloc.h inclusion in heap helpers (found by
kbuild test robot )
v12:
* Add symbol exports for heaps as modules
v13:
* Re-remove symbol exports, per discussion with Brian, as I'll
resubmit the change for review independently.
v14:
* Fix missing argment to WARN() in dma_heap_buffer_destroy()
found and fixed by Dan Carpenter
* Add check in fault hanlder that pgoff isn't larger then
pagecount, reported by Dan Carpenter
v15:
* Drop unused flags field from heap_helper_buffer as suggested
by Sandeep Patil
---
drivers/dma-buf/Makefile | 1 +
drivers/dma-buf/heaps/Makefile | 2 +
drivers/dma-buf/heaps/heap-helpers.c | 271 +++
drivers/dma-buf/heaps/heap-helpers.h | 53 ++
4 files changed, 327 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Makefile
create mode 100644 drivers/dma-buf/heaps/heap-helpers.c
create mode 100644 drivers/dma-buf/heaps/heap-helpers.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index caee5eb3d351..9c190026bfab 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -2,6 +2,7 @@
obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
dma-resv.o seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
+obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
new file mode 100644
index ..de49898112db
--- /dev/null
+++ b/drivers/dma-buf/heaps/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += heap-helpers.o
diff --git a/drivers/dma-buf/heaps/heap-helpers.c
b/drivers/dma-buf/heaps/heap-helpers.c
new file mode 100644
index ..9f964ca3f59c
--- /dev/null
+++ b/drivers/dma-buf/heaps/heap-helpers.c
@@ -0,0 +1,271 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+void init_heap_helper_buffer(struct heap_helper_buffer *buffer,
+void (*free)(struct heap_helper_buffer *))
+{
+ buffer->priv_virt = NULL;
+ mutex_init(>lock);
+ buffer->vmap_cnt = 0;
+ buffer->vaddr = NULL;
+ buffer->pagecount = 0;
+ buffer->pages = NULL;
+ INIT_LIST_HEAD(>attachments);
+ buffer->free = free;
+}
+
+struct dma_buf *heap_helper_export_dmabuf(struct heap_helper_buffer *buffer,
+ int
[PATCH v15 0/5] DMA-BUF Heaps (destaging ION)
Once again, here we are with v15: This patchset implements per-heap devices which can be opened directly and then an ioctl is used to allocate a dmabuf from the heap. The interface is similar, but much simpler then IONs, only providing an ALLOC ioctl. Also, I've provided relatively simple system and cma heaps. I've booted and tested these patches with AOSP on the HiKey960 using the kernel tree here: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap And the userspace changes here: https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 Compared to ION, this patchset is missing the system-contig, carveout and chunk heaps, as I don't have a device that uses those, so I'm unable to do much useful validation there. Additionally we have no upstream users of chunk or carveout, and the system-contig has been deprecated in the common/andoid-* kernels, so this should be ok. I've also removed the stats accounting, since any such accounting should be implemented by dma-buf core or the heaps themselves. New in v15: * Dropped the get_features ioctl as suggested by Brian Starkey and Daniel Vetter * Add listhead comment suggested by Sandeep Patil * Dropped minor value in struct dma_heap as suggested by Sandeep Patil * Drop unused flags field from heap_helper_buffer as suggested by Sandeep Patil * Fix grammar typo from Brian Starkey * Remove usage of dropped get_features ioctl in kselftest test Thanks again for all the reviews and feedback! -john Cc: Laura Abbott Cc: Benjamin Gaignard Cc: Sumit Semwal Cc: Liam Mark Cc: Pratik Patel Cc: Brian Starkey Cc: Vincent Donnefort Cc: Sudipto Paul Cc: Andrew F. Davis Cc: Christoph Hellwig Cc: Chenbo Feng Cc: Alistair Strachan Cc: Hridya Valsaraju Cc: Sandeep Patil Cc: Hillf Danton Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Andrew F. Davis (1): dma-buf: Add dma-buf heaps framework John Stultz (4): dma-buf: heaps: Add heap helpers dma-buf: heaps: Add system heap to dmabuf heaps dma-buf: heaps: Add CMA heap to dmabuf heaps kselftests: Add dma-heap test MAINTAINERS | 18 ++ drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 2 + drivers/dma-buf/dma-heap.c| 297 ++ drivers/dma-buf/heaps/Kconfig | 14 + drivers/dma-buf/heaps/Makefile| 4 + drivers/dma-buf/heaps/cma_heap.c | 177 +++ drivers/dma-buf/heaps/heap-helpers.c | 271 drivers/dma-buf/heaps/heap-helpers.h | 53 drivers/dma-buf/heaps/system_heap.c | 123 include/linux/dma-heap.h | 59 include/uapi/linux/dma-heap.h | 53 tools/testing/selftests/dmabuf-heaps/Makefile | 6 + .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 ++ 14 files changed, 1326 insertions(+) create mode 100644 drivers/dma-buf/dma-heap.c create mode 100644 drivers/dma-buf/heaps/Kconfig create mode 100644 drivers/dma-buf/heaps/Makefile create mode 100644 drivers/dma-buf/heaps/cma_heap.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.c create mode 100644 drivers/dma-buf/heaps/heap-helpers.h create mode 100644 drivers/dma-buf/heaps/system_heap.c create mode 100644 include/linux/dma-heap.h create mode 100644 include/uapi/linux/dma-heap.h create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v15 3/5] dma-buf: heaps: Add system heap to dmabuf heaps
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Vincent Donnefort
Cc: Sudipto Paul
Cc: Andrew F. Davis
Cc: Christoph Hellwig
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Hridya Valsaraju
Cc: Sandeep Patil
Cc: Hillf Danton
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Benjamin Gaignard
Reviewed-by: Brian Starkey
Acked-by: Sandeep Patil
Acked-by: Laura Abbott
Tested-by: Ayan Kumar Halder
Signed-off-by: John Stultz
---
v2:
* Switch allocate to return dmabuf fd
* Simplify init code
* Checkpatch fixups
* Droped dead system-contig code
v3:
* Whitespace fixups from Benjamin
* Make sure we're zeroing the allocated pages (from Liam)
* Use PAGE_ALIGN() consistently (suggested by Brian)
* Fold in new registration style from Andrew
* Avoid needless dynamic allocation of sys_heap (suggested by
Christoph)
* Minor cleanups
* Folded in changes from Andrew to use simplified page list
from the heap helpers
v4:
* Optimization to allocate pages in chunks, similar to old
pagepool code
* Use fd_flags when creating dmabuf fd (Suggested by Benjamin)
v5:
* Back out large order page allocations (was leaking memory,
as the page array didn't properly track order size)
v6:
* Minor whitespace change suggested by Brian
* Remove unused variable
v7:
* Use newly lower-cased init_heap_helper_buffer helper
* Add system heap DOS avoidance suggested by Laura from ION code
* Use new dmabuf export helper
v8:
* Make struct dma_heap_ops consts (suggested by Christoph)
* Get rid of needless struct system_heap (suggested by Christoph)
* Condense dma_heap_buffer and heap_helper_buffer (suggested by
Christoph)
* Add forgotten include file to fix build issue on x86
v12:
* Minor tweaks to prep loading heap from module
v14:
* Fix "redundant assignment to variable ret" issue reported
by Colin King and fixed by Andrew Davis
v15:
* Drop unused heap flag from heap_helper_buffer as suggested
by Sandeep Patil
---
drivers/dma-buf/Kconfig | 2 +
drivers/dma-buf/heaps/Kconfig | 6 ++
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/system_heap.c | 123
4 files changed, 132 insertions(+)
create mode 100644 drivers/dma-buf/heaps/Kconfig
create mode 100644 drivers/dma-buf/heaps/system_heap.c
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index bffa58fc3e6e..0613bb7770f5 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -53,4 +53,6 @@ menuconfig DMABUF_HEAPS
allows userspace to allocate dma-bufs that can be shared
between drivers.
+source "drivers/dma-buf/heaps/Kconfig"
+
endmenu
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
new file mode 100644
index ..205052744169
--- /dev/null
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -0,0 +1,6 @@
+config DMABUF_HEAPS_SYSTEM
+ bool "DMA-BUF System Heap"
+ depends on DMABUF_HEAPS
+ help
+ Choose this option to enable the system dmabuf heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index de49898112db..d1808eca2581 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += heap-helpers.o
+obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
new file mode 100644
index ..1aa01e98c595
--- /dev/null
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF System heap exporter
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "heap-helpers.h"
+
+struct dma_heap *sys_heap;
+
+static void system_heap_free(struct heap_helper_buffer *buffer)
+{
+ pgoff_t pg;
+
+ for (pg = 0; pg < buffer->pagecount; pg++)
+ __free_page(buffer->pages[pg]);
+ kfree(buffer->pages);
+ kfree(buffer);
+}
+
+static int system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
+{
+ struct heap_helper_buffer *helper_buffer;
+ struct dma_buf *dmabuf;
+ int ret = -ENOMEM;
+
[drm-tip:drm-tip 1865/1875] stacktrace.c:undefined reference to `save_stack_trace'
Hi Chenwandun, It's probably a bug fix that unveils the link errors. tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: f5cfd96ad87b58bf3b5dfa5365f8beb8bac15a38 commit: 68acde7629d75d460760a3124c52f358eecc6d26 [1865/1875] drm/dp_mst: fix gcc compile error config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 68acde7629d75d460760a3124c52f358eecc6d26 # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=m68k If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): kernel/stacktrace.o: In function `stack_trace_save': >> stacktrace.c:(.text+0x120): undefined reference to `save_stack_trace' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112215] johnjohn
https://bugs.freedesktop.org/show_bug.cgi?id=112215 JohnJohn changed: What|Removed |Added Status|NEW |ASSIGNED -- 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 V8 0/6] mdev based hardware virtio offloading support
On 2019/11/6 上午1:58, Alex Williamson wrote:
On Tue, 5 Nov 2019 17:32:34 +0800
Jason Wang wrote:
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.
Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.
A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.
Also a real ICF VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.
Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through introducing class id to the device and pairing it with
id_talbe claimed by the driver. On top, this seris also decouple
device specific parents ops out of the common ones.
Pktgen test was done with virito-net + mvnet loop back device.
Please review.
[1] https://lkml.org/lkml/2019/10/31/440
[2] https://lkml.org/lkml/2019/10/15/1226
Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes
Seems we're nearly there, all the remaining comments are relatively
superficial, though I would appreciate a v9 addressing them as well as
the checkpatch warnings:
https://patchwork.freedesktop.org/series/68977/
Will do.
Btw, do you plan to merge vhost-mdev patch on top? Or you prefer it to
go through Michael's vhost tree?
Thanks
Consider this a last call for reviews or acks (or naks) from affected
mdev vendor drivers, mdev-core sub-maintainers (Hi Kirti), virtio
stakeholders, etc. Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 4/6] mdev: introduce virtio device and its device ops
On 2019/11/6 上午1:47, Alex Williamson wrote: +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev" +#define VIRTIO_MDEV_F_VERSION_1 0x1 This entire concept of VIRTIO_MDEV_F_VERSION_1 is gone now, right? Let's remove it here and below. Thanks, Alex Yes, will fix. Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 3/6] mdev: introduce device specific ops
On 2019/11/6 上午2:28, Cornelia Huck wrote: On Tue, 5 Nov 2019 10:44:18 -0700 Alex Williamson wrote: On Tue, 5 Nov 2019 17:50:25 +0100 Cornelia Huck wrote: On Tue, 5 Nov 2019 17:32:37 +0800 Jason Wang wrote: Currently, except for the create and remove, the rest of mdev_parent_ops is designed for vfio-mdev driver only and may not help for kernel mdev driver. With the help of class id, this patch introduces device specific callbacks inside mdev_device structure. This allows different set of callback to be used by vfio-mdev and virtio-mdev. Reviewed-by: Parav Pandit Signed-off-by: Jason Wang --- .../driver-api/vfio-mediated-device.rst | 35 + MAINTAINERS | 1 + drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- drivers/s390/cio/vfio_ccw_ops.c | 18 --- drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- drivers/vfio/mdev/mdev_core.c | 24 - drivers/vfio/mdev/mdev_private.h | 5 ++ drivers/vfio/mdev/vfio_mdev.c | 37 ++--- include/linux/mdev.h | 43 --- include/linux/mdev_vfio_ops.h | 52 +++ samples/vfio-mdev/mbochs.c| 20 --- samples/vfio-mdev/mdpy.c | 20 --- samples/vfio-mdev/mtty.c | 18 --- 13 files changed, 206 insertions(+), 99 deletions(-) create mode 100644 include/linux/mdev_vfio_ops.h (...) @@ -172,10 +163,34 @@ that a driver should use to unregister itself with the mdev core driver:: extern void mdev_unregister_device(struct device *dev); -It is also required to specify the class_id in create() callback through:: +As multiple types of mediated devices may be supported, class id needs +to be specified in the create callback(). This could be done The brackets should probably go behind 'create'? +explicitly for the device that does not use on mdev bus for its "for devices that do not use the mdev bus" ? But why wouldn't they? I feel like I've missed some discussion here :/ The device ops provide a route through mdev-core for known callbacks, which is primarily useful when we have 1:N relation between mdev bus driver and vendor drivers. The obvious example here is vfio-mdev, where we have GVT-g, vfio-ap, vfio-ccw, NVIDIA GRID, and various sample drivers all advertising vfio-mdev support via their class id. However, if we have a tightly coupled vendor driver and mdev bus driver, as the mlx5 support that Parav is developing, the claim is that they prefer not to expose any device ops and intend to interact directly with the mdev device. At least that's my understanding. Thanks, Alex Ah, ok. So maybe use the phrasing "devices that interact with the mdev device directly" vs "devices that use device-specific ops" instead? Not a strong critique, though. Will use what you suggest here. Thanks +operation through: int mdev_set_class(struct mdev_device *mdev, u16 id); +For the device that uses on the mdev bus for its operation, the class "For devices that use the mdev bus..." But same comment as above. +should provide helper function to set class id and device specific +ops. E.g for vfio-mdev devices, the function to be called is:: + + int mdev_set_vfio_ops(struct mdev_device *mdev, + const struct mdev_vfio_device_ops *vfio_ops); + +The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to +match a device with an mdev driver via its id table. The device +specific callbacks (specified in *vfio_ops) are obtainable via +mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev +device (class id MDEV_CLASS_ID_VFIO) uses the following +device-specific ops: + +* open: open callback of vfio mediated device +* close: close callback of vfio mediated device +* ioctl: ioctl callback of vfio mediated device +* read : read emulation callback +* write: write emulation callback +* mmap: mmap emulation callback + Mediated Device Management Interface Through sysfs == Otherwise, looks good. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
On Wed, 6 Nov 2019 at 05:56, Dave Airlie wrote: > > On Wed, 6 Nov 2019 at 05:49, Laurent Pinchart > wrote: > > > > Hi Dave, > > > > Has this pull request fallen through the cracks ? > > It fell down a different crack than usual, it made it from patchwork > onto my hard drive, but then I didn't execute the pull. > > I've pulled it down, thanks for reminder. Now it failed as I mentioned on irc. I think the new kconfig option needs to be a tristate, otherwise setting it to Y and having rcar-du as M fails to link Dave. ___ 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 tip tree
Hi all, On Thu, 10 Oct 2019 13:14:48 +1100 Stephen Rothwell wrote: > > I added the following merge fix patch for today: > This patch is now just: From: Stephen Rothwell Date: Thu, 10 Oct 2019 13:08:43 +1100 Subject: [PATCH] drm/i915: update for mutex_release API change Signed-off-by: Stephen Rothwell --- drivers/gpu/drm/i915/i915_active.c| 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index aa37c07004b9..a47387174434 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -385,7 +385,7 @@ void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f) mutex_acquire(>mutex.dep_map, 0, 0, _THIS_IP_); if (!__i915_active_fence_set(>excl, f)) atomic_inc(>count); - mutex_release(>mutex.dep_map, 0, _THIS_IP_); + mutex_release(>mutex.dep_map, _THIS_IP_); } bool i915_active_acquire_if_busy(struct i915_active *ref) -- 2.23.0 -- Cheers, Stephen Rothwell pgpxjgyTMS9eo.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Tue, 5 Nov 2019 at 07:00, Manasi Navare wrote: > > On Mon, Nov 04, 2019 at 07:48:26PM +1000, David Airlie wrote: > > On Mon, Nov 4, 2019 at 7:18 PM Daniel Vetter wrote: > > > > > > On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote: > > > > In case of tiled displays, if we hotplug just one connector, > > > > fbcon currently just selects the preferred mode and if it is > > > > tiled mode then that becomes a problem if rest of the tiles are > > > > not present. > > > > So in the fbdev driver on hotplug when we probe the client modeset, > > > > we we dont find all the connectors for all tiles, then on a connector > > > > with one tile, just fallback to the first available non tiled mode > > > > to display over a single connector. > > > > > > > > Suggested-by: Ville Syrjälä > > > > Suggested-by: Dave Airlie > > > > Cc: Ville Syrjälä > > > > Cc: Dave Airlie > > > > Signed-off-by: Manasi Navare > > > > > > Hm, should we mayb have a slight timeout first to wait for the 2nd > > > connector? Otherwise lots of flickering going on when plugging in one of > > > these screens ... > > > > Not really, > > > > There are 3 scenarios with the multi-cable tiled monitors. and > > non-resizeable fbdev. > > > > a) it's plugged in at boot. both cables are detected, fbdev gets a > > full tiled mode. > > Yes this works as expected > > > b) it's not plugged in at boot, the user starts plugging it in, fbdev > > was inited via the panel or another monitor. fbdev won't resize. > > c) it's half plugged in at boot, then you get a non-tiled mode, and > > fbdev can't resize to tiled anyways. > > In b and c, when its booted with only 1 cable connected and/or hotplugged only > one cable after boot, I fallback to fisrt available non tiled mode, does that > sound good? > > > > > Also plugging in one of these multi-cable monitors piecemeal is going > > to take multiple seconds for the user to do physical cable plugging. > > So still good with ignoring the second hotplug completely? > However i donno where in the fb helper to stop passing the modeset down > after the drm_fb_helper_hotplug_event() I don't think you can ignore it completely. I think you just have to make the mode picking logic pick the right answer somehow. So you can tell if width/height are going to be lower than the tiled mode size, and in that case just don't enable the secondary tile. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Fri, 1 Nov 2019 at 07:46, Manasi Navare wrote:
>
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the tiles are
> not present.
> So in the fbdev driver on hotplug when we probe the client modeset,
> we we dont find all the connectors for all tiles, then on a connector
> with one tile, just fallback to the first available non tiled mode
> to display over a single connector.
>
> Suggested-by: Ville Syrjälä
> Suggested-by: Dave Airlie
> Cc: Ville Syrjälä
> Cc: Dave Airlie
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_client_modeset.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 895b73f23079..e28a723587db 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -114,6 +114,20 @@ drm_client_find_modeset(struct drm_client_dev *client,
> struct drm_crtc *crtc)
> return NULL;
> }
>
> +static struct drm_display_mode *
> +drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
> +{
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, >modes, head) {
> + if (mode->hdisplay == connector->tile_h_size &&
> + mode->vdisplay == connector->tile_v_size)
> + continue;
> + return mode;
> + }
> + return NULL;
> +}
> +
> static struct drm_display_mode *
> drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
> int height)
> {
> @@ -348,8 +362,17 @@ static bool drm_client_target_preferred(struct
> drm_connector **connectors,
> struct drm_connector *connector;
> u64 conn_configured = 0;
> int tile_pass = 0;
> + int num_tiled_conns = 0;
> int i;
>
> + for (i = 0; i < connector_count; i++) {
> + connector = connectors[i];
> + if (!connector->has_tile)
> + continue;
> +
> + num_tiled_conns ++;
Drop the space before the ++ here. Maybe just make this
if (connectors[i]->has_tile)
num_tiled_conns++;
Reviewed-by: Dave Airlie
Otherwise I think this seems fine, though it does beg the question in
my mind of what happens if I get 2 8K monitors, and plug the first
tile of one in, and the second tile of the other in.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #126 from Rodney A Morris --- (In reply to haro41 from comment #125) > ... thanks for your feedback, so it seems we are faced with the same bug ... > > Btw, i got crashes with at least one vulkan game and ACO compiler backend > enabled too. > I think it really depends of the load pattern. And enabled vsync is > triggering the typical load pattern, with at least one transient (from high > to low load) per frame. > > Is someone affected with this bug here, usually building the kernel from > source locally? If you want someone to apply your changes in bug report no. 110777 to the kernel for testing, I can so but will not be to it until this weekend. As a side note, I've had great success manually limiting the memory clock to level 1,2,3 on my Vega 64. I've played over 7 hours of Stellaris without a crash. -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #209 from L.S.S. --- Really?! Although I haven't really used the card under Windows, if similar behaviors happen on Windows as well then either something's really really wrong here. I haven't tested gaming on Manjaro yet, but at least with amdgpu-pro stuffs on Manjaro the sdma0 freezes with Nemo stopped happening. On the other hand, video card recovery is not yet matured on Linux yet, but on Windows it has already been available thanks to the WDDM, though you cannot completely rely on it, as some apps can still misbehave if the driver has been crashed for at least once in the system lifecycle, and it may eventually fail to recover at some point later on. Which brand of the Radeon RX 5700/XT are you using? For me I'm using a 50th Anniversary edition. How's the thermal condition when you play games on the card? It's possible the card might have weird behavior if it's under load with temperature near triple digits (something that I personally would never allow). I have a PCI slot fan set (consists of 3 slim fans which is around the same length as the card itself) placed beneath the card, blowing upwards, and it seems very effective. With the help of its own blower fans, the card maintains a steady 50 celsius under load. -- 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: [RFC PATCH] cgroup: Document interface files and rationale for DRM controller
On 11/4/2019 4:15 PM, Tejun Heo wrote: > On Mon, Nov 04, 2019 at 05:08:47PM -0500, Brian Welty wrote: >> + gpuset.units >> + gpuset.units.effective >> + gpuset.units.partition >> + >> + gpuset.mems >> + gpuset.mems.effective >> + gpuset.mems.partition >> + >> + sched.max >> + sched.stats >> + sched.weight >> + sched.weight.nice >> + >> + memory.current >> + memory.events >> + memory.high >> + memory.low >> + memory.max >> + memory.min >> + memory.stat >> + memory.swap.current >> + memory.swap.max > > I don't understand why it needs to replicate essentially *all* the > interfaces that system resources are implementing from the get-go. > Some of the above have intersecting functionalities and exist more for > historical reasons and I fail to see how distinctions like min vs. low > and high vs. max would make sense for gpus. Also, why would it have a > separate swap limit of its own? > > Please start with something small and intuitive. I'm gonna nack > anything which sprawls out like this. Most likely, there's still a > ton you guys need to work through to reach the resource model which is > actually useful and trying to define a comprehensive interface upfront > like this is gonna look really silly and will become an ugly drag by > the time the problem space is actually understood. > > It doesn't seem like this is coming through but can you please start > with a simple weight knob? > > Thanks. > Thanks Tejun for the feedback. I was more interested in hearing your thoughts on whether you like the approach to have a set of controls that are consistent with some subset of the existing CPU/MEM ones. Any feedback on this? Didn't really mean to suggest that all of these would be included from the start. Would you agree that this reduced set is a reasonable starting point? + sched.weight + memory.current + memory.max Thoughts on whether this should be very GPU-specific cgroups controller or should be more forward thinking to be useful for other 'accelerator' type devices as well? Thanks, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201539] AMDGPU R9 390 automatic fan speed control in Linux 4.19/4.20/5.0
https://bugzilla.kernel.org/show_bug.cgi?id=201539 --- Comment #25 from MasterCATZ (masterc...@hotmail.com) --- 5.4.0-050400rc6-generic 24 hours and I still have fan control 99% chance I have just jinxed my self now -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 4/4] drm/rockchip: Add support for afbc
Hi Andrzej,
On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> + if (mode_cmd->modifier[0]) {
I believe this can still be DRM_FORMAT_MOD_INVALID, which != 0. You
probably want to explicitly check if it's an AFBC modifier.
> + const struct drm_format_info *info;
> + int bpp;
> +
> + if (!drm_afbc_check_offset(dev, mode_cmd))
> + return ERR_PTR(-EINVAL);
> +
> + if (!drm_afbc_get_superblk_wh(mode_cmd->modifier[0],
> , ))
> + return ERR_PTR(-EINVAL);
> +
> + if (w != 16 || h != 16) {
> + DRM_DEV_ERROR(dev->dev,
> + "Unsupported afbc tile w/h [%d/%d]\n",
> w, h);
This can just be a WARN_ONCE() or something, since it indicates an
impossible condition - the DRM core should've already rejected this
modifier as unsupported.
> + if (mode_cmd->width > ROCKCHIP_MAX_AFBC_WIDTH) {
> + DRM_DEV_ERROR(dev->dev,
> + "Unsupported width %d>%d\n",
> + mode_cmd->width,
> + ROCKCHIP_MAX_AFBC_WIDTH
> + );
Userspace shouldn't be allowed to spam the log by triggering error
messages; please make this debug instead. Whilst you're there, adding
logs to the other error returns here might be useful.
> @@ -166,6 +179,7 @@ struct vop {
> /* optional internal rgb encoder */
> struct rockchip_rgb *rgb;
>
> + struct vop_win *afbc_win;
It seems like everywhere afbc_win is used, it's not actually used for
the window value, but rather just used as an is_afbc_enabled bool. In
that case, it would be better as a real bool, and living in either the
output or plane state.
This would eliminate the need to unset the variable as well.
Relatedly, can one VOP support multiple simultaneous windows using
AFBC? If not, the check that only one window is using AFBC is missing
from this patch.
> +static int vop_convert_afbc_format(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + return AFBC_FMT_U8U8U8U8;
> + case DRM_FORMAT_RGB888:
> + case DRM_FORMAT_BGR888:
> + return AFBC_FMT_U8U8U8;
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + return AFBC_FMT_RGB565;
> + /* either of the below should not be reachable */
Unreachable can be WARN_ONCE() rather than a silent return.
Other than that, this is looking a _lot_ nicer than v1 though!
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Hi Andrzej,
Thanks for taking this on! It's looking better than v1 for sure. A few
things below:
On Mon, 2019-11-04 at 23:12 +0100, Andrzej Pietrasiewicz wrote:
> +bool drm_afbc_check_offset(struct drm_device *dev,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + if (mode_cmd->offsets[0] != 0) {
> + DRM_DEBUG_KMS("AFBC buffers' plane offset should be
> 0\n");
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_afbc_check_offset);
Is this actually universally true? If the offset is sufficiently
aligned for (e.g.) DMA transfers to succeed, is there any reason why it
must be zero?
> +bool drm_afbc_check_size_align(struct drm_device *dev,
> +const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + switch (mode_cmd->modifier[0] &
> AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + if ((mode_cmd->width % 16) || (mode_cmd->height % 16))
> {
This is a dealbreaker for many resolutions: for example, 1366x768 isn't
cleanly divisible by 16 in width. So this means that we would have to
either use a larger buffer and crop, or scale, or something.
No userspace is prepared to align fb width/height to tile dimensions
like this, so this check will basically fail everywhere.
However, overallocation relative to the declared width/height isn't a
problem at all. In order to deal with horizontal alignment, you simply
need to ensure that the stride is a multiple of the tile width; for
vertical arrangement, that the buffer is large enough to contain
sufficient 'lines' to the next tile boundary.
i.e. rather than checking width/height, you should check:
* fb_stride >= (ALIGN(fb_width, tile_width), bpp)
* buf_size >= fb_stride * ALIGN(fb_height, tile_height)
This may force us to do some silly cropping games inside the Rockchip
KMS driver, but I feel it beats the alternative of breaking userspace.
> + DRM_DEBUG_KMS(
> + "AFBC buffer must be aligned to 16
> pixels\n"
> + );
> + return false;
> + }
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> + /* fall through */
It's also incongruous that 32x8 is unsupported here, but has a section
in get_superblk_wh; please harmonise them so this section either does
the checks as above, or that get_superblk_wh doesn't support 32x8
either.
> +bool drm_afbc_check_fb_size_ret(u32 pitch, int bpp,
> + u32 w, u32 h, u32 superblk_w, u32
> superblk_h,
> + size_t size, u32 offset, u32 hdr_align,
> + u32 *payload_off, u32 *total_size)
> +{
> + int n_superblks = 0;
> + u32 superblk_sz = 0;
> + u32 afbc_size = 0;
Please don't initialise the above three variables, given that you go on
to immediately change their values. In this case, initialising to zero
can only hide legitimate uninitialised-variable-use warnings.
> + n_superblks = (w / superblk_w) * (h / superblk_h);
> + superblk_sz = (bpp * superblk_w * superblk_h) / BITS_PER_BYTE;
> + afbc_size = ALIGN(n_superblks * AFBC_HEADER_SIZE, hdr_align);
> + *payload_off = afbc_size;
> +
> + afbc_size += n_superblks * ALIGN(superblk_sz,
> AFBC_SUPERBLK_ALIGNMENT);
> + *total_size = afbc_size + offset;
Generally these are referred to as 'tiles' rather than 'superblocks',
given that I would only expect one superblock per buffer, but if that's
the terminology AFBC uses then it might be better to stick with it.
> + if ((w * bpp) != (pitch * BITS_PER_BYTE)) {
> + DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE)
> (=%u) should be same as width (=%u) * bpp (=%u)\n",
> + pitch * BITS_PER_BYTE, w, bpp
> + );
> + return false;
> + }
Having a too-small pitch is obviously a problem and we should reject
it. But is having a too-large pitch really a problem; does it need to
be an exact match, or can we support the case where the pitch is too
large but also tile-aligned? If we can, it would be very good to
support that.
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 13/14] drm/mxsfb: Add support for horizontal stride
On Mon, Oct 14, 2019 at 02:40:55PM +0200, Stefan Agner wrote:
> Hi Robert,
>
> Sorry it took me so long to have a closer look at this patchset.
>
> I will definitely merge part of it, but this particular patch actually
> breaks i.MX 7. I have vertical stripes on my display with this patch
> applied (using Weston with DRM backend). Not sure why this exactly
> happens, from what I understand this should only affect IP Version 4.
The code tests for ipversion >= 4, which should match the i.MX7.
> Some notes below:
>
> On 2019-08-29 13:30, Robert Chiras wrote:
> > Besides the eLCDIF block, there is another IP block, used in the past
> > for EPDC panels. Since the iMX.8mq doesn't have an EPDC connector, this
> > block is not documented, but we can use it to do additional operations
> > on the frame buffer.
>
> Hm, but this block is part of the ELCDIF block, in terms of clock, power
> domain etc?
On i.MX7 the EPDC IP core is present as the SoC has an EPDC output. Can
the EPDC be used to control LCDIF stride on the i.MX7 too ?
> > In this case, we can use the pigeon registers from this IP block in
> > order to do horizontal crop on the frame buffer processed by the eLCDIF
> > block.
> >
> > Signed-off-by: Robert Chiras
> > Tested-by: Guido Günther
> > ---
> > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 79
> > --
> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 +
> > drivers/gpu/drm/mxsfb/mxsfb_regs.h | 16
> > 3 files changed, 92 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > index a12f53d..317575e 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> > @@ -15,6 +15,7 @@
> >
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -435,13 +436,66 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private
> > *mxsfb)
> > clk_disable_unprepare(mxsfb->clk_axi);
> > }
> >
> > +void mxsfb_set_fb_hcrop(struct mxsfb_drm_private *mxsfb, u32 src_w, u32
> > fb_w)
> > +{
> > + u32 mask_cnt, htotal, hcount;
> > + u32 vdctrl2, vdctrl3, vdctrl4, transfer_count;
> > + u32 pigeon_12_0, pigeon_12_1, pigeon_12_2;
> > +
> > + if (src_w == fb_w) {
> > + writel(0x0, mxsfb->base + HW_EPDC_PIGEON_12_0);
> > + writel(0x0, mxsfb->base + HW_EPDC_PIGEON_12_1);
> > +
> > + return;
> > + }
> > +
> > + transfer_count = readl(mxsfb->base + LCDC_V4_TRANSFER_COUNT);
> > + hcount = TRANSFER_COUNT_GET_HCOUNT(transfer_count);
> > +
> > + transfer_count &= ~TRANSFER_COUNT_SET_HCOUNT(0x);
> > + transfer_count |= TRANSFER_COUNT_SET_HCOUNT(fb_w);
> > + writel(transfer_count, mxsfb->base + LCDC_V4_TRANSFER_COUNT);
> > +
> > + vdctrl2 = readl(mxsfb->base + LCDC_VDCTRL2);
> > + htotal = VDCTRL2_GET_HSYNC_PERIOD(vdctrl2);
> > + htotal += fb_w - hcount;
> > + vdctrl2 &= ~VDCTRL2_SET_HSYNC_PERIOD(0x3);
> > + vdctrl2 |= VDCTRL2_SET_HSYNC_PERIOD(htotal);
> > + writel(vdctrl2, mxsfb->base + LCDC_VDCTRL2);
> > +
> > + vdctrl4 = readl(mxsfb->base + LCDC_VDCTRL4);
> > + vdctrl4 &= ~SET_DOTCLK_H_VALID_DATA_CNT(0x3);
> > + vdctrl4 |= SET_DOTCLK_H_VALID_DATA_CNT(fb_w);
> > + writel(vdctrl4, mxsfb->base + LCDC_VDCTRL4);
> > +
> > + /* configure related pigeon registers */
> > + vdctrl3 = readl(mxsfb->base + LCDC_VDCTRL3);
> > + mask_cnt = GET_HOR_WAIT_CNT(vdctrl3) - 5;
> > +
> > + pigeon_12_0 = PIGEON_12_0_SET_STATE_MASK(0x24) |
> > + PIGEON_12_0_SET_MASK_CNT(mask_cnt)|
> > + PIGEON_12_0_SET_MASK_CNT_SEL(0x6) |
> > + PIGEON_12_0_POL_ACTIVE_LOW|
> > + PIGEON_12_0_EN;
> > + writel(pigeon_12_0, mxsfb->base + HW_EPDC_PIGEON_12_0);
> > +
> > + pigeon_12_1 = PIGEON_12_1_SET_CLR_CNT(src_w) |
> > + PIGEON_12_1_SET_SET_CNT(0x0);
> > + writel(pigeon_12_1, mxsfb->base + HW_EPDC_PIGEON_12_1);
> > +
> > + pigeon_12_2 = 0x0;
> > + writel(pigeon_12_2, mxsfb->base + HW_EPDC_PIGEON_12_2);
> > +}
> > +
> > void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
> >struct drm_plane_state *state)
> > {
> > struct drm_simple_display_pipe *pipe = >pipe;
> > struct drm_crtc *crtc = >crtc;
> > + struct drm_plane_state *new_state = pipe->plane.state;
> > + struct drm_framebuffer *fb = pipe->plane.state->fb;
> > struct drm_pending_vblank_event *event;
> > - dma_addr_t paddr;
> > + u32 fb_addr, src_off, src_w, stride, cpp = 0;
>
> dma_addr_t seems to be the better type here, why change?
>
> >
> > spin_lock_irq(>dev->event_lock);
> > event = crtc->state->event;
> > @@ -456,10 +510,27 @@ void mxsfb_plane_atomic_update(struct
> > mxsfb_drm_private *mxsfb,
> > }
> > spin_unlock_irq(>dev->event_lock);
> >
> > - paddr = mxsfb_get_fb_paddr(mxsfb);
> > - if (paddr) {
> > + if (!fb)
> > +
Re: [PATCH v4 06/14] drm/mxsfb: Update mxsfb with additional pixel formats
Hi Robert,
Thank you for the patch.
On Thu, Aug 29, 2019 at 02:30:07PM +0300, Robert Chiras wrote:
> Since version 4 of eLCDIF, there are some registers that can do
> transformations on the input data, like re-arranging the pixel
> components. By doing that, we can support more pixel formats.
> This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
> is not supported by eLCDIF, the alpha pixel formats were added to the
> supported pixel formats but it will be ignored. This was necessary since
> there are systems (like Android) that requires such pixel formats.
>
> Also, add support for the following pixel formats:
> 16 bpp: RG16 ,BG16, XR15, XB15, AR15, AB15
>
> Set the bus format based on input from the user and panel
> capabilities.
> Save the bus format in crtc->mode.private_flags, so the bridge can
> use it.
>
> Signed-off-by: Robert Chiras
> Signed-off-by: Mirela Rabulea
> Tested-by: Guido Günther
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 147
> ++---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 30 ++--
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 3 +-
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 15
> 4 files changed, 163 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 5e44f57..1be29f5 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -43,14 +43,17 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private
> *mxsfb, u32 val)
> }
>
> /* Setup the MXSFB registers for decoding the pixels out of the framebuffer
> */
> -static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
> +static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb, bool update)
> {
> struct drm_crtc *crtc = >pipe.crtc;
> struct drm_device *drm = crtc->dev;
> const u32 format = crtc->primary->state->fb->format->format;
> - u32 ctrl, ctrl1;
> + u32 ctrl = 0, ctrl1 = 0;
> + bool bgr_format = true;
> + struct drm_format_name_buf format_name_buf;
>
> - ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
> + if (!update)
> + ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
>
> /*
>* WARNING: The bus width, CTRL_SET_BUS_WIDTH(), is configured to
> @@ -59,64 +62,158 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
> *mxsfb)
>* to arbitrary value. This limitation should not pose an issue.
>*/
>
> - /* CTRL1 contains IRQ config and status bits, preserve those. */
> - ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> - ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + if (!update) {
> + /* CTRL1 contains IRQ config and status bits, preserve those. */
> + ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> + ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + }
> +
> + DRM_DEV_DEBUG_DRIVER(drm->dev, "Setting up %s mode\n",
> + drm_get_format_name(format, _name_buf));
> +
> + /* Do some clean-up that we might have from a previous mode */
> + ctrl &= ~CTRL_SHIFT_DIR(1);
> + ctrl &= ~CTRL_SHIFT_NUM(0x3f);
> + if (mxsfb->devdata->ipversion >= 4)
> + writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_CLR) |
> +CTRL2_EVEN_LINE_PATTERN(CTRL2_LINE_PATTERN_CLR),
> +mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
>
> switch (format) {
> - case DRM_FORMAT_RGB565:
> - dev_dbg(drm->dev, "Setting up RGB565 mode\n");
> + case DRM_FORMAT_BGR565: /* BG16 */
> + if (mxsfb->devdata->ipversion < 4)
> + goto err;
This function should not return an error. Invalid pixel formats should
be caught at atomic check time. The easiest way to do so is to use two
different lists of supported formats when constructing the plane, based
on the IP version.
By the way, the IP version register has been removed in i.MX6. i.MX6 and
newer SoCs support a second plane, which I'm trying to get working. It
would help to know what version number to use for the ipversion field
for i.MX6, i.MX7 and i.MX8 in order to enable support for the second
plane based on the SoC model.
On a similar topic, would you happen to have tested the second plane
(configured through AS_CTRL, AS_BUF and AS_NEXT_BUF) ? The plane "works"
but seems to always use a 32bpp format regardless of how I program it,
and the frame buffer start address seems to be shifted for some reason.
> + writel(CTRL2_ODD_LINE_PATTERN(CTRL2_LINE_PATTERN_BGR) |
> + CTRL2_EVEN_LINE_PATTERN(CTRL2_LINE_PATTERN_BGR),
> + mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> + /* Fall through */
> + case DRM_FORMAT_RGB565: /* RG16 */
> + ctrl |= CTRL_SET_WORD_LENGTH(0);
> + ctrl &= ~CTRL_DF16;
> + ctrl1 |=
[Bug 112214] Vega20 crashing randomly while using Xorg or Wayland in Fedora 31
https://bugs.freedesktop.org/show_bug.cgi?id=112214 --- Comment #3 from Alex Deucher --- Can you attach your dmesg output from boot? -- 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 112214] Vega20 crashing randomly while using Xorg or Wayland in Fedora 31
https://bugs.freedesktop.org/show_bug.cgi?id=112214 Alex Deucher changed: What|Removed |Added Attachment #145894|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/15] mm/mmu_notifier: define the header pre-processor parts even if disabled
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead follow the usual pattern and provide most of the header with only
> the functions stubbed out when CONFIG_MMU_NOTIFIER is disabled. This
> ensures code compiles no matter what the config setting is.
>
> While here, struct mmu_notifier_mm is private to mmu_notifier.c, move it.
and correct a minor spelling error in a comment. Good. :)
>
> Reviewed-by: Jérôme Glisse
> Signed-off-by: Jason Gunthorpe
> ---
> include/linux/mmu_notifier.h | 46 +---
> mm/mmu_notifier.c| 13 ++
> 2 files changed, 30 insertions(+), 29 deletions(-)
>
Because this is correct as-is, you can add:
Reviewed-by: John Hubbard
...whether or not you take the following recommendation, which is:
you've only done part of the job of making struct mmu_notifier_mm
private to mmu_notifier.c. There's more:
* struct mmu_notifier_mm is referred to in two places now: mm_types.h
and (still) mmu_notifier.h. Therefore:
a) Move the last two traces of it out of mmu_notifier.h, and
b) Put a forward declaration in mm_types.h, which is where it
belongs because that's where it's referred to.
So if you apply this incremental patch on top, I think it's where
you want to be:
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fa795284..df93a3cc0da9 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -25,6 +25,7 @@
struct address_space;
struct mem_cgroup;
+struct mmu_notifier_mm;
/*
* Each physical page in the system has a struct page associated with
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 51b92ba013dd..84efd2c51f5c 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -8,7 +8,6 @@
#include
#include
-struct mmu_notifier_mm;
struct mmu_notifier;
struct mmu_notifier_range;
struct mmu_range_notifier;
@@ -263,10 +262,7 @@ struct mmu_notifier_range {
enum mmu_notifier_event event;
};
-static inline int mm_has_notifiers(struct mm_struct *mm)
-{
- return unlikely(mm->mmu_notifier_mm);
-}
+int mm_has_notifiers(struct mm_struct *mm);
struct mmu_notifier *mmu_notifier_get_locked(const struct mmu_notifier_ops
*ops,
struct mm_struct *mm);
@@ -477,10 +473,7 @@ static inline void mmu_notifier_invalidate_range(struct
mm_struct *mm,
__mmu_notifier_invalidate_range(mm, start, end);
}
-static inline void mmu_notifier_mm_init(struct mm_struct *mm)
-{
- mm->mmu_notifier_mm = NULL;
-}
+void mmu_notifier_mm_init(struct mm_struct *mm);
static inline void mmu_notifier_mm_destroy(struct mm_struct *mm)
{
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 2b7485919ecf..107f9406a92d 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -47,6 +47,16 @@ struct mmu_notifier_mm {
struct hlist_head deferred_list;
};
+int mm_has_notifiers(struct mm_struct *mm)
+{
+ return unlikely(mm->mmu_notifier_mm);
+}
+
+void mmu_notifier_mm_init(struct mm_struct *mm)
+{
+ mm->mmu_notifier_mm = NULL;
+}
+
/*
* This is a collision-retry read-side/write-side 'lock', a lot like a
* seqcount, however this allows multiple write-sides to hold it at
thanks,
John Hubbard
NVIDIA
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 1bd8e6a09a3c27..12bd603d318ce7 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -7,8 +7,9 @@
> #include
> #include
>
> +struct mmu_notifier_mm;
> struct mmu_notifier;
> -struct mmu_notifier_ops;
> +struct mmu_notifier_range;
>
> /**
> * enum mmu_notifier_event - reason for the mmu notifier callback
> @@ -40,36 +41,8 @@ enum mmu_notifier_event {
> MMU_NOTIFY_SOFT_DIRTY,
> };
>
> -#ifdef CONFIG_MMU_NOTIFIER
> -
> -#ifdef CONFIG_LOCKDEP
> -extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
> -#endif
> -
> -/*
> - * The mmu notifier_mm structure is allocated and installed in
> - * mm->mmu_notifier_mm inside the mm_take_all_locks() protected
> - * critical section and it's released only when mm_count reaches zero
> - * in mmdrop().
> - */
> -struct mmu_notifier_mm {
> - /* all mmu notifiers registerd in this mm are queued in this list */
> - struct hlist_head list;
> - /* to serialize the list modifications and hlist_unhashed */
> - spinlock_t lock;
> -};
> -
> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
>
> -struct mmu_notifier_range {
> - struct vm_area_struct *vma;
> - struct mm_struct *mm;
> - unsigned long start;
> - unsigned long end;
> - unsigned flags;
> - enum mmu_notifier_event event;
> -};
> -
> struct mmu_notifier_ops {
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
Quoting Daniel Vetter (2019-11-05 20:58:25) > On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > > It's broken. > > > > > > Reported-by: Stephen Rothwell > > > References: > > > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > > > Signed-off-by: Daniel Vetter > > > --- > > > Note: Probably best to apply this directly onto drm-next to avoid > > > having drm-next dropped from linux-next until the next pull request. > > > -Daniel > > > --- > > > drivers/gpu/drm/i915/Kconfig.debug | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > > > b/drivers/gpu/drm/i915/Kconfig.debug > > > index ef123eb29168..d2ba8f7e5e50 100644 > > > --- a/drivers/gpu/drm/i915/Kconfig.debug > > > +++ b/drivers/gpu/drm/i915/Kconfig.debug > > > @@ -44,7 +44,6 @@ config DRM_I915_DEBUG > > > select DRM_I915_SELFTEST > > > select DRM_I915_DEBUG_RUNTIME_PM > > > select DRM_I915_DEBUG_MMIO > > > - select BROKEN # for prototype uAPI > > > > You have to replace it with another secret bool as you cannot otherwise > > enable CONFIG_BROKEN in .config. > > Or this: > > diff --git a/init/Kconfig b/init/Kconfig > index b4daad2bac23..4dbea1b9e6bb 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -75,6 +75,7 @@ menu "General setup" > > config BROKEN > bool > + default y > > config BROKEN_ON_SMP > bool > > Either way it needs to be in topic/core-for-CI, not in any official > tree. Because if you allow autobuilders to enable CONFIG_BROKEN, no > matter how well hidden, they'll all break. You can also just revert my > patch that Dave pushed to drm-next (to get us back into the linux-next > club). Fwiw, I think the revert in core-for-CI is reasonable, as that gives devs the ability to toggle on the hidden menus, while at the same time requiring them to have the minimal debug setup. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/mediatek: Add plumbing for layer_check hook
From: Sean Paul
This allows components to implement a .layer_check callback for their
layers which is called during atomic_check.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 12
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 ++
4 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ccf395f17a99..04e7e4bdbdb5 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -394,6 +394,16 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
}
}
+int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
+struct mtk_plane_state *state)
+{
+ unsigned int local_layer;
+ struct mtk_ddp_comp *comp;
+
+ comp = mtk_drm_ddp_comp_for_plane(crtc, plane, _layer);
+ return mtk_ddp_comp_layer_check(comp, local_layer, state);
+}
+
static void mtk_drm_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
index fcc134eb00c9..6afe1c19557a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
@@ -19,5 +19,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *comp);
int mtk_drm_crtc_create(struct drm_device *drm_dev,
const enum mtk_ddp_comp_id *path,
unsigned int path_len);
+int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
+struct mtk_plane_state *state);
#endif /* MTK_DRM_CRTC_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 26441f4d1ad3..3de371e28bdf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -80,6 +80,9 @@ struct mtk_ddp_comp_funcs {
unsigned int (*layer_nr)(struct mtk_ddp_comp *comp);
void (*layer_on)(struct mtk_ddp_comp *comp, unsigned int idx);
void (*layer_off)(struct mtk_ddp_comp *comp, unsigned int idx);
+ int (*layer_check)(struct mtk_ddp_comp *comp,
+ unsigned int idx,
+ struct mtk_plane_state *state);
void (*layer_config)(struct mtk_ddp_comp *comp, unsigned int idx,
struct mtk_plane_state *state);
void (*gamma_set)(struct mtk_ddp_comp *comp,
@@ -152,6 +155,15 @@ static inline void mtk_ddp_comp_layer_off(struct
mtk_ddp_comp *comp,
comp->funcs->layer_off(comp, idx);
}
+static inline int mtk_ddp_comp_layer_check(struct mtk_ddp_comp *comp,
+ unsigned int idx,
+ struct mtk_plane_state *state)
+{
+ if (comp->funcs && comp->funcs->layer_check)
+ return comp->funcs->layer_check(comp, idx, state);
+ return 0;
+}
+
static inline void mtk_ddp_comp_layer_config(struct mtk_ddp_comp *comp,
unsigned int idx,
struct mtk_plane_state *state)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 584a9ecadce6..58b02fffe321 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -84,6 +84,7 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
{
struct drm_framebuffer *fb = state->fb;
struct drm_crtc_state *crtc_state;
+ int ret;
if (!fb)
return 0;
@@ -91,6 +92,11 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
if (!state->crtc)
return 0;
+ ret = mtk_drm_crtc_plane_check(state->crtc, plane,
+ to_mtk_plane_state(state));
+ if (ret)
+ return ret;
+
crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] drm/mediatek: Refactor plane init/check and support rotation
From: Sean Paul Hello, This is a follow-on to [1], which supports the original Y-flip. I've added X-flip and 180 degree rotate. Additionally, the rotation property is only exposed for ovl planes, not rdma planes since rdma doesn't support it. In order to differentiate between the two types, I had to do some plumbing in order to surface the supported rotations of a component as well as allowing a component to implement plane checks. I've tested this on a 4.19 kernel on mt8183. The set was then forward ported to mainline and build tested. The forward port was relatively collision free, but there were a few. Sean [1]- https://lists.freedesktop.org/archives/dri-devel/2019-November/242312.html Sean Paul (7): drm/mediatek: Refactor plane init drm/mediatek: Add helper to get component for a plane drm/mediatek: Add plumbing for layer_check hook drm/mediatek: Plumb supported rotation values from components to plane init drm/mediatek: Support reflect-y plane rotation drm/mediatek: Support reflect-x plane rotation drm/mediatek: Support 180 degree rotation drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 50 +++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 145 ++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 22 +++ drivers/gpu/drm/mediatek/mtk_drm_plane.c| 18 ++- drivers/gpu/drm/mediatek/mtk_drm_plane.h| 4 +- 6 files changed, 199 insertions(+), 42 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] drm/mediatek: Support 180 degree rotation
From: Sean Paul
Now that we support both reflections, we can expose 180 degree rotation
and rely on the simplify routine to convert that into REFLECT_X |
REFLECT_Y
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index f4c4d3fedc5f..4a55bb6e2213 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -143,8 +143,8 @@ static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp
*comp)
static unsigned int mtk_ovl_supported_rotations(struct mtk_ddp_comp *comp)
{
- return DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y |
- DRM_MODE_REFLECT_X;
+ return DRM_MODE_ROTATE_0 | DRM_MODE_ROTATE_180 |
+ DRM_MODE_REFLECT_X | DRM_MODE_REFLECT_Y;
}
static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp, unsigned int idx,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm/mediatek: Plumb supported rotation values from components to plane init
From: Sean Paul
This patch adds the ability for components to expose supported rotations
which will be exposed to userspace via a plane rotation property.
No functional changes in this patch.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 10 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 12 +++-
drivers/gpu/drm/mediatek/mtk_drm_plane.h| 4 +++-
4 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 04e7e4bdbdb5..f80a8ba75977 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -600,13 +600,15 @@ static int mtk_drm_crtc_init_comp_planes(struct
drm_device *drm_dev,
int comp_idx, int pipe)
{
int num_planes = mtk_drm_crtc_num_comp_planes(mtk_crtc, comp_idx);
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[comp_idx];
int i, ret;
for (i = 0; i < num_planes; i++) {
ret = mtk_plane_init(drm_dev,
_crtc->planes[mtk_crtc->layer_nr],
BIT(pipe),
- mtk_drm_crtc_plane_type(mtk_crtc->layer_nr));
+ mtk_drm_crtc_plane_type(mtk_crtc->layer_nr),
+ mtk_ddp_comp_supported_rotations(comp));
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 3de371e28bdf..2f1e9e75b8da 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -77,6 +77,7 @@ struct mtk_ddp_comp_funcs {
void (*stop)(struct mtk_ddp_comp *comp);
void (*enable_vblank)(struct mtk_ddp_comp *comp, struct drm_crtc *crtc);
void (*disable_vblank)(struct mtk_ddp_comp *comp);
+ unsigned int (*supported_rotations)(struct mtk_ddp_comp *comp);
unsigned int (*layer_nr)(struct mtk_ddp_comp *comp);
void (*layer_on)(struct mtk_ddp_comp *comp, unsigned int idx);
void (*layer_off)(struct mtk_ddp_comp *comp, unsigned int idx);
@@ -133,6 +134,15 @@ static inline void mtk_ddp_comp_disable_vblank(struct
mtk_ddp_comp *comp)
comp->funcs->disable_vblank(comp);
}
+static inline
+unsigned int mtk_ddp_comp_supported_rotations(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->supported_rotations)
+ return comp->funcs->supported_rotations(comp);
+
+ return 0;
+}
+
static inline unsigned int mtk_ddp_comp_layer_nr(struct mtk_ddp_comp *comp)
{
if (comp->funcs && comp->funcs->layer_nr)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 58b02fffe321..cd7c97eb7ee6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -138,6 +138,7 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
state->pending.y = plane->state->dst.y1;
state->pending.width = drm_rect_width(>state->dst);
state->pending.height = drm_rect_height(>state->dst);
+ state->pending.rotation = plane->state->rotation;
wmb(); /* Make sure the above parameters are set before update */
state->pending.dirty = true;
}
@@ -160,7 +161,8 @@ static const struct drm_plane_helper_funcs
mtk_plane_helper_funcs = {
};
int mtk_plane_init(struct drm_device *dev, struct drm_plane *plane,
- unsigned long possible_crtcs, enum drm_plane_type type)
+ unsigned long possible_crtcs, enum drm_plane_type type,
+ unsigned int supported_rotations)
{
int err;
@@ -172,6 +174,14 @@ int mtk_plane_init(struct drm_device *dev, struct
drm_plane *plane,
return err;
}
+ if (supported_rotations & ~DRM_MODE_ROTATE_0) {
+ err = drm_plane_create_rotation_property(plane,
+DRM_MODE_ROTATE_0,
+supported_rotations);
+ if (err)
+ DRM_INFO("Create rotation property failed\n");
+ }
+
drm_plane_helper_add(plane, _plane_helper_funcs);
return 0;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
index 6f842df722c7..760885e35b27 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
@@ -20,6 +20,7 @@ struct mtk_plane_pending_state {
unsigned inty;
unsigned intwidth;
unsigned intheight;
+ unsigned introtation;
booldirty;
};
@@
[PATCH v2 6/7] drm/mediatek: Support reflect-x plane rotation
From: Sean Paul
Add support for REFLECT_X rotations.
Cc: Fritz Koenig
Cc: Daniele Castagna
Cc: Miguel Casas
Cc: Mark Yacoub
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index fae10aead3d5..f4c4d3fedc5f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -53,6 +53,7 @@
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
#defineOVL_CON_VIRT_FLIP BIT(9)
+#defineOVL_CON_HORZ_FLIP BIT(10)
struct mtk_disp_ovl_data {
unsigned int addr;
@@ -142,7 +143,8 @@ static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp
*comp)
static unsigned int mtk_ovl_supported_rotations(struct mtk_ddp_comp *comp)
{
- return DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y;
+ return DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y |
+ DRM_MODE_REFLECT_X;
}
static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp, unsigned int idx,
@@ -153,6 +155,7 @@ static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp,
unsigned int idx,
rotation = drm_rotation_simplify(state->rotation,
DRM_MODE_ROTATE_0 |
+DRM_MODE_REFLECT_X |
DRM_MODE_REFLECT_Y);
rotation &= ~DRM_MODE_ROTATE_0;
@@ -269,6 +272,11 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp
*comp, unsigned int idx,
addr += (pending->height - 1) * pending->pitch;
}
+ if (pending->rotation & DRM_MODE_REFLECT_X) {
+ con |= OVL_CON_HORZ_FLIP;
+ addr += pending->pitch - 1;
+ }
+
writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/7] drm/mediatek: Support reflect-y plane rotation
From: Sean Paul
Expose the rotation property and handle REFLECT_Y rotations.
Changes in v2:
- Move the check logic into mtk_disp_ovl.c since it doesn't apply to rdma
Link to v1:
https://lists.freedesktop.org/archives/dri-devel/2019-November/242312.html
Cc: Fritz Koenig
Cc: Daniele Castagna
Cc: Miguel Casas
Cc: Mark Yacoub
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 42 +
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 14878ebf59d7..fae10aead3d5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -3,6 +3,8 @@
* Copyright (c) 2015 MediaTek Inc.
*/
+#include
+
#include
#include
#include
@@ -50,6 +52,7 @@
OVL_CON_CLRFMT_RGB : 0)
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
+#defineOVL_CON_VIRT_FLIP BIT(9)
struct mtk_disp_ovl_data {
unsigned int addr;
@@ -137,6 +140,38 @@ static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp
*comp)
return ovl->data->layer_nr;
}
+static unsigned int mtk_ovl_supported_rotations(struct mtk_ddp_comp *comp)
+{
+ return DRM_MODE_ROTATE_0 | DRM_MODE_REFLECT_Y;
+}
+
+static int mtk_ovl_layer_check(struct mtk_ddp_comp *comp, unsigned int idx,
+ struct mtk_plane_state *mtk_state)
+{
+ struct drm_plane_state *state = _state->base;
+ unsigned int rotation = 0;
+
+ rotation = drm_rotation_simplify(state->rotation,
+DRM_MODE_ROTATE_0 |
+DRM_MODE_REFLECT_Y);
+ rotation &= ~DRM_MODE_ROTATE_0;
+
+ /* We can only do reflection, not rotation */
+ if ((rotation & DRM_MODE_ROTATE_MASK) != 0)
+ return -EINVAL;
+
+ /*
+* TODO: Rotating/reflecting YUV buffers is not supported at this time.
+* Only RGB[AX] variants are supported.
+*/
+ if (state->fb->format->is_yuv && rotation != 0)
+ return -EINVAL;
+
+ state->rotation = rotation;
+
+ return 0;
+}
+
static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
{
unsigned int reg;
@@ -229,6 +264,11 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp
*comp, unsigned int idx,
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
+ if (pending->rotation & DRM_MODE_REFLECT_Y) {
+ con |= OVL_CON_VIRT_FLIP;
+ addr += (pending->height - 1) * pending->pitch;
+ }
+
writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
@@ -263,9 +303,11 @@ static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs
= {
.stop = mtk_ovl_stop,
.enable_vblank = mtk_ovl_enable_vblank,
.disable_vblank = mtk_ovl_disable_vblank,
+ .supported_rotations = mtk_ovl_supported_rotations,
.layer_nr = mtk_ovl_layer_nr,
.layer_on = mtk_ovl_layer_on,
.layer_off = mtk_ovl_layer_off,
+ .layer_check = mtk_ovl_layer_check,
.layer_config = mtk_ovl_layer_config,
.bgclr_in_on = mtk_ovl_bgclr_in_on,
.bgclr_in_off = mtk_ovl_bgclr_in_off,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/mediatek: Refactor plane init
From: Sean Paul
Add a couple of functions which enumerate the number of planes for a
component and initialize the planes for a component.
No functional changes in this patch, but it will allow us to selectively
support rotation if the component supports it.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 77 +++--
1 file changed, 59 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index b841d3706d8b..7d0f50da8e40 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -543,14 +543,63 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *comp)
mtk_drm_finish_page_flip(mtk_crtc);
}
+static int mtk_drm_crtc_num_comp_planes(struct mtk_drm_crtc *mtk_crtc,
+ int comp_idx)
+{
+ struct mtk_ddp_comp *comp;
+
+ if (comp_idx > 1)
+ return 0;
+
+ comp = mtk_crtc->ddp_comp[comp_idx];
+ if (!comp->funcs)
+ return 0;
+
+ if (comp_idx == 1 && !comp->funcs->bgclr_in_on)
+ return 0;
+
+ return mtk_ddp_comp_layer_nr(comp);
+}
+
+static inline
+enum drm_plane_type mtk_drm_crtc_plane_type(unsigned int plane_idx)
+{
+ if (plane_idx == 0)
+ return DRM_PLANE_TYPE_PRIMARY;
+ else if (plane_idx == 1)
+ return DRM_PLANE_TYPE_CURSOR;
+ else
+ return DRM_PLANE_TYPE_OVERLAY;
+
+}
+
+static int mtk_drm_crtc_init_comp_planes(struct drm_device *drm_dev,
+struct mtk_drm_crtc *mtk_crtc,
+int comp_idx, int pipe)
+{
+ int num_planes = mtk_drm_crtc_num_comp_planes(mtk_crtc, comp_idx);
+ int i, ret;
+
+ for (i = 0; i < num_planes; i++) {
+ ret = mtk_plane_init(drm_dev,
+ _crtc->planes[mtk_crtc->layer_nr],
+ BIT(pipe),
+ mtk_drm_crtc_plane_type(mtk_crtc->layer_nr));
+ if (ret)
+ return ret;
+
+ mtk_crtc->layer_nr++;
+ }
+ return 0;
+}
+
int mtk_drm_crtc_create(struct drm_device *drm_dev,
const enum mtk_ddp_comp_id *path, unsigned int path_len)
{
struct mtk_drm_private *priv = drm_dev->dev_private;
struct device *dev = drm_dev->dev;
struct mtk_drm_crtc *mtk_crtc;
- enum drm_plane_type type;
- unsigned int zpos;
+ unsigned int num_comp_planes = 0;
int pipe = priv->num_pipes;
int ret;
int i;
@@ -606,23 +655,15 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
mtk_crtc->ddp_comp[i] = comp;
}
- mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
- if (mtk_crtc->ddp_comp_nr > 1) {
- struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
+ for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
+ num_comp_planes += mtk_drm_crtc_num_comp_planes(mtk_crtc, i);
+
+ mtk_crtc->planes = devm_kcalloc(dev, num_comp_planes,
+ sizeof(struct drm_plane), GFP_KERNEL);
- if (comp->funcs->bgclr_in_on)
- mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
- }
- mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
- sizeof(struct drm_plane),
- GFP_KERNEL);
-
- for (zpos = 0; zpos < mtk_crtc->layer_nr; zpos++) {
- type = (zpos == 0) ? DRM_PLANE_TYPE_PRIMARY :
- (zpos == 1) ? DRM_PLANE_TYPE_CURSOR :
- DRM_PLANE_TYPE_OVERLAY;
- ret = mtk_plane_init(drm_dev, _crtc->planes[zpos],
-BIT(pipe), type);
+ for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
+ ret = mtk_drm_crtc_init_comp_planes(drm_dev, mtk_crtc, i,
+ pipe);
if (ret)
return ret;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/mediatek: Add helper to get component for a plane
From: Sean Paul
Instead of hard-coding which components have planes, add a helper
function to walk the components and map a plane index to a component
layer.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 56 +++--
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 7d0f50da8e40..ccf395f17a99 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -207,6 +207,28 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
*mtk_crtc)
clk_disable_unprepare(mtk_crtc->ddp_comp[i]->clk);
}
+static
+struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc,
+ struct drm_plane *plane,
+ unsigned int *local_layer)
+{
+ struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
+ struct mtk_ddp_comp *comp;
+ int i, count = 0;
+
+ for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
+ comp = mtk_crtc->ddp_comp[i];
+ if (plane->index < (count + mtk_ddp_comp_layer_nr(comp))) {
+ *local_layer = plane->index - count;
+ return comp;
+ }
+ count += mtk_ddp_comp_layer_nr(comp);
+ }
+
+ WARN(1, "Failed to find component for plane %d\n", plane->index);
+ return NULL;
+}
+
static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_crtc *crtc = _crtc->base;
@@ -283,19 +305,12 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = _crtc->planes[i];
struct mtk_plane_state *plane_state;
- struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
- unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
+ struct mtk_ddp_comp *comp;
unsigned int local_layer;
plane_state = to_mtk_plane_state(plane->state);
-
- if (i >= comp_layer_nr) {
- comp = mtk_crtc->ddp_comp[1];
- local_layer = i - comp_layer_nr;
- } else
- local_layer = i;
- mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state);
+ comp = mtk_drm_ddp_comp_for_plane(crtc, plane, _layer);
+ mtk_ddp_comp_layer_config(comp, local_layer, plane_state);
}
return 0;
@@ -343,7 +358,6 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
unsigned int i;
- unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
unsigned int local_layer;
/*
@@ -366,17 +380,15 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
plane_state = to_mtk_plane_state(plane->state);
- if (plane_state->pending.config) {
- if (i >= comp_layer_nr) {
- comp = mtk_crtc->ddp_comp[1];
- local_layer = i - comp_layer_nr;
- } else
- local_layer = i;
-
- mtk_ddp_comp_layer_config(comp, local_layer,
- plane_state);
- plane_state->pending.config = false;
- }
+ if (!plane_state->pending.config)
+ continue;
+
+ comp = mtk_drm_ddp_comp_for_plane(crtc, plane,
+ _layer);
+
+ mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
+ plane_state->pending.config = false;
}
mtk_crtc->pending_planes = false;
}
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
Quoting Daniel Vetter (2019-11-05 20:58:25) > On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > > It's broken. > > > > > > Reported-by: Stephen Rothwell > > > References: > > > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > > > Signed-off-by: Daniel Vetter > > > --- > > > Note: Probably best to apply this directly onto drm-next to avoid > > > having drm-next dropped from linux-next until the next pull request. > > > -Daniel > > > --- > > > drivers/gpu/drm/i915/Kconfig.debug | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > > > b/drivers/gpu/drm/i915/Kconfig.debug > > > index ef123eb29168..d2ba8f7e5e50 100644 > > > --- a/drivers/gpu/drm/i915/Kconfig.debug > > > +++ b/drivers/gpu/drm/i915/Kconfig.debug > > > @@ -44,7 +44,6 @@ config DRM_I915_DEBUG > > > select DRM_I915_SELFTEST > > > select DRM_I915_DEBUG_RUNTIME_PM > > > select DRM_I915_DEBUG_MMIO > > > - select BROKEN # for prototype uAPI > > > > You have to replace it with another secret bool as you cannot otherwise > > enable CONFIG_BROKEN in .config. > > Or this: > > diff --git a/init/Kconfig b/init/Kconfig > index b4daad2bac23..4dbea1b9e6bb 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -75,6 +75,7 @@ menu "General setup" > > config BROKEN > bool > + default y > > config BROKEN_ON_SMP > bool > > Either way it needs to be in topic/core-for-CI, not in any official > tree. Because if you allow autobuilders to enable CONFIG_BROKEN, no > matter how well hidden, they'll all break. You can also just revert my > patch that Dave pushed to drm-next (to get us back into the linux-next > club). But we've explicitly tried to stop autobuilders from selecting it in the first place. That I think is a problem all of its own. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
On Tue, Nov 5, 2019 at 9:38 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-11-05 19:38:29) > > It's broken. > > > > Reported-by: Stephen Rothwell > > References: > > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > > Signed-off-by: Daniel Vetter > > --- > > Note: Probably best to apply this directly onto drm-next to avoid > > having drm-next dropped from linux-next until the next pull request. > > -Daniel > > --- > > drivers/gpu/drm/i915/Kconfig.debug | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > > b/drivers/gpu/drm/i915/Kconfig.debug > > index ef123eb29168..d2ba8f7e5e50 100644 > > --- a/drivers/gpu/drm/i915/Kconfig.debug > > +++ b/drivers/gpu/drm/i915/Kconfig.debug > > @@ -44,7 +44,6 @@ config DRM_I915_DEBUG > > select DRM_I915_SELFTEST > > select DRM_I915_DEBUG_RUNTIME_PM > > select DRM_I915_DEBUG_MMIO > > - select BROKEN # for prototype uAPI > > You have to replace it with another secret bool as you cannot otherwise > enable CONFIG_BROKEN in .config. Or this: diff --git a/init/Kconfig b/init/Kconfig index b4daad2bac23..4dbea1b9e6bb 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -75,6 +75,7 @@ menu "General setup" config BROKEN bool + default y config BROKEN_ON_SMP bool Either way it needs to be in topic/core-for-CI, not in any official tree. Because if you allow autobuilders to enable CONFIG_BROKEN, no matter how well hidden, they'll all break. You can also just revert my patch that Dave pushed to drm-next (to get us back into the linux-next club). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
Quoting Daniel Vetter (2019-11-05 19:38:29) > It's broken. > > Reported-by: Stephen Rothwell > References: > https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html > Signed-off-by: Daniel Vetter > --- > Note: Probably best to apply this directly onto drm-next to avoid > having drm-next dropped from linux-next until the next pull request. > -Daniel > --- > drivers/gpu/drm/i915/Kconfig.debug | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/Kconfig.debug > b/drivers/gpu/drm/i915/Kconfig.debug > index ef123eb29168..d2ba8f7e5e50 100644 > --- a/drivers/gpu/drm/i915/Kconfig.debug > +++ b/drivers/gpu/drm/i915/Kconfig.debug > @@ -44,7 +44,6 @@ config DRM_I915_DEBUG > select DRM_I915_SELFTEST > select DRM_I915_DEBUG_RUNTIME_PM > select DRM_I915_DEBUG_MMIO > - select BROKEN # for prototype uAPI You have to replace it with another secret bool as you cannot otherwise enable CONFIG_BROKEN in .config. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
On Tue, Nov 5, 2019 at 9:34 PM Chris Wilson wrote: > Quoting Daniel Vetter (2019-11-05 19:38:29) > > It's broken. > > So is the code that depends on it. Which is the entire point. > > Don't select it then. See the mail from Stephen, it breaks autobuilders. So we need to do this explicitly, i.e. if you want to set this, you need to explicitly enable CONFIG_BROKEN first. Auto-enabling CONFIG_BROKEN also somewhat defeats the point of this debug option, since it doesn't force users to do the multi-step thing anymore. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Don't select BROKEN
Quoting Daniel Vetter (2019-11-05 19:38:29) > It's broken. So is the code that depends on it. Which is the entire point. Don't select it then. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
On Tue, Nov 5, 2019 at 8:48 PM John Stultz wrote: > > On Tue, Nov 5, 2019 at 11:19 AM Daniel Vetter wrote: > > On Tue, Nov 5, 2019 at 6:41 PM John Stultz wrote: > > > On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter wrote: > > > > > > > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: > > > > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: > > > > > > On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote: > > > > > So even if the heaps are configured via DT (which at the moment there > > > > > is no such binding, so that's not really a valid method yet), there's > > > > > still the question of if the heap is necessary/makes sense on the > > > > > device. And the DT would only control the availability of the heap > > > > > interface, not if the heap driver is loaded or not. > > > > > > > > Hm I thought the cma regions are configured in DT? How does that work if > > > > it's not using DT? > > > > > > So yea, CMA regions are either configured by DT or setup at build time > > > (I think there's a cmdline option to set it up as well). > > > > > > But the CMA regions and the dmabuf cma heap driver are separate > > > things. The latter uses the former. > > > > Huh, I assumed the plan is that whenever there's a cma region, we want > > to instantiate a dma-buf heap for it? Why/when would we not want to do > > that? > > Not quite. Andrew noted that we may not want to expose all CMA regions > via dmabuf heaps, so right now we only expose the default region. I > have follow on patches that I sent out earlier (which requires a > to-be-finalized DT binding) which allows us to specify which other CMA > regions to expose. Why do we not want to expose them all? I figured if there's a cma heap, then a device you have needs it, and if that's the case you might want to allocate for that device from the heap? Maybe link to the discussion? > > > > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers > > > > > for the display framebuffer. So gralloc uses ION to allocate from the > > > > > CMA heap. However on the db845c, it has no such restrictions, so the > > > > > CMA heap isn't necessary. > > > > > > > > Why do you have a CMA region for the 2nd board if you don't need it? > > > > _That_ sounds like some serious memory waster, not a few lines of code > > > > loaded for nothing :-) > > > > > > ??? That's not what I said above. If the db845c doesn't need CMA it > > > won't have a CMA region. > > > > > > The issue at hand is that we may want to avoid loading the dmabuf CMA > > > heap driver on a board that doesn't use CMA. > > > > So the CMA core code is also a module, or how does that work? Not > > No. CMA core isn't available as a module. > > > loading the cma dma-buf heap, but keeping all the other cma code > > around feels slightly silly. Do we have numbers that justify this > > silliness? > > I agree that is maybe not the most critical item on the list, but its > one of many that do add up over time. > > Again, I'll defer to Sandeep or other folks on the Google side to help > with the importance here. Mostly I'm trying to ensure there is > functional parity to ION so we don't give folks any reason they could > object to deprecating it. > > > > The main reason I'm only submitting system and CMA is because those > > > are the only two I personally have a user for (HiKey/HiKey960 boards). > > > It's my hope that once we deprecate ION in Android, vendors will > > > migrate and we'll be able to push them to upstream their heaps as > > > well. > > > > I think for upstream I'd want to see those other heaps first. If > > they're mostly driver allocators exposed as heaps, then I think we > > need something different than heap modules, maybe allow dma-buf to > > allocate from drivers instead. But afaiui all such driver allocators > > we have in upstream are cma regions only right now. > > I'm sorry, I'm not sure I understand what you mean here (I'm not sure > what action I should be taking). Could you clarify this point? I'm not sold on the use-case for this, but maybe if I see the actual use-cases I might be swayed. A very basic/minimal "register a new dma-buf heap" function should be all that's really needed for android, so maybe we can start with that? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
On Wed, 6 Nov 2019 at 05:49, Laurent Pinchart wrote: > > Hi Dave, > > Has this pull request fallen through the cracks ? It fell down a different crack than usual, it made it from patchwork onto my hard drive, but then I didn't execute the pull. I've pulled it down, thanks for reminder. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111922] amdgpu fails to resume on 5.2 kernel [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=111922 --- Comment #4 from Alex Deucher --- Nothing comes to mind. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
Hi Daniel, On Tue, Nov 05, 2019 at 04:41:41PM +0100, Daniel Vetter wrote: > On Tue, Nov 5, 2019 at 4:29 PM Linus Walleij wrote: > > On Tue, Nov 5, 2019 at 1:40 AM Dmitry Torokhov wrote: > > > On Mon, Oct 14, 2019 at 11:43:20AM -0700, Dmitry Torokhov wrote: > > > > > > Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use > > > > the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but > > > > works with arbitrary firmware node. > > > > > > > > Reviewed-by: Laurent Pinchart > > > > Signed-off-by: Dmitry Torokhov > > > > --- > > > > > > > > Andrzej, Neil, > > > > > > > > This depends on the new code that can be bound in > > > > ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree: > > > > > > > > git pull > > > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git > > > > ib-fwnode-gpiod-get-index > > > > > > > > I hope that it would be possible to pull in this immutable branch and > > > > not wait until after 5.5 merge window, or, alternatively, merge through > > > > Linus Walleij's tree. > > > > > > Any chance this could be merged, please? > > > > I'm happy to merge it into the GPIO tree if some DRM maintainer can > > provide an ACK. > > Ack. > > > Getting ACK from DRM people is problematic and a bit of friction in the > > community, DVetter usually advice to seek mutual reviews etc, but IMO > > it would be better if some people felt more compelled to review stuff > > eventually. (And that has the problem that it doesn't scale.) > > This has a review already plus if you merge your implied review. > That's more than good enough imo, so not seeing the issue here? Isn't the issue that the patch should have been picked by someone for drm-misc ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Geert, On Tue, Nov 05, 2019 at 05:14:20PM +0100, Geert Uytterhoeven wrote: > On Thu, Oct 17, 2019 at 9:14 PM Laurent Pinchart wrote: > > On Wed, Oct 16, 2019 at 10:55:40AM +0200, Jacopo Mondi wrote: > > > Minimal increment to the CMM series, this time should really be the last > > > one. > > > > > > Just missing Rob's ack on [1/8] and Laurent's one on [5/8]. > > > > > > Changelog is minimal: > > > CMM > > > - Remove the cmm_config.enable flag. The cmm_config.table field validity > > > is > > > used to enable/disable the LUT operations > > > - Expand comments as suggested by Laurent > > > > > > CRTC > > > - use drm_color_lut_size() to check the LUT table size > > > - Inline calls to rcar_cmm_enable()/disable() > > > - Add TODO entries as suggested by Laurent > > > > > > For the record, the full series changelog is available at: > > > https://paste.debian.net/1107427/ > > > > > > v5 from yesterday with informations on testing is available at: > > > https://lkml.org/lkml/2019/10/15/337 > > > > > > Geert will you collect for DTS patches for the next release? > > > I assume the DU changes go through Laurent instead ? > > > > I've taken patch 1/8 to 6/8 and 8/8 in my tree. I expected Geert to take > > 7/8. > > And so I did. 7/8 is now in arm-soc/for-next. > > However, your drm/du/next branch seems to contain 7/8 instead of 8/8? That was a mistake that I fixed in a second pull request (see https://lists.freedesktop.org/archives/dri-devel/2019-October/241110.html), I forgot to update the drm/du/next branch, but the tag should be correct. I've now fixed the problem in the branch as well. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
Hi Dave, Has this pull request fallen through the cracks ? On Tue, Oct 22, 2019 at 01:31:35PM +0300, Laurent Pinchart wrote: > Hi Dave, > > Second attempt. > > The following changes since commit f1b4a9217efd61d0b84c6dc404596c8519ff6f59: > > Merge tag 'du-next-20191016' of git://linuxtv.org/pinchartl/media into > drm-next (2019-10-22 15:04:07 +1000) > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git tags/du-next-20191022 > > for you to fetch changes up to aad1552f1defd3a5334cd4b2573fae9963d4db57: > > drm: rcar-du: crtc: Register GAMMA_LUT properties (2019-10-22 13:21:18 > +0300) > > > - R-Car DU Color Management Module support > > > Jacopo Mondi (6): > dt-bindings: display: renesas,cmm: Add R-Car CMM documentation > dt-bindings: display, renesas,du: Document cmms property > drm: rcar-du: Add support for CMM > drm: rcar-du: kms: Initialize CMM instances > drm: rcar-du: crtc: Control CMM operations > drm: rcar-du: crtc: Register GAMMA_LUT properties > > .../devicetree/bindings/display/renesas,cmm.yaml | 67 +++ > .../devicetree/bindings/display/renesas,du.txt | 5 + > drivers/gpu/drm/rcar-du/Kconfig| 7 + > drivers/gpu/drm/rcar-du/Makefile | 1 + > drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 > + > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58 ++ > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 +++ > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_group.c| 10 + > drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 + > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + > 13 files changed, 523 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
On Tue, Nov 5, 2019 at 11:19 AM Daniel Vetter wrote: > On Tue, Nov 5, 2019 at 6:41 PM John Stultz wrote: > > On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter wrote: > > > > > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: > > > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: > > > > > On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote: > > > > So even if the heaps are configured via DT (which at the moment there > > > > is no such binding, so that's not really a valid method yet), there's > > > > still the question of if the heap is necessary/makes sense on the > > > > device. And the DT would only control the availability of the heap > > > > interface, not if the heap driver is loaded or not. > > > > > > Hm I thought the cma regions are configured in DT? How does that work if > > > it's not using DT? > > > > So yea, CMA regions are either configured by DT or setup at build time > > (I think there's a cmdline option to set it up as well). > > > > But the CMA regions and the dmabuf cma heap driver are separate > > things. The latter uses the former. > > Huh, I assumed the plan is that whenever there's a cma region, we want > to instantiate a dma-buf heap for it? Why/when would we not want to do > that? Not quite. Andrew noted that we may not want to expose all CMA regions via dmabuf heaps, so right now we only expose the default region. I have follow on patches that I sent out earlier (which requires a to-be-finalized DT binding) which allows us to specify which other CMA regions to expose. > > > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers > > > > for the display framebuffer. So gralloc uses ION to allocate from the > > > > CMA heap. However on the db845c, it has no such restrictions, so the > > > > CMA heap isn't necessary. > > > > > > Why do you have a CMA region for the 2nd board if you don't need it? > > > _That_ sounds like some serious memory waster, not a few lines of code > > > loaded for nothing :-) > > > > ??? That's not what I said above. If the db845c doesn't need CMA it > > won't have a CMA region. > > > > The issue at hand is that we may want to avoid loading the dmabuf CMA > > heap driver on a board that doesn't use CMA. > > So the CMA core code is also a module, or how does that work? Not No. CMA core isn't available as a module. > loading the cma dma-buf heap, but keeping all the other cma code > around feels slightly silly. Do we have numbers that justify this > silliness? I agree that is maybe not the most critical item on the list, but its one of many that do add up over time. Again, I'll defer to Sandeep or other folks on the Google side to help with the importance here. Mostly I'm trying to ensure there is functional parity to ION so we don't give folks any reason they could object to deprecating it. > > The main reason I'm only submitting system and CMA is because those > > are the only two I personally have a user for (HiKey/HiKey960 boards). > > It's my hope that once we deprecate ION in Android, vendors will > > migrate and we'll be able to push them to upstream their heaps as > > well. > > I think for upstream I'd want to see those other heaps first. If > they're mostly driver allocators exposed as heaps, then I think we > need something different than heap modules, maybe allow dma-buf to > allocate from drivers instead. But afaiui all such driver allocators > we have in upstream are cma regions only right now. I'm sorry, I'm not sure I understand what you mean here (I'm not sure what action I should be taking). Could you clarify this point? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 ZenAnonX (zenan...@protonmail.ch) changed: What|Removed |Added CC||zenan...@protonmail.ch --- Comment #62 from ZenAnonX (zenan...@protonmail.ch) --- Kernel: 5.3.8 OS: Arch Linux x86_64 I was able to eliminate crash mentioned in, https://bugzilla.kernel.org/show_bug.cgi?id=204181#c27 and https://bugzilla.kernel.org/show_bug.cgi?id=204181#c34 by removing "amdgpu.vm_update_mode=3" from kernel parameters. This however reintroduced https://bugs.freedesktop.org/show_bug.cgi?id=102322 as mentioned on https://wiki.archlinux.org/index.php/AMDGPU#Freezes_with_%22[drm]_IP_block:gmc_v8_0_is_hung!%22_kernel_error. "BUG: kernel NULL pointer dereference, address: 0008" seems to happen most frequently while browsing internet using icecat. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Don't select BROKEN
It's broken. Reported-by: Stephen Rothwell References: https://lists.freedesktop.org/archives/dri-devel/2019-November/242625.html Signed-off-by: Daniel Vetter --- Note: Probably best to apply this directly onto drm-next to avoid having drm-next dropped from linux-next until the next pull request. -Daniel --- drivers/gpu/drm/i915/Kconfig.debug | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index ef123eb29168..d2ba8f7e5e50 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -44,7 +44,6 @@ config DRM_I915_DEBUG select DRM_I915_SELFTEST select DRM_I915_DEBUG_RUNTIME_PM select DRM_I915_DEBUG_MMIO - select BROKEN # for prototype uAPI default n help Choose this option to turn on extra driver debugging that may affect -- 2.24.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] arm64: dts: renesas: rcar-gen3: Replace "vsps" by "renesas, vsps"
The Renesas-specific "vsps" property lacks a vendor prefix.
Add a "renesas," prefix to comply with DT best practises.
Signed-off-by: Geert Uytterhoeven
---
This depends on '[PATCH 2/3] drm: rcar-du: Recognize "renesas,vsps" in
addition to "vsps"'.
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a774b1.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a774c0.dtsi| 3 ++-
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 3 ++-
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77970.dtsi| 3 ++-
arch/arm64/boot/dts/renesas/r8a77980.dtsi| 3 ++-
arch/arm64/boot/dts/renesas/r8a77990.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi| 2 +-
11 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 34a9f472fbb43072..0a48b53c3f9dcd69 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2640,7 +2640,7 @@
clock-names = "du.0", "du.1", "du.2";
status = "disabled";
- vsps = < 0>, < 0>, < 0>;
+ renesas,vsps = < 0>, < 0>, < 0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
index fe78387e4bb866ec..2ef0e136c84dcd25 100644
--- a/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774b1.dtsi
@@ -2486,7 +2486,7 @@
clock-names = "du.0", "du.1", "du.3";
status = "disabled";
- vsps = < 0>, < 0>, < 1>;
+ renesas,vsps = < 0>, < 0>, < 1>;
ports {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
index c7bdc3606323fc97..40aceb6681474f0d 100644
--- a/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774c0.dtsi
@@ -1813,7 +1813,8 @@
clocks = < CPG_MOD 724>,
< CPG_MOD 723>;
clock-names = "du.0", "du.1";
- vsps = < 0>, < 0>;
+ renesas,vsps = < 0>, < 0>;
+
status = "disabled";
ports {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
index 14d8513d2a47336f..29b20e8aca5863e4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi
@@ -30,7 +30,7 @@
};
{
- vsps = < 0>, < 0>, < 0>, < 0>;
+ renesas,vsps = < 0>, < 0>, < 0>, < 0>;
};
{
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index fde6ec122d3b4006..c7b4ece0ab3ee03f 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -3184,7 +3184,8 @@
clock-names = "du.0", "du.1", "du.2", "du.3";
renesas,cmms = <>, <>, <>, <>;
- vsps = < 0>, < 0>, < 0>, < 1>;
+ renesas,vsps = < 0>, < 0>, < 0>,
+ < 1>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index b9db882b0351155c..95fa1608add896bf 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -2824,7 +2824,7 @@
clock-names = "du.0", "du.1", "du.2";
renesas,cmms = <>, <>, <>;
- vsps = < 0>, < 0>, < 0>;
+ renesas,vsps = < 0>, < 0>, < 0>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index bdbe197774d2f659..fb48dabb25adaf77 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -2500,7 +2500,7 @@
clock-names = "du.0", "du.1", "du.3";
renesas,cmms = <>, <>, <>;
- vsps = < 0>, < 0>, < 1>;
+ renesas,vsps = < 0>, < 0>, < 1>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
index 0d0558e53533f0dc..c47608c3e0fa066f 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77970.dtsi
@@ -1121,7 +1121,8 @@
clock-names = "du.0";
[PATCH 0/3] dt-bindings: display: renesas: du: Add vendor prefix to vsps property
Hi all,
When the Renesas-specific "vsps" property for the Renesas Display Unit
was introduced, it was forgotten to add a vendor prefix.
Hence this patch series fixes that in DT bindings, Linux driver, and DT
source files. The driver retains backward compatibility with old DTBs
by falling back to the old property name when needed.
The first two patches are against Laurent's drm/du/next branch.
The last patch is against renesas-devel, and must be postponed until the
second patch has landed upstream.
Thanks!
Geert Uytterhoeven (3):
dt-bindings: display: renesas: du: Add vendor prefix to vsps property
drm: rcar-du: Recognize "renesas,vsps" in addition to "vsps"
arm64: dts: renesas: rcar-gen3: Replace "vsps" by "renesas,vsps"
.../devicetree/bindings/display/renesas,du.txt | 12 ++--
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 3 ++-
arch/arm64/boot/dts/renesas/r8a7795-es1.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a7795.dtsi| 3 ++-
arch/arm64/boot/dts/renesas/r8a7796.dtsi| 2 +-
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 3 ++-
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 3 ++-
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 +-
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 -
13 files changed, 33 insertions(+), 22 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
From: Icenowy Zheng Some definitions currently in analogix-anx78xx.h are not restricted to the ANX78xx series, but also applicable to other DisplayPort transmitters by Analogix. Split out them to dedicated headers, and make analogix-anx78xx.h include them. Signed-off-by: Icenowy Zheng Signed-off-by: Vasily Khoruzhick Signed-off-by: Torsten Duwe Reviewed-by: Andrzej Hajda --- On Tue, Nov 05, 2019 at 11:41:26AM +0100, Maxime Ripard wrote: > > This one doesn't apply on drm-misc-next. The fix doesn't look really > obvious to me, can you rebase and resend it? Sure. The set was based on 5.4-rc5, which lacks 025910db8057f from drm-misc-next You'll also have to diff -r anx6345-v5/v5-0005-drm-bridge-Add-Analogix-anx6345-support.patch anx6345-v5a/v5-0005-drm-bridge-Add-Analogix-anx6345-support.patch 116,117c116,117 < + [I2C_IDX_DPTX] = ANALOGIX_I2C_DPTX, < + [I2C_IDX_TXCOM] = ANALOGIX_I2C_TXCOMMON, --- > + [I2C_IDX_DPTX] = 0x70, > + [I2C_IDX_TXCOM] = 0x72, To make it compile, with the changed coding style of 025910db8057f. Can you change that on the fly in 5/7 or shall I resend that, too? Torsten --- drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 461 + .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h| 247 +++ .../drm/bridge/analogix/analogix-i2c-txcommon.h| 233 +++ 3 files changed, 483 insertions(+), 458 deletions(-) --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h @@ -6,6 +6,9 @@ #ifndef __ANX78xx_H #define __ANX78xx_H +#include "analogix-i2c-dptx.h" +#include "analogix-i2c-txcommon.h" + /***/ /* Register definitions for RX_PO */ /***/ @@ -210,463 +213,6 @@ #define SP_SET_AVMUTE BIT(0) /***/ -/* Register definitions for TX_P0 */ -/***/ - -/* HDCP Status Register */ -#define SP_TX_HDCP_STATUS_REG 0x00 -#define SP_AUTH_FAIL BIT(5) -#define SP_AUTHEN_PASS BIT(1) - -/* HDCP Control Register 0 */ -#define SP_HDCP_CTRL0_REG 0x01 -#define SP_RX_REPEATER BIT(6) -#define SP_RE_AUTH BIT(5) -#define SP_SW_AUTH_OK BIT(4) -#define SP_HARD_AUTH_ENBIT(3) -#define SP_HDCP_ENC_EN BIT(2) -#define SP_BKSV_SRM_PASS BIT(1) -#define SP_KSVLIST_VLD BIT(0) -/* HDCP Function Enabled */ -#define SP_HDCP_FUNCTION_ENABLED (BIT(0) | BIT(1) | BIT(2) | BIT(3)) - -/* HDCP Receiver BSTATUS Register 0 */ -#defineSP_HDCP_RX_BSTATUS0_REG 0x1b -/* HDCP Receiver BSTATUS Register 1 */ -#defineSP_HDCP_RX_BSTATUS1_REG 0x1c - -/* HDCP Embedded "Blue Screen" Content Registers */ -#define SP_HDCP_VID0_BLUE_SCREEN_REG 0x2c -#define SP_HDCP_VID1_BLUE_SCREEN_REG 0x2d -#define SP_HDCP_VID2_BLUE_SCREEN_REG 0x2e - -/* HDCP Wait R0 Timing Register */ -#define SP_HDCP_WAIT_R0_TIME_REG 0x40 - -/* HDCP Link Integrity Check Timer Register */ -#define SP_HDCP_LINK_CHECK_TIMER_REG 0x41 - -/* HDCP Repeater Ready Wait Timer Register */ -#define SP_HDCP_RPTR_RDY_WAIT_TIME_REG 0x42 - -/* HDCP Auto Timer Register */ -#define SP_HDCP_AUTO_TIMER_REG 0x51 - -/* HDCP Key Status Register */ -#define SP_HDCP_KEY_STATUS_REG 0x5e - -/* HDCP Key Command Register */ -#define SP_HDCP_KEY_COMMAND_REG0x5f -#define SP_DISABLE_SYNC_HDCP BIT(2) - -/* OTP Memory Key Protection Registers */ -#define SP_OTP_KEY_PROTECT1_REG0x60 -#define SP_OTP_KEY_PROTECT2_REG0x61 -#define SP_OTP_KEY_PROTECT3_REG0x62 -#define SP_OTP_PSW10xa2 -#define SP_OTP_PSW20x7e -#define SP_OTP_PSW30xc6 - -/* DP System Control Registers */ -#define SP_DP_SYSTEM_CTRL_BASE (0x80 - 1) -/* Bits for DP System Control Register 2 */ -#define SP_CHA_STA BIT(2) -/* Bits for DP System Control Register 3 */ -#define SP_HPD_STATUS BIT(6) -#define SP_STRM_VALID BIT(2) -/* Bits for DP System Control Register 4 */ -#define SP_ENHANCED_MODE BIT(3) - -/* DP Video Control Register */ -#define SP_DP_VIDEO_CTRL_REG 0x84 -#define SP_COLOR_F_MASK0x06 -#define SP_COLOR_F_SHIFT 1 -#define SP_BPC_MASK0xe0 -#define SP_BPC_SHIFT 5 -# define SP_BPC_6BITS 0x00 -# define SP_BPC_8BITS 0x01 -# define SP_BPC_10BITS0x02 -# define SP_BPC_12BITS0x03 - -/* DP Audio
Re: [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert
On 11/4/19 9:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
>>> *vma)
>>> struct gntdev_priv *priv = file->private_data;
>>>
>>> pr_debug("gntdev_vma_close %p\n", vma);
>>> - if (use_ptemod) {
>>> - /* It is possible that an mmu notifier could be running
>>> -* concurrently, so take priv->lock to ensure that the vma won't
>>> -* vanishing during the unmap_grant_pages call, since we will
>>> -* spin here until that completes. Such a concurrent call will
>>> -* not do any unmapping, since that has been done prior to
>>> -* closing the vma, but it may still iterate the unmap_ops list.
>>> -*/
>>> - mutex_lock(>lock);
>>> + if (use_ptemod && map->vma == vma) {
>>
>> Is it possible for map->vma not to be equal to vma?
> It could be NULL at least if use_ptemod is not set.
>
> Otherwise, I'm not sure, the confusing bit is that the map comes from
> here:
>
> map = gntdev_find_map_index(priv, index, count);
>
> It looks like the intent is that the map->vma is always set to the
> only vma that has the map as private_data.
I am not sure how this can work otherwise. We stash map pointer in vm's
vm_private_data and vice versa (for use_ptemod) gntdev_mmap() so if they
have to match.
That's why I was asking you to see if you had something particular in
mind when you added this test.
> So, I suppose it can be relaxed to a null test and a WARN_ON that it
> hasn't changed?
You mean
if (use_ptemod) {
WARN_ON(map->vma != vma);
...
Yes, that sounds good.
-boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/18] mm/gup: introduce pin_user_pages*() and FOLL_PIN
On 11/5/19 5:10 AM, Mike Rapoport wrote:
...
>> ---
>> Documentation/vm/index.rst | 1 +
>> Documentation/vm/pin_user_pages.rst | 212 ++
>
> I think it belongs to Documentation/core-api.
Done:
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ab0eae1c153a..413f7d7c8642 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -31,6 +31,7 @@ Core utilities
generic-radix-tree
memory-allocation
mm-api
+ pin_user_pages
gfp_mask-from-fs-io
timekeeping
boot-time-mm
...
>> diff --git a/Documentation/vm/pin_user_pages.rst
>> b/Documentation/vm/pin_user_pages.rst
>> new file mode 100644
>> index ..3910f49ca98c
>> --- /dev/null
>> +++ b/Documentation/vm/pin_user_pages.rst
>> @@ -0,0 +1,212 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +
>> +pin_user_pages() and related calls
>> +
>
> I know this is too much to ask, but having pin_user_pages() a part of more
> general GUP description would be really great :)
>
Yes, definitely. But until I saw the reaction to the pin_user_pages() API
family, I didn't want to write too much--it could have all been tossed out
in favor of a whole different API. But now that we've had some initial
reviews, I'm much more confident in being able to write about the larger
API set.
So yes, I'll put that on my pending list.
...
>> +This document describes the following functions: ::
>> +
>> + pin_user_pages
>> + pin_user_pages_fast
>> + pin_user_pages_remote
>> +
>> + pin_longterm_pages
>> + pin_longterm_pages_fast
>> + pin_longterm_pages_remote
>> +
>> +Basic description of FOLL_PIN
>> +=
>> +
>> +A new flag for get_user_pages ("gup") has been added: FOLL_PIN. FOLL_PIN has
>
> Consider reading this after, say, half a year ;-)
>
OK, OK. I knew when I wrote that that it was not going to stay new forever, but
somehow failed to write the right thing anyway. :)
Here's a revised set of paragraphs:
Basic description of FOLL_PIN
=
FOLL_PIN and FOLL_LONGTERM are flags that can be passed to the get_user_pages*()
("gup") family of functions. FOLL_PIN has significant interactions and
interdependencies with FOLL_LONGTERM, so both are covered here.
Both FOLL_PIN and FOLL_LONGTERM are internal to gup, meaning that neither
FOLL_PIN nor FOLL_LONGTERM should not appear at the gup call sites. This allows
the associated wrapper functions (pin_user_pages() and others) to set the
correct combination of these flags, and to check for problems as well.
thanks,
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER
On 01.11.19 19:26, Jason Gunthorpe wrote:
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: xen-de...@lists.xenproject.org
Cc: Juergen Gross
Cc: Stefano Stabellini
Reviewed-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Jason Gunthorpe
---
drivers/xen/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Juergen/Oleksandr/Xen Maintainers:
Would you take this patch through a xen related tree? The only reason
I had in this series is to make it easier to compile-test the gntdev
changes.
Yes, I can take it for 5.5.
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: rcar-du: Recognize "renesas, vsps" in addition to "vsps"
The Renesas-specific "vsps" property lacks a vendor prefix.
Add a "renesas," prefix to comply with DT best practises.
Retain backward compatibility with old DTBs by falling back to "vsps"
when needed.
Fixes: 6d62ef3ac30be756 ("drm: rcar-du: Expose the VSP1 compositor through KMS
planes")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 186422ac552b2870..b14676f7a9f17501 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -544,6 +544,7 @@ static int rcar_du_properties_init(struct rcar_du_device
*rcdu)
static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
{
const struct device_node *np = rcdu->dev->of_node;
+ const char *vsps_prop_name = "renesas,vsps";
struct of_phandle_args args;
struct {
struct device_node *np;
@@ -559,15 +560,21 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
* entry contains a pointer to the VSP DT node and a bitmask of the
* connected DU CRTCs.
*/
- cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
+ ret = of_property_count_u32_elems(np, vsps_prop_name);
+ if (ret < 0) {
+ /* Backward compatibility with old DTBs */
+ vsps_prop_name = "vsps";
+ ret = of_property_count_u32_elems(np, vsps_prop_name);
+ }
+ cells = ret / rcdu->num_crtcs - 1;
if (cells > 1)
return -EINVAL;
for (i = 0; i < rcdu->num_crtcs; ++i) {
unsigned int j;
- ret = of_parse_phandle_with_fixed_args(np, "vsps", cells, i,
- );
+ ret = of_parse_phandle_with_fixed_args(np, vsps_prop_name,
+ cells, i, );
if (ret < 0)
goto error;
@@ -589,8 +596,8 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
/*
* Store the VSP pointer and pipe index in the CRTC. If the
-* second cell of the 'vsps' specifier isn't present, default
-* to 0 to remain compatible with older DT bindings.
+* second cell of the 'renesas,vsps' specifier isn't present,
+* default to 0 to remain compatible with older DT bindings.
*/
rcdu->crtcs[i].vsp = >vsps[j];
rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/19] drm/via: set FOLL_PIN via pin_user_pages_fast()
On 11/5/19 1:49 AM, Daniel Vetter wrote: > On Mon, Nov 04, 2019 at 11:20:38AM -0800, John Hubbard wrote: >> On 11/4/19 10:10 AM, Daniel Vetter wrote: >>> On Thu, Oct 31, 2019 at 04:36:28PM -0700, Ira Weiny wrote: On Wed, Oct 30, 2019 at 03:49:20PM -0700, John Hubbard wrote: > Convert drm/via to use the new pin_user_pages_fast() call, which sets > FOLL_PIN. Setting FOLL_PIN is now required for code that requires > tracking of pinned pages, and therefore for any code that calls > put_user_page(). > Reviewed-by: Ira Weiny >>> >>> No one's touching the via driver anymore, so feel free to merge this >>> through whatever tree suits best (aka I'll drop this on the floor and >>> forget about it now). >>> >>> Acked-by: Daniel Vetter >>> >> >> OK, great. Yes, in fact, I'm hoping Andrew can just push the whole series >> in through the mm tree, because that would allow it to be done in one >> shot, in 5.5 > > btw is there more? We should have a bunch more userptr stuff in various > drivers, so was really surprised that drm/via is the only thing in your > series. There is more, but: 1) Fortunately, the opt-in nature of FOLL_PIN allows converting a few call sites at a time. And so this patchset limits itself to converting the bare minimum required to get started, which is: a) calls sites that have already been converted to put_user_page(), and b) call sites that set FOLL_LONGTERM. So yes, follow-up patches will be required. This is not everything. In fact, if I can fix this series up quickly enough that it makes it into mmotm soon-ish, then there may be time to get some follow-patches on top of it, in time for 5.5. 2) If I recall correctly, Jerome and maybe others are working to remove as many get_user_pages() callers from drm as possible, and instead use a non-pinned page approach, with mmu notifiers instead. I'm not sure of the exact status of that work, but I see that etnaviv, amdgpu, i915, and radeon still call gup() in linux-next. Anyway, some of those call sites will disappear. Although I'd expect a few to remain, because I doubt the simpler GPUs can support page faulting. thanks, John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: display: renesas: du: Add vendor prefix to vsps property
The Renesas-specific "vsps" property lacks a vendor prefix.
Add a "renesas," prefix to comply with DT best practises.
Move "renesas,vsps" below "renesas,cmms" to preserve alphabetical sort
order.
Fixes: 06711e6385a4ab4c ("drm: rcar-du: Document the vsps property in the DT
bindings")
Signed-off-by: Geert Uytterhoeven
---
.../devicetree/bindings/display/renesas,du.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/display/renesas,du.txt
index f6fdaa67c257a046..eb4ae41fe41f83c7 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.txt
+++ b/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -41,15 +41,15 @@ Required Properties:
supplied they must be named "dclkin.x" with "x" being the input clock
numerical index.
- - vsps: A list of phandle and channel index tuples to the VSPs that handle
-the memory interfaces for the DU channels. The phandle identifies the VSP
-instance that serves the DU channel, and the channel index identifies the
-LIF instance in that VSP.
-
- renesas,cmms: A list of phandles to the CMM instances present in the SoC,
one for each available DU channel. The property shall not be specified for
SoCs that do not provide any CMM (such as V3M and V3H).
+ - renesas,vsps: A list of phandle and channel index tuples to the VSPs that
+handle the memory interfaces for the DU channels. The phandle identifies
the
+VSP instance that serves the DU channel, and the channel index identifies
+the LIF instance in that VSP.
+
Required nodes:
The connections to the DU output video ports are modeled using the OF graph
@@ -96,8 +96,8 @@ Example: R8A7795 (R-Car H3) ES2.0 DU
< CPG_MOD 722>,
< CPG_MOD 721>;
clock-names = "du.0", "du.1", "du.2", "du.3";
- vsps = < 0>, < 0>, < 0>, < 1>;
renesas,cmms = <>, <>, <>, <>;
+ renesas,vsps = < 0>, < 0>, < 0>, < 1>;
ports {
#address-cells = <1>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
On Tue, Nov 5, 2019 at 6:41 PM John Stultz wrote: > > On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter wrote: > > > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: > > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: > > > > On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote: > > > So even if the heaps are configured via DT (which at the moment there > > > is no such binding, so that's not really a valid method yet), there's > > > still the question of if the heap is necessary/makes sense on the > > > device. And the DT would only control the availability of the heap > > > interface, not if the heap driver is loaded or not. > > > > Hm I thought the cma regions are configured in DT? How does that work if > > it's not using DT? > > So yea, CMA regions are either configured by DT or setup at build time > (I think there's a cmdline option to set it up as well). > > But the CMA regions and the dmabuf cma heap driver are separate > things. The latter uses the former. Huh, I assumed the plan is that whenever there's a cma region, we want to instantiate a dma-buf heap for it? Why/when would we not want to do that? > > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers > > > for the display framebuffer. So gralloc uses ION to allocate from the > > > CMA heap. However on the db845c, it has no such restrictions, so the > > > CMA heap isn't necessary. > > > > Why do you have a CMA region for the 2nd board if you don't need it? > > _That_ sounds like some serious memory waster, not a few lines of code > > loaded for nothing :-) > > ??? That's not what I said above. If the db845c doesn't need CMA it > won't have a CMA region. > > The issue at hand is that we may want to avoid loading the dmabuf CMA > heap driver on a board that doesn't use CMA. So the CMA core code is also a module, or how does that work? Not loading the cma dma-buf heap, but keeping all the other cma code around feels slightly silly. Do we have numbers that justify this silliness? > > > With Android's GKI effort, there needs to be one kernel that works on > > > all the devices, and they are using modules to try to minimize the > > > amount of memory spent on functionality that isn't universally needed. > > > So on devices that don't need the CMA heap, they'd probably prefer not > > > to load the CMA dmabuf heap driver, so it would be best if it could be > > > built as a module. If we want to build the CMA heap as a module, the > > > symbols it uses need to be exported. > > > > Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not. > > That's fine to dispute. I'm not really in a place to assert one way or > not, but the Android folks have made their ION system and CMA heaps > loadable via a module, so it would seem like having the dmabuf system > and CMA heaps be modular would be useful to properly replace that > usage. > > For instance, the system heap as a module probably doesn't make much > sense, as most boards that want to use the dmabuf heaps interface are > likely to use that as well. CMA is more optional as not all boards > will use that one, so it might make sense to avoid loading it. > > Sandeep: Can you chime in here as to how critical having the system > and cma heaps be modules are? > > > > > > Exporting symbols for no real in-tree users feels fishy. > > > > > > I'm submitting an in-tree user here. So I'm not sure what you mean? I > > > suspect you're thinking there is some hidden/nefarious plan here, but > > > really there isn't. > > > > I was working under the assumption that you're only exporting the symbols > > for other heaps, and keep the current ones in-tree. > > No. I'm trying to allow the (hopefully-soon-to-be-in-tree) system and > cma heap drivers to be loaded from a module. > If other heaps need exports, they can submit their heaps upstream and > argue for the exported symbols themselves. > > > Are there even any > > out-of-tree dma-buf heaps still? out-of-tree and legit different use-case > > I mean ofc, not just out-of-tree because inertia :-) > > So as Andrew mentioned, he has some dmabuf heaps he's working on at > TI. From what I've heard the qualcomm folks like the dmabuf heaps > approach, but I'm not sure if they've taken a pass at converting their > vendor ION heaps to it yet. > > The main reason I'm only submitting system and CMA is because those > are the only two I personally have a user for (HiKey/HiKey960 boards). > It's my hope that once we deprecate ION in Android, vendors will > migrate and we'll be able to push them to upstream their heaps as > well. I think for upstream I'd want to see those other heaps first. If they're mostly driver allocators exposed as heaps, then I think we need something different than heap modules, maybe allow dma-buf to allocate from drivers instead. But afaiui all such driver allocators we have in upstream are cma regions only right now. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79
Re: [PATCH V8 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On Tue, 5 Nov 2019 17:32:40 +0800 Jason Wang wrote: > This sample driver creates mdev device that simulate virtio net device > over virtio mdev transport. The device is implemented through vringh > and workqueue. A device specific dma ops is to make sure HVA is used > directly as the IOVA. This should be sufficient for kernel virtio > driver to work. > > Only 'virtio' type is supported right now. I plan to add 'vhost' type > on top which requires some virtual IOMMU implemented in this sample > driver. > > Signed-off-by: Jason Wang > --- > MAINTAINERS| 1 + > samples/Kconfig| 7 + > samples/vfio-mdev/Makefile | 1 + > samples/vfio-mdev/mvnet.c | 685 + > 4 files changed, 694 insertions(+) > create mode 100644 samples/vfio-mdev/mvnet.c Have not really reviewed this, but looks sane at a glance. Acked-by: Cornelia Huck ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 5/6] virtio: introduce a mdev based transport
On Tue, 5 Nov 2019 17:32:39 +0800 Jason Wang wrote: > This patch introduces a new mdev transport for virtio. This is used to > use kernel virtio driver to drive the mediated device that is capable > of populating virtqueue directly. > > A new virtio-mdev driver will be registered to the mdev bus, when a > new virtio-mdev device is probed, it will register the device with > mdev based config ops. This means it is a software transport between > mdev driver and mdev device. The transport was implemented through > device specific ops which is a part of mdev_parent_ops now. > > Signed-off-by: Jason Wang > --- > drivers/virtio/Kconfig | 7 + > drivers/virtio/Makefile | 1 + > drivers/virtio/virtio_mdev.c | 407 +++ > 3 files changed, 415 insertions(+) > create mode 100644 drivers/virtio/virtio_mdev.c Reviewed-by: Cornelia Huck ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 3/6] mdev: introduce device specific ops
On Tue, 5 Nov 2019 10:44:18 -0700 Alex Williamson wrote: > On Tue, 5 Nov 2019 17:50:25 +0100 > Cornelia Huck wrote: > > > On Tue, 5 Nov 2019 17:32:37 +0800 > > Jason Wang wrote: > > > > > Currently, except for the create and remove, the rest of > > > mdev_parent_ops is designed for vfio-mdev driver only and may not help > > > for kernel mdev driver. With the help of class id, this patch > > > introduces device specific callbacks inside mdev_device > > > structure. This allows different set of callback to be used by > > > vfio-mdev and virtio-mdev. > > > > > > Reviewed-by: Parav Pandit > > > Signed-off-by: Jason Wang > > > --- > > > .../driver-api/vfio-mediated-device.rst | 35 + > > > MAINTAINERS | 1 + > > > drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- > > > drivers/s390/cio/vfio_ccw_ops.c | 18 --- > > > drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- > > > drivers/vfio/mdev/mdev_core.c | 24 - > > > drivers/vfio/mdev/mdev_private.h | 5 ++ > > > drivers/vfio/mdev/vfio_mdev.c | 37 ++--- > > > include/linux/mdev.h | 43 --- > > > include/linux/mdev_vfio_ops.h | 52 +++ > > > samples/vfio-mdev/mbochs.c| 20 --- > > > samples/vfio-mdev/mdpy.c | 20 --- > > > samples/vfio-mdev/mtty.c | 18 --- > > > 13 files changed, 206 insertions(+), 99 deletions(-) > > > create mode 100644 include/linux/mdev_vfio_ops.h > > > > > > > (...) > > > > > @@ -172,10 +163,34 @@ that a driver should use to unregister itself with > > > the mdev core driver:: > > > > > > extern void mdev_unregister_device(struct device *dev); > > > > > > -It is also required to specify the class_id in create() callback > > > through:: > > > +As multiple types of mediated devices may be supported, class id needs > > > +to be specified in the create callback(). This could be done > > > > The brackets should probably go behind 'create'? > > > > > +explicitly for the device that does not use on mdev bus for its > > > > "for devices that do not use the mdev bus" ? > > > > But why wouldn't they? I feel like I've missed some discussion here :/ > > The device ops provide a route through mdev-core for known callbacks, > which is primarily useful when we have 1:N relation between mdev bus > driver and vendor drivers. The obvious example here is vfio-mdev, > where we have GVT-g, vfio-ap, vfio-ccw, NVIDIA GRID, and various sample > drivers all advertising vfio-mdev support via their class id. However, > if we have a tightly coupled vendor driver and mdev bus driver, as the > mlx5 support that Parav is developing, the claim is that they prefer > not to expose any device ops and intend to interact directly with the > mdev device. At least that's my understanding. Thanks, > > Alex Ah, ok. So maybe use the phrasing "devices that interact with the mdev device directly" vs "devices that use device-specific ops" instead? Not a strong critique, though. > > > > +operation through: > > > > > > int mdev_set_class(struct mdev_device *mdev, u16 id); > > > > > > +For the device that uses on the mdev bus for its operation, the > > > class > > > > "For devices that use the mdev bus..." > > > > But same comment as above. > > > > > +should provide helper function to set class id and device > > > specific +ops. E.g for vfio-mdev devices, the function to be > > > called is:: + > > > + int mdev_set_vfio_ops(struct mdev_device *mdev, > > > + const struct mdev_vfio_device_ops > > > *vfio_ops); + > > > +The class id (set by this function to MDEV_CLASS_ID_VFIO) is > > > used to +match a device with an mdev driver via its id table. The > > > device +specific callbacks (specified in *vfio_ops) are > > > obtainable via +mdev_get_vfio_ops() (for use by the mdev bus > > > driver). A vfio-mdev +device (class id MDEV_CLASS_ID_VFIO) uses > > > the following +device-specific ops: > > > + > > > +* open: open callback of vfio mediated device > > > +* close: close callback of vfio mediated device > > > +* ioctl: ioctl callback of vfio mediated device > > > +* read : read emulation callback > > > +* write: write emulation callback > > > +* mmap: mmap emulation callback > > > + > > > Mediated Device Management Interface Through sysfs > > > == > > > > Otherwise, looks good. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #125 from har...@gmx.de --- ... thanks for your feedback, so it seems we are faced with the same bug ... Btw, i got crashes with at least one vulkan game and ACO compiler backend enabled too. I think it really depends of the load pattern. And enabled vsync is triggering the typical load pattern, with at least one transient (from high to low load) per frame. Is someone affected with this bug here, usually building the kernel from source locally? -- 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 V8 0/6] mdev based hardware virtio offloading support
On Tue, 5 Nov 2019 17:32:34 +0800
Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is done by introducing a new mdev transport for virtio
> (virtio_mdev) and register itself as a new kind of mdev driver. Then
> it provides a unified way for kernel virtio driver to talk with mdev
> device implementation.
>
> Though the series only contains kernel driver support, the goal is to
> make the transport generic enough to support userspace drivers. This
> means vhost-mdev[1] could be built on top as well by resuing the
> transport.
>
> A sample driver is also implemented which simulate a virito-net
> loopback ethernet device on top of vringh + workqueue. This could be
> used as a reference implementation for real hardware driver.
>
> Also a real ICF VF driver was also posted here[2] which is a good
> reference for vendors who is interested in their own virtio datapath
> offloading product.
>
> Consider mdev framework only support VFIO device and driver right now,
> this series also extend it to support other types. This is done
> through introducing class id to the device and pairing it with
> id_talbe claimed by the driver. On top, this seris also decouple
> device specific parents ops out of the common ones.
>
> Pktgen test was done with virito-net + mvnet loop back device.
>
> Please review.
>
> [1] https://lkml.org/lkml/2019/10/31/440
> [2] https://lkml.org/lkml/2019/10/15/1226
>
> Changes from V7:
> - drop {set|get}_mdev_features for virtio
> - typo and comment style fixes
Seems we're nearly there, all the remaining comments are relatively
superficial, though I would appreciate a v9 addressing them as well as
the checkpatch warnings:
https://patchwork.freedesktop.org/series/68977/
Consider this a last call for reviews or acks (or naks) from affected
mdev vendor drivers, mdev-core sub-maintainers (Hi Kirti), virtio
stakeholders, etc. Thanks,
Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 4/6] mdev: introduce virtio device and its device ops
On Tue, 5 Nov 2019 17:32:38 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 21 +
> drivers/vfio/mdev/mdev_private.h | 2 +
> include/linux/mdev.h | 6 ++
> include/linux/mdev_virtio_ops.h | 149 +++
> 4 files changed, 178 insertions(+)
> create mode 100644 include/linux/mdev_virtio_ops.h
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 4e70f19ac145..c58253404ed5 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -78,6 +78,27 @@ const struct mdev_vfio_device_ops
> *mdev_get_vfio_ops(struct mdev_device *mdev)
> }
> EXPORT_SYMBOL(mdev_get_vfio_ops);
>
> +/*
> + * Specify the virtio device ops for the mdev device, this
> + * must be called during create() callback for virtio mdev device.
> + */
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct mdev_virtio_device_ops *virtio_ops)
> +{
> + mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
> + mdev->virtio_ops = virtio_ops;
> +}
> +EXPORT_SYMBOL(mdev_set_virtio_ops);
> +
> +/* Get the virtio device ops for the mdev device. */
> +const struct mdev_virtio_device_ops *
> +mdev_get_virtio_ops(struct mdev_device *mdev)
> +{
> + WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
> + return mdev->virtio_ops;
> +}
> +EXPORT_SYMBOL(mdev_get_virtio_ops);
> +
> struct device *mdev_dev(struct mdev_device *mdev)
> {
> return >dev;
> diff --git a/drivers/vfio/mdev/mdev_private.h
> b/drivers/vfio/mdev/mdev_private.h
> index 411227373625..2c74dd032409 100644
> --- a/drivers/vfio/mdev/mdev_private.h
> +++ b/drivers/vfio/mdev/mdev_private.h
> @@ -11,6 +11,7 @@
> #define MDEV_PRIVATE_H
>
> #include
> +#include
>
> int mdev_bus_register(void);
> void mdev_bus_unregister(void);
> @@ -38,6 +39,7 @@ struct mdev_device {
> u16 class_id;
> union {
> const struct mdev_vfio_device_ops *vfio_ops;
> + const struct mdev_virtio_device_ops *virtio_ops;
> };
> };
>
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 9e37506d1987..f3d75a60c2b5 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -17,6 +17,7 @@
>
> struct mdev_device;
> struct mdev_vfio_device_ops;
> +struct mdev_virtio_device_ops;
>
> /*
> * Called by the parent device driver to set the device which represents
> @@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
> void mdev_set_vfio_ops(struct mdev_device *mdev,
> const struct mdev_vfio_device_ops *vfio_ops);
> const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device
> *mdev);
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct mdev_virtio_device_ops *virtio_ops);
> +const struct mdev_virtio_device_ops *
> +mdev_get_virtio_ops(struct mdev_device *mdev);
>
> extern struct bus_type mdev_bus_type;
>
> @@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
>
> enum {
> MDEV_CLASS_ID_VFIO = 1,
> + MDEV_CLASS_ID_VIRTIO = 2,
> /* New entries must be added here */
> };
>
> diff --git a/include/linux/mdev_virtio_ops.h b/include/linux/mdev_virtio_ops.h
> new file mode 100644
> index ..379bfa5d6a30
> --- /dev/null
> +++ b/include/linux/mdev_virtio_ops.h
> @@ -0,0 +1,149 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Virtio mediated device driver
> + *
> + * Copyright 2019, Red Hat Corp.
> + * Author: Jason Wang
> + */
> +#ifndef MDEV_VIRTIO_OPS_H
> +#define MDEV_VIRTIO_OPS_H
> +
> +#include
> +#include
> +#include
> +
> +#define VIRTIO_MDEV_DEVICE_API_STRING"virtio-mdev"
> +#define VIRTIO_MDEV_F_VERSION_1 0x1
This entire concept of VIRTIO_MDEV_F_VERSION_1 is gone now, right?
Let's remove it here and below. Thanks,
Alex
> +
> +struct virtio_mdev_callback {
> + irqreturn_t (*callback)(void *data);
> + void *private;
> +};
> +
> +/**
> + * struct mdev_virtio_device_ops - Structure to be registered for each
> + * mdev device to register the device for virtio/vhost drivers.
> + *
> + * The device ops that is supported by VIRTIO_MDEV_F_VERSION_1, the
> + * callbacks are mandatory unless explicity mentioned.
> + *
> + * @set_vq_address: Set the address of virtqueue
> + * @mdev: mediated device
> + * @idx: virtqueue index
> + * @desc_area: address of desc area
> + * @driver_area: address of driver area
> + * @device_area: address of device area
> + * Returns integer: success (0) or error (< 0)
> + * @set_vq_num: Set the size of virtqueue
> + *
Re: [PATCH V8 3/6] mdev: introduce device specific ops
On Tue, 5 Nov 2019 17:50:25 +0100 Cornelia Huck wrote: > On Tue, 5 Nov 2019 17:32:37 +0800 > Jason Wang wrote: > > > Currently, except for the create and remove, the rest of > > mdev_parent_ops is designed for vfio-mdev driver only and may not help > > for kernel mdev driver. With the help of class id, this patch > > introduces device specific callbacks inside mdev_device > > structure. This allows different set of callback to be used by > > vfio-mdev and virtio-mdev. > > > > Reviewed-by: Parav Pandit > > Signed-off-by: Jason Wang > > --- > > .../driver-api/vfio-mediated-device.rst | 35 + > > MAINTAINERS | 1 + > > drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- > > drivers/s390/cio/vfio_ccw_ops.c | 18 --- > > drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- > > drivers/vfio/mdev/mdev_core.c | 24 - > > drivers/vfio/mdev/mdev_private.h | 5 ++ > > drivers/vfio/mdev/vfio_mdev.c | 37 ++--- > > include/linux/mdev.h | 43 --- > > include/linux/mdev_vfio_ops.h | 52 +++ > > samples/vfio-mdev/mbochs.c| 20 --- > > samples/vfio-mdev/mdpy.c | 20 --- > > samples/vfio-mdev/mtty.c | 18 --- > > 13 files changed, 206 insertions(+), 99 deletions(-) > > create mode 100644 include/linux/mdev_vfio_ops.h > > > > (...) > > > @@ -172,10 +163,34 @@ that a driver should use to unregister itself with > > the mdev core driver:: > > > > extern void mdev_unregister_device(struct device *dev); > > > > -It is also required to specify the class_id in create() callback through:: > > +As multiple types of mediated devices may be supported, class id needs > > +to be specified in the create callback(). This could be done > > The brackets should probably go behind 'create'? > > > +explicitly for the device that does not use on mdev bus for its > > "for devices that do not use the mdev bus" ? > > But why wouldn't they? I feel like I've missed some discussion here :/ The device ops provide a route through mdev-core for known callbacks, which is primarily useful when we have 1:N relation between mdev bus driver and vendor drivers. The obvious example here is vfio-mdev, where we have GVT-g, vfio-ap, vfio-ccw, NVIDIA GRID, and various sample drivers all advertising vfio-mdev support via their class id. However, if we have a tightly coupled vendor driver and mdev bus driver, as the mlx5 support that Parav is developing, the claim is that they prefer not to expose any device ops and intend to interact directly with the mdev device. At least that's my understanding. Thanks, Alex > > +operation through: > > > > int mdev_set_class(struct mdev_device *mdev, u16 id); > > > > +For the device that uses on the mdev bus for its operation, the class > > "For devices that use the mdev bus..." > > But same comment as above. > > > +should provide helper function to set class id and device specific > > +ops. E.g for vfio-mdev devices, the function to be called is:: > > + > > + int mdev_set_vfio_ops(struct mdev_device *mdev, > > + const struct mdev_vfio_device_ops *vfio_ops); > > + > > +The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to > > +match a device with an mdev driver via its id table. The device > > +specific callbacks (specified in *vfio_ops) are obtainable via > > +mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev > > +device (class id MDEV_CLASS_ID_VFIO) uses the following > > +device-specific ops: > > + > > +* open: open callback of vfio mediated device > > +* close: close callback of vfio mediated device > > +* ioctl: ioctl callback of vfio mediated device > > +* read : read emulation callback > > +* write: write emulation callback > > +* mmap: mmap emulation callback > > + > > Mediated Device Management Interface Through sysfs > > == > > Otherwise, looks good. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/2] Allow DMA BUF heaps to be loaded as modules
On Tue, Nov 5, 2019 at 1:43 AM Daniel Vetter wrote: > > On Mon, Nov 04, 2019 at 10:57:44AM -0800, John Stultz wrote: > > On Mon, Nov 4, 2019 at 1:58 AM Daniel Vetter wrote: > > > On Fri, Oct 25, 2019 at 11:48:32PM +, John Stultz wrote: > > So even if the heaps are configured via DT (which at the moment there > > is no such binding, so that's not really a valid method yet), there's > > still the question of if the heap is necessary/makes sense on the > > device. And the DT would only control the availability of the heap > > interface, not if the heap driver is loaded or not. > > Hm I thought the cma regions are configured in DT? How does that work if > it's not using DT? So yea, CMA regions are either configured by DT or setup at build time (I think there's a cmdline option to set it up as well). But the CMA regions and the dmabuf cma heap driver are separate things. The latter uses the former. > > On the HiKey/HiKey960 boards, we have to allocate contiguous buffers > > for the display framebuffer. So gralloc uses ION to allocate from the > > CMA heap. However on the db845c, it has no such restrictions, so the > > CMA heap isn't necessary. > > Why do you have a CMA region for the 2nd board if you don't need it? > _That_ sounds like some serious memory waster, not a few lines of code > loaded for nothing :-) ??? That's not what I said above. If the db845c doesn't need CMA it won't have a CMA region. The issue at hand is that we may want to avoid loading the dmabuf CMA heap driver on a board that doesn't use CMA. > > With Android's GKI effort, there needs to be one kernel that works on > > all the devices, and they are using modules to try to minimize the > > amount of memory spent on functionality that isn't universally needed. > > So on devices that don't need the CMA heap, they'd probably prefer not > > to load the CMA dmabuf heap driver, so it would be best if it could be > > built as a module. If we want to build the CMA heap as a module, the > > symbols it uses need to be exported. > > Yeah, I guess I'm disagreeing on whether dma-buf heaps are core or not. That's fine to dispute. I'm not really in a place to assert one way or not, but the Android folks have made their ION system and CMA heaps loadable via a module, so it would seem like having the dmabuf system and CMA heaps be modular would be useful to properly replace that usage. For instance, the system heap as a module probably doesn't make much sense, as most boards that want to use the dmabuf heaps interface are likely to use that as well. CMA is more optional as not all boards will use that one, so it might make sense to avoid loading it. Sandeep: Can you chime in here as to how critical having the system and cma heaps be modules are? > > > Exporting symbols for no real in-tree users feels fishy. > > > > I'm submitting an in-tree user here. So I'm not sure what you mean? I > > suspect you're thinking there is some hidden/nefarious plan here, but > > really there isn't. > > I was working under the assumption that you're only exporting the symbols > for other heaps, and keep the current ones in-tree. No. I'm trying to allow the (hopefully-soon-to-be-in-tree) system and cma heap drivers to be loaded from a module. If other heaps need exports, they can submit their heaps upstream and argue for the exported symbols themselves. > Are there even any > out-of-tree dma-buf heaps still? out-of-tree and legit different use-case > I mean ofc, not just out-of-tree because inertia :-) So as Andrew mentioned, he has some dmabuf heaps he's working on at TI. From what I've heard the qualcomm folks like the dmabuf heaps approach, but I'm not sure if they've taken a pass at converting their vendor ION heaps to it yet. The main reason I'm only submitting system and CMA is because those are the only two I personally have a user for (HiKey/HiKey960 boards). It's my hope that once we deprecate ION in Android, vendors will migrate and we'll be able to push them to upstream their heaps as well. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #32 from peter m --- updated kernel to 5.3.8-200.fc30, problem still exists -- 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 111922] amdgpu fails to resume on 5.2 kernel [regression]
https://bugs.freedesktop.org/show_bug.cgi?id=111922 --- Comment #3 from Pierre Ossman --- Issue still remains with 5.4.0-rc6 unfortunately. :/ Do you have any patches or commits I could try reverting? It's much easier building a test RPM here. It should be something during the 5.2.0 merge window. Anything likely from that set? -- 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: Incorrect buffer handling in dw-hdmi bridge audio
On Tue, 05 Nov 2019 18:02:03 +0100, Russell King - ARM Linux admin wrote: > > On Tue, Nov 05, 2019 at 05:44:26PM +0100, Takashi Iwai wrote: > > On Tue, 05 Nov 2019 17:33:44 +0100, > > Takashi Iwai wrote: > > > > > > On Tue, 05 Nov 2019 17:02:15 +0100, > > > Russell King - ARM Linux admin wrote: > > > > > > > > On Tue, Nov 05, 2019 at 09:07:43AM +0100, Neil Armstrong wrote: > > > > > Hi, > > > > > > > > > > On 05/11/2019 08:55, Takashi Iwai wrote: > > > > > > Hi, > > > > > > > > > > > > while recently working on the ALSA memory allocator API cleanup, I > > > > > > noticed that dw-hdmi bridge driver seems doing weird about the > > > > > > buffer > > > > > > management. It pre-allocates the usual device buffers fully at the > > > > > > probe time, while each stream allocates the buffer via the vmalloc > > > > > > helpers and replaces with it at each open. > > > > > > > > > > > > I guess it's no expected behavior? It's basically a full waste of > > > > > > resources, and the vmalloc buffer isn't guaranteed to work well for > > > > > > mmap on every architecture. > > > > > > > > > > > > Below is the patch to address it. Can anyone check whether this > > > > > > still > > > > > > works? > > > > > > > > > > I don't have the setup to check, but this has been pushed by Russell > > > > > I Added in CC. > > > > > > > > > > I also added the imx maintainer since it's (AFAIK) only used on iMX > > > > > SoCs. > > > > > > > > > > Neil > > > > > > > > > > > > > > > > > Since I have a cleanup series and this is involved, I'd like to take > > > > > > the fix through my tree once after it's confirmed (and get ACK if > > > > > > possible). > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Takashi > > > > > > > > > > > > -- 8< -- > > > > > > From: Takashi Iwai > > > > > > Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer > > > > > > allocations > > > > > > > > > > > > The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, > > > > > > while it re-allocates and releases vmalloc pages. This is not only > > > > > > a > > > > > > lot of waste resources but also causes the mmap malfunction. > > > > > > > > > > > > Change / drop the vmalloc-related code and use the standard buffer > > > > > > allocation / release code instead. > > > > > > > > I think getting rid of the vmalloc code here is a mistake - I seem to > > > > remember using the standard buffer allocation causes failures, due to > > > > memory fragmentation. Since the hardware is limited to DMA from at > > > > most one page, there is no reason for this driver to require contiguous > > > > pages, hence why it's using - and should use - vmalloc pages. vmalloc > > > > is way kinder to the MM subsystem than trying to request large order > > > > contiguous pages. > > > > > > > > So, NAK on this patch. > > > > > > OK, then we should do other way round, rather drop the buffer > > > preallocation instead. Currently vmalloc buffer is always allocated > > > at each open and overrides the preallocated buffer, so the whole 64k > > > and more are wasted for no use. > > > > > > (BTW, the current code has this snippet: > > > > > > /* Limit the buffer size to the size of the preallocated buffer */ > > > ret = snd_pcm_hw_constraint_minmax(runtime, > > > SNDRV_PCM_HW_PARAM_BUFFER_SIZE, > > > 0, substream->dma_buffer.bytes); > > > > > > ... and this would have to limit the buffer size only to the > > > preallocated size -- which essentially makes the argument above > > > invalid. However, this check looks actually bogus, the constraint > > > parameter should be SNDRV_PCM_HW_PARAM_BUFFER_BYTES, not _SIZE. It > > > might be the reason it worked somehow...) > > > > > > So below is the revised patch. Could you guys check it again? > > > > > > There I copied the comment as is, although the 512k mentioned there > > > looks inconsistent with the actual code. Should it be 1M? > > > > ... and reading the patch again, I found that the hw constraint call > > can be dropped as well. The dw_hdmi_hw definition already contains > > the max buffer size. > > > > Below is the re-revised patch. Please check it. > > I was slightly wrong - sorry. It's been a long time since I looked at > this driver, or even used it - but it is the only driver that supports > HDMI audio on iMX6 platforms, so I guess there are lots of users out > there... or maybe not if none of them use mainline kernels. > > The hardware is capable of reading across a page. However, the hardware > is _not_ capable of reading any data that is formatted as ALSA APIs > allow it to be. The driver has to reformat the ALSA supplied sound > buffers to the layout the hardware requires. > > To do this, we have two different buffers: > > - The substream buffer is the buffer which the hardware reads from. > - The runtime buffer is the buffer which ALSA uses. > > The call to
Re: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
On Tue, Nov 5, 2019 at 3:33 AM Fabrizio Castro wrote: > > Hello Rob, > > Thank you for your feedback! > > > From: Rob Herring > > Sent: 04 November 2019 21:23 > > Subject: Re: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose > > lvds-encoder > > > > On Mon, Nov 4, 2019 at 10:58 AM Fabrizio Castro > > wrote: > > > > > > In an effort to repurpose lvds-encoder.c to also serve the > > > function of LVDS decoders, we ended up defining a new "generic" > > > compatible string, therefore adapt the dt-bindings to fit the > > > new purpose. Also, convert the dt-bindings from .txt to .yaml > > > while at it. > > > > "Also, ... while at it." is a sign for split into 2 patches. > > Will split into 2 patches > > > > > > Signed-off-by: Fabrizio Castro > > > > > > --- > > > v1->v2: > > > * Converted to dt-schema as per Neil's comment > > > --- > > > .../bindings/display/bridge/lvds-codec.yaml| 117 > > > + > > > .../bindings/display/bridge/lvds-transmitter.txt | 66 > > > 2 files changed, 117 insertions(+), 66 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > delete mode 100644 > > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > new file mode 100644 > > > index 000..ff79bc2 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml > > > @@ -0,0 +1,117 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/display/bridge/lvds-codec.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Trasnparent LVDS encoders and LVDS decoders > > > > Typo > > Will fix > > > > > > + > > > +maintainers: > > > + - Laurent Pinchart > > > + > > > +description: | > > > + This binding supports transparent LVDS encoders and LVDS decoders that > > > don't > > > + require any configuration. > > > + > > > + LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. > > > Multiple > > > + incompatible data link layers have been used over time to transmit > > > image data > > > + to LVDS panels. This binding targets devices compatible with the > > > following > > > + specifications only. > > > + > > > + [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, > > > February > > > + 1999 (Version 1.0), Japan Electronic Industry Development Association > > > (JEIDA) > > > + [LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National > > > + Semiconductor > > > + [VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), > > > Video > > > + Electronics Standards Association (VESA) > > > + > > > + Those devices have been marketed under the FPD-Link and FlatLink brand > > > names > > > + among others. > > > + > > > +properties: > > > + compatible: > > > +description: | > > > + Any encoder or decoder compatible with this generic binding, but > > > with > > > + additional properties not listed here, must define its own binding > > > and > > > + list a device specific compatible first followed by the generic > > > compatible > > > +items: > > > + - enum: > > > > You can drop 'items' when there's only 1. > > Will drop > > > > > > +- lvds-encoder # for LVDS encoders > > > +- lvds-decoder # for LVDS decoders > > > + > > > + ports: > > > +type: object > > > +description: | > > > + This device has two video ports. Their connections are modeled > > > using the > > > + OF graph bindings specified in > > > Documentation/devicetree/bindings/graph.txt > > > +properties: > > > + port@0: > > > +type: object > > > +description: | > > > + With LVDS encoders port 0 is for parallel input > > > + With LVDS decoders port 0 is for LVDS input > > > + > > > + port@1: > > > +type: object > > > +description: | > > > + With LVDS encoders port 1 is for LVDS output > > > + With LVDS decoders port 1 is for parallel output > > > > port@* are required, right? > > Yes, port@0 and port@1 are both required, similarly to: > Documentation/devicetree/bindings/display/st,stm32-dsi.yaml > therefore I have put "ports" under "required", in a similar fashion. > What's the right way of specifying this? Same as any other property: required: - port@0 - port@1 At the correct level of course. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112214] Vega20 crashing randomly while using Xorg or Wayland in Fedora 31
https://bugs.freedesktop.org/show_bug.cgi?id=112214 --- Comment #2 from ren...@woralelandia.com --- Created attachment 145894 --> https://bugs.freedesktop.org/attachment.cgi?id=145894=edit journal of entire session before freeze -- 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 112214] Vega20 crashing randomly while using Xorg or Wayland in Fedora 31
https://bugs.freedesktop.org/show_bug.cgi?id=112214 --- Comment #1 from ren...@woralelandia.com --- Created attachment 145893 --> https://bugs.freedesktop.org/attachment.cgi?id=145893=edit hardware info via fpaste --sysinfo -- 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 112214] Vega20 crashing randomly while using Xorg or Wayland in Fedora 31
https://bugs.freedesktop.org/show_bug.cgi?id=112214 Bug ID: 112214 Summary: Vega20 crashing randomly while using Xorg or Wayland in Fedora 31 Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ren...@woralelandia.com Created attachment 145892 --> https://bugs.freedesktop.org/attachment.cgi?id=145892=edit dmidecode It seems my Radeon VII is crashing from time to time. Sometimes several times a day, sometimes every few days. I will attach journal and hardware info. -- 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: Incorrect buffer handling in dw-hdmi bridge audio
On Tue, Nov 05, 2019 at 05:44:26PM +0100, Takashi Iwai wrote: > On Tue, 05 Nov 2019 17:33:44 +0100, > Takashi Iwai wrote: > > > > On Tue, 05 Nov 2019 17:02:15 +0100, > > Russell King - ARM Linux admin wrote: > > > > > > On Tue, Nov 05, 2019 at 09:07:43AM +0100, Neil Armstrong wrote: > > > > Hi, > > > > > > > > On 05/11/2019 08:55, Takashi Iwai wrote: > > > > > Hi, > > > > > > > > > > while recently working on the ALSA memory allocator API cleanup, I > > > > > noticed that dw-hdmi bridge driver seems doing weird about the buffer > > > > > management. It pre-allocates the usual device buffers fully at the > > > > > probe time, while each stream allocates the buffer via the vmalloc > > > > > helpers and replaces with it at each open. > > > > > > > > > > I guess it's no expected behavior? It's basically a full waste of > > > > > resources, and the vmalloc buffer isn't guaranteed to work well for > > > > > mmap on every architecture. > > > > > > > > > > Below is the patch to address it. Can anyone check whether this still > > > > > works? > > > > > > > > I don't have the setup to check, but this has been pushed by Russell I > > > > Added in CC. > > > > > > > > I also added the imx maintainer since it's (AFAIK) only used on iMX > > > > SoCs. > > > > > > > > Neil > > > > > > > > > > > > > > Since I have a cleanup series and this is involved, I'd like to take > > > > > the fix through my tree once after it's confirmed (and get ACK if > > > > > possible). > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > Takashi > > > > > > > > > > -- 8< -- > > > > > From: Takashi Iwai > > > > > Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer > > > > > allocations > > > > > > > > > > The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, > > > > > while it re-allocates and releases vmalloc pages. This is not only a > > > > > lot of waste resources but also causes the mmap malfunction. > > > > > > > > > > Change / drop the vmalloc-related code and use the standard buffer > > > > > allocation / release code instead. > > > > > > I think getting rid of the vmalloc code here is a mistake - I seem to > > > remember using the standard buffer allocation causes failures, due to > > > memory fragmentation. Since the hardware is limited to DMA from at > > > most one page, there is no reason for this driver to require contiguous > > > pages, hence why it's using - and should use - vmalloc pages. vmalloc > > > is way kinder to the MM subsystem than trying to request large order > > > contiguous pages. > > > > > > So, NAK on this patch. > > > > OK, then we should do other way round, rather drop the buffer > > preallocation instead. Currently vmalloc buffer is always allocated > > at each open and overrides the preallocated buffer, so the whole 64k > > and more are wasted for no use. > > > > (BTW, the current code has this snippet: > > > > /* Limit the buffer size to the size of the preallocated buffer */ > > ret = snd_pcm_hw_constraint_minmax(runtime, > >SNDRV_PCM_HW_PARAM_BUFFER_SIZE, > >0, substream->dma_buffer.bytes); > > > > ... and this would have to limit the buffer size only to the > > preallocated size -- which essentially makes the argument above > > invalid. However, this check looks actually bogus, the constraint > > parameter should be SNDRV_PCM_HW_PARAM_BUFFER_BYTES, not _SIZE. It > > might be the reason it worked somehow...) > > > > So below is the revised patch. Could you guys check it again? > > > > There I copied the comment as is, although the 512k mentioned there > > looks inconsistent with the actual code. Should it be 1M? > > ... and reading the patch again, I found that the hw constraint call > can be dropped as well. The dw_hdmi_hw definition already contains > the max buffer size. > > Below is the re-revised patch. Please check it. I was slightly wrong - sorry. It's been a long time since I looked at this driver, or even used it - but it is the only driver that supports HDMI audio on iMX6 platforms, so I guess there are lots of users out there... or maybe not if none of them use mainline kernels. The hardware is capable of reading across a page. However, the hardware is _not_ capable of reading any data that is formatted as ALSA APIs allow it to be. The driver has to reformat the ALSA supplied sound buffers to the layout the hardware requires. To do this, we have two different buffers: - The substream buffer is the buffer which the hardware reads from. - The runtime buffer is the buffer which ALSA uses. The call to snd_pcm_lib_preallocate_pages_for_all() allocates the hardware buffer, which is a single contiguous buffer of fixed size. The user buffer is allocated with snd_pcm_lib_alloc_vmalloc_buffer(). Hence, the driver makes use of both. You can't get rid of either of them. -- RMK's Patch system:
Re: [PATCH V8 4/6] mdev: introduce virtio device and its device ops
On Tue, 5 Nov 2019 17:32:38 +0800 Jason Wang wrote: > This patch implements basic support for mdev driver that supports > virtio transport for kernel virtio driver. > > Signed-off-by: Jason Wang > --- > drivers/vfio/mdev/mdev_core.c| 21 + > drivers/vfio/mdev/mdev_private.h | 2 + > include/linux/mdev.h | 6 ++ > include/linux/mdev_virtio_ops.h | 149 +++ > 4 files changed, 178 insertions(+) > create mode 100644 include/linux/mdev_virtio_ops.h Reviewed-by: Cornelia Huck ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 3/6] mdev: introduce device specific ops
On Tue, 5 Nov 2019 17:32:37 +0800 Jason Wang wrote: > Currently, except for the create and remove, the rest of > mdev_parent_ops is designed for vfio-mdev driver only and may not help > for kernel mdev driver. With the help of class id, this patch > introduces device specific callbacks inside mdev_device > structure. This allows different set of callback to be used by > vfio-mdev and virtio-mdev. > > Reviewed-by: Parav Pandit > Signed-off-by: Jason Wang > --- > .../driver-api/vfio-mediated-device.rst | 35 + > MAINTAINERS | 1 + > drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --- > drivers/s390/cio/vfio_ccw_ops.c | 18 --- > drivers/s390/crypto/vfio_ap_ops.c | 14 +++-- > drivers/vfio/mdev/mdev_core.c | 24 - > drivers/vfio/mdev/mdev_private.h | 5 ++ > drivers/vfio/mdev/vfio_mdev.c | 37 ++--- > include/linux/mdev.h | 43 --- > include/linux/mdev_vfio_ops.h | 52 +++ > samples/vfio-mdev/mbochs.c| 20 --- > samples/vfio-mdev/mdpy.c | 20 --- > samples/vfio-mdev/mtty.c | 18 --- > 13 files changed, 206 insertions(+), 99 deletions(-) > create mode 100644 include/linux/mdev_vfio_ops.h > (...) > @@ -172,10 +163,34 @@ that a driver should use to unregister itself with the > mdev core driver:: > > extern void mdev_unregister_device(struct device *dev); > > -It is also required to specify the class_id in create() callback through:: > +As multiple types of mediated devices may be supported, class id needs > +to be specified in the create callback(). This could be done The brackets should probably go behind 'create'? > +explicitly for the device that does not use on mdev bus for its "for devices that do not use the mdev bus" ? But why wouldn't they? I feel like I've missed some discussion here :/ > +operation through: > > int mdev_set_class(struct mdev_device *mdev, u16 id); > > +For the device that uses on the mdev bus for its operation, the class "For devices that use the mdev bus..." But same comment as above. > +should provide helper function to set class id and device specific > +ops. E.g for vfio-mdev devices, the function to be called is:: > + > + int mdev_set_vfio_ops(struct mdev_device *mdev, > + const struct mdev_vfio_device_ops *vfio_ops); > + > +The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to > +match a device with an mdev driver via its id table. The device > +specific callbacks (specified in *vfio_ops) are obtainable via > +mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev > +device (class id MDEV_CLASS_ID_VFIO) uses the following > +device-specific ops: > + > +* open: open callback of vfio mediated device > +* close: close callback of vfio mediated device > +* ioctl: ioctl callback of vfio mediated device > +* read : read emulation callback > +* write: write emulation callback > +* mmap: mmap emulation callback > + > Mediated Device Management Interface Through sysfs > == Otherwise, looks good. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Incorrect buffer handling in dw-hdmi bridge audio
On Tue, 05 Nov 2019 17:33:44 +0100, Takashi Iwai wrote: > > On Tue, 05 Nov 2019 17:02:15 +0100, > Russell King - ARM Linux admin wrote: > > > > On Tue, Nov 05, 2019 at 09:07:43AM +0100, Neil Armstrong wrote: > > > Hi, > > > > > > On 05/11/2019 08:55, Takashi Iwai wrote: > > > > Hi, > > > > > > > > while recently working on the ALSA memory allocator API cleanup, I > > > > noticed that dw-hdmi bridge driver seems doing weird about the buffer > > > > management. It pre-allocates the usual device buffers fully at the > > > > probe time, while each stream allocates the buffer via the vmalloc > > > > helpers and replaces with it at each open. > > > > > > > > I guess it's no expected behavior? It's basically a full waste of > > > > resources, and the vmalloc buffer isn't guaranteed to work well for > > > > mmap on every architecture. > > > > > > > > Below is the patch to address it. Can anyone check whether this still > > > > works? > > > > > > I don't have the setup to check, but this has been pushed by Russell I > > > Added in CC. > > > > > > I also added the imx maintainer since it's (AFAIK) only used on iMX SoCs. > > > > > > Neil > > > > > > > > > > > Since I have a cleanup series and this is involved, I'd like to take > > > > the fix through my tree once after it's confirmed (and get ACK if > > > > possible). > > > > > > > > > > > > Thanks! > > > > > > > > Takashi > > > > > > > > -- 8< -- > > > > From: Takashi Iwai > > > > Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer > > > > allocations > > > > > > > > The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, > > > > while it re-allocates and releases vmalloc pages. This is not only a > > > > lot of waste resources but also causes the mmap malfunction. > > > > > > > > Change / drop the vmalloc-related code and use the standard buffer > > > > allocation / release code instead. > > > > I think getting rid of the vmalloc code here is a mistake - I seem to > > remember using the standard buffer allocation causes failures, due to > > memory fragmentation. Since the hardware is limited to DMA from at > > most one page, there is no reason for this driver to require contiguous > > pages, hence why it's using - and should use - vmalloc pages. vmalloc > > is way kinder to the MM subsystem than trying to request large order > > contiguous pages. > > > > So, NAK on this patch. > > OK, then we should do other way round, rather drop the buffer > preallocation instead. Currently vmalloc buffer is always allocated > at each open and overrides the preallocated buffer, so the whole 64k > and more are wasted for no use. > > (BTW, the current code has this snippet: > > /* Limit the buffer size to the size of the preallocated buffer */ > ret = snd_pcm_hw_constraint_minmax(runtime, > SNDRV_PCM_HW_PARAM_BUFFER_SIZE, > 0, substream->dma_buffer.bytes); > > ... and this would have to limit the buffer size only to the > preallocated size -- which essentially makes the argument above > invalid. However, this check looks actually bogus, the constraint > parameter should be SNDRV_PCM_HW_PARAM_BUFFER_BYTES, not _SIZE. It > might be the reason it worked somehow...) > > So below is the revised patch. Could you guys check it again? > > There I copied the comment as is, although the 512k mentioned there > looks inconsistent with the actual code. Should it be 1M? ... and reading the patch again, I found that the hw constraint call can be dropped as well. The dw_hdmi_hw definition already contains the max buffer size. Below is the re-revised patch. Please check it. thanks, Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] drm/bridge: dw-hdmi: Drop superfluous buffer preallocation The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, while it always re-allocates and releases vmalloc pages, hence the preallocated pages are never used. Also, the current code contains the hw constraint to limit the buffer size to the preallocated size. It doesn't work as expected, however, because it's applying to an incorrect parameter (SNDRV_PCM_HW_PARAM_BUFFER_SIZE instead of _BUFFER_BYTES). This patch tries to address these issues: drop the unnecessary buffer preallocation and also drop the unnecessary hw constriant. Without the buffer preallocation, the hw constraint becomes superfluous, as dw_hdmi_hw definition already contains the buffer byte size constraints. Signed-off-by: Takashi Iwai --- drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c index 2b7539701b42..2778d6bcc14e 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c @@ -337,13 +337,6 @@ static int
dw-dsi dphy timing calculations
Hi Philippe, when you did the dd the dw-dsi generalization, dw_mipi_dsi_dphy_timing_config() did end up with static values and a comment stating "data & clock lane timers should be computed according to panel blankings and to the automatic clock lane control mode...". Especially with the PHY_HS2LP_TIME(0x60) I ran into problems. On the Google-Gru-Scarlet (ChromeOS tablet with a highres display) everything works nicely (panel clock 229MHz) but on the device I'm on right now (panel clock 64MHz) I end up with broken output (pixel garbage). When I set it to the value found in the Rockchip vendor kernel PHY_HS2LP_TIME(0x14) that display works as expected. The Rockchip SoC manual is pretty sparse on what this value should actually be, so I'm hoping that you may have some insights ;-) . So far I have found https://github.com/surdupetru/huawei-p6/blob/master/kernel/huawei/hwp6_u06/drivers/video/k3/mipi_dsi.c#L97 and https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c#L276 but simply copying strange calculatons seems wrong, similarly to just swapping the hardcoded value from 0x40 to my needed 0x14 ;-) . So if you have some insights I would be most grateful :-D . Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm: Add support for DP 1.4 Compliance edid corruption test 4.2.2.6
DP 1.4 edid corruption test requires source DUT to write calculated
CRC, not the corrupted CRC from reference sink.
Return the calculated CRC back, and initiate the required sequence.
-v2: Have separate routine for returning real CRC
-v3: Rewrite checksum computation routine to avoid duplicated code.
Rename to avoid confusion
-v4: Fix a minor typo.
Signed-off-by: Jerry (Fangzhi) Zuo
---
drivers/gpu/drm/drm_dp_helper.c | 36
drivers/gpu/drm/drm_edid.c | 18 +++---
include/drm/drm_connector.h | 7 +++
include/drm/drm_dp_helper.h | 3 +++
4 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index ffc68d305afe..22a0e966ea9f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -336,6 +336,42 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
}
EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
+/**
+ * drm_dp_send_real_edid_checksum() - send back real edid checksum value
+ * @aux: DisplayPort AUX channel
+ * @real_edid_checksum: real edid checksum for the last block
+ *
+ * Returns true on success
+ */
+bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
+u8 real_edid_checksum)
+{
+u8 link_edid_read = 0, auto_test_req = 0;
+u8 test_resp = 0;
+
+drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req, 1);
+auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
+
+drm_dp_dpcd_read(aux, DP_TEST_REQUEST, _edid_read, 1);
+link_edid_read &= DP_TEST_LINK_EDID_READ;
+
+if (!auto_test_req || !link_edid_read) {
+DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
+return false;
+}
+
+drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR, _test_req,
1);
+
+/* send back checksum for the last edid extension block data */
+drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM, _edid_checksum, 1);
+
+test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
+drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, _resp, 1);
+
+return true;
+}
+EXPORT_SYMBOL(drm_dp_send_real_edid_checksum);
+
/**
* drm_dp_link_probe() - probe a DisplayPort link for capabilities
* @aux: DisplayPort AUX channel
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82a4ceed3fcf..ff64e5f1feb6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1348,10 +1348,19 @@ static int drm_edid_block_checksum(const u8 *raw_edid)
{
int i;
u8 csum = 0;
- for (i = 0; i < EDID_LENGTH; i++)
+
+ for (i = 0; i < EDID_LENGTH - 1; i++)
csum += raw_edid[i];
- return csum;
+ return (0x100 - csum);
+}
+
+static bool drm_edid_block_checksum_diff(const u8 *raw_edid, u8 real_checksum)
+{
+ if (raw_edid[EDID_LENGTH - 1] != real_checksum)
+ return true;
+ else
+ return false;
}
static bool drm_edid_is_zero(const u8 *in_edid, int length)
@@ -1409,7 +1418,7 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid,
}
csum = drm_edid_block_checksum(raw_edid);
- if (csum) {
+ if (drm_edid_block_checksum_diff(raw_edid, csum)) {
if (edid_corrupt)
*edid_corrupt = true;
@@ -1572,6 +1581,9 @@ static void connector_bad_edid(struct drm_connector
*connector,
prefix, DUMP_PREFIX_NONE, 16, 1,
block, EDID_LENGTH, false);
}
+
+ /* Calculate real checksum for the last edid extension block data */
+ connector->real_edid_checksum = drm_edid_block_checksum(edid +
edid[0x7e] * EDID_LENGTH);
}
/* Get override or firmware EDID */
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 681cb590f952..eb0d8c7b35fd 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1345,6 +1345,13 @@ struct drm_connector {
* rev1.1 4.2.2.6
*/
bool edid_corrupt;
+ /**
+ * @real_edid_checksum: real edid checksum value for corrupted edid
block.
+ * Required in Displayport 1.4 compliance testing
+ * rev1.1 4.2.2.6
+ */
+uint8_t real_edid_checksum;
+
/** @debugfs_entry: debugfs directory for this connector */
struct dentry *debugfs_entry;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 5a795075d5da..84709d7810f8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1383,6 +1383,9 @@ static inline ssize_t drm_dp_dpcd_writeb(struct
drm_dp_aux *aux,
int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
u8 status[DP_LINK_STATUS_SIZE]);
+bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
+
[pull] drm/msm: msm-next for 5.5
(lets try this again with a $subject) Hi Dave, This time around: + OCMEM support to enable the couple generations that had shared OCMEM rather than GMEM exclusively for the GPU (late a3xx and I think basically all of a4xx). Bjorn and Brian decided to land this through the drm tree to avoid having to coordinate merge requests. + a510 support, and various associated display support + the usual misc cleanups and fixes The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce: Linux 5.4-rc2 (2019-10-06 14:27:30 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-11-05 for you to fetch changes up to e20c9284c8f212081afc28471daaac9b0d54252f: drm/msm/adreno: Add support for Adreno 510 GPU (2019-11-04 13:18:31 -0800) AngeloGioacchino Del Regno (6): drm/msm/mdp5: Add optional TBU and TBU_RT clocks dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks drm/msm/mdp5: Add configuration for msm8x76 drm/msm/dsi: Add configuration for 28nm PLL on family B drm/msm/dsi: Add configuration for 8x76 drm/msm/adreno: Add support for Adreno 510 GPU Arnd Bergmann (1): drm/msm: include linux/sched/task.h Ben Dooks (2): drm/msm: make a5xx_show and a5xx_gpu_state_put static drm/msm/mdp5: make config variables static Brian Masney (6): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property soc: qcom: add OCMEM driver drm/msm/gpu: add ocmem init/cleanup functions soc: qcom: ocmem: add missing includes drm/msm/hdmi: silence -EPROBE_DEFER warning Drew Davenport (7): drm/msm/dpu: Remove unused variables drm/msm/dpu: Remove unused macro drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm: Remove unused function arguments Krzysztof Wilczynski (1): drm/msm/dsi: Move static keyword to the front of declarations Rob Clark (4): firmware: qcom: scm: add OCMEM lock/unlock interface firmware: qcom: scm: add support to restore secure config to qcm_scm-32 drm/msm: fix rd dumping for split-IB1 drm/msm: always dump buffer base/size Sean Paul (1): drm/msm: Sanitize the modeset_is_locked checks in dpu Stephan Gerhold (1): drm/msm/dsi: Implement qcom, dsi-phy-regulator-ldo-mode for 28nm PHY zhengbin (11): drm/msm/dpu: Remove set but not used variable 'priv' in dpu_kms.c drm/msm/dpu: Remove set but not used variable 'priv' in dpu_encoder_phys_vid.c drm/msm/dpu: Remove set but not used variable 'priv' in dpu_core_irq.c drm/msm/dpu: Remove set but not used variables 'dpu_cstate', 'priv' drm/msm/dpu: Remove set but not used variables 'cmd_enc', 'priv' drm/msm/dpu: Remove set but not used variables 'mode', 'dpu_kms', 'priv' drm/msm/mdp5: Remove set but not used variable 'fmt' drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup drm/msm/dsi: Remove set but not used variable 'lpx' drm/msm/dsi: Remove set but not used variable 'lp' drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in modeset_init .../devicetree/bindings/display/msm/gmu.txt| 51 +++ .../devicetree/bindings/display/msm/mdp5.txt | 2 + .../devicetree/bindings/sram/qcom,ocmem.yaml | 96 + drivers/firmware/qcom_scm-32.c | 52 ++- drivers/firmware/qcom_scm-64.c | 12 + drivers/firmware/qcom_scm.c| 53 +++ drivers/firmware/qcom_scm.h| 9 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 28 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 25 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 79 +++- drivers/gpu/drm/msm/adreno/a5xx_power.c| 7 + drivers/gpu/drm/msm/adreno/adreno_device.c | 15 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 40 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h| 15 + drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 43 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 21 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 39 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 15 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 7 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 60 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 4 - drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c
[no subject]
Hi Dave, This time around: + OCMEM support to enable the couple generations that had shared OCMEM rather than GMEM exclusively for the GPU (late a3xx and I think basically all of a4xx). Bjorn and Brian decided to land this through the drm tree to avoid having to coordinate merge requests. + a510 support, and various associated display support + the usual misc cleanups and fixes The following changes since commit da0c9ea146cbe92b832f1b0f694840ea8eb33cce: Linux 5.4-rc2 (2019-10-06 14:27:30 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2019-11-05 for you to fetch changes up to e20c9284c8f212081afc28471daaac9b0d54252f: drm/msm/adreno: Add support for Adreno 510 GPU (2019-11-04 13:18:31 -0800) AngeloGioacchino Del Regno (6): drm/msm/mdp5: Add optional TBU and TBU_RT clocks dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks drm/msm/mdp5: Add configuration for msm8x76 drm/msm/dsi: Add configuration for 28nm PLL on family B drm/msm/dsi: Add configuration for 8x76 drm/msm/adreno: Add support for Adreno 510 GPU Arnd Bergmann (1): drm/msm: include linux/sched/task.h Ben Dooks (2): drm/msm: make a5xx_show and a5xx_gpu_state_put static drm/msm/mdp5: make config variables static Brian Masney (6): dt-bindings: soc: qcom: add On Chip MEMory (OCMEM) bindings dt-bindings: display: msm: gmu: add optional ocmem property soc: qcom: add OCMEM driver drm/msm/gpu: add ocmem init/cleanup functions soc: qcom: ocmem: add missing includes drm/msm/hdmi: silence -EPROBE_DEFER warning Drew Davenport (7): drm/msm/dpu: Remove unused variables drm/msm/dpu: Remove unused macro drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm/dpu: Remove unnecessary NULL checks drm/msm: Remove unused function arguments Krzysztof Wilczynski (1): drm/msm/dsi: Move static keyword to the front of declarations Rob Clark (4): firmware: qcom: scm: add OCMEM lock/unlock interface firmware: qcom: scm: add support to restore secure config to qcm_scm-32 drm/msm: fix rd dumping for split-IB1 drm/msm: always dump buffer base/size Sean Paul (1): drm/msm: Sanitize the modeset_is_locked checks in dpu Stephan Gerhold (1): drm/msm/dsi: Implement qcom, dsi-phy-regulator-ldo-mode for 28nm PHY zhengbin (11): drm/msm/dpu: Remove set but not used variable 'priv' in dpu_kms.c drm/msm/dpu: Remove set but not used variable 'priv' in dpu_encoder_phys_vid.c drm/msm/dpu: Remove set but not used variable 'priv' in dpu_core_irq.c drm/msm/dpu: Remove set but not used variables 'dpu_cstate', 'priv' drm/msm/dpu: Remove set but not used variables 'cmd_enc', 'priv' drm/msm/dpu: Remove set but not used variables 'mode', 'dpu_kms', 'priv' drm/msm/mdp5: Remove set but not used variable 'fmt' drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in blend_setup drm/msm/dsi: Remove set but not used variable 'lpx' drm/msm/dsi: Remove set but not used variable 'lp' drm/msm/mdp5: Remove set but not used variable 'hw_cfg' in modeset_init .../devicetree/bindings/display/msm/gmu.txt| 51 +++ .../devicetree/bindings/display/msm/mdp5.txt | 2 + .../devicetree/bindings/sram/qcom,ocmem.yaml | 96 + drivers/firmware/qcom_scm-32.c | 52 ++- drivers/firmware/qcom_scm-64.c | 12 + drivers/firmware/qcom_scm.c| 53 +++ drivers/firmware/qcom_scm.h| 9 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 28 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 25 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 3 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 79 +++- drivers/gpu/drm/msm/adreno/a5xx_power.c| 7 + drivers/gpu/drm/msm/adreno/adreno_device.c | 15 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 40 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.h| 15 + drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 43 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 21 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 20 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 39 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 15 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 7 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 60 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 4 - drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 6 +-
Re: Incorrect buffer handling in dw-hdmi bridge audio
On Tue, 05 Nov 2019 17:02:15 +0100, Russell King - ARM Linux admin wrote: > > On Tue, Nov 05, 2019 at 09:07:43AM +0100, Neil Armstrong wrote: > > Hi, > > > > On 05/11/2019 08:55, Takashi Iwai wrote: > > > Hi, > > > > > > while recently working on the ALSA memory allocator API cleanup, I > > > noticed that dw-hdmi bridge driver seems doing weird about the buffer > > > management. It pre-allocates the usual device buffers fully at the > > > probe time, while each stream allocates the buffer via the vmalloc > > > helpers and replaces with it at each open. > > > > > > I guess it's no expected behavior? It's basically a full waste of > > > resources, and the vmalloc buffer isn't guaranteed to work well for > > > mmap on every architecture. > > > > > > Below is the patch to address it. Can anyone check whether this still > > > works? > > > > I don't have the setup to check, but this has been pushed by Russell I > > Added in CC. > > > > I also added the imx maintainer since it's (AFAIK) only used on iMX SoCs. > > > > Neil > > > > > > > > Since I have a cleanup series and this is involved, I'd like to take > > > the fix through my tree once after it's confirmed (and get ACK if > > > possible). > > > > > > > > > Thanks! > > > > > > Takashi > > > > > > -- 8< -- > > > From: Takashi Iwai > > > Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer allocations > > > > > > The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, > > > while it re-allocates and releases vmalloc pages. This is not only a > > > lot of waste resources but also causes the mmap malfunction. > > > > > > Change / drop the vmalloc-related code and use the standard buffer > > > allocation / release code instead. > > I think getting rid of the vmalloc code here is a mistake - I seem to > remember using the standard buffer allocation causes failures, due to > memory fragmentation. Since the hardware is limited to DMA from at > most one page, there is no reason for this driver to require contiguous > pages, hence why it's using - and should use - vmalloc pages. vmalloc > is way kinder to the MM subsystem than trying to request large order > contiguous pages. > > So, NAK on this patch. OK, then we should do other way round, rather drop the buffer preallocation instead. Currently vmalloc buffer is always allocated at each open and overrides the preallocated buffer, so the whole 64k and more are wasted for no use. (BTW, the current code has this snippet: /* Limit the buffer size to the size of the preallocated buffer */ ret = snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_SIZE, 0, substream->dma_buffer.bytes); ... and this would have to limit the buffer size only to the preallocated size -- which essentially makes the argument above invalid. However, this check looks actually bogus, the constraint parameter should be SNDRV_PCM_HW_PARAM_BUFFER_BYTES, not _SIZE. It might be the reason it worked somehow...) So below is the revised patch. Could you guys check it again? There I copied the comment as is, although the 512k mentioned there looks inconsistent with the actual code. Should it be 1M? Thanks! Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] drm/bridge: dw-hdmi: A couple of fixes wrt buffer allocation The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV, while it always re-allocates and releases vmalloc pages, hence the preallocated pages are never used. Also, the current code contains the hw constraint to limit the buffer size to the preallocated size. It doesn't work as expected, however, because it's applying to an incorrect parameter (SNDRV_PCM_HW_PARAM_BUFFER_SIZE instead of _BUFFER_BYTES). This patch tries to address these issues: drop the unnecessary buffer preallocation and fix the hw constraint to the right parameter. Since the buffer preallocation is dropped, the max buffer size that was passed to the preallocation is passed directly now to the hw constraint call. Signed-off-by: Takashi Iwai --- drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c index 2b7539701b42..3efbbc59994b 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c @@ -337,10 +337,14 @@ static int dw_hdmi_open(struct snd_pcm_substream *substream) if (ret < 0) return ret; - /* Limit the buffer size to the size of the preallocated buffer */ + /* +* Limit the buffer size: +* to support 8-channel 96kHz audio reliably, we need 512k +* to satisfy alsa with our restricted period (ERR004323). +*/ ret = snd_pcm_hw_constraint_minmax(runtime, -
[Bug 111763] ring_gfx hangs/freezes on Navi gpus
https://bugs.freedesktop.org/show_bug.cgi?id=111763 --- Comment #24 from wychuchol --- (In reply to wychuchol from comment #23) > (In reply to wychuchol from comment #19) > > After some time in Witcher 3 GOTY run with Lutris PC restarts on it's own. I > > thought something is overheating (I've noticed graphic card memory in > > PSensor sometimes reaching 90 so I thought maybe that's what's happening) > > but I investigated kern.log and this always happened before that autonomous > > reset: > > > > Nov 2 22:01:53 pop-os kernel: [ 979.244964] pcieport :00:01.1: AER: > > Corrected error received: :01:00.0 > > Nov 2 22:01:53 pop-os kernel: [ 979.244967] nvme :01:00.0: AER: PCIe > > Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID) > > Nov 2 22:01:53 pop-os kernel: [ 979.244968] nvme :01:00.0: AER: > > device [1987:5012] error status/mask=1000/6000 > > Nov 2 22:01:53 pop-os kernel: [ 979.244968] nvme :01:00.0: AER: > > [12] Timeout > > Nov 2 22:01:53 pop-os kernel: [ 979.262629] Emergency Sync complete > > Thing with those AER errors is that they can go on and on and reset happens > few minutes after the last logged error. > This might be overheating, I managed to find how to output sensors readings > into txt log and found that memory went up to 96 C (or rather it stayed > there for about 1m 10s) > Last reading before reset: > amdgpu-pci-2800 > Adapter: PCI adapter > vddgfx: +1.16 V > fan1:1551 RPM (min =0 RPM, max = 3200 RPM) > edge: +74.0°C (crit = +118.0°C, hyst = -273.1°C) >(emerg = +99.0°C) > junction: +88.0°C (crit = +99.0°C, hyst = -273.1°C) >(emerg = +99.0°C) > mem: +96.0°C (crit = +99.0°C, hyst = -273.1°C) >(emerg = +99.0°C) > power1: 162.00 W (cap = 195.00 W) > > k10temp-pci-00c3 > Adapter: PCI adapter > Tdie: +70.5°C (high = +70.0°C) > Tctl: +70.5°C > > Now the weird thing is - if this is in fact overheating why fan didn't go > beyond 1600 rpm even once Highest was like 1581 rpm and I don't have > silent bios switched on (sapphire pulse rx 5700 xt, lever facing away from > video ports). Okay I don't think it's overheating anymore. I found a moment in Anomaly 1.5.0 I can't get past without system resetting, just before a psi storm in Army Warehouses (I can provide a savefile). Last sensors reading before crash (5 second increments): amdgpu-pci-2800 Adapter: PCI adapter vddgfx: +1.01 V fan1:1560 RPM (min =0 RPM, max = 3200 RPM) edge: +69.0°C (crit = +118.0°C, hyst = -273.1°C) (emerg = +99.0°C) junction: +84.0°C (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) mem: +80.0°C (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) power1: 227.00 W (cap = 195.00 W) k10temp-pci-00c3 Adapter: PCI adapter Tdie: +71.8°C (high = +70.0°C) Tctl: +71.8°C -- 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: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Tue, Nov 5, 2019 at 2:08 AM Brian Masney wrote:
>
> On Mon, Nov 04, 2019 at 04:19:07PM -0800, Rob Clark wrote:
> > On Mon, Nov 4, 2019 at 4:01 PM Brian Masney wrote:
> > >
> > > Hey Rob,
> > >
> > > Since commit 2d99ced787e3 ("drm/msm: async commit support"), the frame
> > > buffer console on my Nexus 5 began throwing these errors:
> > >
> > > msm fd90.mdss: pp done time out, lm=0
> > >
> > > The display still works.
> > >
> > > I see that mdp5_flush_commit() was introduced in commit 9f6b65642bd2
> > > ("drm/msm: add kms->flush_commit()") with a TODO comment and the commit
> > > description mentions flushing registers. I assume that this is the
> > > proper fix. If so, can you point me to where these registers are
> > > defined and I can work on the mdp5 implementation.
> >
> > See mdp5_ctl_commit(), which writes the CTL_FLUSH registers.. the idea
> > would be to defer writing CTL_FLUSH[ctl_id] = flush_mask until
> > kms->flush() (which happens from a timer shortly before vblank).
> >
> > But I think the async flush case should not come up with fbcon? It
> > was really added to cope with hwcursor updates (and userspace that
> > assumes it can do an unlimited # of cursor updates per frame).. the
> > intention was that nothing should change in the sequence for mdp5 (but
> > I guess that was not the case).
>
> The 'pp done time out' errors go away if I revert the following three
> commits:
>
> cd6d923167b1 ("drm/msm/dpu: async commit support")
> d934a712c5e6 ("drm/msm: add atomic traces")
> 2d99ced787e3 ("drm/msm: async commit support")
>
> I reverted the first one to fix a compiler error, and the second one so
> that the last patch can be reverted without any merge conflicts.
>
> I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> buffer dance around the screen like its out of sync. I renamed
> crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> declaration. Here's the relevant part of what I tried:
>
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms *kms,
> struct drm_atomic_state *st
>
> static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> {
> - /* TODO */
> + struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> + struct drm_crtc *crtc;
> +
> + for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> + if (!crtc->state->active)
> + continue;
> +
> + mdp5_crtc_flush_all(crtc);
> + }
> }
>
> Any tips would be appreciated.
I think this is along the lines of what we need to enable async commit
for mdp5 (but also removing the flush from the atomic-commit path)..
the principle behind the async commit is to do all the atomic state
commit normally, but defer writing the flush bits. This way, if you
get another async update before the next vblank, you just apply it
immediately instead of waiting for vblank.
But I guess you are on a command mode panel, if I remember? Which is
a case I didn't have a way to test. And I'm not entirely about how
kms_funcs->vsync_time() should be implemented for cmd mode panels.
That all said, I think we should first fix what is broken, before
worrying about extending async commit support to mdp5.. which
shouldn't hit the async==true path, due to not implementing
kms_funcs->vsync_time().
What I think is going on is that, in the cmd mode case,
mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
which waits for a pp-done irq regardless of whether there is a flush
in progress. Since there is no flush pending, the irq never comes.
But the expectation is that kms_funcs->wait_flush() returns
immediately if there is nothing to wait for.
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 0/8] drm: rcar-du: Add Color Management Module (CMM)
Hi Laurent,
On Thu, Oct 17, 2019 at 9:14 PM Laurent Pinchart
wrote:
> On Wed, Oct 16, 2019 at 10:55:40AM +0200, Jacopo Mondi wrote:
> > Minimal increment to the CMM series, this time should really be the last
> > one.
> >
> > Just missing Rob's ack on [1/8] and Laurent's one on [5/8].
> >
> > Changelog is minimal:
> > CMM
> > - Remove the cmm_config.enable flag. The cmm_config.table field validity is
> > used to enable/disable the LUT operations
> > - Expand comments as suggested by Laurent
> >
> > CRTC
> > - use drm_color_lut_size() to check the LUT table size
> > - Inline calls to rcar_cmm_enable()/disable()
> > - Add TODO entries as suggested by Laurent
> >
> > For the record, the full series changelog is available at:
> > https://paste.debian.net/1107427/
> >
> > v5 from yesterday with informations on testing is available at:
> > https://lkml.org/lkml/2019/10/15/337
> >
> > Geert will you collect for DTS patches for the next release?
> > I assume the DU changes go through Laurent instead ?
>
> I've taken patch 1/8 to 6/8 and 8/8 in my tree. I expected Geert to take
> 7/8.
And so I did. 7/8 is now in arm-soc/for-next.
However, your drm/du/next branch seems to contain 7/8 instead of 8/8?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V8 2/6] modpost: add support for mdev class id
On Tue, 5 Nov 2019 17:32:36 +0800 Jason Wang wrote: > Add support to parse mdev class id table. > > Reviewed-by: Parav Pandit > Signed-off-by: Jason Wang > --- > drivers/vfio/mdev/vfio_mdev.c | 2 ++ > scripts/mod/devicetable-offsets.c | 3 +++ > scripts/mod/file2alias.c | 11 +++ > 3 files changed, 16 insertions(+) Reviewed-by: Cornelia Huck ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/21] drm/bridge: Add a drm_bridge_state object
On 23/10/2019 17:45, Boris Brezillon wrote:
> One of the last remaining objects to not have its atomic state.
>
> This is being motivated by our attempt to support runtime bus-format
> negotiation between elements of the bridge chain.
> This patch just paves the road for such a feature by adding a new
> drm_bridge_state object inheriting from drm_private_obj so we can
> re-use some of the existing state initialization/tracking logic.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
>
> Changes in v2:
> * Use drm_for_each_bridge_in_chain()
> * Rename helpers to be more consistent with the rest of the DRM API
> * Improve/fix the doc
> ---
> drivers/gpu/drm/drm_atomic.c| 39 +++
> drivers/gpu/drm/drm_atomic_helper.c | 20
> drivers/gpu/drm/drm_bridge.c| 168 +++-
> include/drm/drm_atomic.h| 3 +
> include/drm/drm_bridge.h| 118 +++
> 5 files changed, 343 insertions(+), 5 deletions(-)
>
[...]
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -660,6 +660,9 @@ __drm_atomic_get_current_plane_state(struct
> drm_atomic_state *state,
> return plane->state;
> }
>
> +int __must_check
> +drm_atomic_add_encoder_bridges(struct drm_atomic_state *state,
> +struct drm_encoder *encoder);
> int __must_check
> drm_atomic_add_affected_connectors(struct drm_atomic_state *state,
> struct drm_crtc *crtc);
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 238e84ab63a3..a608c47d1de5 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -25,6 +25,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,6 +34,23 @@ struct drm_bridge;
> struct drm_bridge_timings;
> struct drm_panel;
>
> +/**
> + * struct drm_bridge_state - Atomic bridge state object
> + * @base: inherit from _private_state
> + * @bridge: the bridge this state refers to
> + */
> +struct drm_bridge_state {
> + struct drm_private_state base;
> +
> + struct drm_bridge *bridge;
> +};
> +
> +static inline struct drm_bridge_state *
> +drm_priv_to_bridge_state(struct drm_private_state *priv)
> +{
> + return container_of(priv, struct drm_bridge_state, base);
> +}
> +
> /**
> * struct drm_bridge_funcs - drm_bridge control functions
> */
> @@ -338,6 +356,48 @@ struct drm_bridge_funcs {
>*/
> void (*atomic_post_disable)(struct drm_bridge *bridge,
> struct drm_atomic_state *state);
> +
> + /**
> + * @atomic_duplicate_state:
> + *
> + * Duplicate the current bridge state object (which is guaranteed to be
> + * non-NULL).
> + *
> + * The atomic_duplicate_state() is optional, the core falls back on
> + * _atomic_helper_bridge_duplicate_state() when not implemented.
> + *
> + * RETURNS:
> + * A valid drm_bridge_state object or NULL if the allocation fails.
> + */
> + struct drm_bridge_state *(*atomic_duplicate_state)(struct drm_bridge
> *bridge);
> +
> + /**
> + * @atomic_destroy_state:
> + *
> + * Destroy a bridge state object previously allocated by
> + * _bridge_funcs.atomic_duplicate_state().
> + *
> + * The atomic_destroy_state hook is optional, the coref falls back on
> + * _atomic_helper_bridge_destroy_state() when not implemented.
> + */
> + void (*atomic_destroy_state)(struct drm_bridge *bridge,
> + struct drm_bridge_state *state);
> +
> + /**
> + * @atomic_reset:
> + *
> + * Reset the bridge to a predefined state (or retrieve its current
> + * state) and return a _bridge_state object matching this state.
> + * This function is called at attach time.
> + *
> + * The atomic_reset hook is optional, the core falls back on
> + * _atomic_helper_bridge_reset() when not implemented.
> + *
> + * RETURNS:
> + * A valid drm_bridge_state object in case of success, an ERR_PTR()
> + * giving the reaon of the failure otherwise.
> + */
> + struct drm_bridge_state *(*atomic_reset)(struct drm_bridge *bridge);
> };
>
> /**
> @@ -380,6 +440,8 @@ struct drm_bridge_timings {
> * struct drm_bridge - central DRM bridge control structure
> */
> struct drm_bridge {
> + /** @base: inherit from _private_object */
> + struct drm_private_obj base;
> /** @dev: DRM device this bridge belongs to */
> struct drm_device *dev;
> /** @encoder: encoder to which this bridge is connected */
> @@ -404,6 +466,12 @@ struct drm_bridge {
> void *driver_private;
> };
>
> +static inline struct drm_bridge *
> +drm_priv_to_bridge(struct drm_private_obj *priv)
> +{
> + return container_of(priv, struct drm_bridge, base);
> +}
> +
> void drm_bridge_add(struct drm_bridge *bridge);
> void
