[PATCH 3/3] drm/msm/dpu: check blob limitations during create blob ioctl
Limit the blob size and number of blobs that can be allocated
by a client. This prevents fuzzers from abusing this ioctl and
exhausting the system memory.
Signed-off-by: Steve Cohen
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 6c92f0f..5fbb7c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -41,6 +41,8 @@
*/
#define DPU_DEBUGFS_DIR "msm_dpu"
#define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
+#define MAX_BLOB_PROP_SIZE (PAGE_SIZE * 30)
+#define MAX_BLOB_PROP_COUNT250
static int dpu_kms_hw_init(struct msm_kms *kms);
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
@@ -544,6 +546,17 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
return ret;
}
+static int dpu_kms_createblob_check(unsigned int count, size_t length)
+{
+ if (count >= MAX_BLOB_PROP_COUNT)
+ return -EINVAL;
+
+ if (length > MAX_BLOB_PROP_SIZE)
+ return -EINVAL;
+
+ return 0;
+}
+
static long dpu_kms_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -683,6 +696,7 @@ static const struct msm_kms_funcs kms_funcs = {
#ifdef CONFIG_DEBUG_FS
.debugfs_init= dpu_kms_debugfs_init,
#endif
+ .createblob_check = dpu_kms_createblob_check,
};
static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V11 4/6] mdev: introduce virtio device and its device ops
On 11/7/2019 8:41 PM, Jason Wang wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
I'm not expert on virtio part, my ack is from mdev perspective.
Reviewed-by: Kirti Wankhede
Thanks,
Kirti
---
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 &mdev->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
+ *
[PATCH v2 3/8] ARM: DTS: am3517: add sgx gpu child node
and add interrupt.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/am3517.dtsi | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index bf3002009b00..48d5a250fd40 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -97,7 +97,7 @@
* revision register instead of the unreadable OCP revision
* register.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x5014 0x4>;
reg-names = "rev";
@@ -107,10 +107,11 @@
#size-cells = <1>;
ranges = <0 0x5000 0x4000>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: gpu@0 {
+ compatible = "ti,am3517-sgx530-125",
"img,sgx530-125", "img,sgx530";
+ reg = <0x0 0x4000>;
+ interrupts = <21>;
+ };
};
};
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/msm: add support for createblob_check driver hook
Allow msm_kms devices to register a hook to check blob count
and blob size limitations before a new blob is created.
Signed-off-by: Steve Cohen
---
drivers/gpu/drm/msm/msm_drv.c | 25 +
drivers/gpu/drm/msm/msm_kms.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c84f0a8..d0b0419 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -680,6 +680,30 @@ static void msm_disable_vblank(struct drm_device *dev,
unsigned int pipe)
vblank_ctrl_queue_work(priv, pipe, false);
}
+static int msm_createblob_check (struct drm_device *dev, size_t length,
+ struct drm_file *file_priv)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+ unsigned int count = 0;
+ struct drm_property_blob *blob;
+
+ if (!kms)
+ return -EINVAL;
+
+ if (!kms->funcs->createblob_check)
+ return 0;
+
+ mutex_lock(&dev->mode_config.blob_lock);
+ list_for_each_entry(blob, &file_priv->blobs, head_file) {
+ if (count < UINT_MAX)
+ count++;
+ }
+ mutex_unlock(&dev->mode_config.blob_lock);
+
+ return kms->funcs->createblob_check(count, length);
+}
+
/*
* DRM ioctls:
*/
@@ -1011,6 +1035,7 @@ static struct drm_driver msm_driver = {
.gem_prime_vmap = msm_gem_prime_vmap,
.gem_prime_vunmap = msm_gem_prime_vunmap,
.gem_prime_mmap = msm_gem_prime_mmap,
+ .createblob_check = msm_createblob_check,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = msm_debugfs_init,
#endif
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 1cbef6b..8a7e581 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -126,6 +126,7 @@ struct msm_kms_funcs {
/* debugfs: */
int (*debugfs_init)(struct msm_kms *kms, struct drm_minor *minor);
#endif
+ int (*createblob_check)(unsigned int count, size_t length);
};
struct msm_kms;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] dt-bindings: gpu: mali-midgard: Tidy up conversion to YAML
Am 06.11.19 um 16:34 schrieb Rob Herring: > On Wed, Nov 6, 2019 at 9:07 AM Andreas Färber wrote: >> Am Mittwoch, den 06.11.2019, 08:24 -0600 schrieb Rob Herring: >>> This patch is problematic because there's changes in arm-soc juno/dt >>> branch and there's now a patch for exynos5420 (t628). I'd propose I >>> apply this such that we don't get a merge conflict with juno/dt and >>> we >>> finish resorting after rc1 (or when both branches are in Linus' >>> tree). >> >> This series has dependencies for the Realtek-side RFC patches and is >> not yet ready to merge, so you can take this prep PATCH through your >> tree for v5.6 probably, or feel free to rebase/rework as you see fit - >> I'd just appreciate being credited at least via Reported-by. :) > > I was assuming the non-RFC patches are good to go, so I was going to > pick up 1, 2, and 7. Actually 1, 2 and 4 should be good to go; 7 if you fix the subject or if I respin. Also 6 if you can have someone check that no new properties will be needed for 470 (no Linux driver support yet). All but 1 assuming you'll be okay to add SoC-specific restrictions on clocks/resets/domains later, once we've fully figured it out (cf. cover letter for current errors - looking into power domains next). Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> Nice design, I love the seq foundation! So far, I'm not able to spot anything
> actually wrong with the implementation, sorry about that.
Alas :( I feel there must be a bug in here still, but onwards!
One of the main sad points was it didn't make sense to use the
existing seqlock/seqcount primitives as they have both the wrong write
concurrancy model and extra barriers that are not needed when it is
always manipulated under a spinlock
> 1. There is a rather severe naming overlap (not technically a naming conflict,
> but still) with existing mmn work, which already has, for example:
>
> struct mmu_notifier_range
>
> ...and you're adding:
>
> struct mmu_range_notifier
>
> ...so I'll try to help sort that out.
Yes, I've been sad about this too.
> So this should read:
>
> enum mmu_range_notifier_event {
> MMU_NOTIFY_RELEASE,
> };
>
> ...assuming that we stay with "mmu_range_notifier" as a core name for this
> whole thing.
>
> Also, it is best moved down to be next to the new MNR structs, so that all the
> MNR stuff is in one group.
I agree with Jerome, this enum is part of the 'struct
mmu_notifier_range' (ie the description of the invalidation) and it
doesn't really matter that only these new notifiers can be called with
this type, it is still part of the mmu_notifier_range.
The comment already says it only applies to the mmu_range_notifier
scheme..
> > #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
> > @@ -222,6 +228,26 @@ struct mmu_notifier {
> > unsigned int users;
> > };
> >
>
> That should also be moved down, next to the new structs.
Which this?
> > +/**
> > + * struct mmu_range_notifier_ops
> > + * @invalidate: Upon return the caller must stop using any SPTEs within
> > this
> > + * range, this function can sleep. Return false if blocking
> > was
> > + * required but range is non-blocking
> > + */
>
> How about this (I'm not sure I fully understand the return value, though):
>
> /**
> * struct mmu_range_notifier_ops
> * @invalidate: Upon return the caller must stop using any SPTEs within this
> *range.
> *
> *This function is permitted to sleep.
> *
> *@Return: false if blocking was required, but @range is
> *non-blocking.
> *
> */
Is this kdoc format for function pointers?
>
> > +struct mmu_range_notifier_ops {
> > + bool (*invalidate)(struct mmu_range_notifier *mrn,
> > + const struct mmu_notifier_range *range,
> > + unsigned long cur_seq);
> > +};
> > +
> > +struct mmu_range_notifier {
> > + struct interval_tree_node interval_tree;
> > + const struct mmu_range_notifier_ops *ops;
> > + struct hlist_node deferred_item;
> > + unsigned long invalidate_seq;
> > + struct mm_struct *mm;
> > +};
> > +
>
> Again, now we have the new struct mmu_range_notifier, and the old
> struct mmu_notifier_range, and it's not good.
>
> Ideas:
>
> a) Live with it.
>
> b) (Discarded, too many callers): rename old one. Nope.
>
> c) Rename new one. Ideas:
>
> struct mmu_interval_notifier
> struct mmu_range_intersection
> ...other ideas?
This odd duality has already cause some confusion, but names here are
hard. mmu_interval_notifier is the best alternative I've heard.
Changing this name is a lot of work - are we happy
'mmu_interval_notifier' is the right choice?
> > +/**
> > + * mmu_range_set_seq - Save the invalidation sequence
>
> How about:
>
> * mmu_range_set_seq - Set the .invalidate_seq to a new value.
It is not a 'new value', it is a value that is provided to the
invalidate callback
>
> > + * @mrn - The mrn passed to invalidate
> > + * @cur_seq - The cur_seq passed to invalidate
> > + *
> > + * This must be called unconditionally from the invalidate callback of a
> > + * struct mmu_range_notifier_ops under the same lock that is used to call
> > + * mmu_range_read_retry(). It updates the sequence number for later use by
> > + * mmu_range_read_retry().
> > + *
> > + * If the user does not call mmu_range_read_begin() or
> > mmu_range_read_retry()
>
> nit: "caller" is better than "user", when referring to...well, callers.
> "user"
> most often refers to user space, whereas a call stack and function calling is
> clearly what you're referring to here (and in other places, especially "user
> lock").
Done
> > +/**
> > + * mmu_range_check_retry - Test if a collision has occurred
> > + * mrn: The range under lock
> > + * seq: The return of the matching mmu_range_read_begin()
> > + *
> > + * This can be used in the critical section between mmu_range_read_begin()
> > and
> > + * mmu_range_read_retry(). A return of true indicates an invalidation has
> > + * collided with this lock and a future mmu_range_read_retry() will return
> > + * true.
> > + *
> > + * False is not reliable and only suggests a collision has not happened. It
>
> let
[PATCH v3 4/7] drm: Define DRM_MODE_CONNECTOR_PARALLEL
The existing DRM_MODE_CONNECTOR_ definitions don't seem to
describe the connector for RGB/Parallel embedded displays,
hence add DRM_MODE_CONNECTOR_PARALLEL.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* New patch
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2166000..b233029 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -93,6 +93,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] = {
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
{ DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{ DRM_MODE_CONNECTOR_SPI, "SPI" },
+ { DRM_MODE_CONNECTOR_PARALLEL, "Parallel" },
};
void drm_connector_ida_init(void)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 735c8cf..5852f47 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -362,6 +362,7 @@ enum drm_mode_subconnector {
#define DRM_MODE_CONNECTOR_DPI 17
#define DRM_MODE_CONNECTOR_WRITEBACK 18
#define DRM_MODE_CONNECTOR_SPI 19
+#define DRM_MODE_CONNECTOR_PARALLEL20
struct drm_mode_get_connector {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: add driver hook for create blob limitations
Allow drivers with blob limitations to run checks before blobs
are created. This can be used to limit how much memory can be
allocated based on driver requirements.
Signed-off-by: Steve Cohen
---
drivers/gpu/drm/drm_property.c | 7 +++
include/drm/drm_drv.h | 9 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 892ce63..507a8a1 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -793,6 +793,13 @@ int drm_mode_createblob_ioctl(struct drm_device *dev,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
+ if (dev->driver->createblob_check) {
+ ret = dev->driver->createblob_check(
+ dev, out_resp->length, file_priv);
+ if (ret)
+ return ret;
+ }
+
blob = drm_property_create_blob(dev, out_resp->length, NULL);
if (IS_ERR(blob))
return PTR_ERR(blob);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 8976afe..73b39b89 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -776,6 +776,15 @@ struct drm_driver {
int (*dma_quiescent) (struct drm_device *);
int (*context_dtor) (struct drm_device *dev, int context);
int dev_priv_size;
+
+ /**
+* @createblob_check: driver check for creating blob properties
+*
+* Hook for checking blob limitations imposed by drivers
+*/
+ int (*createblob_check) (struct drm_device *dev,
+size_t length,
+struct drm_file *file_priv);
};
extern unsigned int drm_debug;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] ARM: DTS: am33xx: add sgx gpu child node
and add interrupt.
Tested on BeagleBone Black.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/am33xx.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a9d848d50b20..dbfb9d5aa915 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -480,10 +480,11 @@
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: gpu@0 {
+ compatible = "ti,am335x-sgx530-125",
"img,sgx530-125", "img,sgx530";
+ reg = <0x00 0x100>; /* 16 MB */
+ interrupts = <37>;
+ };
};
};
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] ARM: shmobile_defconfig: Enable support for panels from EDT
The iwg20d comes with an LCD panel from Emerging Display Technologies Corporation (EDT), therefore enable what's required to support it. Signed-off-by: Fabrizio Castro --- v2->v3: * No change v1->v2: * No change --- arch/arm/configs/shmobile_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index c6c7035..ab416a5 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_TOUCHSCREEN_EDT_FT5X06=y CONFIG_TOUCHSCREEN_ST1232=y CONFIG_INPUT_MISC=y CONFIG_INPUT_ADXL34X=y @@ -125,7 +126,9 @@ CONFIG_VIDEO_ADV7604=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_DUMB_VGA_DAC=y +CONFIG_DRM_LVDS_CODEC=y CONFIG_DRM_SII902X=y CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_I2C_ADV7511_AUDIO=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Convert the lvds-transmitter binding to DT schema format using
json-schema.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* Extracted conversion to dt-schema as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-transmitter.txt | 66
.../bindings/display/bridge/lvds-transmitter.yaml | 91 ++
2 files changed, 91 insertions(+), 66 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
deleted file mode 100644
index 60091db..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Parallel to LVDS Encoder
-
-
-This binding supports the parallel to LVDS encoders 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.
-
-
-Required properties:
-
-- compatible: Must be "lvds-encoder"
-
- Any encoder compatible with this generic binding, but with additional
- properties not listed here, must list a device specific compatible first
- followed by this generic compatible.
-
-Required nodes:
-
-This device has two video ports. Their connections are modeled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for parallel input
-- Video port 1 for LVDS output
-
-
-Example
-
-lvds-encoder {
- compatible = "lvds-encoder";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- lvds_enc_in: endpoint {
- remote-endpoint = <&display_out_rgb>;
- };
- };
-
- port@1 {
- reg = <1>;
-
- lvds_enc_out: endpoint {
- remote-endpoint = <&lvds_panel_in>;
- };
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
new file mode 100644
index 000..5be163a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Parallel to LVDS Encoder
+
+maintainers:
+ - Laurent Pinchart
+
+description: |
+ This binding supports the parallel to LVDS encoders 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
+enum:
+ - lvds-encoder
+
+ 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: |
+ Port 0 is for parall
Re: [PATCH 2/3] drm/rockchip: add ability to handle external dphys in mipi-dsi
Hi Laurent, Am Mittwoch, 6. November 2019, 14:05:57 CET schrieb Laurent Pinchart: > On Wed, Nov 06, 2019 at 12:26:49PM +0100, Heiko Stuebner wrote: > > While the common case is that the dsi controller uses an internal dphy, > > accessed through the phy registers inside the dsi controller, there is > > also the possibility to use a separate dphy from a different vendor. > > > > One such case is the Rockchip px30 that uses a Innosilicon Mipi dphy, > > so add the support for handling such a constellation, including the pll > > also getting generated inside that external phy. > > > > Signed-off-by: Heiko Stuebner > > --- > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 ++- > > .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 54 ++- > > 2 files changed, 57 insertions(+), 4 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt > > > > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt > > index ce4c1fc9116c..8b25156a9dcf 100644 > > --- > > a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt > > +++ > > b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt > > @@ -8,8 +8,9 @@ Required properties: > > "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". > > - reg: Represent the physical address range of the controller. > > - interrupts: Represent the controller's interrupt to the CPU(s). > > -- clocks, clock-names: Phandles to the controller's pll reference > > - clock(ref) and APB clock(pclk). For RK3399, a phy config clock > > +- clocks, clock-names: Phandles to the controller's and APB clock(pclk) > > + and either a pll reference clock(ref) (internal dphy) or pll clock(pll) > > + (when connected to an external phy). For RK3399, a phy config clock > > Why does external PHY clock need to be specified here ? Shouldn't it be > handled by the PHY instead ? You're completely right and it seems I didn't "see the forest for the trees", as there actually exists the phy_configure_* structs to transfer parameters to an external phy in a correct way. I'll revise my approach (and the phy driver) accordingly. Thanks for the push in the right direction :-) Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv1 2/2] drm/panel: simple: Add support for AUO G156XTN01.0 panel
Add timings for the AUO G156XTN01.0 panel.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 46ca59db6819..49a3f3b3d4be 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -858,6 +858,29 @@ static const struct panel_desc auo_g133han01 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
};
+static const struct drm_display_mode auo_g156xtn01_mode = {
+ .clock = 76000,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 33,
+ .hsync_end = 1366 + 33 + 67,
+ .htotal = 1560,
+ .vdisplay = 768,
+ .vsync_start = 768 + 4,
+ .vsync_end = 768 + 4 + 4,
+ .vtotal = 806,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_g156xtn01 = {
+ .modes = &auo_g156xtn01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 344,
+ .height = 194,
+ },
+};
+
static const struct display_timing auo_g185han01_timings = {
.pixelclock = { 12000, 14400, 17500 },
.hactive = { 1920, 1920, 1920 },
@@ -3143,6 +3166,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "auo,g133han01",
.data = &auo_g133han01,
+ }, {
+ .compatible = "auo,g156xtn01",
+ .data = &auo_g156xtn01,
}, {
.compatible = "auo,g185han01",
.data = &auo_g185han01,
--
2.24.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] ARM: DTS: omap4: add sgx gpu child node
and add interrupt.
Since omap4420/30/60 and omap4470 come with different SGX variants
we need to introduce a new omap4470.dtsi. If an omap4470 board
does not want to use SGX it is no problem to still include
omap4460.dtsi.
Tested on PandaBoard ES.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap4.dtsi | 9 +
arch/arm/boot/dts/omap4470.dts | 15 +++
2 files changed, 20 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4470.dts
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7cc95bc1598b..4d5958fbe1ef 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -347,10 +347,11 @@
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: img@0 {
+ compatible = "ti,omap4-sgx540-120",
"img,sgx540-120", "img,sgx540";
+ reg = <0x0 0x200>; /* 32MB */
+ interrupts = ;
+ };
};
dss: dss@5800 {
diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
new file mode 100644
index ..19b554612401
--- /dev/null
+++ b/arch/arm/boot/dts/omap4470.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for OMAP4470 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#include "omap4460.dtsi"
+
+&sgx {
+ compatible = "img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112";
+};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] allow DRM drivers to limit creation of blobs
Fuzzers used in Android compliance testing repeatedly call the create blob IOCTL which eventually exhausts the system memory. This series adds a hook which allows drivers to impose their own limitations on the size and/or number of blobs created. Steve Cohen (3): drm: add driver hook for create blob limitations drm/msm: add support for createblob_check driver hook drm/msm/dpu: check blob limitations during create blob ioctl drivers/gpu/drm/drm_property.c | 7 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 ++ drivers/gpu/drm/msm/msm_drv.c | 25 + drivers/gpu/drm/msm/msm_kms.h | 1 + include/drm/drm_drv.h | 9 + 5 files changed, 56 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert
On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> > 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.
I amended my copy of the patch with the above, has this rework shown
signs of working?
@@ -436,7 +436,8 @@ 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 && map->vma == vma) {
+ if (use_ptemod) {
+ WARN_ON(map->vma != vma);
mmu_range_notifier_remove(&map->notifier);
map->vma = NULL;
}
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] ARM: DTS: omap3: add sgx gpu child node
and add interrupt
Tested on OpenPandora 600 MHz.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap34xx.dtsi | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 7b09cbee8bb8..9b050d71849b 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -111,7 +111,7 @@
* are also different clocks, but we do not have any dts users
* for it.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x5014 0x4>;
reg-names = "rev";
@@ -121,10 +121,11 @@
#size-cells = <1>;
ranges = <0 0x5000 0x4000>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: gpu@0 {
+ compatible = "ti,omap3-sgx530-121",
"img,sgx530-121", "img,sgx530";
+ reg = <0x0 0x4000>; /* 64kB */
+ interrupts = <21>;
+ };
};
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > > >
> > > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > > mmu_range_notifier.h
> > > > header file, but I know that's extra work. Maybe later as a follow-up
> > > > patch,
> > > > if anyone has the time.
> > >
> > > The range notifier should get the event too, it would be a waste, i think
> > > it is
> > > an oversight here. The release event is fine so NAK to you separate
> > > event. Event
> > > is really an helper for notifier i had a set of patch for nouveau to
> > > leverage
> > > this i need to resucite them. So no need to split thing, i would just
> > > forward
> > > the event ie add event to mmu_range_notifier_ops.invalidate() i failed to
> > > catch
> > > that in v1 sorry.
> >
> > I think what you mean is already done?
> >
> > struct mmu_range_notifier_ops {
> > bool (*invalidate)(struct mmu_range_notifier *mrn,
> >const struct mmu_notifier_range *range,
> >unsigned long cur_seq);
>
> Yes it is sorry, i got confuse with mmu_range_notifier and mmu_notifier_range
> :)
> It is almost a palyndrome structure ;)
Lets change the name then, this is clearly not working. I'll reflow
everything tomorrow
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/rockchip: dsi: add px30 support
Add the compatible and GRF definitions for the PX30 soc.
Signed-off-by: Heiko Stuebner
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 1e6578f911a0..13858f377a0c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -140,6 +140,12 @@
#define DW_MIPI_NEEDS_PHY_CFG_CLK BIT(0)
#define DW_MIPI_NEEDS_GRF_CLK BIT(1)
+#define PX30_GRF_PD_VO_CON10x0438
+#define PX30_DSI_FORCETXSTOPMODE (0xf << 7)
+#define PX30_DSI_FORCERXMODE BIT(6)
+#define PX30_DSI_TURNDISABLE BIT(5)
+#define PX30_DSI_LCDC_SEL BIT(0)
+
#define RK3288_GRF_SOC_CON60x025c
#define RK3288_DSI0_LCDC_SEL BIT(6)
#define RK3288_DSI1_LCDC_SEL BIT(9)
@@ -1049,6 +1055,24 @@ static int dw_mipi_dsi_rockchip_remove(struct
platform_device *pdev)
return 0;
}
+static const struct rockchip_dw_dsi_chip_data px30_chip_data[] = {
+ {
+ .reg = 0xff45,
+ .lcdsel_grf_reg = PX30_GRF_PD_VO_CON1,
+ .lcdsel_big = HIWORD_UPDATE(0, PX30_DSI_LCDC_SEL),
+ .lcdsel_lit = HIWORD_UPDATE(PX30_DSI_LCDC_SEL,
+ PX30_DSI_LCDC_SEL),
+
+ .lanecfg1_grf_reg = PX30_GRF_PD_VO_CON1,
+ .lanecfg1 = HIWORD_UPDATE(0, PX30_DSI_TURNDISABLE |
+PX30_DSI_FORCERXMODE |
+PX30_DSI_FORCETXSTOPMODE),
+
+ .max_data_lanes = 4,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dw_dsi_chip_data rk3288_chip_data[] = {
{
.reg = 0xff96,
@@ -1117,6 +1141,9 @@ static const struct rockchip_dw_dsi_chip_data
rk3399_chip_data[] = {
static const struct of_device_id dw_mipi_dsi_rockchip_dt_ids[] = {
{
+.compatible = "rockchip,px30-mipi-dsi",
+.data = &px30_chip_data,
+ }, {
.compatible = "rockchip,rk3288-mipi-dsi",
.data = &rk3288_chip_data,
}, {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] ARM: DTS: omap36xx: add sgx gpu child node
and add interrupt.
Tested on GTA04 and BeagleBoard XM.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap36xx.dtsi | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 1e552f08f120..851d4abb943b 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -145,7 +145,7 @@
* "ti,sysc-omap4" type register with just sidle and midle bits
* available while omap34xx has "ti,sysc-omap2" type sysconfig.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5000fe00 0x4>,
<0x5000fe10 0x4>;
@@ -162,10 +162,11 @@
#size-cells = <1>;
ranges = <0 0x5000 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: gpu@0 {
+ compatible = "ti,omap3-sgx530-125",
"img,sgx530-125", "img,sgx530";
+ reg = <0x0 0x1>;/* 64kB */
+ interrupts = <21>;
+ };
};
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Jacopo,
Thank you for your feedback!
> From: Jacopo Mondi
> Sent: 07 November 2019 18:19
> Subject: Re: [PATCH v2 1/4] drm/bridge: Repurpose lvds-encoder.c
>
> Hi Fabrizio,
> thanks for the patch.
>
> On Mon, Nov 04, 2019 at 04:58:00PM +, Fabrizio Castro wrote:
> > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > not just LVDS encoders.
> > Instead of creating a new driver for addressing support for
> > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > good.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v1->v2:
> > * No change
> > ---
> > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > drivers/gpu/drm/bridge/Makefile | 2 +-
> > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > ++
> > drivers/gpu/drm/bridge/lvds-encoder.c | 155 ---
> > 4 files changed, 174 insertions(+), 160 deletions(-)
> > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3436297..9e75ca4e 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> >
> > -config DRM_LVDS_ENCODER
> > - tristate "Transparent parallel to LVDS encoder support"
> > +config DRM_LVDS_CODEC
> > + tristate "Transparent LVDS encoders and decoders support"
> > depends on OF
> > select DRM_KMS_HELPER
> > select DRM_PANEL_BRIDGE
> > help
> > - Support for transparent parallel to LVDS encoders that don't require
> > - any configuration.
> > + Support for transparent LVDS encoders and LVDS decoders that don't
> > + require any configuration.
> >
> > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf..8a9178a 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,7 +2,7 @@
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > new file mode 100644
> > index 000..8a1979c
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2016 Laurent Pinchart
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +struct lvds_codec {
> > + struct drm_bridge bridge;
> > + struct drm_bridge *panel_bridge;
> > + struct gpio_desc *powerdown_gpio;
> > + u32 connector_type;
> > +};
> > +
> > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
>
> Weird indentation. Align to open ( to match the rest of the driver's
> style.
Will do, throughout the file.
>
> > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > +bridge);
> > +}
> > +
> > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
>
> Here too
>
> > + if (lvds_codec->powerdown_gpio)
> > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > +}
> > +
> > +static void lvds_codec_disable(struct drm_bridge *bridge)
> > +{
> > + struct lvds_codec *lvds_codec = container_of(bridge,
> > +struct lvds_codec,
> > +bridge);
> > +
> > + if (lvds_codec->powerdown_gpio)
> > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
> > +}
> > +
> > +static struct drm_bridge_funcs funcs = {
> > + .attach = lvds_codec_attach,
> > + .enable = lvds_codec_enable,
> > + .disable = lvds_codec_disable,
> > +};
> > +
> > +stat
[PATCH v2 0/8] ARM/MIPS: DTS: add child nodes describing the PVRSGX present in some OMAP SoC and JZ4780
Changes: * tried convert bindings to YAML format - suggested by Rob Herring * added JZ4780 DTS node (proven to load the driver) * removed timer and img,cores properties until we know we really need them - suggested by Rob Herring PATCH V1 2019-10-18 20:46:35: This patch set defines child nodes for the SGX5xx interface inside the OMAP SoC so that a driver can be found and probed by the compatible strings and can retrieve information about the SGX revision that is included in a specific SoC. It also defines the interrupt number to be used by the SGX driver. There is currently no mainline driver for these GPUs, but a project [1] is ongoing with the goal to get the open-source part as provided by TI/IMG into drivers/staging/pvr. The kernel modules built from this project have successfully demonstrated to work with the DTS definitions from this patch set on AM335x BeagleBone Black and OMAP5 Pyra. They partially works on DM3730 and PandaBoard ES but that is likely a problem in the kernel driver or the (non-free) user-space blobs. There is potential to extend this work to JZ4780 (CI20 board) and BananaPi-M3 (A83) and even some Intel Poulsbo and CedarView devices. [1]: https://github.com/openpvrsgx-devgroup H. Nikolaus Schaller (8): RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs ARM: DTS: am33xx: add sgx gpu child node ARM: DTS: am3517: add sgx gpu child node ARM: DTS: omap3: add sgx gpu child node ARM: DTS: omap36xx: add sgx gpu child node ARM: DTS: omap4: add sgx gpu child node ARM: DTS: omap5: add sgx gpu child node MIPS: DTS: jz4780: add sgx gpu node .../devicetree/bindings/gpu/img,pvrsgx.yaml | 128 ++ arch/arm/boot/dts/am33xx.dtsi | 9 +- arch/arm/boot/dts/am3517.dtsi | 11 +- arch/arm/boot/dts/omap34xx.dtsi | 11 +- arch/arm/boot/dts/omap36xx.dtsi | 11 +- arch/arm/boot/dts/omap4.dtsi | 9 +- arch/arm/boot/dts/omap4470.dts| 15 ++ arch/arm/boot/dts/omap5.dtsi | 9 +- arch/mips/boot/dts/ingenic/jz4780.dtsi| 11 ++ 9 files changed, 187 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml create mode 100644 arch/arm/boot/dts/omap4470.dts -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
lvds-encoder.c implementation is also suitable for LVDS decoders,
not just LVDS encoders.
Instead of creating a new driver for addressing support for
transparent LVDS decoders, repurpose lvds-encoder.c for the greater
good.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* No change
v1->v2:
* No change
---
drivers/gpu/drm/bridge/Kconfig| 8 +-
drivers/gpu/drm/bridge/Makefile | 2 +-
drivers/gpu/drm/bridge/lvds-codec.c | 131
drivers/gpu/drm/bridge/lvds-encoder.c | 155 --
4 files changed, 136 insertions(+), 160 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3436297..9e75ca4e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
Support for non-programmable RGB to VGA DAC bridges, such as ADI
ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
-config DRM_LVDS_ENCODER
- tristate "Transparent parallel to LVDS encoder support"
+config DRM_LVDS_CODEC
+ tristate "Transparent LVDS encoders and decoders support"
depends on OF
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
help
- Support for transparent parallel to LVDS encoders that don't require
- any configuration.
+ Support for transparent LVDS encoders and LVDS decoders that don't
+ require any configuration.
config DRM_MEGACHIPS_STDP_GE_B850V3_FW
tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..8a9178a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,7 +2,7 @@
obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
-obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
+obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
new file mode 100644
index 000..d57a8eb
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019 Renesas Electronics Corporation
+ * Copyright (C) 2016 Laurent Pinchart
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct lvds_codec {
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
+};
+
+static int lvds_codec_attach(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
+bridge);
+}
+
+static void lvds_codec_enable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
+}
+
+static void lvds_codec_disable(struct drm_bridge *bridge)
+{
+ struct lvds_codec *lvds_codec = container_of(bridge,
+struct lvds_codec, bridge);
+
+ if (lvds_codec->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
+}
+
+static struct drm_bridge_funcs funcs = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+};
+
+static int lvds_codec_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *panel_node;
+ struct drm_panel *panel;
+ struct lvds_codec *lvds_codec;
+
+ lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
+ if (!lvds_codec)
+ return -ENOMEM;
+
+ lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_codec->powerdown_gpio))
+ return PTR_ERR(lvds_codec->powerdown_gpio);
+
+ panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (!panel_node) {
+ dev_dbg(dev, "panel DT node not found\n");
+ return -ENXIO;
+ }
+
+ panel = of_drm_find_panel(panel_node);
+ of_node_put(panel_node);
+ if (IS_ERR
[PATCH v2 8/8] MIPS: DTS: jz4780: add sgx gpu node
and add interrupt and clocks.
Tested to build for CI20 board and load a (non-working) driver.
Suggested-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index c54bd7cfec55..21ea5f4a405b 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -46,6 +46,17 @@
#clock-cells = <1>;
};
+ gpu: gpu@1304 {
+ compatible = "ingenic,jz4780-sgx540-120", "img,sgx540-120",
"img,sgx540", "img,sgx5";
+ reg = <0x1304 0x4000>;
+
+ clocks = <&cgu JZ4780_CLK_GPU>;
+ clock-names = "gpu";
+
+ interrupt-parent = <&intc>;
+ interrupts = <63>;
+ };
+
tcu: timer@10002000 {
compatible = "ingenic,jz4780-tcu",
"ingenic,jz4770-tcu",
--
2.23.0
___
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 Thu, Nov 7, 2019 at 9:40 AM Jeffrey Hugo wrote:
>
> On Thu, Nov 7, 2019 at 9:17 AM Rob Clark wrote:
> >
> > On Thu, Nov 7, 2019 at 3:10 AM Brian Masney wrote:
> > >
> > > On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > > > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > > > wrote:
> > > > >
> > > > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> > > > > >
> > > > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > > > > wrote:
> > > > > > > > > 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.
> > > > > > >
> > > > > > > Yes, this is a command-mode panel and there's no hardware frame
> > > > > > > counter
> > > > > > > available. The key to getting the display working on this phone
> > > > > > > was this
> > > > > > > patch:
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > > > > >
> > > > > > > > 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.
> > > > > > >
> > > > > > > I don't think that's happening in this case. I added some
> > > > > > > pr_info()
> > > > > > > statements to request
[PATCH v2 1/8] RFC: dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
The Imagination PVR/SGX GPU is part of several SoC from
multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
and others.
With this binding, we describe how the SGX processor is
interfaced to the SoC (registers, interrupt etc.).
Clock, Reset and power management should be handled
by a parent node or elsewhere.
---
I have used the doc2yaml script to get a first veryion
but I am still stuggling with the yaml thing. My impression
is that while it is human readable, it is not very human
writable... Unfortunately I haven't found a good tutorial
for Dummies (like me) for bindings in YAML.
The big problem is not the YAML syntax but what the schema
should contain and how to correctly formulate ideas in this
new language.
Specific questions for this RFC:
* formatting: is space/tab indentation correct?
* are strings with "" correct or without?
* how do I specify that there is a list of compatible strings required in a
specific order?
* but there are multiple such lists, and only one of them is to be chosen?
* how can be described in the binding that there should be certain values in
the parent node (ranges) to make it work?
I was not able to run
make dt_binding_check dtbs_check
due to some missing dependencies (which I did not want to
invest time to research them) on my build host, so I could
not get automated help from those.
---
.../devicetree/bindings/gpu/img,pvrsgx.yaml | 128 ++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
new file mode 100644
index ..b1b021601c47
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: None
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bindings/gpu/img,pvrsgx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination PVR/SGX GPU
+
+maintainers:
+ - H. Nikolaus Schaller
+description: |+
+ This binding describes the Imagination SGX5 series of 3D accelerators which
+ are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780,
+ Allwinner A83, and Intel Poulsbo and CedarView.
+
+ Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by
+ this binding.
+
+ The SGX node is usually a child node of some DT node belonging to the SoC
+ which handles clocks, reset and general address space mapping of the SGX
+ register area.
+
+properties:
+ compatible:
+oneOf:
+ - item:
+# BeagleBoard ABC, OpenPandora 600MHz
+- const: "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530",
"img,sgx5"
+# BeagleBoard XM, GTA04, OpenPandora 1GHz
+- const: "ti,omap3-sgx530-125", "img,sgx530-125", "img,sgx530",
"img,sgx5"
+# BeagleBone Black
+- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530",
"img,sgx5"
+# Pandaboard (ES)
+- const: "ti,omap4-sgx540-120", "img,sgx540-120", "img,sgx540",
"img,sgx5"
+- const "ti,omap4-sgx544-112", "img,sgx544-112", "img,sgx544",
"img,sgx5"
+# OMAP5 UEVM, Pyra Handheld
+"ti,omap5-sgx544-116", "img,sgx544-116", "img,sgx544", "img,sgx5"
+"ti,dra7-sgx544-116", "img,sgx544-116", "img,sgx544", "img,sgx5"
+# CI20
+"ingenic,jz4780-sgx540-120", "img,sgx540-120", "img,sgx540",
"img,sgx5";
+
+ reg:
+items:
+ - description: physical base address and length of the register area
+
+ interrupts:
+ items:
+ - description: interrupt from SGX subsystem to core processor
+
+ clocks:
+ items:
+ - description: optional clocks
+
+ required:
+- compatible
+- reg
+- interrupts
+
+examples: |
+ gpu@fe00 {
+ compatible = "ti,omap-omap5-sgx544-116", "img,sgx544-116",
"img,sgx544", "img,sgx5";
+ reg = <0xfe00 0x200>;
+ interrupts = ;
+ };
+
+
+historical: |
+ Imagination PVR/SGX GPU
+
+ Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by
this binding.
+
+ Required properties:
+ - compatible:Should be one of
+ "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530",
"img,sgx5"; - BeagleBoard ABC, OpenPandora 600MHz
+ "ti,omap3-sgx530-125", "img,sgx530-125", "img,sgx530",
"img,sgx5"; - BeagleBoard XM, GTA04, OpenPandora 1GHz
+ "ti,am3517-sgx530-125", "img,sgx530-125", "img,sgx530",
"img,sgx5";
+ "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530",
"img,sgx5"; - BeagleBone Black
+ "ti,omap4-sgx540-120", "img,sgx540-120", "img,sgx540",
"img,sgx5"; - Pandaboard (ES)
+ "ti,omap4-sgx544-112", "img,sgx544-112", "img,sgx544",
"img,sgx5";
+ "ti,omap5-sgx544-116", "img,sgx544-116", "img,sgx544",
"img,sgx5"; - OMAP5 UEVM, Pyra Handheld
+ "ti,dra7-sgx544-116", "img,sgx544-116", "img,s
[PATCH v3 6/7] ARM: dts: iwg20d-q7-common: Add LCD support
The iwg20d comes with a 7" capacitive touch screen, therefore
add support for it.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* No change
v1->v2:
* No change
---
arch/arm/boot/dts/iwg20d-q7-common.dtsi | 85
arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 -
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index ae75a1db..3428b8d 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -46,6 +46,49 @@
clock-frequency = <2600>;
};
+ lcd_backlight: backlight {
+ compatible = "pwm-backlight";
+
+ pwms = <&pwm3 0 500 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&gpio5 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ lvds-receiver {
+ compatible = "lvds-decoder";
+ powerdown = <&gpio7 25 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds_receiver_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds_receiver_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+ };
+
+ panel {
+ compatible = "edt,etm0700g0dh6", "simple-panel";
+ backlight = <&lcd_backlight>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds_receiver_out>;
+ };
+ };
+ };
+
reg_1p5v: 1p5v {
compatible = "regulator-fixed";
regulator-name = "1P5V";
@@ -120,6 +163,18 @@
status = "okay";
};
+&du {
+ status = "okay";
+};
+
+&gpio2 {
+ touch-interrupt {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ input;
+ };
+};
+
&hsusb {
status = "okay";
pinctrl-0 = <&usb0_pins>;
@@ -147,6 +202,25 @@
VDDIO-supply = <®_3p3v>;
VDDD-supply = <®_1p5v>;
};
+
+ touch: touchpanel@38 {
+ compatible = "edt,edt-ft5406";
+ reg = <0x38>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port@1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&lvds_receiver_in>;
+ };
+ };
+ };
};
&pci0 {
@@ -180,6 +254,11 @@
function = "i2c2";
};
+ pwm3_pins: pwm3 {
+ groups = "pwm3";
+ function = "pwm3";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
@@ -218,6 +297,12 @@
};
};
+&pwm3 {
+ pinctrl-0 = <&pwm3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&rcar_sound {
pinctrl-0 = <&sound_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
index 0e99df2..ede2e0c 100644
--- a/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi
@@ -39,7 +39,6 @@
&du {
pinctrl-0 = <&du_pins>;
pinctrl-names = "default";
- status = "okay";
ports {
port@0 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] dt-bindings: display: bridge: Repurpose lvds-encoder
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.
Signed-off-by: Fabrizio Castro
---
v2->v3:
* Extracted conversion to lvds-codec as per Rob's comment
v1->v2:
* Converted to dt-schema as per Neil's comment
---
.../bindings/display/bridge/lvds-codec.yaml| 120 +
.../bindings/display/bridge/lvds-transmitter.yaml | 91
2 files changed, 120 insertions(+), 91 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
delete mode 100644
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
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..3ebdf96
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -0,0 +1,120 @@
+# 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: Transparent LVDS encoders and LVDS decoders
+
+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
+enum:
+ - 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
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+examples:
+ - |
+lvds-encoder {
+ compatible = "lvds-encoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+remote-endpoint = <&display_out_rgb>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+remote-endpoint = <&lvds_panel_in>;
+ };
+};
+ };
+};
+
+ - |
+lvds-decoder {
+ compatible = "lvds-decoder";
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+
+ lvds_dec_in: endpoint {
+remote-endpoint = <&display_out_lvds>;
+ };
+};
+
+port@1 {
+ reg = <1>;
+
+ lvds_dec_out: endpoint {
+remote-endpoint = <&rgb_panel_in>;
+ };
+};
+ };
+};
+
+...
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
deleted file mode 100644
index 5be163a..000
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
+++ /dev/null
@@ -1,91 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0
-%YAML 1.2
-$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Parallel to LVDS Encoder
-
-maintainers:
- - Laurent Pinchart
-
-description: |
- This binding supports the parallel to LVDS encoders 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
Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo wrote:
> >
> > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> > >
> > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney wrote:
> > > >
> > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > wrote:
> > > > > > 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.
> > > >
> > > > Yes, this is a command-mode panel and there's no hardware frame counter
> > > > available. The key to getting the display working on this phone was this
> > > > patch:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > >
> > > > > 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.
> > > >
> > > > I don't think that's happening in this case. I added some pr_info()
> > > > statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> > > > Here's the first two sets of messages that appear in dmesg:
> > > >
> > > > [ 14.018907] msm fd90.mdss: pp done time out, lm=0
> > > > [ 14.018993] request_pp_done_pending: HERE
> > > > [ 14.074208] mdp5_crtc_pp_done_irq: HERE
> > > > [ 14.074368] Console: switching to colour frame buffer device 135x120
> > > > [ 14.138938] msm fd90.mdss: pp done time out, lm=0
> > > > [ 14.139021] request_pp_done_pending: HERE
> > > > [ 14.158097] mdp5_crtc_pp_done_irq: HERE
> > > >
> > > > The messages go on like this with the same pattern.
> > > >
> > > > I tried two different changes:
> > > >
> > > > 1) I moved the request_pp_done_pending() and corresponding if statement
> > > >from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
> > > >
> > > > 2) I increased the timeout in wait_for_completion_timeout() by several
> > > >increments; all the way to 5 seconds.
> > >
> > > increasing the timeout won't help, becaus
[PATCH v2 4/5] dt-bindings: display: rockchip-dsi: add px30 compatible
The px30 SoC also uses a dw-mipi-dsi controller, so add the compatible value for it. Signed-off-by: Heiko Stuebner --- .../bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1ba9237d0ac0..151be3bba06f 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -4,8 +4,10 @@ Rockchip specific extensions to the Synopsys Designware MIPI DSI Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. -- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". - "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". +- compatible: one of + "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi" + "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi" + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi" - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: use DRM_DEV_ERROR for log output
On Thu, Nov 07, 2019 at 08:38:51AM -0500, Sean Paul wrote:
> On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
> > On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> > > Replace the use of the dev_err macro with the DRM_DEV_ERROR
> > > DRM helper macro.
> >
> > The commit message should show the reason _why_ you are doing
> > this instead of just stating that you are doing this.
> >
> > It's not that dev_err is uncommon in drivers/gpu/drm.
> >
>
> It is uncommon (this is the sole instance) in rockchip, however. So it makes
> sense to convert the dev_* prints in rockchip to DRM_DEV for consistency.
>
> Wambui, could you also please convert the dev_warn instance as well?
>
Sure, I can send a patch for that.
> I'll apply this to drm-misc-next and expand on the commit message a bit.
>
Thanks,
wambui
> Thanks,
>
> Sean
>
> > $ git grep -w dev_err drivers/gpu/drm | wc -l
> > 1950
> > $ git grep -w DRM_DEV_ERROR drivers/gpu/drm | wc -l
> > 756
> >
> > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > []
> > > @@ -916,7 +916,7 @@ static int dw_mipi_dsi_rockchip_probe(struct
> > > platform_device *pdev)
> > > }
> > >
> > > if (!dsi->cdata) {
> > > - dev_err(dev, "no dsi-config for %s node\n", np->name);
> > > + DRM_DEV_ERROR(dev, "no dsi-config for %s node\n", np->name);
> > > return -EINVAL;
> > > }
> >
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V11 1/6] mdev: class id support
On 11/7/2019 8:41 PM, Jason Wang wrote:
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
Reviewed-by: Kirti Wankhede
Thanks,
Kirti
---
.../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(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_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 &mdev->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
[PATCHv1 1/2] drm/panel: simple: Add support for AUO G121EAN01.4 panel
Add timings for the AUO G121EAN01.4 panel.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 28fa6ba7b767..46ca59db6819 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -806,6 +806,29 @@ static const struct panel_desc auo_g104sn02 = {
},
};
+static const struct drm_display_mode auo_g121ean01_mode = {
+ .clock = 66700,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 58,
+ .hsync_end = 1280 + 58 + 8,
+ .htotal = 1280 + 58 + 8 + 70,
+ .vdisplay = 800,
+ .vsync_start = 800 + 6,
+ .vsync_end = 800 + 6 + 4,
+ .vtotal = 800 + 6 + 4 + 10,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_g121ean01 = {
+ .modes = &auo_g121ean01_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 261,
+ .height = 163,
+ },
+};
+
static const struct display_timing auo_g133han01_timings = {
.pixelclock = { 13400, 14120, 14900 },
.hactive = { 1920, 1920, 1920 },
@@ -3114,6 +3137,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "auo,g104sn02",
.data = &auo_g104sn02,
+ }, {
+ .compatible = "auo,g121ean01.4",
+ .data = &auo_g121ean01,
}, {
.compatible = "auo,g133han01",
.data = &auo_g133han01,
--
2.24.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: change to_mock() to an inline function
Since this function is defined in a header file, it should be
'static inline' instead of 'static'.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h
index f0f8bbd82dfc..22818bbb139d 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.h
@@ -14,7 +14,7 @@ struct mock_dmabuf {
struct page *pages[];
};
-static struct mock_dmabuf *to_mock(struct dma_buf *buf)
+static inline struct mock_dmabuf *to_mock(struct dma_buf *buf)
{
return buf->priv;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] dw-mipi-dsi support for Rockchip px30
This series adds support for the dsi controller on the px30. The main difference to previous incarnations is the use of an external dphy for the output. changes in v2: - drop handling the dphy-pll manually, instead use the regular phy configuration operations, thanks Laurent for the suggestion - add missing px30 compatible to the binding and make binding changes separate patches Heiko Stuebner (5): drm/bridge/synopsys: dsi: move phy_ops callbacks around panel enablement dt-bindings: display: rockchip-dsi: document external phys drm/rockchip: add ability to handle external dphys in mipi-dsi dt-bindings: display: rockchip-dsi: add px30 compatible drm/rockchip: dsi: add px30 support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 13 ++- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 13 ++- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 95 ++- 3 files changed, 106 insertions(+), 15 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: use DRM_DEV_ERROR for log output
Replace the use of the dev_err macro with the DRM_DEV_ERROR
DRM helper macro.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index bc073ec5c183..5f23cf702cb4 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -916,7 +916,7 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
}
if (!dsi->cdata) {
- dev_err(dev, "no dsi-config for %s node\n", np->name);
+ DRM_DEV_ERROR(dev, "no dsi-config for %s node\n", np->name);
return -EINVAL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V11 3/6] mdev: introduce device specific ops
On 11/7/2019 8:41 PM, 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
Reviewed-by: Kirti Wankhede
Thanks,
Kirti
---
.../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)
RE: [PATCH v2 2/4] dt-bindings: display: bridge: Repurpose lvds-encoder
Hello Rob, Thank you for your feedback! > From: Rob Herring > Sent: 05 November 2019 17:08 > Subject: 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
Re: [PATCH 1/2] drm: replace Compliance/Margin magic numbers with PCI_EXP_LNKCTL2 definitions
On Thu, Nov 7, 2019 at 4:30 PM Ilia Mirkin wrote: > > On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote: > > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h > > index 29d6e93fd15e..03446be8a7be 100644 > > --- a/include/uapi/linux/pci_regs.h > > +++ b/include/uapi/linux/pci_regs.h > > @@ -673,6 +673,8 @@ > > #define PCI_EXP_LNKCTL2_TLS_8_0GT 0x0003 /* Supported Speed 8GT/s */ > > #define PCI_EXP_LNKCTL2_TLS_16_0GT0x0004 /* Supported Speed 16GT/s */ > > #define PCI_EXP_LNKCTL2_TLS_32_0GT0x0005 /* Supported Speed 32GT/s */ > > +#define PCI_EXP_LNKCTL2_ENTER_COMP0x0010 /* Enter Compliance */ > > +#define PCI_EXP_LNKCTL2_TX_MARGIN 0x0380 /* Enter Compliance */ > > Without commenting on the meat of the patch, this comment should > probably read "Transmit Margin" or something along those lines? Indeed, thank you! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING in dma_buf_vunmap
syzbot suspects this bug was fixed by commit: commit 62dcb4f41836bd3c44b5b651bb6df07ea4cb1551 Author: Hans Verkuil Date: Thu Nov 8 12:23:37 2018 + media: vb2: check memory model for VIDIOC_CREATE_BUFS bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=116af11c60 start commit: d41217aa Merge tag 'pci-v4.20-fixes-1' of git://git.kernel.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=4a0a89f12ca9b0f5 dashboard link: https://syzkaller.appspot.com/bug?extid=a9317fe7ad261fc76b88 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f7b6f540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105a278340 If the result looks correct, please mark the bug fixed by replying with: #syz fix: media: vb2: check memory model for VIDIOC_CREATE_BUFS For information about bisection process see: https://goo.gl/tpsmEJ#bisection ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] RFC: dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
> Am 07.11.2019 um 15:35 schrieb Rob Herring : > > On Thu, Nov 7, 2019 at 5:06 AM H. Nikolaus Schaller > wrote: >> >> The Imagination PVR/SGX GPU is part of several SoC from >> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo >> and others. >> >> With this binding, we describe how the SGX processor is >> interfaced to the SoC (registers, interrupt etc.). >> >> Clock, Reset and power management should be handled >> by a parent node or elsewhere. > > That's probably TI specific... Yes and no. For example the img4780 seems to need a clock reference in the gpu node. But it could maybe connected in a parent node like recent TI SoC do with the target-module approach. And our goal is to end up with a common driver for all SoC and architectures in far future. Then, probably clock, reset and power management should be handled in the same way. > >> --- >> >> I have used the doc2yaml script to get a first veryion >> but I am still stuggling with the yaml thing. My impression >> is that while it is human readable, it is not very human >> writable... Unfortunately I haven't found a good tutorial >> for Dummies (like me) for bindings in YAML. > > Did you read .../bindings/example-schema.yaml? It explains the common > cases and what schema are doing. Yes. > I recently added to it, so look at > the version in linux-next. Ah, ok. I haven't read that one. > >> The big problem is not the YAML syntax but what the schema >> should contain and how to correctly formulate ideas in this >> new language. >> >> Specific questions for this RFC: >> >> * formatting: is space/tab indentation correct? > > YAML requires spaces. Which is quite uncommon if you aren't a python programmer... >> * are strings with "" correct or without? > > Generally only keys or values starting with '#' need quotes. There's > other cases, but we simply don't hit them with DT. We tend to quote > $ref values, but that's not strictly needed. Ok. Good. > >> * how do I specify that there is a list of compatible strings required in a >> specific order? > > An 'items' list defines the order. I see. > >> * but there are multiple such lists, and only one of them is to be chosen? > >^^ > 'oneOf' is the schema keyword you are looking for. Ok. > >> * how can be described in the binding that there should be certain values in >> the parent node (ranges) to make it work? > > You can't. Schemas match on a node and work down from there. So you > can do it, but it's more complicated. You'd need a custom 'select' > select that matches on the parent node having the child node you are > looking for (assuming the parent is something generic like > 'simple-bus' which you can't match on). However, based on the example, > I'd say checking 'ranges' is outside the scope of schema checks. > 'ranges' doesn't have to be a certain value any more than every case > of 'reg' (except maybe i2c devices with fixed addresses). Ok. > It's up to > the .dts author how exactly to do address translation. Well, my concern as a regular .dts author is that I usually treat bindings as documentation and giving hints how to write a .dts and what to take care of. If it is not complete, I get into big trouble. > I would like to have more ranges/reg checks such as bounds checks and > overlapping addresses, but I think we'd do those with code, not > schema. > >> I was not able to run >> >>make dt_binding_check dtbs_check >> >> due to some missing dependencies (which I did not want to >> invest time to research them) on my build host, so I could >> not get automated help from those. > > Dependencies are documented in Documentation/devicetree/writing-schema.rst. One says it needs a libyaml but after installing one my HOSTCC didn't find it. The other asks for another script which seems to be missing. > >> --- >> .../devicetree/bindings/gpu/img,pvrsgx.yaml | 128 ++ >> 1 file changed, 128 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> >> diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> new file mode 100644 >> index ..b1b021601c47 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.yaml >> @@ -0,0 +1,128 @@ >> +# SPDX-License-Identifier: None > > Obviously not valid. :) > >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/bindings/gpu/img,pvrsgx.yaml# > > This should have been correct with the script, but you need to drop > 'bindings'. Ok. > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Imagination PVR/SGX GPU >> + >> +maintainers: >> + - H. Nikolaus Schaller >> +description: |+ >> + This binding describes the Imagination SGX5 series of 3D accelerators >> which >> + are found in several different SoC like TI OMAP, Sitara, Ingenic JZ4780, >> + Allwinner A83, and In
[PATCH v2 7/8] ARM: DTS: omap5: add sgx gpu child node
and add interrupt.
Tested on Pyra-Handheld.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1fb7937638f0..333da4788088 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -274,10 +274,11 @@
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: gpu@0 {
+ compatible = "ti,omap5-sgx544-116",
"img,sgx544-116", "img,sgx544";
+ reg = <0x0 0x1>;
+ interrupts = ;
+ };
};
dss: dss@5800 {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/rockchip: add ability to handle external dphys in mipi-dsi
While the common case is that the dsi controller uses an internal dphy,
accessed through the phy registers inside the dsi controller, there is
also the possibility to use a separate dphy from a different vendor.
One such case is the Rockchip px30 that uses a Innosilicon Mipi dphy,
so add the support for handling such a constellation, including the pll
also getting generated inside that external phy.
Signed-off-by: Heiko Stuebner
---
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 68 +--
1 file changed, 64 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index bc073ec5c183..1e6578f911a0 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -223,6 +224,10 @@ struct dw_mipi_dsi_rockchip {
bool is_slave;
struct dw_mipi_dsi_rockchip *slave;
+ /* optional external dphy */
+ struct phy *phy;
+ union phy_configure_opts phy_opts;
+
unsigned int lane_mbps; /* per lane */
u16 input_div;
u16 feedback_div;
@@ -359,6 +364,9 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
struct dw_mipi_dsi_rockchip *dsi = priv_data;
int ret, i, vco;
+ if (dsi->phy)
+ return 0;
+
/*
* Get vco from frequency(lane_mbps)
* vco frequency table
@@ -467,6 +475,28 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+static void dw_mipi_dsi_phy_power_on(void *priv_data)
+{
+ struct dw_mipi_dsi_rockchip *dsi = priv_data;
+ int ret;
+
+ ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
+ if (ret) {
+ DRM_DEV_ERROR(dsi->dev, "failed to set phy mode: %d\n", ret);
+ return;
+ }
+
+ phy_configure(dsi->phy, &dsi->phy_opts);
+ phy_power_on(dsi->phy);
+}
+
+static void dw_mipi_dsi_phy_power_off(void *priv_data)
+{
+ struct dw_mipi_dsi_rockchip *dsi = priv_data;
+
+ phy_power_off(dsi->phy);
+}
+
static int
dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct drm_display_mode *mode,
unsigned long mode_flags, u32 lanes, u32 format,
@@ -504,6 +534,17 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
"DPHY clock frequency is out of range\n");
}
+ /* for external phy only a the mipi_dphy_config is necessary */
+ if (dsi->phy) {
+ phy_mipi_dphy_get_default_config(mode->clock * 1000 * 10 / 8,
+bpp, lanes,
+&dsi->phy_opts.mipi_dphy);
+ dsi->lane_mbps = target_mbps;
+ *lane_mbps = dsi->lane_mbps;
+
+ return 0;
+ }
+
fin = clk_get_rate(dsi->pllref_clk);
fout = target_mbps * USEC_PER_SEC;
@@ -561,6 +602,8 @@ dw_mipi_dsi_get_lane_mbps(void *priv_data, const struct
drm_display_mode *mode,
static const struct dw_mipi_dsi_phy_ops dw_mipi_dsi_rockchip_phy_ops = {
.init = dw_mipi_dsi_phy_init,
+ .power_on = dw_mipi_dsi_phy_power_on,
+ .power_off = dw_mipi_dsi_phy_power_off,
.get_lane_mbps = dw_mipi_dsi_get_lane_mbps,
};
@@ -920,12 +963,29 @@ static int dw_mipi_dsi_rockchip_probe(struct
platform_device *pdev)
return -EINVAL;
}
+ /* try to get a possible external dphy */
+ dsi->phy = devm_phy_optional_get(dev, "dphy");
+ if (IS_ERR(dsi->phy)) {
+ ret = PTR_ERR(dsi->phy);
+ DRM_DEV_ERROR(dev, "failed to get mipi dphy: %d\n", ret);
+ return ret;
+ }
+
dsi->pllref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(dsi->pllref_clk)) {
- ret = PTR_ERR(dsi->pllref_clk);
- DRM_DEV_ERROR(dev,
- "Unable to get pll reference clock: %d\n", ret);
- return ret;
+ if (dsi->phy) {
+ /*
+* if external phy is present, pll will be
+* generated there.
+*/
+ dsi->pllref_clk = NULL;
+ } else {
+ ret = PTR_ERR(dsi->pllref_clk);
+ DRM_DEV_ERROR(dev,
+ "Unable to get pll reference clock: %d\n",
+ ret);
+ return ret;
+ }
}
if (dsi->cdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
--
2.23.0
___
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 Thu, Nov 7, 2019 at 9:17 AM Rob Clark wrote:
>
> On Thu, Nov 7, 2019 at 3:10 AM Brian Masney wrote:
> >
> > On Wed, Nov 06, 2019 at 08:58:59AM -0800, Rob Clark wrote:
> > > On Wed, Nov 6, 2019 at 8:47 AM Jeffrey Hugo
> > > wrote:
> > > >
> > > > On Wed, Nov 6, 2019 at 9:30 AM Rob Clark wrote:
> > > > >
> > > > > On Wed, Nov 6, 2019 at 1:13 AM Brian Masney
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > > > > > > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney
> > > > > > > wrote:
> > > > > > > > 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.
> > > > > >
> > > > > > Yes, this is a command-mode panel and there's no hardware frame
> > > > > > counter
> > > > > > available. The key to getting the display working on this phone was
> > > > > > this
> > > > > > patch:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > I don't think that's happening in this case. I added some pr_info()
> > > > > > statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> > > > > > Here's the first two sets of messages that appear in dmesg:
> > > > > >
> > > > > > [ 14.018907] msm fd90.mdss: pp done time out, lm=0
> > > > > > [ 14.018993] request_pp_done_pending: HERE
> > > > > > [ 14.074208] mdp5_crtc_pp_done_irq: HERE
> > > > > > [ 14.074368] Console: switching to colour frame buffer device
>
[PATCH v3 0/7] Add LCD panel support to iwg20d
The iW-RainboW-G20D-Qseven RZ/G1M,G1N Qseven Development Platform comes with a 7" capacitive display kit from Emerging Display Technologies Corporation (EDT). This series adds all that's necessary for supporting it. Thanks, Fab v2->v3: * Split the dt-schema patch in two pathes as per Rob's comment * Made fixes to the dt-schema according to Rob's comment * Made fixes to the lvds-codec driver according to Jacopo's comments * Added two new patches: * drm: Define DRM_MODE_CONNECTOR_PARALLEL * drm/panel: panel-simple: Add connector type for etm0700g0dh6 v1->v2: * Convert dt-bindings to dt-schema Fabrizio Castro (7): dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema drm/bridge: Repurpose lvds-encoder.c dt-bindings: display: bridge: Repurpose lvds-encoder drm: Define DRM_MODE_CONNECTOR_PARALLEL drm/panel: panel-simple: Add connector type for etm0700g0dh6 ARM: dts: iwg20d-q7-common: Add LCD support ARM: shmobile_defconfig: Enable support for panels from EDT .../bindings/display/bridge/lvds-codec.yaml| 120 .../bindings/display/bridge/lvds-transmitter.txt | 66 - arch/arm/boot/dts/iwg20d-q7-common.dtsi| 85 +++ arch/arm/boot/dts/iwg20d-q7-dbcm-ca.dtsi | 1 - arch/arm/configs/shmobile_defconfig| 3 + drivers/gpu/drm/bridge/Kconfig | 8 +- drivers/gpu/drm/bridge/Makefile| 2 +- drivers/gpu/drm/bridge/lvds-codec.c| 131 + drivers/gpu/drm/bridge/lvds-encoder.c | 155 - drivers/gpu/drm/drm_connector.c| 1 + drivers/gpu/drm/panel/panel-simple.c | 1 + include/uapi/drm/drm_mode.h| 1 + 12 files changed, 347 insertions(+), 227 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml delete mode 100644 Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/7] drm/panel: panel-simple: Add connector type for etm0700g0dh6
Add connector type for the etm0700g0dh6 from Emerging Display
Technologies (EDT).
Signed-off-by: Fabrizio Castro
---
v2->v3:
* New patch
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5d48768..82065ff 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1342,6 +1342,7 @@ static const struct panel_desc edt_etm0700g0dh6 = {
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_PARALLEL,
};
static const struct panel_desc edt_etm0700g0bdh6 = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] RFC: dt-bindings: add img,pvrsgx.yaml for Imagination GPUs
* H. Nikolaus Schaller [191107 11:07]: > +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530", > "img,sgx5" This should be without the x, maybe use the earliest one here for "ti,am3352-sgx530-125" like we have for "ti,am3352-uart". We could use "ti,am3-sgx530-125" but that can get confused then with am3517 then. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] dt-bindings: display: rockchip-dsi: document external phys
Some dw-mipi-dsi instances in Rockchip SoCs use external dphys. In these cases the needs clock will also be generated externally so these don't need the ref-clock as well. Signed-off-by: Heiko Stuebner --- .../bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index ce4c1fc9116c..1ba9237d0ac0 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -9,8 +9,9 @@ Required properties: - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk). For RK3399, a phy config clock - (phy_cfg) and a grf clock(grf) are required. As described in [1]. + clock(ref) when using an internal dphy and APB clock(pclk). + For RK3399, a phy config clock (phy_cfg) and a grf clock(grf) + are required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. @@ -18,6 +19,8 @@ Required properties: - video port 1 for either a panel or subsequent encoder Optional properties: +- phys: from general PHY binding: the phandle for the PHY device. +- phy-names: Should be "dphy" if phys references an external phy. - power-domains: a phandle to mipi dsi power domain node. - resets: list of phandle + reset specifier pairs, as described in [3]. - reset-names: string reset name, must be "apb". -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: make more headers self-contained
On Fri, Nov 8, 2019 at 2:15 PM Masahiro Yamada
wrote:
>
> The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
> directories have never been compile-tested, but it would be possible
> to make them self-contained.
>
> This commit only addresses missing and forward
> struct declarations.
>
> Signed-off-by: Masahiro Yamada
> ---
I confirmed this patch is applicable to next-20191107
but CI fails to apply it.
Which branch should I base my patch on?
>
> drivers/gpu/drm/i915/gem/selftests/mock_context.h | 3 +++
> drivers/gpu/drm/i915/gt/selftests/mock_timeline.h | 2 ++
> drivers/gpu/drm/i915/gvt/cmd_parser.h | 4
> drivers/gpu/drm/i915/gvt/display.h| 5 +
> drivers/gpu/drm/i915/gvt/edid.h | 4
> drivers/gpu/drm/i915/gvt/execlist.h | 2 ++
> drivers/gpu/drm/i915/gvt/fb_decoder.h | 2 ++
> drivers/gpu/drm/i915/gvt/hypercall.h | 4
> drivers/gpu/drm/i915/gvt/interrupt.h | 3 +++
> drivers/gpu/drm/i915/gvt/mmio.h | 2 ++
> drivers/gpu/drm/i915/gvt/page_track.h | 3 +++
> drivers/gpu/drm/i915/gvt/sched_policy.h | 3 +++
> drivers/gpu/drm/i915/selftests/mock_drm.h | 2 ++
> drivers/gpu/drm/i915/selftests/mock_gtt.h | 3 +++
> drivers/gpu/drm/i915/selftests/mock_region.h | 5 +
> drivers/gpu/drm/i915/selftests/mock_uncore.h | 3 +++
> 16 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> index 0b926653914f..45de09ec28d1 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> +++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
> @@ -7,6 +7,9 @@
> #ifndef __MOCK_CONTEXT_H
> #define __MOCK_CONTEXT_H
>
> +struct drm_file;
> +struct drm_i915_private;
> +
> void mock_init_contexts(struct drm_i915_private *i915);
>
> struct i915_gem_context *
> diff --git a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
> b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
> index 689efc66c908..d2bcc3df6183 100644
> --- a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
> +++ b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
> @@ -7,6 +7,8 @@
> #ifndef __MOCK_TIMELINE__
> #define __MOCK_TIMELINE__
>
> +#include
> +
> struct intel_timeline;
>
> void mock_timeline_init(struct intel_timeline *timeline, u64 context);
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.h
> b/drivers/gpu/drm/i915/gvt/cmd_parser.h
> index 286703643002..ab25d151932a 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.h
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.h
> @@ -38,6 +38,10 @@
>
> #define GVT_CMD_HASH_BITS 7
>
> +struct intel_gvt;
> +struct intel_shadow_wa_ctx;
> +struct intel_vgpu_workload;
> +
> void intel_gvt_clean_cmd_parser(struct intel_gvt *gvt);
>
> int intel_gvt_init_cmd_parser(struct intel_gvt *gvt);
> diff --git a/drivers/gpu/drm/i915/gvt/display.h
> b/drivers/gpu/drm/i915/gvt/display.h
> index a87f33e6a23c..b59b34046e1e 100644
> --- a/drivers/gpu/drm/i915/gvt/display.h
> +++ b/drivers/gpu/drm/i915/gvt/display.h
> @@ -35,6 +35,11 @@
> #ifndef _GVT_DISPLAY_H_
> #define _GVT_DISPLAY_H_
>
> +#include
> +
> +struct intel_gvt;
> +struct intel_vgpu;
> +
> #define SBI_REG_MAX20
> #define DPCD_SIZE 0x700
>
> diff --git a/drivers/gpu/drm/i915/gvt/edid.h b/drivers/gpu/drm/i915/gvt/edid.h
> index f6dfc8b795ec..dfe0cbc6aad8 100644
> --- a/drivers/gpu/drm/i915/gvt/edid.h
> +++ b/drivers/gpu/drm/i915/gvt/edid.h
> @@ -35,6 +35,10 @@
> #ifndef _GVT_EDID_H_
> #define _GVT_EDID_H_
>
> +#include
> +
> +struct intel_vgpu;
> +
> #define EDID_SIZE 128
> #define EDID_ADDR 0x50 /* Linux hvm EDID addr */
>
> diff --git a/drivers/gpu/drm/i915/gvt/execlist.h
> b/drivers/gpu/drm/i915/gvt/execlist.h
> index 5ccc2c695848..5c0c1fd30c83 100644
> --- a/drivers/gpu/drm/i915/gvt/execlist.h
> +++ b/drivers/gpu/drm/i915/gvt/execlist.h
> @@ -35,6 +35,8 @@
> #ifndef _GVT_EXECLIST_H_
> #define _GVT_EXECLIST_H_
>
> +#include
> +
> struct execlist_ctx_descriptor_format {
> union {
> u32 ldw;
> diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.h
> b/drivers/gpu/drm/i915/gvt/fb_decoder.h
> index 60c155085029..67b6ede9e707 100644
> --- a/drivers/gpu/drm/i915/gvt/fb_decoder.h
> +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.h
> @@ -36,6 +36,8 @@
> #ifndef _GVT_FB_DECODER_H_
> #define _GVT_FB_DECODER_H_
>
> +#include
> +
> #define _PLANE_CTL_FORMAT_SHIFT24
> #define _PLANE_CTL_TILED_SHIFT 10
> #define _PIPE_V_SRCSZ_SHIFT0
> diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
> b/drivers/gpu/drm/i915/gvt/hypercall.h
> index 4862fb12778e..9599c0a762b2 100644
> --- a/drivers/gpu/drm/i915/gvt/hypercall.h
> +++ b/drivers/gpu/drm/i915/gvt/hypercall.h
> @@ -33,6 +33,10 @@
> #ifndef _GVT_HYPERCALL_H_
> #define _GVT_HYPERCALL_H_
>
> +#include
> +
> +st
[PATCH 2/2] drm/i915: make more headers self-contained
The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
directories have never been compile-tested, but it would be possible
to make them self-contained.
This commit only addresses missing and forward
struct declarations.
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/gem/selftests/mock_context.h | 3 +++
drivers/gpu/drm/i915/gt/selftests/mock_timeline.h | 2 ++
drivers/gpu/drm/i915/gvt/cmd_parser.h | 4
drivers/gpu/drm/i915/gvt/display.h| 5 +
drivers/gpu/drm/i915/gvt/edid.h | 4
drivers/gpu/drm/i915/gvt/execlist.h | 2 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 2 ++
drivers/gpu/drm/i915/gvt/hypercall.h | 4
drivers/gpu/drm/i915/gvt/interrupt.h | 3 +++
drivers/gpu/drm/i915/gvt/mmio.h | 2 ++
drivers/gpu/drm/i915/gvt/page_track.h | 3 +++
drivers/gpu/drm/i915/gvt/sched_policy.h | 3 +++
drivers/gpu/drm/i915/selftests/mock_drm.h | 2 ++
drivers/gpu/drm/i915/selftests/mock_gtt.h | 3 +++
drivers/gpu/drm/i915/selftests/mock_region.h | 5 +
drivers/gpu/drm/i915/selftests/mock_uncore.h | 3 +++
16 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
index 0b926653914f..45de09ec28d1 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.h
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.h
@@ -7,6 +7,9 @@
#ifndef __MOCK_CONTEXT_H
#define __MOCK_CONTEXT_H
+struct drm_file;
+struct drm_i915_private;
+
void mock_init_contexts(struct drm_i915_private *i915);
struct i915_gem_context *
diff --git a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
index 689efc66c908..d2bcc3df6183 100644
--- a/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
+++ b/drivers/gpu/drm/i915/gt/selftests/mock_timeline.h
@@ -7,6 +7,8 @@
#ifndef __MOCK_TIMELINE__
#define __MOCK_TIMELINE__
+#include
+
struct intel_timeline;
void mock_timeline_init(struct intel_timeline *timeline, u64 context);
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.h
b/drivers/gpu/drm/i915/gvt/cmd_parser.h
index 286703643002..ab25d151932a 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.h
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.h
@@ -38,6 +38,10 @@
#define GVT_CMD_HASH_BITS 7
+struct intel_gvt;
+struct intel_shadow_wa_ctx;
+struct intel_vgpu_workload;
+
void intel_gvt_clean_cmd_parser(struct intel_gvt *gvt);
int intel_gvt_init_cmd_parser(struct intel_gvt *gvt);
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index a87f33e6a23c..b59b34046e1e 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -35,6 +35,11 @@
#ifndef _GVT_DISPLAY_H_
#define _GVT_DISPLAY_H_
+#include
+
+struct intel_gvt;
+struct intel_vgpu;
+
#define SBI_REG_MAX20
#define DPCD_SIZE 0x700
diff --git a/drivers/gpu/drm/i915/gvt/edid.h b/drivers/gpu/drm/i915/gvt/edid.h
index f6dfc8b795ec..dfe0cbc6aad8 100644
--- a/drivers/gpu/drm/i915/gvt/edid.h
+++ b/drivers/gpu/drm/i915/gvt/edid.h
@@ -35,6 +35,10 @@
#ifndef _GVT_EDID_H_
#define _GVT_EDID_H_
+#include
+
+struct intel_vgpu;
+
#define EDID_SIZE 128
#define EDID_ADDR 0x50 /* Linux hvm EDID addr */
diff --git a/drivers/gpu/drm/i915/gvt/execlist.h
b/drivers/gpu/drm/i915/gvt/execlist.h
index 5ccc2c695848..5c0c1fd30c83 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.h
+++ b/drivers/gpu/drm/i915/gvt/execlist.h
@@ -35,6 +35,8 @@
#ifndef _GVT_EXECLIST_H_
#define _GVT_EXECLIST_H_
+#include
+
struct execlist_ctx_descriptor_format {
union {
u32 ldw;
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.h
b/drivers/gpu/drm/i915/gvt/fb_decoder.h
index 60c155085029..67b6ede9e707 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.h
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.h
@@ -36,6 +36,8 @@
#ifndef _GVT_FB_DECODER_H_
#define _GVT_FB_DECODER_H_
+#include
+
#define _PLANE_CTL_FORMAT_SHIFT24
#define _PLANE_CTL_TILED_SHIFT 10
#define _PIPE_V_SRCSZ_SHIFT0
diff --git a/drivers/gpu/drm/i915/gvt/hypercall.h
b/drivers/gpu/drm/i915/gvt/hypercall.h
index 4862fb12778e..9599c0a762b2 100644
--- a/drivers/gpu/drm/i915/gvt/hypercall.h
+++ b/drivers/gpu/drm/i915/gvt/hypercall.h
@@ -33,6 +33,10 @@
#ifndef _GVT_HYPERCALL_H_
#define _GVT_HYPERCALL_H_
+#include
+
+struct device;
+
enum hypervisor_type {
INTEL_GVT_HYPERVISOR_XEN = 0,
INTEL_GVT_HYPERVISOR_KVM,
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.h
b/drivers/gpu/drm/i915/gvt/interrupt.h
index 5313fb1b33e1..fcd663811d37 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.h
+++ b/drivers/gpu/drm/i915/gvt/interrupt.h
@@ -32,6 +32,8 @@
#ifndef _GVT_INTERRUPT_H_
#define _GVT_INTERRUPT_H_
+#include
+
enum intel_gvt_event_typ
Re: [PATCH v2 1/8] RFC: dt-bindings: add img, pvrsgx.yaml for Imagination GPUs
> Am 07.11.2019 um 16:54 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [191107 11:07]: >> +- const: "ti,am335x-sgx530-125", "img,sgx530-125", "img,sgx530", >> "img,sgx5" > > This should be without the x, maybe use the earliest one here > for "ti,am3352-sgx530-125" like we have for "ti,am3352-uart". Ok, fine. Will update accordingly. > We could use "ti,am3-sgx530-125" but that can get confused > then with am3517 then. Indeed. BR and thanks, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > Extra credit: IMHO, this clearly deserves to all be in a new
> > mmu_range_notifier.h
> > header file, but I know that's extra work. Maybe later as a follow-up patch,
> > if anyone has the time.
>
> The range notifier should get the event too, it would be a waste, i think it
> is
> an oversight here. The release event is fine so NAK to you separate event.
> Event
> is really an helper for notifier i had a set of patch for nouveau to leverage
> this i need to resucite them. So no need to split thing, i would just forward
> the event ie add event to mmu_range_notifier_ops.invalidate() i failed to
> catch
> that in v1 sorry.
I think what you mean is already done?
struct mmu_range_notifier_ops {
bool (*invalidate)(struct mmu_range_notifier *mrn,
const struct mmu_notifier_range *range,
unsigned long cur_seq);
> No it is always odd, you must call mmu_range_set_seq() only from the
> op->invalidate_range() callback at which point the seq is odd. As well
> when mrn is added and its seq first set it is set to an odd value
> always. Maybe the comment, should read:
>
> * mrn->invalidate_seq is always, yes always, set to an odd value. This
> ensures
>
> To stress that it is not an error.
I went with this:
/*
* mrn->invalidate_seq must always be set to an odd value via
* mmu_range_set_seq() using the provided cur_seq from
* mn_itree_inv_start_range(). This ensures that if seq does wrap we
* will always clear the below sleep in some reasonable time as
* mmn_mm->invalidate_seq is even in the idle state.
*/
> > > + spin_lock(&mmn_mm->lock);
> > > + if (mmn_mm->active_invalidate_ranges) {
> > > + if (mn_itree_is_invalidating(mmn_mm))
> > > + hlist_add_head(&mrn->deferred_item,
> > > +&mmn_mm->deferred_list);
> > > + else {
> > > + mmn_mm->invalidate_seq |= 1;
> > > + interval_tree_insert(&mrn->interval_tree,
> > > + &mmn_mm->itree);
> > > + }
> > > + mrn->invalidate_seq = mmn_mm->invalidate_seq;
> > > + } else {
> > > + WARN_ON(mn_itree_is_invalidating(mmn_mm));
> > > + mrn->invalidate_seq = mmn_mm->invalidate_seq - 1;
> >
> > Ohhh, checkmate. I lose. Why is *subtracting* the right thing to do
> > for seq numbers here? I'm acutely unhappy trying to figure this out.
> > I suspect it's another unfortunate side effect of trying to use the
> > lower bit of the seq number (even/odd) for something else.
>
> If there is no mmn_mm->active_invalidate_ranges then it means that
> mmn_mm->invalidate_seq is even and thus mmn_mm->invalidate_seq - 1
> is an odd number which means that mrn->invalidate_seq is initialized
> to odd value and if you follow the rule for calling mmu_range_set_seq()
> then it will _always_ be an odd number and this close the loop with
> the above comments :)
The key thing is that it is an odd value that will take a long time
before mmn_mm->invalidate seq reaches it
> > > + might_lock(&mm->mmap_sem);
> > > +
> > > + mmn_mm = smp_load_acquire(&mm->mmu_notifier_mm);
> >
> > What does the above pair with? Should have a comment that specifies that.
>
> It was discussed in v1 but maybe a comment of what was said back then would
> be helpful. Something like:
>
> /*
> * We need to insure that all writes to mm->mmu_notifier_mm are visible before
> * any checks we do on mmn_mm below as otherwise CPU might re-order write done
> * by another CPU core to mm->mmu_notifier_mm structure fields after the read
> * belows.
> */
This comment made it, just at the store side:
/*
* Serialize the update against mmu_notifier_unregister. A
* side note: mmu_notifier_release can't run concurrently with
* us because we hold the mm_users pin (either implicitly as
* current->mm or explicitly with get_task_mm() or similar).
* We can't race against any other mmu notifier method either
* thanks to mm_take_all_locks().
*
* release semantics on the initialization of the mmu_notifier_mm's
* contents are provided for unlocked readers. acquire can only be
* used while holding the mmgrab or mmget, and is safe because once
* created the mmu_notififer_mm is not freed until the mm is
* destroyed. As above, users holding the mmap_sem or one of the
* mm_take_all_locks() do not need to use acquire semantics.
*/
if (mmu_notifier_mm)
smp_store_release(&mm->mmu_notifier_mm, mmu_notifier_mm);
Which I think is really overly belaboring the typical smp
store/release pattern, but people do seem unfamiliar with them...
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freed
[PATCH] drm/qxl: Complete exception handling in qxl_device_init()
From: Markus Elfring
Date: Thu, 7 Nov 2019 18:05:08 +0100
A coccicheck run provided information like the following.
drivers/gpu/drm/qxl/qxl_kms.c:295:1-7: ERROR: missing iounmap;
ioremap on line 178 and execution via conditional on line 185
Generated by: scripts/coccinelle/free/iounmap.cocci
A jump target was specified in an if branch. The corresponding function
call did not release the desired system resource then.
Thus use the label “rom_unmap” instead to fix the exception handling
for this function implementation.
Fixes: 5043348a4969ae1661c008efe929abd0d76e3792 ("drm: qxl: Fix error handling
at qxl_device_init")
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 611cbe7aee69..bfc1631093e9 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -184,7 +184,7 @@ int qxl_device_init(struct qxl_device *qdev,
if (!qxl_check_device(qdev)) {
r = -ENODEV;
- goto surface_mapping_free;
+ goto rom_unmap;
}
r = qxl_bo_init(qdev);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm/bridge/synopsys: dsi: move phy_ops callbacks around panel enablement
If implementation-specific phy_ops need to be defined they probably
should be enabled before trying to talk to the panel and disabled only
after the panel was disabled.
Right now they are enabled last and disabled first, so might make it
impossible to talk to some panels - example for this being the px30
with an external Innosilicon dphy that needs the phy to be enabled
to transfer commands to the panel.
So move the calls appropriately.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 675442bfc1bd..49f5600a1dea 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -797,9 +797,6 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
- if (phy_ops->power_off)
- phy_ops->power_off(dsi->plat_data->priv_data);
-
/*
* Switch to command mode before panel-bridge post_disable &
* panel unprepare.
@@ -816,6 +813,9 @@ static void dw_mipi_dsi_bridge_post_disable(struct
drm_bridge *bridge)
*/
dsi->panel_bridge->funcs->post_disable(dsi->panel_bridge);
+ if (phy_ops->power_off)
+ phy_ops->power_off(dsi->plat_data->priv_data);
+
if (dsi->slave) {
dw_mipi_dsi_disable(dsi->slave);
clk_disable_unprepare(dsi->slave->pclk);
@@ -882,6 +882,9 @@ static void dw_mipi_dsi_mode_set(struct dw_mipi_dsi *dsi,
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
+
+ if (phy_ops->power_on)
+ phy_ops->power_on(dsi->plat_data->priv_data);
}
static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -898,15 +901,11 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
static void dw_mipi_dsi_bridge_enable(struct drm_bridge *bridge)
{
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
- const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
/* Switch to video mode for panel-bridge enable & panel enable */
dw_mipi_dsi_set_mode(dsi, MIPI_DSI_MODE_VIDEO);
if (dsi->slave)
dw_mipi_dsi_set_mode(dsi->slave, MIPI_DSI_MODE_VIDEO);
-
- if (phy_ops->power_on)
- phy_ops->power_on(dsi->plat_data->priv_data);
}
static enum drm_mode_status
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V11 2/6] modpost: add support for mdev class id
On 11/7/2019 8:41 PM, Jason Wang wrote:
Add support to parse mdev class id table.
Reviewed-by: Parav Pandit
Reviewed-by: Cornelia Huck
Signed-off-by: Jason Wang
Reviewed-by: Kirti Wankhede
Thanks,
Kirti
---
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Hi,
On Tue, Oct 15, 2019 at 5:52 PM Xin Ji wrote:
>
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
> to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
>
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/Makefile |2 +-
> drivers/gpu/drm/bridge/analogix/Kconfig |6 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> drivers/gpu/drm/bridge/analogix/anx7625.c | 2043
> +
> drivers/gpu/drm/bridge/analogix/anx7625.h | 406 ++
> 5 files changed, 2457 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf..bcd388a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
> obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> -obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-y += analogix/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e930ff9..b2f127e 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -2,3 +2,9 @@
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> +
> +config ANALOGIX_ANX7625
> + tristate "Analogix MIPI to DP interface support"
> + help
> + ANX7625 is an ultra-low power 4K mobile HD transmitter
> designed
> + for portable devices. It converts MIPI/DPI to DisplayPort1.3
> 4K.
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index fdbf3fd..8a52867 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> new file mode 100644
> index 000..456b95c
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -0,0 +1,2043 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "anx7625.h"
> +
> +/*
> + * there is a sync issue while access I2C register between AP(CPU) and
> + * internal firmware(OCM), to avoid the race condition, AP should access
> + * the reserved slave address before slave address occurs changes.
> + */
> +static int i2c_access_workaround(struct anx7625_data *ctx,
> +struct i2c_client *client)
> +{
> + u8 offset;
> + struct device *dev = &client->dev;
> + int ret;
> +
> + if (client == ctx->last_client)
> + return 0;
> +
> + ctx->last_client = client;
> +
> + if (client == ctx->i2c.tcpc_client)
> + offset = RSVD_00_ADDR;
> + else if (client == ctx->i2c.tx_p0_client)
> + offset = RSVD_D1_ADDR;
> + else if (client == ctx->i2c.tx_p1_client)
> + offset = RSVD_60_ADDR;
> + else if (client == ctx->i2c.rx_p0_client)
> + offset = RSVD_39_ADDR;
> + else if (client == ctx->i2c.rx_p1_client)
> + offset = RSVD_7F_ADDR;
> + else
> + offset = RSVD_00_ADDR;
> +
> + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev,
> + "failed to access i2c id=%x\n:%x",
> + client->addr, offset);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_read(struct anx7625_data *ctx,
> + struct i2c_client *client, u8 reg_addr)
> +{
> + int ret;
> + struct device *dev = &client->dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_byte_data(client, reg_addr);
> + if (ret < 0)
> +
Re: [PATCH 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c
On Thu, 7 Nov 2019 16:02:59 -0500 Sean Paul wrote: > From: Sean Paul > > Hey all, > I'm back with another trace events patchset. My first attempt [1] went > better than expected, with enthusiasm for the idea and distain for the > implementation. > > As promised, I went through and added proper trace events. > > Before I get _too_ far, I wanted to post this set to get feedback on the > direction I'm going. I've gone back and forth on whether to introduce a > bunch of trace systems vs using the trace class enum. I've settled on > the trace class enum since it seems more extensible and easier to use in > production that just having the blunt "enable this system", or > the tedious "enable each event I'm interested in individually" methods. > > So, consider this one an RFC unless we're all in agreement, in which > case we should apply it :) > Hi Sean, thanks for working on this. I'm not at all familiar with the trace infrastructure, so I'd like to know how flight recorder type of behaviour (a continuously written fixed size ring buffer) can be achieved. Let us have a display server in userspace which in production hits an unexpected condition with DRM and needs to record information for post-mortem debugging. What should it do to have a trace log after the fact to attach with a bug report? I assume that is a major use case for this new feature. Is performance profiling another use case? Is it ok to build userspace to rely on these trace events during normal operations, e.g. for continuous adjustment of timings/timers? Thanks, pq > > [1]- https://patchwork.freedesktop.org/patch/335350/ > > Sean Paul (6): > drm: trace: Make the vblank queued/delivered events classed > drm: trace: Introduce drm_trace() and trace event classes > drm: trace: Add trace events for atomic state lifetime > drm: trace: Add crtc state trace events > drm: trace: Add connector state tracing > drm: trace: Add plane state tracing > > Documentation/gpu/drm-internals.rst | 9 + > drivers/gpu/drm/drm_atomic.c| 61 ++- > drivers/gpu/drm/drm_trace.h | 563 ++-- > drivers/gpu/drm/drm_vblank.c| 8 +- > 4 files changed, 609 insertions(+), 32 deletions(-) > pgplqDcA6PUHD.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: make more headers self-contained
Quoting Masahiro Yamada (2019-11-08 05:42:33) > On Fri, Nov 8, 2019 at 2:15 PM Masahiro Yamada > wrote: > > > > The headers in the gem/selftests/, gt/selftests, gvt/, selftests/ > > directories have never been compile-tested, but it would be possible > > to make them self-contained. > > > > This commit only addresses missing and forward > > struct declarations. > > > > Signed-off-by: Masahiro Yamada > > --- > > I confirmed this patch is applicable to next-20191107 > but CI fails to apply it. CI is ahead of -next, even more so before the merge window when our MR trees (used for -next) are frozen, but development continues. > Which branch should I base my patch on? https://cgit.freedesktop.org/drm-tip/ #drm-tip -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] allow DRM drivers to limit creation of blobs
On Thu, Nov 07, 2019 at 02:39:11PM -0500, Steve Cohen wrote: > Fuzzers used in Android compliance testing repeatedly call the > create blob IOCTL which eventually exhausts the system memory. > This series adds a hook which allows drivers to impose their own > limitations on the size and/or number of blobs created. Pretty sure this isn't just a problem for msm/dpu alone, why this very limited approach? Also, why are your fuzzers not also allocating enormous amounts of gem buffers, which will also exhaust memory eventually? -Daniel > > Steve Cohen (3): > drm: add driver hook for create blob limitations > drm/msm: add support for createblob_check driver hook > drm/msm/dpu: check blob limitations during create blob ioctl > > drivers/gpu/drm/drm_property.c | 7 +++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 ++ > drivers/gpu/drm/msm/msm_drv.c | 25 + > drivers/gpu/drm/msm/msm_kms.h | 1 + > include/drm/drm_drv.h | 9 + > 5 files changed, 56 insertions(+) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] ARM: shmobile_defconfig: Enable support for panels from EDT
Hi Laurent,
On Thu, Nov 7, 2019 at 9:56 PM Laurent Pinchart
wrote:
> On Thu, Nov 07, 2019 at 08:11:03PM +, Fabrizio Castro wrote:
> > The iwg20d comes with an LCD panel from Emerging Display
> > Technologies Corporation (EDT), therefore enable what's
> > required to support it.
> >
> > Signed-off-by: Fabrizio Castro
> >
> > ---
> > v2->v3:
> > * No change
> > v1->v2:
> > * No change
> > ---
> > arch/arm/configs/shmobile_defconfig | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/configs/shmobile_defconfig
> > b/arch/arm/configs/shmobile_defconfig
> > index c6c7035..ab416a5 100644
> > --- a/arch/arm/configs/shmobile_defconfig
> > +++ b/arch/arm/configs/shmobile_defconfig
> > @@ -66,6 +66,7 @@ CONFIG_INPUT_EVDEV=y
> > CONFIG_KEYBOARD_GPIO=y
> > # CONFIG_INPUT_MOUSE is not set
> > CONFIG_INPUT_TOUCHSCREEN=y
> > +CONFIG_TOUCHSCREEN_EDT_FT5X06=y
>
> Do these options need to be built-in, or could modules work too ?
All Renesas-specific config options in shmobile_defconfig are builtin,
unlike in multi_v7_defconfig and arm64_defconfig.
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 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c
On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote: > On Thu, 7 Nov 2019 16:02:59 -0500 > Sean Paul wrote: > > > From: Sean Paul > > > > Hey all, > > I'm back with another trace events patchset. My first attempt [1] went > > better than expected, with enthusiasm for the idea and distain for the > > implementation. > > > > As promised, I went through and added proper trace events. > > > > Before I get _too_ far, I wanted to post this set to get feedback on the > > direction I'm going. I've gone back and forth on whether to introduce a > > bunch of trace systems vs using the trace class enum. I've settled on > > the trace class enum since it seems more extensible and easier to use in > > production that just having the blunt "enable this system", or > > the tedious "enable each event I'm interested in individually" methods. > > > > So, consider this one an RFC unless we're all in agreement, in which > > case we should apply it :) > > > > Hi Sean, > > thanks for working on this. I'm not at all familiar with the trace > infrastructure, so I'd like to know how flight recorder type of > behaviour (a continuously written fixed size ring buffer) can be > achieved. Let us have a display server in userspace which in production > hits an unexpected condition with DRM and needs to record information > for post-mortem debugging. What should it do to have a trace log after > the fact to attach with a bug report? Yeah I think this has the uapi smell, so would need the userspace side too, once we agree on something. > I assume that is a major use case for this new feature. Is performance > profiling another use case? > > Is it ok to build userspace to rely on these trace events during normal > operations, e.g. for continuous adjustment of timings/timers? Yeah I'm kinda freaked out about this. In the old thread we discussed the question of whether dumping dmesg into tracepoints would make them uapi, but no conclusion was reached. Now instead we're going to duplicate a lot of these debug outputs, with specific trace events, which is going to make them even more uapi. And a lot of these are very much implementation details (drivers might change their opinion on which other states they need for check/commit, e.g. if they move a bunch of global state from crtcs into a new driver private internal object). Explicit tracepoints with symbol value imo will have a much higher chance that someone starts relying on them. Also, dmesg is uapi too. Except there's a gentlemen's agreement that you should depend upon it because it will make kernel engineers really pissed if they can't change/move a specific string. So from that point I think just dumping the existing debug strings as unstructured strings into trace buffers is a much better idea. Plus no need to have the same information duplicated in both a debug output and a tracepoint. I think even slightly structured debug tracepoints (e.g. a simple (drm_object_id, string) pair) would be too structured since then userspace could start watching for events on specific things and maybe use that for their retry loops after TEST_ONLY failures. Even though we have a lot of debug output strings where that bit of structure is essentially there already. Aside from this a question on process ... I re-read the old thread and I'm not sure how you concluded we've reached consensus on this here, seemed all pretty inconclusive on the details and discussions died out? -Daniel > > > Thanks, > pq > > > > > > [1]- https://patchwork.freedesktop.org/patch/335350/ > > > > Sean Paul (6): > > drm: trace: Make the vblank queued/delivered events classed > > drm: trace: Introduce drm_trace() and trace event classes > > drm: trace: Add trace events for atomic state lifetime > > drm: trace: Add crtc state trace events > > drm: trace: Add connector state tracing > > drm: trace: Add plane state tracing > > > > Documentation/gpu/drm-internals.rst | 9 + > > drivers/gpu/drm/drm_atomic.c| 61 ++- > > drivers/gpu/drm/drm_trace.h | 563 ++-- > > drivers/gpu/drm/drm_vblank.c| 8 +- > > 4 files changed, 609 insertions(+), 32 deletions(-) > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c
On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote: > Is it ok to build userspace to rely on these trace events during normal > operations, e.g. for continuous adjustment of timings/timers? Aside discussion on this: If we add this (I think userspace might want some information about the point of no return and why we missed it) then I think we should expose that with an improved drm_event and clear semantics. If we start to encourage compositors to use tracepoints to figure out why the kernel doesn't behave (TEST_ONLY failure, or missed flip target), and use that for behaviour, we've baked implementation details into the uapi. And then we're screwed. So if you have any need for timing information that you see solved with a tracepoint, pls bring this up so we can add proper uapi. And yes I know that if someone doesn't we still need to keep that tracepoint working, but with all things uapi the question isn't whether we'll screw up (we will), but how often. And less often is massively better :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c
On Fri, Nov 08, 2019 at 09:46:48AM +0100, Daniel Vetter wrote: > On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote: > > On Thu, 7 Nov 2019 16:02:59 -0500 > > Sean Paul wrote: > > > > > From: Sean Paul > > > > > > Hey all, > > > I'm back with another trace events patchset. My first attempt [1] went > > > better than expected, with enthusiasm for the idea and distain for the > > > implementation. > > > > > > As promised, I went through and added proper trace events. > > > > > > Before I get _too_ far, I wanted to post this set to get feedback on the > > > direction I'm going. I've gone back and forth on whether to introduce a > > > bunch of trace systems vs using the trace class enum. I've settled on > > > the trace class enum since it seems more extensible and easier to use in > > > production that just having the blunt "enable this system", or > > > the tedious "enable each event I'm interested in individually" methods. > > > > > > So, consider this one an RFC unless we're all in agreement, in which > > > case we should apply it :) > > > > > > > Hi Sean, > > > > thanks for working on this. I'm not at all familiar with the trace > > infrastructure, so I'd like to know how flight recorder type of > > behaviour (a continuously written fixed size ring buffer) can be > > achieved. Let us have a display server in userspace which in production > > hits an unexpected condition with DRM and needs to record information > > for post-mortem debugging. What should it do to have a trace log after > > the fact to attach with a bug report? > > Yeah I think this has the uapi smell, so would need the userspace side > too, once we agree on something. > > > I assume that is a major use case for this new feature. Is performance > > profiling another use case? > > > > Is it ok to build userspace to rely on these trace events during normal > > operations, e.g. for continuous adjustment of timings/timers? > > Yeah I'm kinda freaked out about this. In the old thread we discussed the > question of whether dumping dmesg into tracepoints would make them uapi, > but no conclusion was reached. > > Now instead we're going to duplicate a lot of these debug outputs, with > specific trace events, which is going to make them even more uapi. And a > lot of these are very much implementation details (drivers might change > their opinion on which other states they need for check/commit, e.g. if > they move a bunch of global state from crtcs into a new driver private > internal object). Explicit tracepoints with symbol value imo will have a > much higher chance that someone starts relying on them. > > Also, dmesg is uapi too. Except there's a gentlemen's agreement that you > should depend upon it because it will make kernel engineers really pissed > if they can't change/move a specific string. So from that point I think > just dumping the existing debug strings as unstructured strings into trace > buffers is a much better idea. Plus no need to have the same information > duplicated in both a debug output and a tracepoint. > > I think even slightly structured debug tracepoints (e.g. a simple > (drm_object_id, string) pair) would be too structured since then userspace > could start watching for events on specific things and maybe use that for > their retry loops after TEST_ONLY failures. Even though we have a lot of > debug output strings where that bit of structure is essentially there > already. > > Aside from this a question on process ... I re-read the old thread and I'm > not sure how you concluded we've reached consensus on this here, seemed > all pretty inconclusive on the details and discussions died out? Reading the thread again I guess it was Joonas comment that tracepoints are also uapi, and you concluded we can't do this at all. The trouble is, _everything_ that's observeable from userspace is uapi. So dmesg, timing of the code, ... For a real funky example of this look at the ext4 regression, where better code resulted in less entropy generated and the system hung at boot-up. But on the flip side, it's only uapi we can't change if someone depends upon it. For dmesg most people understand that parsing dmesg is bad taste, so generally not a big problem. For tracepoints, especially if they come with lots of structured uapi, it's a lot more "this is baked in forever". But it doesn't have to be, with changed them quite a few times. But as a rule of thumb, the more structured the data is you present to userspace, the more likely they'll use it in actual control flow, and the more likely a change will break userspace in a meaningful way. Hence for debugging I think least amount of structure is best, plus huge warnings that you really shouldn't use this for anything else than debug logs. Anything more that leaks all these implementation details gives me the chillies. And Pekka's question right off the bat with "can I use this for tuning timers" kinda proves my point. If it loosk like intentional uapi usersp
Re: [PATCH 1/2] drm/i915: change to_mock() to an inline function
Quoting Masahiro Yamada (2019-11-08 05:13:55) > Since this function is defined in a header file, it should be > 'static inline' instead of 'static'. > > Signed-off-by: Masahiro Yamada Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
Hi Fabrizio,
On Mon, Nov 4, 2019 at 11:42 AM Fabrizio Castro
wrote:
> > From: Neil Armstrong
> > Sent: 04 November 2019 09:18
> > Subject: Re: [PATCH 1/4] drm/bridge: Repurpose lvds-encoder.c
> >
> > On 30/10/2019 14:43, Fabrizio Castro wrote:
> > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > not just LVDS encoders.
> > > Instead of creating a new driver for addressing support for
> > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > good.
> > >
> > > Signed-off-by: Fabrizio Castro
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > drivers/gpu/drm/bridge/lvds-codec.c | 169
> > > ++
> > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > ---
> > > 4 files changed, 174 insertions(+), 160 deletions(-)
> > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 3436297..9e75ca4e 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > >
> > > -config DRM_LVDS_ENCODER
> > > - tristate "Transparent parallel to LVDS encoder support"
> > > +config DRM_LVDS_CODEC
> >
> >
> > I'm not CCed on other patches, but I'm pretty sure you should fix other
> > Kconfig and defconfigs selecting this config in this patch to avoid
> > breaking bisect.
>
> My understanding is that no defconfig and no other option refer directly to
> DRM_LVDS_ENCODER, do you mind being a little bit more specific here?
Sidenote: it looks like CONFIG_DRM_LVDS_ENCODER should have been enabled
in shmobile_defconfig since commits 381ddfe478871588 ("drm: rcar-du:
Hardcode encoders types to DRM_MODE_ENCODER_NONE") and 7160d57b6f81185c
("drm: bridge: lvds-encoder: Add thine,thc63lvdm83d compatible string"),
to support thine,thc63lvdm83d in arch/arm/boot/dts/r8a7779-marzen.dts?
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 0/7][rebased] Add anx6345 DP/eDP bridge for Olimex Teres-I
On Mon, Nov 04, 2019 at 11:34:23AM +0100, Torsten Duwe wrote: > On Wed, Nov 06, 2019 at 04:21:31PM +0100, Maxime Ripard wrote: > > > > Please resend the whole series rebased on top of either linux-next or > > drm-misc-next. > > Here it is. Applies cleanly to both, modulo those patches already in. applied, thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hello,
On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> Hello Laurent,
>
> Thank you for your feedback!
>
> > From: devicetree-ow...@vger.kernel.org
> > On Behalf Of Laurent Pinchart
> > Sent: 07 November 2019 20:35
> > Subject: Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
> >
> > Hi Fabrizio,
> >
> > Thank you for the patch.
> >
> > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > not just LVDS encoders.
> > > Instead of creating a new driver for addressing support for
> > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > good.
> > >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v2->v3:
> > > * No change
> > > v1->v2:
> > > * No change
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > --
> > > 4 files changed, 136 insertions(+), 160 deletions(-)
> >
> > It would help if you added the -M1 option to git-format-patch to detect
> > the rename, the result would be easier to review.
>
> Will do, thank you for the hint
>
> >
> > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 3436297..9e75ca4e 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > >
> > > -config DRM_LVDS_ENCODER
> > > - tristate "Transparent parallel to LVDS encoder support"
> > > +config DRM_LVDS_CODEC
> > > + tristate "Transparent LVDS encoders and decoders support"
> > > depends on OF
> > > select DRM_KMS_HELPER
> > > select DRM_PANEL_BRIDGE
> > > help
> > > - Support for transparent parallel to LVDS encoders that don't require
> > > - any configuration.
> > > + Support for transparent LVDS encoders and LVDS decoders that don't
> > > + require any configuration.
> > >
> > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 4934fcf..8a9178a 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -2,7 +2,7 @@
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > megachips-stdp-ge-b850v3-fw.o
> > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > new file mode 100644
> > > index 000..d57a8eb
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > @@ -0,0 +1,131 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > + * Copyright (C) 2016 Laurent Pinchart
> > >
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct lvds_codec {
> > > + struct drm_bridge bridge;
> > > + struct drm_bridge *panel_bridge;
> > > + struct gpio_desc *powerdown_gpio;
> > > +};
> > > +
> > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > > + bridge);
> > > +}
> > > +
> > > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > > +}
> > > +
> > > +static void lvds_codec_disable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > +
[Bug 110580] [CI][BAT] igt@.* - skip - Chamelium ports not enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110580 --- Comment #62 from Lakshmi --- *** Bug 112232 has been marked as a duplicate of this bug. *** -- 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: [PATCHv2 1/4] drm/arm: Factor out generic afbc helpers
Hi Daniel,
On Thu, Nov 07, 2019 at 08:28:08PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:49:14PM +, Brian Starkey wrote:
> > Hi Daniel,
> >
> > On Thu, Nov 07, 2019 at 06:32:01PM +0100, Daniel Vetter wrote:
> > > On Thu, Nov 7, 2019 at 6:20 PM Brian Starkey
> > > wrote:
> > > >
> > > > Hi Daniel,
> > > >
> > > > On Tue, Nov 05, 2019 at 11:26:36PM +, Daniel Stone wrote:
> > > > > 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)
> > > >
> > > > Well, sort of.
> > > >
> > > > I agree with you that for horizontal padding, we can indeed use pitch.
> > > >
> > > > However, the AFBC decoder(s) need to know exactly what the total
> > > > _allocated_ size in pixels of the buffer is - as this influences the
> > > > header size, and we need to know the header size to know where it ends
> > > > and the body begins.
> > > >
> > > > I see a couple of possible ways forwards:
> > > >
> > > > - Keep it as-is. The restrictive checks ensure that there's no
> > > >ambiguity and we use the fb width/height to determine the real
> > > >allocated width/height. Userspace needs to be AFBC-aware and set up
> > > >plane cropping to handle the alignment differences.
> > > >
> > > > - Use pitch to determine the "real" width, and internally in the
> > > >kernel align height up to the next alignment boundary. This works
> > > >OK, so long as there's no additional padding at the bottom of the
> > > >buffer. This would work, but I can't figure a way to check/enforce
> > > >that there's no additional padding at the bottom.
> > > >
> > > > - Something else...
> > > >
> > > > The checks as-implemented were deliberately conservative, and don't
> > > > preclude doing some relaxation in the future.
> > > >
> > > > On Android, gralloc is used to store the "real" allocated width/height
> > > > and this is used to set up the DRM API appropriately.
> > >
> > > Fake stride + real visible h/w in the drmfb. Because that's how it
> > > works with all the tiled formats already, and expecting userspace to
> > > fudge this all correctly seems very backwards to me. In a way we had
> > > that entire fake stride discussion already for the block size format
> > > stuff already, but now in a different flavour.
> >
> > Fake stride - like I said, no problem; sounds good. That solves one
> > dimension.
> >
> > So do you have a proposal for how we determine what the allocated
> > height is in that case? I don't really see a way.
>
> Could you compute the height by looking at the buffer size? Or does that
> not help since the header stuff is generally rather small?
I've wondered about that. We might be able to use it heuristically,
but it does place certain assumptions on the allocator - for instance
rounding up
Re: [PATCH v2] drm/i915: make more headers self-contained
Quoting Masahiro Yamada (2019-11-08 09:41:42) > The headers in the gem/selftests/, gt/selftests, gvt/, selftests/ > directories have never been compile-tested, but it would be possible > to make them self-contained. > > This commit only addresses missing and forward > struct declarations. > > Signed-off-by: Masahiro Yamada Thanks a lot for doing this, Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205393] [amdgpu powerplay] vega10: custom pp_table, AVFS accidentally reenabled after display powersave
https://bugzilla.kernel.org/show_bug.cgi?id=205393 --- Comment #9 from har...@gmx.de --- (In reply to tempel.julian from comment #7) > Is this really only relevant for Vega 10? > Also on Polaris voltage is reset to default when using a customized > powerplay table e.g. after a modeline switch (happens when closing Sway > session with ctr + shift + e). I don't have a polaris card for debugging, but looking at the code, i think that a similar bug could be relevant too. Vega10 is smu9, while Polaris is smu7, but both firmwares generally support AVFS and enabling/disabling this feature. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205393] [amdgpu powerplay] vega10: custom pp_table, AVFS accidentally reenabled after display powersave
https://bugzilla.kernel.org/show_bug.cgi?id=205393 --- Comment #10 from tempel.jul...@gmail.com --- I'd try out patches if you want. :) Though it's probably not really important, as the regular overdrive functionality works fine with Polaris. Much more important would be situation for Navi, as regular overdrive doesn't work with it yet and one is dependent on the powerplay table method: https://bugs.freedesktop.org/show_bug.cgi?id=111762 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/7] dt-bindings: display: bridge: Convert lvds-transmitter binding to json-schema
Hi Fabrizio,
On Fri, Nov 08, 2019 at 09:15:02AM +, Fabrizio Castro wrote:
> On 07 November 2019 20:21 Laurent Pinchart wrote:
> > On Thu, Nov 07, 2019 at 08:10:57PM +, Fabrizio Castro wrote:
> > > Convert the lvds-transmitter binding to DT schema format using
> > > json-schema.
> > >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v2->v3:
> > > * Extracted conversion to dt-schema as per Rob's comment
> > > v1->v2:
> > > * Converted to dt-schema as per Neil's comment
> > > ---
> > > .../bindings/display/bridge/lvds-transmitter.txt | 66
> > > .../bindings/display/bridge/lvds-transmitter.yaml | 91
> > > ++
> > > 2 files changed, 91 insertions(+), 66 deletions(-)
> > > delete mode 100644
> > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > > deleted file mode 100644
> > > index 60091db..000
> > > ---
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> > > +++ /dev/null
> > > @@ -1,66 +0,0 @@
> > > -Parallel to LVDS Encoder
> > > -
> > > -
> > > -This binding supports the parallel to LVDS encoders 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.
> > > -
> > > -
> > > -Required properties:
> > > -
> > > -- compatible: Must be "lvds-encoder"
> > > -
> > > - Any encoder compatible with this generic binding, but with additional
> > > - properties not listed here, must list a device specific compatible
> > > first
> > > - followed by this generic compatible.
> > > -
> > > -Required nodes:
> > > -
> > > -This device has two video ports. Their connections are modeled using the
> > > OF
> > > -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > > -
> > > -- Video port 0 for parallel input
> > > -- Video port 1 for LVDS output
> > > -
> > > -
> > > -Example
> > >
> > > -
> > > -lvds-encoder {
> > > - compatible = "lvds-encoder";
> > > -
> > > - ports {
> > > - #address-cells = <1>;
> > > - #size-cells = <0>;
> > > -
> > > - port@0 {
> > > - reg = <0>;
> > > -
> > > - lvds_enc_in: endpoint {
> > > - remote-endpoint = <&display_out_rgb>;
> > > - };
> > > - };
> > > -
> > > - port@1 {
> > > - reg = <1>;
> > > -
> > > - lvds_enc_out: endpoint {
> > > - remote-endpoint = <&lvds_panel_in>;
> > > - };
> > > - };
> > > - };
> > > -};
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > > new file mode 100644
> > > index 000..5be163a
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.yaml
> > > @@ -0,0 +1,91 @@
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/bridge/lvds-transmitter.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Parallel to LVDS Encoder
> > > +
> > > +maintainers:
> > > + - Laurent Pinchart
> > > +
> > > +description: |
> > > + This binding supports the parallel to LVDS encoders 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
> > > (JE
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hi Fabrizio,
On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> On 07 November 2019 20:35 Laurent Pinchart wrote:
> > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > not just LVDS encoders.
> > > Instead of creating a new driver for addressing support for
> > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > good.
> > >
> > > Signed-off-by: Fabrizio Castro
> > >
> > > ---
> > > v2->v3:
> > > * No change
> > > v1->v2:
> > > * No change
> > > ---
> > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > --
> > > 4 files changed, 136 insertions(+), 160 deletions(-)
> >
> > It would help if you added the -M1 option to git-format-patch to detect
> > the rename, the result would be easier to review.
>
> Will do, thank you for the hint
>
> > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > >
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 3436297..9e75ca4e 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > Support for non-programmable RGB to VGA DAC bridges, such as ADI
> > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder DACs.
> > >
> > > -config DRM_LVDS_ENCODER
> > > - tristate "Transparent parallel to LVDS encoder support"
> > > +config DRM_LVDS_CODEC
> > > + tristate "Transparent LVDS encoders and decoders support"
> > > depends on OF
> > > select DRM_KMS_HELPER
> > > select DRM_PANEL_BRIDGE
> > > help
> > > - Support for transparent parallel to LVDS encoders that don't require
> > > - any configuration.
> > > + Support for transparent LVDS encoders and LVDS decoders that don't
> > > + require any configuration.
> > >
> > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > tristate "MegaChips stdp4028-ge-b850v3-fw and stdp2690-ge-b850v3-fw"
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 4934fcf..8a9178a 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -2,7 +2,7 @@
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > megachips-stdp-ge-b850v3-fw.o
> > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > new file mode 100644
> > > index 000..d57a8eb
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > @@ -0,0 +1,131 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > + * Copyright (C) 2016 Laurent Pinchart
> > >
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +
> > > +struct lvds_codec {
> > > + struct drm_bridge bridge;
> > > + struct drm_bridge *panel_bridge;
> > > + struct gpio_desc *powerdown_gpio;
> > > +};
> > > +
> > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + return drm_bridge_attach(bridge->encoder, lvds_codec->panel_bridge,
> > > + bridge);
> > > +}
> > > +
> > > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > > +}
> > > +
> > > +static void lvds_codec_disable(struct drm_bridge *bridge)
> > > +{
> > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > + struct lvds_codec, bridge);
> > > +
> > > + if (lvds_codec->powerdown_gpio)
> > > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 1);
> > > +}
> > > +
> > > +static struct drm_bridge_funcs funcs = {
> > > + .attach = lvds_codec_attach,
> > > + .enable = lvds_codec_enable,
> > > + .disable = lvds_codec_d
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hello Jacopo,
On Fri, Nov 08, 2019 at 10:39:27AM +0100, Jacopo Mondi wrote:
> On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> > On 07 November 2019 20:35 Laurent Pinchart wrote:
> > > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > > not just LVDS encoders.
> > > > Instead of creating a new driver for addressing support for
> > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > > good.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > >
> > > > ---
> > > > v2->v3:
> > > > * No change
> > > > v1->v2:
> > > > * No change
> > > > ---
> > > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > >
> > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > > --
> > > > 4 files changed, 136 insertions(+), 160 deletions(-)
> > >
> > > It would help if you added the -M1 option to git-format-patch to detect
> > > the rename, the result would be easier to review.
> >
> > Will do, thank you for the hint
> >
> > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > index 3436297..9e75ca4e 100644
> > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > > Support for non-programmable RGB to VGA DAC bridges, such as
> > > > ADI
> > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder
> > > > DACs.
> > > >
> > > > -config DRM_LVDS_ENCODER
> > > > - tristate "Transparent parallel to LVDS encoder support"
> > > > +config DRM_LVDS_CODEC
> > > > + tristate "Transparent LVDS encoders and decoders support"
> > > > depends on OF
> > > > select DRM_KMS_HELPER
> > > > select DRM_PANEL_BRIDGE
> > > > help
> > > > - Support for transparent parallel to LVDS encoders that don't
> > > > require
> > > > - any configuration.
> > > > + Support for transparent LVDS encoders and LVDS decoders that
> > > > don't
> > > > + require any configuration.
> > > >
> > > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > > tristate "MegaChips stdp4028-ge-b850v3-fw and
> > > > stdp2690-ge-b850v3-fw"
> > > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > > b/drivers/gpu/drm/bridge/Makefile
> > > > index 4934fcf..8a9178a 100644
> > > > --- a/drivers/gpu/drm/bridge/Makefile
> > > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > > @@ -2,7 +2,7 @@
> > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > > megachips-stdp-ge-b850v3-fw.o
> > > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > new file mode 100644
> > > > index 000..d57a8eb
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > @@ -0,0 +1,131 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +/*
> > > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > > + * Copyright (C) 2016 Laurent Pinchart
> > > >
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include
> > > > +#include
> > > > +
> > > > +struct lvds_codec {
> > > > + struct drm_bridge bridge;
> > > > + struct drm_bridge *panel_bridge;
> > > > + struct gpio_desc *powerdown_gpio;
> > > > +};
> > > > +
> > > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > +{
> > > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > > +struct lvds_codec,
> > > > bridge);
> > > > +
> > > > + return drm_bridge_attach(bridge->encoder,
> > > > lvds_codec->panel_bridge,
> > > > +bridge);
> > > > +}
> > > > +
> > > > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > > > +{
> > > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > > +struct lvds_codec,
> > > > bridge);
> > > > +
> > > > + if (lvds_codec->powerdown_gpio)
> > > > + gpiod_set_value_cansleep(lvds_codec->powerdown_gpio, 0);
> > >
Re: [PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
Greg, have you taken this one by any chance?
> ---
> drivers/power/avs/smartreflex.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
> index 4684e7df833a81e9..5376f3d22f31eade 100644
> --- a/drivers/power/avs/smartreflex.c
> +++ b/drivers/power/avs/smartreflex.c
> @@ -905,7 +905,7 @@ static int omap_sr_probe(struct platform_device *pdev)
> sr_info->dbg_dir = debugfs_create_dir(sr_info->name, sr_dbg_dir);
>
> debugfs_create_file("autocomp", S_IRUGO | S_IWUSR, sr_info->dbg_dir,
> - (void *)sr_info, &pm_sr_fops);
> + sr_info, &pm_sr_fops);
> debugfs_create_x32("errweight", S_IRUGO, sr_info->dbg_dir,
> &sr_info->err_weight);
> debugfs_create_x32("errmaxlimit", S_IRUGO, sr_info->dbg_dir,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hi Laurent,
On Fri, Nov 08, 2019 at 01:06:58PM +0200, Laurent Pinchart wrote:
> Hello Jacopo,
>
> On Fri, Nov 08, 2019 at 10:39:27AM +0100, Jacopo Mondi wrote:
> > On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> > > On 07 November 2019 20:35 Laurent Pinchart wrote:
> > > > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > > > not just LVDS encoders.
> > > > > Instead of creating a new driver for addressing support for
> > > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > > > good.
> > > > >
> > > > > Signed-off-by: Fabrizio Castro
> > > > >
> > > > > ---
> > > > > v2->v3:
> > > > > * No change
> > > > > v1->v2:
> > > > > * No change
> > > > > ---
> > > > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > > >
> > > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > > > --
> > > > > 4 files changed, 136 insertions(+), 160 deletions(-)
> > > >
> > > > It would help if you added the -M1 option to git-format-patch to detect
> > > > the rename, the result would be easier to review.
> > >
> > > Will do, thank you for the hint
> > >
> > > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > > > >
> > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > > index 3436297..9e75ca4e 100644
> > > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > > > Support for non-programmable RGB to VGA DAC bridges, such as
> > > > > ADI
> > > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder
> > > > > DACs.
> > > > >
> > > > > -config DRM_LVDS_ENCODER
> > > > > - tristate "Transparent parallel to LVDS encoder support"
> > > > > +config DRM_LVDS_CODEC
> > > > > + tristate "Transparent LVDS encoders and decoders support"
> > > > > depends on OF
> > > > > select DRM_KMS_HELPER
> > > > > select DRM_PANEL_BRIDGE
> > > > > help
> > > > > - Support for transparent parallel to LVDS encoders that don't
> > > > > require
> > > > > - any configuration.
> > > > > + Support for transparent LVDS encoders and LVDS decoders that
> > > > > don't
> > > > > + require any configuration.
> > > > >
> > > > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > > > tristate "MegaChips stdp4028-ge-b850v3-fw and
> > > > > stdp2690-ge-b850v3-fw"
> > > > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > > > b/drivers/gpu/drm/bridge/Makefile
> > > > > index 4934fcf..8a9178a 100644
> > > > > --- a/drivers/gpu/drm/bridge/Makefile
> > > > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > > > @@ -2,7 +2,7 @@
> > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > > > megachips-stdp-ge-b850v3-fw.o
> > > > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > new file mode 100644
> > > > > index 000..d57a8eb
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > @@ -0,0 +1,131 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +/*
> > > > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > > > + * Copyright (C) 2016 Laurent Pinchart
> > > > >
> > > > > + */
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +struct lvds_codec {
> > > > > + struct drm_bridge bridge;
> > > > > + struct drm_bridge *panel_bridge;
> > > > > + struct gpio_desc *powerdown_gpio;
> > > > > +};
> > > > > +
> > > > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > > +{
> > > > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > > > + struct lvds_codec,
> > > > > bridge);
> > > > > +
> > > > > + return drm_bridge_attach(bridge->encoder,
> > > > > lvds_codec->panel_bridge,
> > > > > + bridge);
> > > > > +}
> > > > > +
> > > > > +static void lvds_codec_enable(struct drm_bridge *bridge)
> > > > > +{
> > > > > + struct lvds
Re: [PATCH 4/5] power: avs: smartreflex: Remove superfluous cast in debugfs_create_file() call
On Fri, Nov 08, 2019 at 12:24:42PM +0100, Rafael J. Wysocki wrote: > On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote: > > There is no need to cast a typed pointer to a void pointer when calling > > a function that accepts the latter. Remove it, as the cast prevents > > further compiler checks. > > > > Signed-off-by: Geert Uytterhoeven > > Greg, have you taken this one by any chance? Nope, it's all yours! :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 085/205] qxl: fix null-pointer crash during suspend
From: Peter Wu
[ Upstream commit 7948a2b15873319d1bff4d37c09b9f2bf87b9021 ]
"crtc->helper_private" is not initialized by the QXL driver and thus the
"crtc_funcs->disable" call would crash (resulting in suspend failure).
Fix this by converting the suspend/resume functions to use the
drm_mode_config_helper_* helpers.
Tested system sleep with QEMU 3.0 using "echo mem > /sys/power/state".
During suspend the following message is visible from QEMU:
spice/server/display-channel.c:2425:display_channel_validate_surface:
canvas address is 0x7fd05da68308 for 0 (and is NULL)
spice/server/display-channel.c:2426:display_channel_validate_surface:
failed on 0
This seems to be triggered by QXL_IO_NOTIFY_CMD after
QXL_IO_DESTROY_PRIMARY_ASYNC, but aside from the warning things still
seem to work (tested with both the GTK and -spice options).
Signed-off-by: Peter Wu
Link:
http://patchwork.freedesktop.org/patch/msgid/20180904202747.14968-1-pe...@lekensteyn.nl
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/qxl/qxl_drv.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 2445e75cf7ea6..d00f45eed03ca 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -136,20 +136,11 @@ static int qxl_drm_freeze(struct drm_device *dev)
{
struct pci_dev *pdev = dev->pdev;
struct qxl_device *qdev = dev->dev_private;
- struct drm_crtc *crtc;
-
- drm_kms_helper_poll_disable(dev);
-
- console_lock();
- qxl_fbdev_set_suspend(qdev, 1);
- console_unlock();
+ int ret;
- /* unpin the front buffers */
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
- const struct drm_crtc_helper_funcs *crtc_funcs =
crtc->helper_private;
- if (crtc->enabled)
- (*crtc_funcs->disable)(crtc);
- }
+ ret = drm_mode_config_helper_suspend(dev);
+ if (ret)
+ return ret;
qxl_destroy_monitors_object(qdev);
qxl_surf_evict(qdev);
@@ -175,14 +166,7 @@ static int qxl_drm_resume(struct drm_device *dev, bool
thaw)
}
qxl_create_monitors_object(qdev);
- drm_helper_resume_force_mode(dev);
-
- console_lock();
- qxl_fbdev_set_suspend(qdev, 0);
- console_unlock();
-
- drm_kms_helper_poll_enable(dev);
- return 0;
+ return drm_mode_config_helper_resume(dev);
}
static int qxl_pm_suspend(struct device *dev)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] drm/bridge: Repurpose lvds-encoder.c
Hi Jacopo,
On Fri, Nov 08, 2019 at 12:37:37PM +0100, Jacopo Mondi wrote:
> On Fri, Nov 08, 2019 at 01:06:58PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 08, 2019 at 10:39:27AM +0100, Jacopo Mondi wrote:
> > > On Fri, Nov 08, 2019 at 09:22:56AM +, Fabrizio Castro wrote:
> > > > On 07 November 2019 20:35 Laurent Pinchart wrote:
> > > > > On Thu, Nov 07, 2019 at 08:10:58PM +, Fabrizio Castro wrote:
> > > > > > lvds-encoder.c implementation is also suitable for LVDS decoders,
> > > > > > not just LVDS encoders.
> > > > > > Instead of creating a new driver for addressing support for
> > > > > > transparent LVDS decoders, repurpose lvds-encoder.c for the greater
> > > > > > good.
> > > > > >
> > > > > > Signed-off-by: Fabrizio Castro
> > > > > >
> > > > > > ---
> > > > > > v2->v3:
> > > > > > * No change
> > > > > > v1->v2:
> > > > > > * No change
> > > > > > ---
> > > > > > drivers/gpu/drm/bridge/Kconfig| 8 +-
> > > > > > drivers/gpu/drm/bridge/Makefile | 2 +-
> > > > > > drivers/gpu/drm/bridge/lvds-codec.c | 131
> > > > > >
> > > > > > drivers/gpu/drm/bridge/lvds-encoder.c | 155
> > > > > > --
> > > > > > 4 files changed, 136 insertions(+), 160 deletions(-)
> > > > >
> > > > > It would help if you added the -M1 option to git-format-patch to
> > > > > detect
> > > > > the rename, the result would be easier to review.
> > > >
> > > > Will do, thank you for the hint
> > > >
> > > > > > create mode 100644 drivers/gpu/drm/bridge/lvds-codec.c
> > > > > > delete mode 100644 drivers/gpu/drm/bridge/lvds-encoder.c
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > > > > b/drivers/gpu/drm/bridge/Kconfig
> > > > > > index 3436297..9e75ca4e 100644
> > > > > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > > > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > > > > @@ -45,14 +45,14 @@ config DRM_DUMB_VGA_DAC
> > > > > > Support for non-programmable RGB to VGA DAC bridges, such as
> > > > > > ADI
> > > > > > ADV7123, TI THS8134 and THS8135 or passive resistor ladder
> > > > > > DACs.
> > > > > >
> > > > > > -config DRM_LVDS_ENCODER
> > > > > > - tristate "Transparent parallel to LVDS encoder support"
> > > > > > +config DRM_LVDS_CODEC
> > > > > > + tristate "Transparent LVDS encoders and decoders support"
> > > > > > depends on OF
> > > > > > select DRM_KMS_HELPER
> > > > > > select DRM_PANEL_BRIDGE
> > > > > > help
> > > > > > - Support for transparent parallel to LVDS encoders that don't
> > > > > > require
> > > > > > - any configuration.
> > > > > > + Support for transparent LVDS encoders and LVDS decoders that
> > > > > > don't
> > > > > > + require any configuration.
> > > > > >
> > > > > > config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> > > > > > tristate "MegaChips stdp4028-ge-b850v3-fw and
> > > > > > stdp2690-ge-b850v3-fw"
> > > > > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > > > > b/drivers/gpu/drm/bridge/Makefile
> > > > > > index 4934fcf..8a9178a 100644
> > > > > > --- a/drivers/gpu/drm/bridge/Makefile
> > > > > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > > > > @@ -2,7 +2,7 @@
> > > > > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > > > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > > > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > > > > -obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > > > > +obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > > > > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > > > > megachips-stdp-ge-b850v3-fw.o
> > > > > > obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> > > > > > obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> > > > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > > new file mode 100644
> > > > > > index 000..d57a8eb
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > > > @@ -0,0 +1,131 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > > > +/*
> > > > > > + * Copyright (C) 2019 Renesas Electronics Corporation
> > > > > > + * Copyright (C) 2016 Laurent Pinchart
> > > > > >
> > > > > > + */
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +struct lvds_codec {
> > > > > > + struct drm_bridge bridge;
> > > > > > + struct drm_bridge *panel_bridge;
> > > > > > + struct gpio_desc *powerdown_gpio;
> > > > > > +};
> > > > > > +
> > > > > > +static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > > > +{
> > > > > > + struct lvds_codec *lvds_codec = container_of(bridge,
> > > > > > +struct lvds_codec,
> > > > > > bridge);
> > > > > > +
> > > > > > + return drm_bri
Re: [PATCH v3 0/4] drm/udl: Convert to SHMEM
Hi! 2019. 11. 08. 8:36 keltezéssel, Thomas Zimmermann írta: Hi Böszörményi FYI, it's Zoltan, as it's my first name. :-) Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán: Have you tried to increase the buffer size? There's a command-line option to control this setting. [1] Yes, I did, it didn't help. I used swiotlb=49152 (96MB) and swiotlb=65536 (128MB) vs the default 32768 (64MB). This parameter controls the _number of slab slots_ instead of a single contiguous size as I read in the kernel sources. With swiotlb=65536 I get the same error and dmesg lines: [ 97.671898] udl 2-1.2:1.0: swiotlb buffer is full (sz: 1978368 bytes), total 65536 (slots), used 28 (slots) [ 107.477068] udl 2-1.2:1.0: swiotlb buffer is full (sz: 524288 bytes), total 65536 (slots), used 584 (slots) [ 108.311947] udl 2-1.2:1.0: swiotlb buffer is full (sz: 2080768 bytes), total 65536 (slots), used 0 (slots) [ 110.330940] udl 2-1.2:1.0: swiotlb buffer is full (sz: 3031040 bytes), total 65536 (slots), used 56 (slots) [ 111.102755] udl 2-1.2:1.0: swiotlb buffer is full (sz: 3145728 bytes), total 65536 (slots), used 1536 (slots) It turned out, it's the combination of IO_TLB_SEGSIZE * (1< Best regards, Zoltán Best regards Thomas [1] https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB [ 133.320410] udl 2-1.2:1.0: overflow 0x0001199e4000+2211840 of DMA mask bus mask 0 [ 133.320424] WARNING: CPU: 0 PID: 739 at kernel/dma/direct.c:35 report_addr+0x3e/0x70 [ 133.320425] Modules linked in: 8021q garp mrp stp llc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realt ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_hda_codec iTCO_wdt elo irqbypass iTCO_vendor_support intel_cstate snd_hda_core intel_uncore snd_hwdep intel_rapl_perf snd_pcm pcspkr i2c_i801 snd_timer e1000e snd joydev lpc_ich soundcore ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 ip6table_filter ip6_tables nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_multiport xt_conntrack iptable_nat nf_nat xt_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle i915 udl i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm cr c32_pclmul crc32c_intel serio_raw video [ 133.320463] CPU: 0 PID: 739 Comm: Xorg Not tainted 5.3.8 #1 [ 133.320465] Hardware name: TOSHIBA 4852E70/Intel H61 Express Chipset, BIOS XBKT200 01/04/2017 [ 133.320467] EIP: report_addr+0x3e/0x70 [ 133.320470] Code: 00 89 4d f8 85 d2 74 44 8b 0a 8b 5a 04 ba fe ff ff ff 39 ca ba 00 00 00 00 19 da 73 17 80 3d 9c 16 14 d0 00 0f 84 24 09 00 00 <0f> 0b 8b 5d fc c9 c3 8d 76 00 8b 90 5c 01 00 00 0b 90 58 01 00 00 [ 133.320472] EAX: EBX: ECX: f5b89e00 EDX: 0007 [ 133.320473] ESI: EDI: ecf3921c EBP: ec56bcf4 ESP: ec56bce8 [ 133.320475] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00213286 [ 133.320476] CR0: 80050033 CR2: b7236020 CR3: 2c72a000 CR4: 000406f0 [ 133.320477] Call Trace: [ 133.320484] dma_direct_map_page+0x158/0x180 [ 133.320487] dma_direct_map_sg+0x4f/0xa0 [ 133.320564] i915_gem_map_dma_buf+0x1b8/0x1d0 [i915] [ 133.320568] dma_buf_map_attachment+0x4f/0x90 [ 133.320572] udl_gem_prime_import+0x43/0x12a [udl] [ 133.320607] drm_gem_prime_fd_to_handle+0x97/0x180 [drm] [ 133.320625] ? drm_gem_prime_export+0xa0/0xa0 [drm] [ 133.320642] ? drm_gem_prime_import+0x20/0x20 [drm] [ 133.320658] ? drm_prime_handle_to_fd_ioctl+0x70/0x70 [drm] [ 133.320673] drm_prime_fd_to_handle_ioctl+0x2f/0x50 [drm] [ 133.320689] drm_ioctl_kernel+0x8f/0xd0 [drm] [ 133.320706] drm_ioctl+0x21c/0x3c0 [drm] [ 133.320721] ? drm_prime_handle_to_fd_ioctl+0x70/0x70 [drm] [ 133.320726] ? file_modified+0x30/0x30 [ 133.320728] ? file_update_time+0xfe/0x130 [ 133.320731] ? page_add_file_rmap+0x72/0xd0 [ 133.320734] ? fault_dirty_shared_page.isra.122+0x6d/0xb0 [ 133.320750] ? drm_version+0x80/0x80 [drm] [ 133.320753] do_vfs_ioctl+0x9a/0x6c0 [ 133.320757] ksys_ioctl+0x56/0x80 [ 133.320760] sys_ioctl+0x16/0x20 [ 133.320763] do_fast_syscall_32+0x82/0x1c7 [ 133.320766] entry_SYSENTER_32+0x9f/0xf2 [ 133.320768] EIP: 0xb7f84a75 [ 133.320770] Code: e8 1c 00 00 00 89 d3 eb cf 8d 74 26 00 b8 40 42 0f 00 eb b5 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 [ 133.320772] EAX: ffda EBX: 000c ECX: c00c642e EDX: bff26be0 [ 133.320773] ESI: 0221ad20 EDI: c00c642e EBP: 000c ESP: bff26b88 [ 133.320775] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00203296 [ 133.320777] ---[ end trace 18cd4f77716f2f5f ]--- With your drm-next and your patch set, the call trace is obviously different: [ 37.486584] udl 2-1.2:1.0: swiotlb buffer is full (sz: 536576 bytes), total 32768 (slots), used 1536 (slots) [ 37.486591] udl 2-1.2:1.0: overflow 0x00011a47d000+536576 of DMA mask bus mask 0 [ 37.486598] [ cut h
Re: [PATCH v3 0/4] drm/udl: Convert to SHMEM
Hi Am 08.11.19 um 13:06 schrieb Böszörményi Zoltán: > Hi! > > 2019. 11. 08. 8:36 keltezéssel, Thomas Zimmermann írta: >> Hi Böszörményi > > FYI, it's Zoltan, as it's my first name. :-) Sorry. > >> Am 07.11.19 um 16:10 schrieb Böszörményi Zoltán: >> Have you tried to increase the buffer size? There's a command-line >> option to control this setting. [1] > > Yes, I did, it didn't help. I used swiotlb=49152 (96MB) and > swiotlb=65536 (128MB) vs the default 32768 (64MB). > > This parameter controls the _number of slab slots_ instead of > a single contiguous size as I read in the kernel sources. > > With swiotlb=65536 I get the same error and dmesg lines: > > [ 97.671898] udl 2-1.2:1.0: swiotlb buffer is full (sz: 1978368 > bytes), total 65536 (slots), used 28 (slots) > [ 107.477068] udl 2-1.2:1.0: swiotlb buffer is full (sz: 524288 bytes), > total 65536 (slots), used 584 (slots) > [ 108.311947] udl 2-1.2:1.0: swiotlb buffer is full (sz: 2080768 > bytes), total 65536 (slots), used 0 (slots) > [ 110.330940] udl 2-1.2:1.0: swiotlb buffer is full (sz: 3031040 > bytes), total 65536 (slots), used 56 (slots) > [ 111.102755] udl 2-1.2:1.0: swiotlb buffer is full (sz: 3145728 > bytes), total 65536 (slots), used 1536 (slots) > > It turned out, it's the combination of IO_TLB_SEGSIZE * (1< that is too small. It is currently 128 * 2KB if I'm counting right in > binary. > > I have just tried with these settings in swiotlb.h: > > #define IO_TLB_SHIFT 12 > #define IO_TLB_SEGSIZE 1024 > > That's 4MB, used as contiguous DMA memory. The whole swiotlb aperture > is still 64MB, it's just that there is now a smaller number of larger > buffers. > > The warning messages were all about buffer sizes smaller than 4MB, > so I thought it worth a try and it indeed fixed the issue. > > Now I can reliably reconfigure the monitor's orientation attached > to UDL in relation to the monitors attached to the Intel device. Great! > > I remember having the same "swiotlb buffer is full" issue during the late > 2.6.x kernel series, around Fedora 27 or so, with the radeon driver. > > I don't know if changing the swiotlb values is the proper solution, or > to add some scatter-gather interface somewhere in UDL or PRIME or whatever. > > Now, where should I post this report? Kernel bugzilla? Or is this mail > thread enough? There's an entry with contact info for swiotlb in MAINTAINERS. > > To get back to the topic of this patchset, you can add my: > > Tested-by: Zoltán Böszörményi Thanks for testing the patchset. I push it shortly before receiving your mail, unfortunately. Best regards Thomas > > Best regards, > Zoltán > >> >> Best regards >> Thomas >> >> [1] https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB >> >> >>> [ 133.320410] udl 2-1.2:1.0: overflow 0x0001199e4000+2211840 of DMA >>> mask bus mask 0 >>> [ 133.320424] WARNING: CPU: 0 PID: 739 at kernel/dma/direct.c:35 >>> report_addr+0x3e/0x70 >>> [ 133.320425] Modules linked in: 8021q garp mrp stp llc intel_rapl_msr >>> intel_rapl_common x86_pkg_temp_thermal intel_powerclamp coretemp >>> kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realt >>> ek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_hda_codec >>> iTCO_wdt elo irqbypass iTCO_vendor_support intel_cstate snd_hda_core >>> intel_uncore snd_hwdep intel_rapl_perf snd_pcm pcspkr >>> i2c_i801 snd_timer e1000e snd joydev lpc_ich soundcore ip6t_REJECT >>> nf_reject_ipv6 nf_log_ipv6 ip6table_filter ip6_tables nf_log_ipv4 >>> nf_log_common xt_LOG xt_limit xt_multiport xt_conntrack >>> iptable_nat nf_nat xt_connmark nf_conntrack nf_defrag_ipv6 >>> nf_defrag_ipv4 libcrc32c iptable_mangle i915 udl i2c_algo_bit >>> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm cr >>> c32_pclmul crc32c_intel serio_raw video >>> [ 133.320463] CPU: 0 PID: 739 Comm: Xorg Not tainted 5.3.8 #1 >>> [ 133.320465] Hardware name: TOSHIBA 4852E70/Intel H61 Express Chipset, >>> BIOS XBKT200 01/04/2017 >>> [ 133.320467] EIP: report_addr+0x3e/0x70 >>> [ 133.320470] Code: 00 89 4d f8 85 d2 74 44 8b 0a 8b 5a 04 ba fe ff ff >>> ff 39 ca ba 00 00 00 00 19 da 73 17 80 3d 9c 16 14 d0 00 0f 84 24 09 00 >>> 00 <0f> 0b 8b 5d fc c9 c3 8d 76 00 8b 90 5c 01 00 00 0b 90 58 01 00 00 >>> [ 133.320472] EAX: EBX: ECX: f5b89e00 EDX: 0007 >>> [ 133.320473] ESI: EDI: ecf3921c EBP: ec56bcf4 ESP: ec56bce8 >>> [ 133.320475] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: >>> 00213286 >>> [ 133.320476] CR0: 80050033 CR2: b7236020 CR3: 2c72a000 CR4: 000406f0 >>> [ 133.320477] Call Trace: >>> [ 133.320484] dma_direct_map_page+0x158/0x180 >>> [ 133.320487] dma_direct_map_sg+0x4f/0xa0 >>> [ 133.320564] i915_gem_map_dma_buf+0x1b8/0x1d0 [i915] >>> [ 133.320568] dma_buf_map_attachment+0x4f/0x90 >>> [ 133.320572] udl_gem_prime_import+0x43/0x12a [udl] >>> [ 133.320607] drm_gem_prime_fd_to_handle+0x97/0x180 [drm] >>> [ 133.320625] ? drm_gem_prime_export+0xa0/0xa0 [drm] >>> [ 133.320642]
[PATCH 3/4] drm/fb-helper: Remove drm_fb_helper_unlink_fbi()
There are no callers of drm_fb_helper_unlink_fbi() left. Remove the
function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 16 +---
include/drm/drm_fb_helper.h | 6 --
2 files changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1038a2f0639e..eb97f34a15ea 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -563,8 +563,7 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
* drm_fb_helper_fini - finialize a &struct drm_fb_helper
* @fb_helper: driver-allocated fbdev helper, can be NULL
*
- * This cleans up all remaining resources associated with @fb_helper. Must be
- * called after drm_fb_helper_unlink_fbi() was called.
+ * This cleans up all remaining resources associated with @fb_helper.
*/
void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
{
@@ -604,19 +603,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_fini);
-/**
- * drm_fb_helper_unlink_fbi - wrapper around unlink_framebuffer
- * @fb_helper: driver-allocated fbdev helper, can be NULL
- *
- * A wrapper around unlink_framebuffer implemented by fbdev core
- */
-void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper)
-{
- if (fb_helper && fb_helper->fbdev)
- unlink_framebuffer(fb_helper->fbdev);
-}
-EXPORT_SYMBOL(drm_fb_helper_unlink_fbi);
-
static bool drm_fbdev_use_shadow_fb(struct drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index e3a75ff07390..1c2e0c3cf857 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -231,8 +231,6 @@ void drm_fb_helper_fill_info(struct fb_info *info,
struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes);
-void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper);
-
void drm_fb_helper_deferred_io(struct fb_info *info,
struct list_head *pagelist);
@@ -356,10 +354,6 @@ static inline int drm_fb_helper_ioctl(struct fb_info
*info, unsigned int cmd,
return 0;
}
-static inline void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper)
-{
-}
-
static inline void drm_fb_helper_deferred_io(struct fb_info *info,
struct list_head *pagelist)
{
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/udl: Remove udl implementation of GEM's free_object()
Udl used to have a custom implementation for free_object() of
struct drm_gem_object_funcs. It unmapped the memory buffer of
the fbdev emulation. With the switch to generic fbdev emulation,
this is now handled by the fbdev code internally.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_gem.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 6eade6b4b0dc..b6e26f98aa0a 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -17,22 +17,6 @@
* GEM object funcs
*/
-static void udl_gem_object_free_object(struct drm_gem_object *obj)
-{
- struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
-
- /* Fbdev emulation vmaps the buffer. Unmap it here for consistency
-* with the original udl GEM code.
-*
-* TODO: Switch to generic fbdev emulation and release the
-* GEM object with drm_gem_shmem_free_object().
-*/
- if (shmem->vaddr)
- drm_gem_shmem_vunmap(obj, shmem->vaddr);
-
- drm_gem_shmem_free_object(obj);
-}
-
static int udl_gem_object_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
@@ -91,7 +75,7 @@ static void *udl_gem_object_vmap(struct drm_gem_object *obj)
}
static const struct drm_gem_object_funcs udl_gem_object_funcs = {
- .free = udl_gem_object_free_object,
+ .free = drm_gem_shmem_free_object,
.print_info = drm_gem_shmem_print_info,
.pin = drm_gem_shmem_pin,
.unpin = drm_gem_shmem_unpin,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] fbdev: Unexport unlink_framebuffer()
There are no external callers of unlink_framebuffer() left. Make the
function an internal interface.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/core/fbmem.c | 3 +--
include/linux/fb.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 95c32952fa8a..86b06a599f96 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1673,7 +1673,7 @@ static void unbind_console(struct fb_info *fb_info)
console_unlock();
}
-void unlink_framebuffer(struct fb_info *fb_info)
+static void unlink_framebuffer(struct fb_info *fb_info)
{
int i;
@@ -1692,7 +1692,6 @@ void unlink_framebuffer(struct fb_info *fb_info)
fb_info->dev = NULL;
}
-EXPORT_SYMBOL(unlink_framebuffer);
static void do_unregister_framebuffer(struct fb_info *fb_info)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 41e0069eca0a..a6ad528990de 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -606,7 +606,6 @@ extern ssize_t fb_sys_write(struct fb_info *info, const
char __user *buf,
/* drivers/video/fbmem.c */
extern int register_framebuffer(struct fb_info *fb_info);
extern void unregister_framebuffer(struct fb_info *fb_info);
-extern void unlink_framebuffer(struct fb_info *fb_info);
extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
const char *name);
extern int remove_conflicting_framebuffers(struct apertures_struct *a,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/udl: Replace fbdev code with generic emulation
The udl driver can use the generic fbdev implementation. Convert it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.c | 4 +-
drivers/gpu/drm/udl/udl_drv.h | 5 -
drivers/gpu/drm/udl/udl_fb.c | 270 +-
drivers/gpu/drm/udl/udl_main.c| 2 -
drivers/gpu/drm/udl/udl_modeset.c | 3 +-
5 files changed, 7 insertions(+), 277 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 563cc5809e56..55c0f9dfee29 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,8 @@ static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM,
.release = udl_driver_release,
+ .lastclose = drm_fb_helper_lastclose,
+
/* gem hooks */
.gem_create_object = udl_driver_gem_create_object,
@@ -119,7 +122,6 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
struct drm_device *dev = usb_get_intfdata(interface);
drm_kms_helper_poll_disable(dev);
- udl_fbdev_unplug(dev);
udl_drop_usb(dev);
drm_dev_unplug(dev);
drm_dev_put(dev);
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 987d99ae2dfa..5bdc57779f95 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -47,8 +47,6 @@ struct urb_list {
size_t size;
};
-struct udl_fbdev;
-
struct udl_device {
struct drm_device drm;
struct device *dev;
@@ -62,7 +60,6 @@ struct udl_device {
struct urb_list urbs;
atomic_t lost_pixels; /* 1 = a render op failed. Need screen refresh */
- struct udl_fbdev *fbdev;
char mode_buf[1024];
uint32_t mode_buf_len;
atomic_t bytes_rendered; /* raw pixel-bytes driver asked to render */
@@ -98,8 +95,6 @@ int udl_init(struct udl_device *udl);
void udl_fini(struct drm_device *dev);
int udl_fbdev_init(struct drm_device *dev);
-void udl_fbdev_cleanup(struct drm_device *dev);
-void udl_fbdev_unplug(struct drm_device *dev);
struct drm_framebuffer *
udl_fb_user_fb_create(struct drm_device *dev,
struct drm_file *file,
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index f8153b726343..afe74f892a2b 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -20,19 +20,9 @@
#include "udl_drv.h"
-#define DL_DEFIO_WRITE_DELAY(HZ/20) /* fb_deferred_io.delay in jiffies */
-
-static int fb_defio = 0; /* Optionally enable experimental fb_defio mmap
support */
static int fb_bpp = 16;
module_param(fb_bpp, int, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
-module_param(fb_defio, int, S_IWUSR | S_IRUSR | S_IWGRP | S_IRGRP);
-
-struct udl_fbdev {
- struct drm_fb_helper helper; /* must be first */
- struct udl_framebuffer ufb;
- int fb_count;
-};
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
@@ -156,123 +146,6 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x,
int y,
return 0;
}
-static int udl_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
- unsigned long start = vma->vm_start;
- unsigned long size = vma->vm_end - vma->vm_start;
- unsigned long offset;
- unsigned long page, pos;
-
- if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
- return -EINVAL;
-
- offset = vma->vm_pgoff << PAGE_SHIFT;
-
- if (offset > info->fix.smem_len || size > info->fix.smem_len - offset)
- return -EINVAL;
-
- pos = (unsigned long)info->fix.smem_start + offset;
-
- pr_debug("mmap() framebuffer addr:%lu size:%lu\n",
- pos, size);
-
- /* We don't want the framebuffer to be mapped encrypted */
- vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
-
- while (size > 0) {
- page = vmalloc_to_pfn((void *)pos);
- if (remap_pfn_range(vma, start, page, PAGE_SIZE, PAGE_SHARED))
- return -EAGAIN;
-
- start += PAGE_SIZE;
- pos += PAGE_SIZE;
- if (size > PAGE_SIZE)
- size -= PAGE_SIZE;
- else
- size = 0;
- }
-
- /* VM_IO | VM_DONTEXPAND | VM_DONTDUMP are set by remap_pfn_range() */
- return 0;
-}
-
-/*
- * It's common for several clients to have framebuffer open simultaneously.
- * e.g. both fbcon and X. Makes things interesting.
- * Assumes caller is holding info->lock (for open and release at least)
- */
-static int udl_fb_open(struct fb_info *info, int user)
-{
- struct udl_fbdev *ufbdev = info->par;
- struct drm_device *dev = ufbdev->ufb.base.dev;
- struct udl_device *udl = to_udl(dev);
-
- /* If the USB device is gone, we don't accept new opens */
- if (drm_dev_is
[PATCH 0/4] drm/udl: Replace fbdev by generic emulation
The udl driver can use the generic fbdev emulation. After conversion, a number of cleanups can be applied. The fbdev conversion is in patch 1. The original fbdev code in udl mapped the framebuffer's GEM object memory unconditionally, and unmapped the memory in the object's free() function. The respective code in free() can now be removed (Patch 2). And as udl was the only remaining external user of unlink_framebuffer(), that function now becomes an internal interface of the fbdev code. The patchset has been tested by running the console, X11 and Weston on a DisplayLink adapter. Thomas Zimmermann (4): drm/udl: Replace fbdev code with generic emulation drm/udl: Remove udl implementation of GEM's free_object() drm/fb-helper: Remove drm_fb_helper_unlink_fbi() fbdev: Unexport unlink_framebuffer() drivers/gpu/drm/drm_fb_helper.c | 16 +- drivers/gpu/drm/udl/udl_drv.c | 4 +- drivers/gpu/drm/udl/udl_drv.h | 5 - drivers/gpu/drm/udl/udl_fb.c | 270 +- drivers/gpu/drm/udl/udl_gem.c | 18 +- drivers/gpu/drm/udl/udl_main.c| 2 - drivers/gpu/drm/udl/udl_modeset.c | 3 +- drivers/video/fbdev/core/fbmem.c | 3 +- include/drm/drm_fb_helper.h | 6 - include/linux/fb.h| 1 - 10 files changed, 10 insertions(+), 318 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203471] Tearing on Raven Ridge and RX560X PRIME setup even with Vsync enabled
https://bugzilla.kernel.org/show_bug.cgi?id=203471 Haxk20 (haxk...@gmail.com) changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|CODE_FIX|--- --- Comment #20 from Haxk20 (haxk...@gmail.com) --- Can we get help on this ? This is a kind of bad bug because it seems to happen in some games and in some it does not. Not only that but it started happening in video too on firefox and that is really horrible. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/panfrost: remove DRM_AUTH and respective comment
On Fri, 1 Nov 2019 at 13:34, Steven Price wrote:
>
> On 01/11/2019 13:03, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > As of earlier commit we have address space separation. Yet we forgot to
> > remove the respective comment and DRM_AUTH in the ioctl declaration.
> >
> > Cc: Tomeu Vizoso
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Robin Murphy
> > Cc: Steven Price
> > Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
> > Signed-off-by: Emil Velikov
>
> Reviewed-by: Steven Price
>
> I'm not sure DRM_AUTH provided us with much in the first place (because
> render nodes could snoop/affect the primary node), but since we have
> address space separation it's clearly not required now.
>
Thanks Steve. This is exactly the reason why I removed it from most
other drivers.
There are equivalent vmwgfx changes and a DRM core patch in this series.
Do you think you'll have some time to check those over? Would be
amazing if I can apply the lot in one go to drm-misc.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: drop DRM_AUTH from PRIME_TO/FROM_HANDLE ioctls
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> As mentioned by Christian, for drivers which support only primary nodes
> this changes the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS.
>
> For others, this check in particular will be a noop. So let's remove it
> as suggested by Christian.
>
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
> Cc: Daniel Vetter
> Cc: Sean Paul
> Acked-by: Christian König
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/drm_ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index fcd728d7cf72..5afb39688b55 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -652,8 +652,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETRESOURCES, drm_mode_getresources, 0),
>
> - DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
> drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> - DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
> drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
> drm_prime_handle_to_fd_ioctl, DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
> drm_prime_fd_to_handle_ioctl, DRM_RENDER_ALLOW),
>
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES,
> drm_mode_getplane_res, 0),
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 0),
> --
Humble poke? Sean, others?
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/vmwgfx: move the require_exist handling together
On Fri, 1 Nov 2019 at 13:05, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Move the render_client hunk for require_exist alongside the rest.
> Keeping all the reasons why an existing object is needed, in a single
> place makes it easier to follow.
>
> Cc: VMware Graphics
> Cc: Thomas Hellstrom
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index 29d8794f0421..1f989f3605c8 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -909,16 +909,12 @@ vmw_surface_handle_reference(struct vmw_private
> *dev_priv,
> uint32_t handle;
> struct ttm_base_object *base;
> int ret;
> - bool require_exist = false;
>
> if (handle_type == DRM_VMW_HANDLE_PRIME) {
> ret = ttm_prime_fd_to_handle(tfile, u_handle, &handle);
> if (unlikely(ret != 0))
> return ret;
> } else {
> - if (unlikely(drm_is_render_client(file_priv)))
> - require_exist = true;
> -
> handle = u_handle;
> }
>
> @@ -935,6 +931,8 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
> }
>
> if (handle_type != DRM_VMW_HANDLE_PRIME) {
> + bool require_exist = false;
> +
> user_srf = container_of(base, struct vmw_user_surface,
> prime.base);
>
> @@ -946,6 +944,9 @@ vmw_surface_handle_reference(struct vmw_private *dev_priv,
> user_srf->master != file_priv->master)
> require_exist = true;
>
> + if (unlikely(drm_is_render_client(file_priv)))
> + require_exist = true;
> +
> ret = ttm_ref_object_add(tfile, base, TTM_REF_USAGE, NULL,
> require_exist);
> if (unlikely(ret != 0)) {
> --
Thomas, VMware devs, humble poke?
Any comments and review would be appreciated.
Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 01/12] drm: Inline drm_color_lut_extract()
On Thu, Nov 07, 2019 at 06:40:14PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This thing can get called several thousand times per LUT
> > so seems like we want to inline it to:
> > - avoid the function call overhead
> > - allow constant folding
> >
> > A quick synthetic test (w/o any hardware interaction) with
> > a ridiculously large LUT size shows about 50% reduction in
> > runtime on my HSW and BSW boxes. Slightly less with more
> > reasonable LUT size but still easily measurable in tens
> > of microseconds.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_color_mgmt.c | 24
> > include/drm/drm_color_mgmt.h | 23 ++-
>
> You forgot to add the include stanza in the kerneldoc .rst files, which
> means this is now lost from the output. Please fix.
Aye. A bit funny that we already have a bunch of other kerneldocs
in that header but it's not included in the .rst.
> -Daniel
>
> > 2 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 4ce5c6d8de99..19c5f635992a 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -108,30 +108,6 @@
> > * standard enum values supported by the DRM plane.
> > */
> >
> > -/**
> > - * drm_color_lut_extract - clamp and round LUT entries
> > - * @user_input: input value
> > - * @bit_precision: number of bits the hw LUT supports
> > - *
> > - * Extract a degamma/gamma LUT value provided by user (in the form of
> > - * &drm_color_lut entries) and round it to the precision supported by the
> > - * hardware.
> > - */
> > -uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
> > -{
> > - uint32_t val = user_input;
> > - uint32_t max = 0x >> (16 - bit_precision);
> > -
> > - /* Round only if we're not using full precision. */
> > - if (bit_precision < 16) {
> > - val += 1UL << (16 - bit_precision - 1);
> > - val >>= 16 - bit_precision;
> > - }
> > -
> > - return clamp_val(val, 0, max);
> > -}
> > -EXPORT_SYMBOL(drm_color_lut_extract);
> > -
> > /**
> > * drm_crtc_enable_color_mgmt - enable color management properties
> > * @crtc: DRM CRTC
> > diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> > index d1c662d92ab7..069b21d61871 100644
> > --- a/include/drm/drm_color_mgmt.h
> > +++ b/include/drm/drm_color_mgmt.h
> > @@ -29,7 +29,28 @@
> > struct drm_crtc;
> > struct drm_plane;
> >
> > -uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t
> > bit_precision);
> > +/**
> > + * drm_color_lut_extract - clamp and round LUT entries
> > + * @user_input: input value
> > + * @bit_precision: number of bits the hw LUT supports
> > + *
> > + * Extract a degamma/gamma LUT value provided by user (in the form of
> > + * &drm_color_lut entries) and round it to the precision supported by the
> > + * hardware.
> > + */
> > +static inline u32 drm_color_lut_extract(u32 user_input, int bit_precision)
> > +{
> > + u32 val = user_input;
> > + u32 max = 0x >> (16 - bit_precision);
> > +
> > + /* Round only if we're not using full precision. */
> > + if (bit_precision < 16) {
> > + val += 1UL << (16 - bit_precision - 1);
> > + val >>= 16 - bit_precision;
> > + }
> > +
> > + return clamp_val(val, 0, max);
> > +}
> >
> > void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> > uint degamma_lut_size,
> > --
> > 2.23.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/15] mm/mmu_notifier: add an interval tree notifier
On Thu, Nov 07, 2019 at 10:33:02PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> > >
> > > enum mmu_range_notifier_event {
> > > MMU_NOTIFY_RELEASE,
> > > };
> > >
> > > ...assuming that we stay with "mmu_range_notifier" as a core name for
> > > this
> > > whole thing.
> > >
> > > Also, it is best moved down to be next to the new MNR structs, so that
> > > all the
> > > MNR stuff is in one group.
> >
> > I agree with Jerome, this enum is part of the 'struct
> > mmu_notifier_range' (ie the description of the invalidation) and it
> > doesn't really matter that only these new notifiers can be called with
> > this type, it is still part of the mmu_notifier_range.
> >
> > The comment already says it only applies to the mmu_range_notifier
> > scheme..
>
> In fact the enum is entirely unused. We might as well just kill it off
> entirely.
I had patches to use it, i need to re-post them. I posted them long ago
and i droped the ball. I will re-spin after this.
Cheers,
Jérôme
___
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 #5 from Pierre Ossman --- That's a shame. I did find bug 111811, which looks very similar. Through that I found this patch: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg40304.html Unfortunately it does not solve the issue here. :/ Have you checked if you can reproduce this in a 2200G in your end? Or other Raven Ridge APUs? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/12] drm: Inline drm_color_lut_extract()
From: Ville Syrjälä
This thing can get called several thousand times per LUT
so seems like we want to inline it to:
- avoid the function call overhead
- allow constant folding
A quick synthetic test (w/o any hardware interaction) with
a ridiculously large LUT size shows about 50% reduction in
runtime on my HSW and BSW boxes. Slightly less with more
reasonable LUT size but still easily measurable in tens
of microseconds.
v2: Include drm_color_mgmt.h in the .rst (Daniel)
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
Reviewed-by: Nicholas Kazlauskas
---
Documentation/gpu/drm-kms.rst| 3 +++
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 23 ++-
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 23a3c986ef6d..c68588ce4090 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -479,6 +479,9 @@ Color Management Properties
.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:
+.. kernel-doc:: include/drm/drm_color_mgmt.h
+ :internal:
+
Tile Group Property
---
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 4ce5c6d8de99..19c5f635992a 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -108,30 +108,6 @@
* standard enum values supported by the DRM plane.
*/
-/**
- * drm_color_lut_extract - clamp and round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-EXPORT_SYMBOL(drm_color_lut_extract);
-
/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index d1c662d92ab7..069b21d61871 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -29,7 +29,28 @@
struct drm_crtc;
struct drm_plane;
-uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+/**
+ * drm_color_lut_extract - clamp and round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+static inline u32 drm_color_lut_extract(u32 user_input, int bit_precision)
+{
+ u32 val = user_input;
+ u32 max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
--
2.23.0
___
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 #6 from Pierre Ossman --- Hmmm... I did get this from that patch though: > [ 98.391016] amdgpu :38:00.0: GPU mode1 reset > [ 98.391072] [drm] psp mode 1 reset not supported now! > [ 98.391074] amdgpu :38:00.0: GPU mode1 reset failed > [ 98.391151] amdgpu :38:00.0: GPU mode1 reset > [ 98.391198] [drm] psp mode 1 reset not supported now! > [ 98.391199] amdgpu :38:00.0: GPU mode1 reset failed > [ 98.391358] [drm:amdgpu_device_suspend [amdgpu]] *ERROR* amdgpu asic reset > failed Not sure if it helps. -- 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/rockchip: use DRM_DEV_ERROR for log output
Hi,
[it seems your Reply-To mail header is set strangely as
Reply-To: 20191107133851.GF63329@art_vandelay
which confuses my MTA]
Am Freitag, 8. November 2019, 13:46:30 CET schrieb Wambui Karuga:
> On Thu, Nov 07, 2019 at 08:38:51AM -0500, Sean Paul wrote:
> > On Thu, Nov 07, 2019 at 01:54:22AM -0800, Joe Perches wrote:
> > > On Thu, 2019-11-07 at 12:29 +0300, Wambui Karuga wrote:
> > > > Replace the use of the dev_err macro with the DRM_DEV_ERROR
> > > > DRM helper macro.
> > >
> > > The commit message should show the reason _why_ you are doing
> > > this instead of just stating that you are doing this.
> > >
> > > It's not that dev_err is uncommon in drivers/gpu/drm.
> > >
> >
> > It is uncommon (this is the sole instance) in rockchip, however. So it makes
> > sense to convert the dev_* prints in rockchip to DRM_DEV for consistency.
> >
> > Wambui, could you also please convert the dev_warn instance as well?
> >
> Hey, Sean.
> Trying to convert this dev_warn instance, but the corresponding DRM_WARN
> macro does not take the dev parameter which seems to be useful in the
> original output.
> Should I still convert it to DRM_WARN without the hdmi->dev parameter?
There exists DRM_DEV_ERROR, DRM_DEV_INFO and DRM_DEV_DEBUG to
handle actual devices. Interestingly there is no DRM_DEV_WARN though.
So depending on what Sean suggest another option would be to add the
missing DRM_DEV_WARN and then use it to replace the dev_warn.
Heiko
>
> Thanks,
> wambui
> > I'll apply this to drm-misc-next and expand on the commit message a bit.
> >
> > Thanks,
> >
> > Sean
> >
> > > $ git grep -w dev_err drivers/gpu/drm | wc -l
> > > 1950
> > > $ git grep -w DRM_DEV_ERROR drivers/gpu/drm | wc -l
> > > 756
> > >
> > > > diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > > > b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> > > []
> > > > @@ -916,7 +916,7 @@ static int dw_mipi_dsi_rockchip_probe(struct
> > > > platform_device *pdev)
> > > > }
> > > >
> > > > if (!dsi->cdata) {
> > > > - dev_err(dev, "no dsi-config for %s node\n", np->name);
> > > > + DRM_DEV_ERROR(dev, "no dsi-config for %s node\n",
> > > > np->name);
> > > > return -EINVAL;
> > > > }
> > >
> > >
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/4] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
Hi Rob, On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote: > On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote: > > On Thu, Sep 26, 2019 at 09:15:01AM -0500, Rob Herring wrote: > > > On Wed, Sep 25, 2019 at 6:56 PM Laurent Pinchart wrote: > > > > > > > > From: Hyun Kwon > > > > > > > > The bindings describe the ZynqMP DP subsystem. They don't support the > > > > interface with the programmable logic (FPGA) or audio yet. > > > > > > > > Signed-off-by: Hyun Kwon > > > > Signed-off-by: Laurent Pinchart > > > > --- > > > > Changes since v8: > > > > > > > > - Convert to yaml > > > > - Rename aclk to dp_apb_clk > > > > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml: > > > display@fd4a: clock-names:2: 'dp_vtc_pixel_clk_in' was expected > > > > If you allow me to steal a bit of your brain time, could you help me > > expressing the clocks constraint ? > > > > clocks: > > description: > > The AXI clock and at least one video clock are mandatory, the audio > > clock > > optional. > > minItems: 2 > > maxItems: 4 > > items: > > - description: AXI clock > > - description: Audio clock > > - description: Non-live video clock (from Processing System) > > - description: Live video clock (from Programmable Logic) > > clock-names: > > minItems: 2 > > maxItems: 4 > > items: > > - const: dp_apb_clk > > - const: dp_aud_clk > > - const: dp_vtc_pixel_clk_in > > - const: dp_live_video_in_clk > > > > dp_apb_clk is required, dp_aud_clk is optional, and at least one of > > dp_vtc_pixel_clk_in and dp_live_video_in_clk is required. > > I'm hoping people's inability to express the schema will prevent > complicated ones like this in the first place... > > clock-names: > oneOf: > - minItems: 3 > maxItems: 4 > items: > - const: dp_apb_clk > - const: dp_aud_clk > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > - minItems: 2 > maxItems: 3 > items: > - const: dp_apb_clk > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] The above would make clock-names = "dp_apb_clk", "dp_vtc_pixel_clk_in", "dp_vtc_pixel_clk_in"; valid. I've investigated a little bit and found uniqueItems which solves my issue. Would the following simpler solution be acceptable ? clock-names: minItems: 2 maxItems: 4 items: - const: dp_apb_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - const: dp_aud_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] uniqueItems: true > Strictly speaking, that leaves items clocks wrong, but 'description' > doesn't do anything. So I'd just leave it as is. Speaking of which, there doesn't seem to be anything that validates the size of clocks and clock-names being identical. Is that a known issue ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/4] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings
Hi Rob, On Fri, Nov 08, 2019 at 04:07:33PM +0200, Laurent Pinchart wrote: > On Thu, Sep 26, 2019 at 09:57:29AM -0500, Rob Herring wrote: > > On Thu, Sep 26, 2019 at 9:23 AM Laurent Pinchart wrote: > >> On Thu, Sep 26, 2019 at 09:15:01AM -0500, Rob Herring wrote: > >>> On Wed, Sep 25, 2019 at 6:56 PM Laurent Pinchart wrote: > > From: Hyun Kwon > > The bindings describe the ZynqMP DP subsystem. They don't support the > interface with the programmable logic (FPGA) or audio yet. > > Signed-off-by: Hyun Kwon > Signed-off-by: Laurent Pinchart > --- > Changes since v8: > > - Convert to yaml > - Rename aclk to dp_apb_clk > >>> > >>> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.example.dt.yaml: > >>> display@fd4a: clock-names:2: 'dp_vtc_pixel_clk_in' was expected > >> > >> If you allow me to steal a bit of your brain time, could you help me > >> expressing the clocks constraint ? > >> > >> clocks: > >> description: > >> The AXI clock and at least one video clock are mandatory, the audio > >> clock > >> optional. > >> minItems: 2 > >> maxItems: 4 > >> items: > >> - description: AXI clock > >> - description: Audio clock > >> - description: Non-live video clock (from Processing System) > >> - description: Live video clock (from Programmable Logic) > >> clock-names: > >> minItems: 2 > >> maxItems: 4 > >> items: > >> - const: dp_apb_clk > >> - const: dp_aud_clk > >> - const: dp_vtc_pixel_clk_in > >> - const: dp_live_video_in_clk > >> > >> dp_apb_clk is required, dp_aud_clk is optional, and at least one of > >> dp_vtc_pixel_clk_in and dp_live_video_in_clk is required. > > > > I'm hoping people's inability to express the schema will prevent > > complicated ones like this in the first place... > > > > clock-names: > > oneOf: > > - minItems: 3 > > maxItems: 4 > > items: > > - const: dp_apb_clk > > - const: dp_aud_clk > > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > > - minItems: 2 > > maxItems: 3 > > items: > > - const: dp_apb_clk > > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > > The above would make > > clock-names = "dp_apb_clk", "dp_vtc_pixel_clk_in", > "dp_vtc_pixel_clk_in"; > > valid. I've investigated a little bit and found uniqueItems which solves > my issue. > > Would the following simpler solution be acceptable ? > > clock-names: > minItems: 2 > maxItems: 4 > items: > - const: dp_apb_clk > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > - const: dp_aud_clk > - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] > uniqueItems: true To give more context, clocks: description: The AXI clock and at least one video clock are mandatory, the audio clock is optional. minItems: 2 maxItems: 4 items: - description: dp_apb_clk is the AXI clock - description: dp_aud_clk is the Audio clock - description: dp_vtc_pixel_clk_in is the non-live video clock (from Processing System) - description: dp_live_video_in_clk is the live video clock (from Programmable Logic) clock-names: minItems: 2 maxItems: 4 items: - const: dp_apb_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - const: dp_aud_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] uniqueItems: true > > Strictly speaking, that leaves items clocks wrong, but 'description' > > doesn't do anything. So I'd just leave it as is. > > Speaking of which, there doesn't seem to be anything that validates the > size of clocks and clock-names being identical. Is that a known issue ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm: trace: Introduce drm_trace() and instrument drm_atomic.c
On Fri, 8 Nov 2019 09:50:30 +0100 Daniel Vetter wrote: > On Fri, Nov 08, 2019 at 10:16:59AM +0200, Pekka Paalanen wrote: > > Is it ok to build userspace to rely on these trace events during normal > > operations, e.g. for continuous adjustment of timings/timers? > > Aside discussion on this: If we add this (I think userspace might want > some information about the point of no return and why we missed it) then I > think we should expose that with an improved drm_event and clear > semantics. > > If we start to encourage compositors to use tracepoints to figure out why > the kernel doesn't behave (TEST_ONLY failure, or missed flip target), and > use that for behaviour, we've baked implementation details into the uapi. > And then we're screwed. > > So if you have any need for timing information that you see solved with a > tracepoint, pls bring this up so we can add proper uapi. And yes I know > that if someone doesn't we still need to keep that tracepoint working, but > with all things uapi the question isn't whether we'll screw up (we will), > but how often. And less often is massively better :-) Haha, sorry, that particular question was practically trolling, but OTOH something I can well imagine someone doing. Trying to fish out reasons for TEST_ONLY failing is a much better example. On third hand, profiling tools probably would depend on some trace points specifically. As for the uapi for a DRM flight recorder, I'd be happy to have that in Weston as my time permits. Alas, it needs two people and I can be only one: either the reviewer or the author. :-) I can see two ways to use a DRM flight recorder: - a file you grab as a whole after the fact, or - a stream you subscribe to and store the results in your own ring buffer The former is simpler, the latter would allow interleaving DRM and app notes as they happen rather than trying to rebuild a log from timestamps afterwards. Thanks, pq pgp_tJfQYzDEV.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
