Re: [PATCH v6 2/4] drm/bridge: add lvds controller support for sam9x7
On Wed, Apr 17, 2024 at 08:11:35AM +0530, Dharma Balasubiramani wrote:
> Add a new LVDS controller driver for sam9x7 which does the following:
> - Prepares and enables the LVDS Peripheral clock
> - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
> to the global bridge list.
> - Identifies its output endpoint as panel and adds it to the encoder
> display pipeline
> - Enables the LVDS serializer
>
> Signed-off-by: Manikandan Muralidharan
> Signed-off-by: Dharma Balasubiramani
> ---
> Changelog
> v5 -> v6
> - No Changes.
> v4 -> v5
> - Drop the unused variable 'format'.
> - Use DRM wrapper for dev_err() to maintain uniformity.
> - return -ENODEV instead of -EINVAL to maintain consistency with other DRM
> bridge drivers.
> v3 -> v4
> - No changes.
> v2 ->v3
> - Correct Typo error "serializer".
> - Consolidate get() and prepare() functions and use devm_clk_get_prepared().
> - Remove unused variable 'ret' in probe().
> - Use devm_pm_runtime_enable() and drop the mchp_lvds_remove().
> v1 -> v2
> - Drop 'res' variable and combine two lines into one.
> - Handle deferred probe properly, use dev_err_probe().
> - Don't print anything on deferred probe. Dropped print.
> - Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
> - symbol 'mchp_lvds_driver' was not declared. It should be static.
> ---
> drivers/gpu/drm/bridge/Kconfig | 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/microchip-lvds.c | 228
> 3 files changed, 236 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index efd996f6c138..889098e2d65f 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -190,6 +190,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
> to DP++. This is used with the i.MX6 imx-ldb
> driver. You are likely to say N here.
>
> +config DRM_MICROCHIP_LVDS_SERIALIZER
> + tristate "Microchip LVDS serializer support"
> + depends on OF
> + depends on DRM_ATMEL_HLCDC
> + help
> + Support for Microchip's LVDS serializer.
> +
> config DRM_NWL_MIPI_DSI
> tristate "Northwest Logic MIPI DSI Host controller"
> depends on DRM
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 017b5832733b..7df87b582dca 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.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_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
> b/drivers/gpu/drm/bridge/microchip-lvds.c
> new file mode 100644
> index ..149704f498a6
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/microchip-lvds.c
> @@ -0,0 +1,228 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
> + *
> + * Author: Manikandan Muralidharan
> + * Author: Dharma Balasubiramani
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define LVDS_POLL_TIMEOUT_MS 1000
> +
> +/* LVDSC register offsets */
> +#define LVDSC_CR 0x00
> +#define LVDSC_CFGR 0x04
> +#define LVDSC_SR 0x0C
> +#define LVDSC_WPMR 0xE4
> +
> +/* Bitfields in LVDSC_CR (Control Register) */
> +#define LVDSC_CR_SER_EN BIT(0)
> +
> +/* Bitfields in LVDSC_CFGR (Configuration Register) */
> +#define LVDSC_CFGR_PIXSIZE_24BITS0
> +#define LVDSC_CFGR_DEN_POL_HIGH 0
> +#define LVDSC_CFGR_DC_UNBALANCED 0
> +#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
> +
> +/*Bitfields in LVDSC_SR */
> +#define LVDSC_SR_CS BIT(0)
> +
> +/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
> +#define LVDSC_WPMR_WPKEY_MASKGENMASK(31, 8)
> +#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
> +
> +struct mchp_lvds {
> + struct device *dev;
> + void __iomem *regs;
> + struct clk *pclk;
> + struct drm_panel *panel;
> + struct drm_bridge bridge;
> + struct drm_bridge *panel_bridge;
> +};
> +
> +static inline struct mchp_lvds *bridge_to_lvds(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct mchp_lvds, bridge);
> +}
> +
> +static inline u32 lvds_readl(struct mchp_lvds *lvds, u32 offset)
> +{
> + return readl_relaxed(lvds->regs + offs
Re: [PATCH v2 1/9] drm/ttm: Allow TTM LRU list nodes of different types
Am 17.04.24 um 03:15 schrieb Matthew Brost:
On Tue, Apr 16, 2024 at 12:07:22PM +0200, Thomas Hellström wrote:
To be able to handle list unlocking while traversing the LRU
list, we want the iterators not only to point to the next
position of the list traversal, but to insert themselves as
list nodes at that point to work around the fact that the
next node might otherwise disappear from the list while
the iterator is pointing to it.
These list nodes need to be easily distinguishable from other
list nodes so that others traversing the list can skip
over them.
So declare a struct ttm_lru_item, with a struct list_head member
and a type enum. This will slightly increase the size of a
struct ttm_resource.
Changes in previous series:
- Update enum ttm_lru_item_type documentation.
Patch itself makes sense to me. One style question (or maybe
suggestion?) below.
Cc: Christian König
Cc: Somalapuram Amaranath
Cc:
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_device.c | 13 --
drivers/gpu/drm/ttm/ttm_resource.c | 70 ++
include/drm/ttm/ttm_resource.h | 51 +-
3 files changed, 110 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 76027960054f..f27406e851e5 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -270,17 +270,22 @@ EXPORT_SYMBOL(ttm_device_fini);
static void ttm_device_clear_lru_dma_mappings(struct ttm_device *bdev,
struct list_head *list)
{
- struct ttm_resource *res;
+ struct ttm_lru_item *lru;
spin_lock(&bdev->lru_lock);
- while ((res = list_first_entry_or_null(list, typeof(*res), lru))) {
- struct ttm_buffer_object *bo = res->bo;
+ while ((lru = list_first_entry_or_null(list, typeof(*lru), link))) {
+ struct ttm_buffer_object *bo;
+
+ if (!ttm_lru_item_is_res(lru))
+ continue;
+
+ bo = ttm_lru_item_to_res(lru)->bo;
/* Take ref against racing releases once lru_lock is unlocked */
if (!ttm_bo_get_unless_zero(bo))
continue;
- list_del_init(&res->lru);
+ list_del_init(&bo->resource->lru.link);
spin_unlock(&bdev->lru_lock);
if (bo->ttm)
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index be8d286513f9..7aa5ca5c0e33 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -69,8 +69,8 @@ void ttm_lru_bulk_move_tail(struct ttm_lru_bulk_move *bulk)
dma_resv_assert_held(pos->last->bo->base.resv);
man = ttm_manager_type(pos->first->bo->bdev, i);
- list_bulk_move_tail(&man->lru[j], &pos->first->lru,
- &pos->last->lru);
+ list_bulk_move_tail(&man->lru[j], &pos->first->lru.link,
+ &pos->last->lru.link);
}
}
}
@@ -83,14 +83,38 @@ ttm_lru_bulk_move_pos(struct ttm_lru_bulk_move *bulk,
struct ttm_resource *res)
return &bulk->pos[res->mem_type][res->bo->priority];
}
+/* Return the previous resource on the list (skip over non-resource list items) */
+static struct ttm_resource *ttm_lru_prev_res(struct ttm_resource *cur)
+{
+ struct ttm_lru_item *lru = &cur->lru;
+
+ do {
+ lru = list_prev_entry(lru, link);
+ } while (!ttm_lru_item_is_res(lru));
+
+ return ttm_lru_item_to_res(lru);
+}
+
+/* Return the next resource on the list (skip over non-resource list items) */
+static struct ttm_resource *ttm_lru_next_res(struct ttm_resource *cur)
+{
+ struct ttm_lru_item *lru = &cur->lru;
+
+ do {
+ lru = list_next_entry(lru, link);
+ } while (!ttm_lru_item_is_res(lru));
+
+ return ttm_lru_item_to_res(lru);
+}
+
/* Move the resource to the tail of the bulk move range */
static void ttm_lru_bulk_move_pos_tail(struct ttm_lru_bulk_move_pos *pos,
struct ttm_resource *res)
{
if (pos->last != res) {
if (pos->first == res)
- pos->first = list_next_entry(res, lru);
- list_move(&res->lru, &pos->last->lru);
+ pos->first = ttm_lru_next_res(res);
+ list_move(&res->lru.link, &pos->last->lru.link);
pos->last = res;
}
}
@@ -121,11 +145,11 @@ static void ttm_lru_bulk_move_del(struct
ttm_lru_bulk_move *bulk,
pos->first = NULL;
pos->last = NULL;
} else if (pos->first == res) {
- pos->first = list_next_entry(res, lru);
+ pos->first = ttm_lru_next_res(res);
} else if (pos->last == res) {
- pos->last = list_prev_entry(res,
[PATCH] nouveau: rip out busy fence waits
From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Just nuke it, there should be no need to do fence waits in a
busy CPU loop.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fence.c | 30 +
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
6 files changed, 6 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8a30f5a0525b..a4e8f625fce6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -902,7 +902,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict,
* Without this the operation can timeout and we'll fallback to a
* software copy, which might take several minutes to finish.
*/
- nouveau_fence_wait(fence, false, false);
+ nouveau_fence_wait(fence, false);
ret = ttm_bo_move_accel_cleanup(bo, &fence->base, evict, false,
new_reg);
nouveau_fence_unref(&fence);
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 7c97b2886807..66fca95c10c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -72,7 +72,7 @@ nouveau_channel_idle(struct nouveau_channel *chan)
ret = nouveau_fence_new(&fence, chan);
if (!ret) {
- ret = nouveau_fence_wait(fence, false, false);
+ ret = nouveau_fence_wait(fence, false);
nouveau_fence_unref(&fence);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 12feecf71e75..033a09cd3c8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -128,7 +128,7 @@ static void nouveau_dmem_page_free(struct page *page)
static void nouveau_dmem_fence_done(struct nouveau_fence **fence)
{
if (fence) {
- nouveau_fence_wait(*fence, true, false);
+ nouveau_fence_wait(*fence, false);
nouveau_fence_unref(fence);
} else {
/*
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index c3ea3cd933cd..8de941379324 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -312,39 +312,11 @@ nouveau_fence_wait_legacy(struct dma_fence *f, bool intr,
long wait)
return timeout - t;
}
-static int
-nouveau_fence_wait_busy(struct nouveau_fence *fence, bool intr)
-{
- int ret = 0;
-
- while (!nouveau_fence_done(fence)) {
- if (time_after_eq(jiffies, fence->timeout)) {
- ret = -EBUSY;
- break;
- }
-
- __set_current_state(intr ?
- TASK_INTERRUPTIBLE :
- TASK_UNINTERRUPTIBLE);
-
- if (intr && signal_pending(current)) {
- ret = -ERESTARTSYS;
- break;
- }
- }
-
- __set_current_state(TASK_RUNNING);
- return ret;
-}
-
int
-nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, bool intr)
+nouveau_fence_wait(struct nouveau_fence *fence, bool intr)
{
long ret;
- if (!lazy)
- return nouveau_fence_wait_busy(fence, intr);
-
ret = dma_fence_wait_timeout(&fence->base, intr, 15 * HZ);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index bc13110bdfa4..88213014b675 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -23,7 +23,7 @@ void nouveau_fence_unref(struct nouveau_fence **);
int nouveau_fence_emit(struct nouveau_fence *);
bool nouveau_fence_done(struct nouveau_fence *);
-int nouveau_fence_wait(struct nouveau_fence *, bool lazy, bool intr);
+int nouveau_fence_wait(struct nouveau_fence *, bool intr);
int nouveau_fence_sync(struct nouveau_bo *, struct nouveau_channel *, bool
exclusive, bool intr);
struct nouveau_fence_chan {
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 49c2bcbef129..f715e381da69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -928,7 +928,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
}
if (sync) {
- if (!(ret = nouveau_fence_wait(fence, false, false))) {
+ if (!(ret = nouveau_fence_wait(fe
[PATCH v4] drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
Eliminate fetch_and_zero (Jani)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 52 +--
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b758fd110c20..1551a40a675e 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -793,7 +793,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!IS_DGFX(i915))
return;
- hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
+ hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return;
@@ -819,14 +819,12 @@ void i915_hwmon_register(struct drm_i915_private *i915)
hwm_get_preregistration_info(i915);
/* hwmon_dev points to device hwmon */
- hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
-ddat,
-&hwm_chip_info,
-hwm_groups);
- if (IS_ERR(hwmon_dev)) {
- i915->hwmon = NULL;
- return;
- }
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
+ ddat,
+ &hwm_chip_info,
+ hwm_groups);
+ if (IS_ERR(hwmon_dev))
+ goto err;
ddat->hwmon_dev = hwmon_dev;
@@ -839,16 +837,38 @@ void i915_hwmon_register(struct drm_i915_private *i915)
if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
hwmon_energy_input, 0))
continue;
- hwmon_dev = devm_hwmon_device_register_with_info(dev,
ddat_gt->name,
-ddat_gt,
-
&hwm_gt_chip_info,
-NULL);
- if (!IS_ERR(hwmon_dev))
- ddat_gt->hwmon_dev = hwmon_dev;
+ hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
+ ddat_gt,
+ &hwm_gt_chip_info,
+ NULL);
+ if (IS_ERR(hwmon_dev))
+ goto err;
+
+ ddat_gt->hwmon_dev = hwmon_dev;
}
+ return;
+err:
+ i915_hwmon_unregister(i915);
}
void i915_hwmon_unregister(struct drm_i915_private *i915)
{
- fetch_and_zero(&i915->hwmon);
+ struct i915_hwmon *hwmon = i915->hwmon;
+ struct intel_gt *gt;
+ int i;
+
+ if (!hwmon)
+ return;
+
+ for_each_gt(gt, i915, i)
+ if (hwmon->ddat_gt[i].hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat_gt[i].hwmon_dev);
+
+ if (hwmon->ddat.hwmon_dev)
+ hwmon_device_unregister(hwmon->ddat.hwmon_dev);
+
+ mutex_destroy(&hwmon->hwmon_lock);
+
+ kfree(i915->hwmon);
+ i915->hwmon = NULL;
}
--
2.41.0
[PATCH v2] doc: dma-buf: fix grammar typo
Use 'supported' instead of 'support'. 'support' makes no sense in this context. Signed-off-by: Baruch Siach --- v2: Add commit log message (Christian König) --- Documentation/driver-api/dma-buf.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 0c153d79ccc4..29abf1eebf9f 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -77,7 +77,7 @@ consider though: the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other llseek operation will report -EINVAL. - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + If llseek on dma-buf FDs isn't supported the kernel will report -ESPIPE for all cases. Userspace can use this to detect support for discovering the dma-buf size using llseek. -- 2.43.0
[PATCH v6 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani Reviewed-by: Neil Armstrong Acked-by: Nicolas Ferre --- Changelog v5 -> v6 - Correct the file name sam9x7-lvds.yaml -> sam9x75-lvds.yaml. v4 -> v5 v3 -> v4 - No changes. v2 -> v3 - Move the entry before "MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER". v1 -> v2 - No Changes. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index c23fda1aa1f0..e49347eac596 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14563,6 +14563,14 @@ S: Supported F: Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml F: drivers/pwm/pwm-atmel.c +MICROCHIP SAM9x7-COMPATIBLE LVDS CONTROLLER +M: Manikandan Muralidharan +M: Dharma Balasubiramani +L: dri-devel@lists.freedesktop.org +S: Supported +F: Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml +F: drivers/gpu/drm/bridge/microchip-lvds.c + MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER M: Eugen Hristev L: linux-...@vger.kernel.org -- 2.25.1
[PATCH v6 4/4] ARM: configs: at91: Enable LVDS serializer support
Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani Acked-by: Hari Prasath Gujulan Elango Acked-by: Nicolas Ferre --- Changelog v4 -> v5 v3 -> v4 v2 -> v3 - No Changes. --- arch/arm/configs/at91_dt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 1d53aec4c836..6eabe2313c9a 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -143,6 +143,7 @@ CONFIG_VIDEO_OV2640=m CONFIG_VIDEO_OV7740=m CONFIG_DRM=y CONFIG_DRM_ATMEL_HLCDC=y +CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER=y CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_PANEL_EDP=y CONFIG_FB_ATMEL=y -- 2.25.1
Re: [PATCH] drm/mediatek/dp: fix mtk_dp_aux_transfer return value
[PATCH v6 0/4] LVDS Controller Support for SAM9X75 SoC
This patch series introduces LVDS controller support for the SAM9X75 SoC. The LVDS controller is designed to work with Microchip's sam9x7 series System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling capabilities. Patch series Changelog: - Include configs: at91: Enable LVDS serializer - include all necessary To/Cc entries. The Individual Changelogs are available on the respective patches. Dharma Balasubiramani (4): dt-bindings: display: bridge: add sam9x75-lvds binding drm/bridge: add lvds controller support for sam9x7 MAINTAINERS: add SAM9X7 SoC's LVDS controller ARM: configs: at91: Enable LVDS serializer support .../bridge/microchip,sam9x75-lvds.yaml| 55 + MAINTAINERS | 8 + arch/arm/configs/at91_dt_defconfig| 1 + drivers/gpu/drm/bridge/Kconfig| 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/microchip-lvds.c | 228 ++ 6 files changed, 300 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c -- 2.25.1
[PATCH v6 1/4] dt-bindings: display: bridge: add sam9x75-lvds binding
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Rob Herring
---
Changelog
v5 -> v6
- No Changes.
v4 -> v5
- No changes.
v3 -> v4
- Rephrase the commit subject.
v2 -> v3
- No changes.
v1 -> v2
- Remove '|' in description, as there is no formatting to preserve.
- Remove 'gclk' from clock-names as there is only one clock(pclk).
- Remove the unused headers and include only used ones.
- Change the compatible name specific to SoC (sam9x75) instead of entire series.
- Change file name to match the compatible name.
---
.../bridge/microchip,sam9x75-lvds.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
new file mode 100644
index ..862ef441ac9f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAM9X75 LVDS Controller
+
+maintainers:
+ - Dharma Balasubiramani
+
+description:
+ The Low Voltage Differential Signaling Controller (LVDSC) manages data
+ format conversion from the LCD Controller internal DPI bus to OpenLDI
+ LVDS output signals. LVDSC functions include bit mapping, balanced mode
+ management, and serializer.
+
+properties:
+ compatible:
+const: microchip,sam9x75-lvds
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Peripheral Bus Clock
+
+ clock-names:
+items:
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+lvds-controller@f806 {
+ compatible = "microchip,sam9x75-lvds";
+ reg = <0xf806 0x100>;
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
+ clock-names = "pclk";
+};
--
2.25.1
[PATCH v6 2/4] drm/bridge: add lvds controller support for sam9x7
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display pipeline
- Enables the LVDS serializer
Signed-off-by: Manikandan Muralidharan
Signed-off-by: Dharma Balasubiramani
---
Changelog
v5 -> v6
- No Changes.
v4 -> v5
- Drop the unused variable 'format'.
- Use DRM wrapper for dev_err() to maintain uniformity.
- return -ENODEV instead of -EINVAL to maintain consistency with other DRM
bridge drivers.
v3 -> v4
- No changes.
v2 ->v3
- Correct Typo error "serializer".
- Consolidate get() and prepare() functions and use devm_clk_get_prepared().
- Remove unused variable 'ret' in probe().
- Use devm_pm_runtime_enable() and drop the mchp_lvds_remove().
v1 -> v2
- Drop 'res' variable and combine two lines into one.
- Handle deferred probe properly, use dev_err_probe().
- Don't print anything on deferred probe. Dropped print.
- Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
- symbol 'mchp_lvds_driver' was not declared. It should be static.
---
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/microchip-lvds.c | 228
3 files changed, 236 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index efd996f6c138..889098e2d65f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -190,6 +190,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
to DP++. This is used with the i.MX6 imx-ldb
driver. You are likely to say N here.
+config DRM_MICROCHIP_LVDS_SERIALIZER
+ tristate "Microchip LVDS serializer support"
+ depends on OF
+ depends on DRM_ATMEL_HLCDC
+ help
+ Support for Microchip's LVDS serializer.
+
config DRM_NWL_MIPI_DSI
tristate "Northwest Logic MIPI DSI Host controller"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 017b5832733b..7df87b582dca 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.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_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
b/drivers/gpu/drm/bridge/microchip-lvds.c
new file mode 100644
index ..149704f498a6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/microchip-lvds.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan
+ * Author: Dharma Balasubiramani
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LVDS_POLL_TIMEOUT_MS 1000
+
+/* LVDSC register offsets */
+#define LVDSC_CR 0x00
+#define LVDSC_CFGR 0x04
+#define LVDSC_SR 0x0C
+#define LVDSC_WPMR 0xE4
+
+/* Bitfields in LVDSC_CR (Control Register) */
+#define LVDSC_CR_SER_ENBIT(0)
+
+/* Bitfields in LVDSC_CFGR (Configuration Register) */
+#define LVDSC_CFGR_PIXSIZE_24BITS 0
+#define LVDSC_CFGR_DEN_POL_HIGH0
+#define LVDSC_CFGR_DC_UNBALANCED 0
+#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
+
+/*Bitfields in LVDSC_SR */
+#define LVDSC_SR_CSBIT(0)
+
+/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
+#define LVDSC_WPMR_WPKEY_MASK GENMASK(31, 8)
+#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
+
+struct mchp_lvds {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *pclk;
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+};
+
+static inline struct mchp_lvds *bridge_to_lvds(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mchp_lvds, bridge);
+}
+
+static inline u32 lvds_readl(struct mchp_lvds *lvds, u32 offset)
+{
+ return readl_relaxed(lvds->regs + offset);
+}
+
+static inline void lvds_writel(struct mchp_lvds *lvds, u32 offset, u32 val)
+{
+ writel_relaxed(val, lvds->regs + offset);
+}
+
+static void lvds_serialiser_on(struct mchp_lvds *lvds)
+{
+ unsigned long timeout = jiffies +
msecs_to_jiffies(LVDS_POLL_TIMEOUT_MS);
+
+ /* The LVDSC registers can o
Re: [PATCH v2 4/9] drm/ttm: Allow continued swapout after -ENOSPC falure
On Tue, Apr 16, 2024 at 12:07:25PM +0200, Thomas Hellström wrote:
> The -ENOSPC failure from ttm_bo_swapout() meant that the lru_lock
> was dropped and simply restarting the iteration meant we'd likely
> hit the same error again on the same resource. Now that we can
> restart the iteration even if the lock was dropped, do that.
>
It is not clear what you describe in this commit message (-ENOSPC ==
-EBUSY + lru_lock dropped) is true (no comments in code).
It does appears to be true after examining ttm_bo_swapout() closely.
Maybe out of scope for the series but would it be possible to add some
kernel doc to ttm_device_swapout stating this?
Patch it self makes sense to me.
Matt
> Cc: Christian König
> Cc: Somalapuram Amaranath
> Cc:
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/ttm/ttm_device.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index e8a6a1dab669..4a030b4bc848 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -168,15 +168,20 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
> ttm_operation_ctx *ctx,
>
> num_pages = PFN_UP(bo->base.size);
> ret = ttm_bo_swapout(bo, ctx, gfp_flags);
> - /* ttm_bo_swapout has dropped the lru_lock */
> - if (!ret) {
> - ttm_resource_cursor_fini(&cursor);
> - return num_pages;
> - }
> - if (ret != -EBUSY) {
> - ttm_resource_cursor_fini(&cursor);
> - return ret;
> + /* Couldn't swap out, and retained the lru_lock */
> + if (ret == -EBUSY)
> + continue;
> + /* Couldn't swap out and dropped the lru_lock */
> + if (ret == -ENOSPC) {
> + spin_lock(&bdev->lru_lock);
> + continue;
> }
> + /*
> + * Dropped the lock and either succeeded or
> + * hit an error that forces us to break.
> + */
> + ttm_resource_cursor_fini(&cursor);
> + return ret ? ret : num_pages;
> }
> }
> ttm_resource_cursor_fini_locked(&cursor);
> --
> 2.44.0
>
[PATCH] drm/vmwgfx: Remove duplicate vmwgfx_vkms.h header
./drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c: vmwgfx_vkms.h is included more than once. Reported-by: Abaci Robot Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8772 Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c index 7e93a45948f7..3bfcf671fcd5 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c @@ -31,7 +31,6 @@ #include "vmwgfx_bo.h" #include "vmwgfx_drv.h" #include "vmwgfx_kms.h" -#include "vmwgfx_vkms.h" #include "vmw_surface_cache.h" -- 2.20.1.7.g153144c
Re: [PATCH v2 1/9] drm/ttm: Allow TTM LRU list nodes of different types
On Tue, Apr 16, 2024 at 12:07:22PM +0200, Thomas Hellström wrote:
> To be able to handle list unlocking while traversing the LRU
> list, we want the iterators not only to point to the next
> position of the list traversal, but to insert themselves as
> list nodes at that point to work around the fact that the
> next node might otherwise disappear from the list while
> the iterator is pointing to it.
>
> These list nodes need to be easily distinguishable from other
> list nodes so that others traversing the list can skip
> over them.
>
> So declare a struct ttm_lru_item, with a struct list_head member
> and a type enum. This will slightly increase the size of a
> struct ttm_resource.
>
> Changes in previous series:
> - Update enum ttm_lru_item_type documentation.
>
Patch itself makes sense to me. One style question (or maybe
suggestion?) below.
> Cc: Christian König
> Cc: Somalapuram Amaranath
> Cc:
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/ttm/ttm_device.c | 13 --
> drivers/gpu/drm/ttm/ttm_resource.c | 70 ++
> include/drm/ttm/ttm_resource.h | 51 +-
> 3 files changed, 110 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index 76027960054f..f27406e851e5 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -270,17 +270,22 @@ EXPORT_SYMBOL(ttm_device_fini);
> static void ttm_device_clear_lru_dma_mappings(struct ttm_device *bdev,
> struct list_head *list)
> {
> - struct ttm_resource *res;
> + struct ttm_lru_item *lru;
>
> spin_lock(&bdev->lru_lock);
> - while ((res = list_first_entry_or_null(list, typeof(*res), lru))) {
> - struct ttm_buffer_object *bo = res->bo;
> + while ((lru = list_first_entry_or_null(list, typeof(*lru), link))) {
> + struct ttm_buffer_object *bo;
> +
> + if (!ttm_lru_item_is_res(lru))
> + continue;
> +
> + bo = ttm_lru_item_to_res(lru)->bo;
>
> /* Take ref against racing releases once lru_lock is unlocked */
> if (!ttm_bo_get_unless_zero(bo))
> continue;
>
> - list_del_init(&res->lru);
> + list_del_init(&bo->resource->lru.link);
> spin_unlock(&bdev->lru_lock);
>
> if (bo->ttm)
> diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> b/drivers/gpu/drm/ttm/ttm_resource.c
> index be8d286513f9..7aa5ca5c0e33 100644
> --- a/drivers/gpu/drm/ttm/ttm_resource.c
> +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> @@ -69,8 +69,8 @@ void ttm_lru_bulk_move_tail(struct ttm_lru_bulk_move *bulk)
> dma_resv_assert_held(pos->last->bo->base.resv);
>
> man = ttm_manager_type(pos->first->bo->bdev, i);
> - list_bulk_move_tail(&man->lru[j], &pos->first->lru,
> - &pos->last->lru);
> + list_bulk_move_tail(&man->lru[j], &pos->first->lru.link,
> + &pos->last->lru.link);
> }
> }
> }
> @@ -83,14 +83,38 @@ ttm_lru_bulk_move_pos(struct ttm_lru_bulk_move *bulk,
> struct ttm_resource *res)
> return &bulk->pos[res->mem_type][res->bo->priority];
> }
>
> +/* Return the previous resource on the list (skip over non-resource list
> items) */
> +static struct ttm_resource *ttm_lru_prev_res(struct ttm_resource *cur)
> +{
> + struct ttm_lru_item *lru = &cur->lru;
> +
> + do {
> + lru = list_prev_entry(lru, link);
> + } while (!ttm_lru_item_is_res(lru));
> +
> + return ttm_lru_item_to_res(lru);
> +}
> +
> +/* Return the next resource on the list (skip over non-resource list items)
> */
> +static struct ttm_resource *ttm_lru_next_res(struct ttm_resource *cur)
> +{
> + struct ttm_lru_item *lru = &cur->lru;
> +
> + do {
> + lru = list_next_entry(lru, link);
> + } while (!ttm_lru_item_is_res(lru));
> +
> + return ttm_lru_item_to_res(lru);
> +}
> +
> /* Move the resource to the tail of the bulk move range */
> static void ttm_lru_bulk_move_pos_tail(struct ttm_lru_bulk_move_pos *pos,
> struct ttm_resource *res)
> {
> if (pos->last != res) {
> if (pos->first == res)
> - pos->first = list_next_entry(res, lru);
> - list_move(&res->lru, &pos->last->lru);
> + pos->first = ttm_lru_next_res(res);
> + list_move(&res->lru.link, &pos->last->lru.link);
> pos->last = res;
> }
> }
> @@ -121,11 +145,11 @@ static void ttm_lru_bulk_move_del(struct
> ttm_lru_bulk_move *bulk,
> pos->first = NULL;
> pos->last = NULL;
> } else if (pos->first == res) {
> - pos->first = list_next_entry(res, l
[PATCH v2 4/4] drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler
In V3D, the conclusion of a job is indicated by a IRQ. When a job
finishes, then we update the local and the global GPU stats of that
queue. But, while the GPU stats are being updated, a user might be
reading the stats from sysfs or fdinfo.
For example, on `gpu_stats_show()`, we could think about a scenario where
`v3d->queue[queue].start_ns != 0`, then an interruption happens, we update
the value of `v3d->queue[queue].start_ns` to 0, we come back to
`gpu_stats_show()` to calculate `active_runtime` and now,
`active_runtime = timestamp`.
In this simple example, the user would see a spike in the queue usage,
that didn't matches reality.
In order to address this issue properly, use a seqcount to protect read
and write sections of the code.
Fixes: 09a93cc4f7d1 ("drm/v3d: Implement show_fdinfo() callback for GPU usage
stats")
Reported-by: Tvrtko Ursulin
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_drv.c | 10 ++
drivers/gpu/drm/v3d/v3d_drv.h | 21 +
drivers/gpu/drm/v3d/v3d_gem.c | 7 +--
drivers/gpu/drm/v3d/v3d_sched.c | 7 +++
drivers/gpu/drm/v3d/v3d_sysfs.c | 11 +++
5 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 52e3ba9df46f..cf15fa142968 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -121,6 +121,7 @@ v3d_open(struct drm_device *dev, struct drm_file *file)
1, NULL);
memset(&v3d_priv->stats[i], 0, sizeof(v3d_priv->stats[i]));
+ seqcount_init(&v3d_priv->stats[i].lock);
}
v3d_perfmon_open_file(v3d_priv);
@@ -150,20 +151,21 @@ static void v3d_show_fdinfo(struct drm_printer *p, struct
drm_file *file)
for (queue = 0; queue < V3D_MAX_QUEUES; queue++) {
struct v3d_stats *stats = &file_priv->stats[queue];
+ u64 active_runtime, jobs_completed;
+
+ v3d_get_stats(stats, timestamp, &active_runtime,
&jobs_completed);
/* Note that, in case of a GPU reset, the time spent during an
* attempt of executing the job is not computed in the runtime.
*/
drm_printf(p, "drm-engine-%s: \t%llu ns\n",
- v3d_queue_to_string(queue),
- stats->start_ns ? stats->enabled_ns + timestamp -
stats->start_ns
- : stats->enabled_ns);
+ v3d_queue_to_string(queue), active_runtime);
/* Note that we only count jobs that completed. Therefore, jobs
* that were resubmitted due to a GPU reset are not computed.
*/
drm_printf(p, "v3d-jobs-%s: \t%llu jobs\n",
- v3d_queue_to_string(queue), stats->jobs_completed);
+ v3d_queue_to_string(queue), jobs_completed);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 5a198924d568..5211df7c7317 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -40,8 +40,29 @@ struct v3d_stats {
u64 start_ns;
u64 enabled_ns;
u64 jobs_completed;
+
+ /*
+* This seqcount is used to protect the access to the GPU stats
+* variables. It must be used as, while we are reading the stats,
+* IRQs can happen and the stats can be updated.
+*/
+ seqcount_t lock;
};
+static inline void v3d_get_stats(const struct v3d_stats *stats, u64 timestamp,
+u64 *active_runtime, u64 *jobs_completed)
+{
+ unsigned int seq;
+
+ do {
+ seq = read_seqcount_begin(&stats->lock);
+ *active_runtime = stats->enabled_ns;
+ if (stats->start_ns)
+ *active_runtime += timestamp - stats->start_ns;
+ *jobs_completed = stats->jobs_completed;
+ } while (read_seqcount_retry(&stats->lock, seq));
+}
+
struct v3d_queue_state {
struct drm_gpu_scheduler sched;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index d14589d3ae6c..da8faf3b9011 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -247,8 +247,11 @@ v3d_gem_init(struct drm_device *dev)
int ret, i;
for (i = 0; i < V3D_MAX_QUEUES; i++) {
- v3d->queue[i].fence_context = dma_fence_context_alloc(1);
- memset(&v3d->queue[i].stats, 0, sizeof(v3d->queue[i].stats));
+ struct v3d_queue_state *queue = &v3d->queue[i];
+
+ queue->fence_context = dma_fence_context_alloc(1);
+ memset(&queue->stats, 0, sizeof(queue->stats));
+ seqcount_init(&queue->stats.lock);
}
spin_lock_init(&v3d->mm_lock);
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_s
[PATCH v2 3/4] drm/v3d: Create function to update a set of GPU stats
Given a set of GPU stats, that is, a `struct v3d_stats` related to a
queue in a given context, create a function that can update this set
of GPU stats.
Signed-off-by: Maíra Canal
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/v3d/v3d_sched.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index b6b5542c3fcf..b9614944931c 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -118,6 +118,14 @@ v3d_job_start_stats(struct v3d_job *job, enum v3d_queue
queue)
global_stats->start_ns = now;
}
+static void
+v3d_stats_update(struct v3d_stats *stats, u64 now)
+{
+ stats->enabled_ns += now - stats->start_ns;
+ stats->jobs_completed++;
+ stats->start_ns = 0;
+}
+
void
v3d_job_update_stats(struct v3d_job *job, enum v3d_queue queue)
{
@@ -127,13 +135,8 @@ v3d_job_update_stats(struct v3d_job *job, enum v3d_queue
queue)
struct v3d_stats *local_stats = &file->stats[queue];
u64 now = local_clock();
- local_stats->enabled_ns += now - local_stats->start_ns;
- local_stats->jobs_completed++;
- local_stats->start_ns = 0;
-
- global_stats->enabled_ns += now - global_stats->start_ns;
- global_stats->jobs_completed++;
- global_stats->start_ns = 0;
+ v3d_stats_update(local_stats, now);
+ v3d_stats_update(global_stats, now);
}
static struct dma_fence *v3d_bin_job_run(struct drm_sched_job *sched_job)
--
2.44.0
[PATCH v2 2/4] drm/v3d: Create a struct to store the GPU stats
This will make it easier to instantiate the GPU stats variables and it
will create a structure where we can store all the variables that refer
to GPU stats.
Note that, when we created the struct `v3d_stats`, we renamed
`jobs_sent` to `jobs_completed`. This better express the semantics of
the variable, as we are only accounting jobs that have been completed.
Signed-off-by: Maíra Canal
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/v3d/v3d_drv.c | 15 +++
drivers/gpu/drm/v3d/v3d_drv.h | 18 ++
drivers/gpu/drm/v3d/v3d_gem.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 20
drivers/gpu/drm/v3d/v3d_sysfs.c | 10 ++
5 files changed, 36 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3debf37e7d9b..52e3ba9df46f 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -115,14 +115,12 @@ v3d_open(struct drm_device *dev, struct drm_file *file)
v3d_priv->v3d = v3d;
for (i = 0; i < V3D_MAX_QUEUES; i++) {
- v3d_priv->enabled_ns[i] = 0;
- v3d_priv->start_ns[i] = 0;
- v3d_priv->jobs_sent[i] = 0;
-
sched = &v3d->queue[i].sched;
drm_sched_entity_init(&v3d_priv->sched_entity[i],
DRM_SCHED_PRIORITY_NORMAL, &sched,
1, NULL);
+
+ memset(&v3d_priv->stats[i], 0, sizeof(v3d_priv->stats[i]));
}
v3d_perfmon_open_file(v3d_priv);
@@ -151,20 +149,21 @@ static void v3d_show_fdinfo(struct drm_printer *p, struct
drm_file *file)
enum v3d_queue queue;
for (queue = 0; queue < V3D_MAX_QUEUES; queue++) {
+ struct v3d_stats *stats = &file_priv->stats[queue];
+
/* Note that, in case of a GPU reset, the time spent during an
* attempt of executing the job is not computed in the runtime.
*/
drm_printf(p, "drm-engine-%s: \t%llu ns\n",
v3d_queue_to_string(queue),
- file_priv->start_ns[queue] ?
file_priv->enabled_ns[queue]
- + timestamp -
file_priv->start_ns[queue]
- :
file_priv->enabled_ns[queue]);
+ stats->start_ns ? stats->enabled_ns + timestamp -
stats->start_ns
+ : stats->enabled_ns);
/* Note that we only count jobs that completed. Therefore, jobs
* that were resubmitted due to a GPU reset are not computed.
*/
drm_printf(p, "v3d-jobs-%s: \t%llu jobs\n",
- v3d_queue_to_string(queue),
file_priv->jobs_sent[queue]);
+ v3d_queue_to_string(queue), stats->jobs_completed);
}
}
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index ee3545226d7f..5a198924d568 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -36,15 +36,20 @@ static inline char *v3d_queue_to_string(enum v3d_queue
queue)
return "UNKNOWN";
}
+struct v3d_stats {
+ u64 start_ns;
+ u64 enabled_ns;
+ u64 jobs_completed;
+};
+
struct v3d_queue_state {
struct drm_gpu_scheduler sched;
u64 fence_context;
u64 emit_seqno;
- u64 start_ns;
- u64 enabled_ns;
- u64 jobs_sent;
+ /* Stores the GPU stats for this queue in the global context. */
+ struct v3d_stats stats;
};
/* Performance monitor object. The perform lifetime is controlled by userspace
@@ -188,11 +193,8 @@ struct v3d_file_priv {
struct drm_sched_entity sched_entity[V3D_MAX_QUEUES];
- u64 start_ns[V3D_MAX_QUEUES];
-
- u64 enabled_ns[V3D_MAX_QUEUES];
-
- u64 jobs_sent[V3D_MAX_QUEUES];
+ /* Stores the GPU stats for a specific queue for this fd. */
+ struct v3d_stats stats[V3D_MAX_QUEUES];
};
struct v3d_bo {
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index afc565078c78..d14589d3ae6c 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -248,9 +248,7 @@ v3d_gem_init(struct drm_device *dev)
for (i = 0; i < V3D_MAX_QUEUES; i++) {
v3d->queue[i].fence_context = dma_fence_context_alloc(1);
- v3d->queue[i].start_ns = 0;
- v3d->queue[i].enabled_ns = 0;
- v3d->queue[i].jobs_sent = 0;
+ memset(&v3d->queue[i].stats, 0, sizeof(v3d->queue[i].stats));
}
spin_lock_init(&v3d->mm_lock);
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 8ca61bcd4b1c..b6b5542c3fcf 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
[PATCH v2 0/4] drm/v3d: Fix GPU stats inconsistencies and race-condition
The first version of this series had the intention to fix two major issues with the GPU stats: 1. We were incrementing `enabled_ns` twice by the end of each job. 2. There is a race-condition between the IRQ handler and the users The first of the issues was already addressed and the fix was applied to drm-misc-fixes. Now, what is left, addresses the second issue. Apart from addressing this issue, this series improved the GPU stats code as a whole. We reduced code repetition as a whole, creating functions to start and update the GPU stats. This will likely reduce the odds of issue #1 happen again. Best Regards, - Maíra v1 -> v2: https://lore.kernel.org/dri-devel/20240403203517.731876-1-mca...@igalia.com/T/ * As the first patch was a bugfix, it was pushed to drm-misc-fixes. * [1/4]: Add Chema Casanova's R-b * [2/4]: s/jobs_sent/jobs_completed and add the reasoning in the commit message (Chema Casanova) * [2/4]: Add Chema Casanova's and Tvrtko Ursulin's R-b * [3/4]: Call `local_clock()` only once, by adding a new parameter to the `v3d_stats_update` function (Chema Casanova) * [4/4]: Move new line to the correct patch (2/4) (Tvrtko Ursulin) * [4/4]: Use `seqcount_t` as locking primitive instead of a `rw_lock` (Tvrtko Ursulin) Maíra Canal (4): drm/v3d: Create two functions to update all GPU stats variables drm/v3d: Create a struct to store the GPU stats drm/v3d: Create function to update a set of GPU stats drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler drivers/gpu/drm/v3d/v3d_drv.c | 19 +++ drivers/gpu/drm/v3d/v3d_drv.h | 40 +++--- drivers/gpu/drm/v3d/v3d_gem.c | 9 ++-- drivers/gpu/drm/v3d/v3d_irq.c | 48 ++--- drivers/gpu/drm/v3d/v3d_sched.c | 94 + drivers/gpu/drm/v3d/v3d_sysfs.c | 13 ++--- 6 files changed, 105 insertions(+), 118 deletions(-) -- 2.44.0
[PATCH v2 1/4] drm/v3d: Create two functions to update all GPU stats variables
Currently, we manually perform all operations to update the GPU stats
variables. Apart from the code repetition, this is very prone to errors,
as we can see on commit 35f4f8c9fc97 ("drm/v3d: Don't increment
`enabled_ns` twice").
Therefore, create two functions to manage updating all GPU stats
variables. Now, the jobs only need to call for `v3d_job_update_stats()`
when the job is done and `v3d_job_start_stats()` when starting the job.
Co-developed-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Maíra Canal
Reviewed-by: Jose Maria Casanova Crespo
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 +
drivers/gpu/drm/v3d/v3d_irq.c | 48 ++--
drivers/gpu/drm/v3d/v3d_sched.c | 80 +++--
3 files changed, 40 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 1950c723dde1..ee3545226d7f 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -543,6 +543,7 @@ void v3d_mmu_insert_ptes(struct v3d_bo *bo);
void v3d_mmu_remove_ptes(struct v3d_bo *bo);
/* v3d_sched.c */
+void v3d_job_update_stats(struct v3d_job *job, enum v3d_queue queue);
int v3d_sched_init(struct v3d_dev *v3d);
void v3d_sched_fini(struct v3d_dev *v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
index ce6b2fb341d1..d469bda52c1a 100644
--- a/drivers/gpu/drm/v3d/v3d_irq.c
+++ b/drivers/gpu/drm/v3d/v3d_irq.c
@@ -102,18 +102,8 @@ v3d_irq(int irq, void *arg)
if (intsts & V3D_INT_FLDONE) {
struct v3d_fence *fence =
to_v3d_fence(v3d->bin_job->base.irq_fence);
- struct v3d_file_priv *file =
v3d->bin_job->base.file->driver_priv;
- u64 runtime = local_clock() - file->start_ns[V3D_BIN];
-
- file->jobs_sent[V3D_BIN]++;
- v3d->queue[V3D_BIN].jobs_sent++;
-
- file->start_ns[V3D_BIN] = 0;
- v3d->queue[V3D_BIN].start_ns = 0;
-
- file->enabled_ns[V3D_BIN] += runtime;
- v3d->queue[V3D_BIN].enabled_ns += runtime;
+ v3d_job_update_stats(&v3d->bin_job->base, V3D_BIN);
trace_v3d_bcl_irq(&v3d->drm, fence->seqno);
dma_fence_signal(&fence->base);
status = IRQ_HANDLED;
@@ -122,18 +112,8 @@ v3d_irq(int irq, void *arg)
if (intsts & V3D_INT_FRDONE) {
struct v3d_fence *fence =
to_v3d_fence(v3d->render_job->base.irq_fence);
- struct v3d_file_priv *file =
v3d->render_job->base.file->driver_priv;
- u64 runtime = local_clock() - file->start_ns[V3D_RENDER];
-
- file->jobs_sent[V3D_RENDER]++;
- v3d->queue[V3D_RENDER].jobs_sent++;
-
- file->start_ns[V3D_RENDER] = 0;
- v3d->queue[V3D_RENDER].start_ns = 0;
-
- file->enabled_ns[V3D_RENDER] += runtime;
- v3d->queue[V3D_RENDER].enabled_ns += runtime;
+ v3d_job_update_stats(&v3d->render_job->base, V3D_RENDER);
trace_v3d_rcl_irq(&v3d->drm, fence->seqno);
dma_fence_signal(&fence->base);
status = IRQ_HANDLED;
@@ -142,18 +122,8 @@ v3d_irq(int irq, void *arg)
if (intsts & V3D_INT_CSDDONE(v3d->ver)) {
struct v3d_fence *fence =
to_v3d_fence(v3d->csd_job->base.irq_fence);
- struct v3d_file_priv *file =
v3d->csd_job->base.file->driver_priv;
- u64 runtime = local_clock() - file->start_ns[V3D_CSD];
-
- file->jobs_sent[V3D_CSD]++;
- v3d->queue[V3D_CSD].jobs_sent++;
-
- file->start_ns[V3D_CSD] = 0;
- v3d->queue[V3D_CSD].start_ns = 0;
-
- file->enabled_ns[V3D_CSD] += runtime;
- v3d->queue[V3D_CSD].enabled_ns += runtime;
+ v3d_job_update_stats(&v3d->csd_job->base, V3D_CSD);
trace_v3d_csd_irq(&v3d->drm, fence->seqno);
dma_fence_signal(&fence->base);
status = IRQ_HANDLED;
@@ -189,18 +159,8 @@ v3d_hub_irq(int irq, void *arg)
if (intsts & V3D_HUB_INT_TFUC) {
struct v3d_fence *fence =
to_v3d_fence(v3d->tfu_job->base.irq_fence);
- struct v3d_file_priv *file =
v3d->tfu_job->base.file->driver_priv;
- u64 runtime = local_clock() - file->start_ns[V3D_TFU];
-
- file->jobs_sent[V3D_TFU]++;
- v3d->queue[V3D_TFU].jobs_sent++;
-
- file->start_ns[V3D_TFU] = 0;
- v3d->queue[V3D_TFU].start_ns = 0;
-
- file->enabled_ns[V3D_TFU] += runtime;
- v3d->queue[V3D_TFU].enabled_ns += runtime;
+ v3d_job_update_stats(&v3d->tfu_job->base, V3D_TFU);
trace_v3d_tfu_irq(&v3d->drm, fence->seqno);
dma_fence_signal(&fence->base);
st
Re: [PATCH v5 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
Hi Dharma, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.9-rc4 next-20240416] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Dharma-Balasubiramani/dt-bindings-display-bridge-add-sam9x75-lvds-binding/20240405-123901 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20240405043536.274220-4-dharma.b%40microchip.com patch subject: [PATCH v5 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller reproduce: (https://download.01.org/0day-ci/archive/20240417/202404170727.uvhfx4sd-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202404170727.uvhfx4sd-...@intel.com/ All warnings (new ones prefixed by >>): Warning: Documentation/devicetree/bindings/power/wakeup-source.txt references a file that doesn't exist: Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt Warning: Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/siliconmitus,sm5703.yaml Warning: Documentation/devicetree/bindings/sound/fsl-asoc-card.txt references a file that doesn't exist: Documentation/devicetree/bindings/sound/fsl,asrc.txt Warning: Documentation/gpu/amdgpu/display/display-contributing.rst references a file that doesn't exist: Documentation/GPU/amdgpu/display/mpo-overview.rst >> Warning: MAINTAINERS references a file that doesn't exist: >> Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml Using alabaster theme -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
[PATCH 2/7] drm/msm/dsi: Pass bonded-DSI hdisplay/2 to DSC timing configuration
When configuring the timing of DSI hosts (interfaces) in
dsi_timing_setup() all values written to registers are taking bonded
DSI into account by dividing the original mode width by 2 (half the
data is sent over each of the two DSI hosts), but the full width
instead of the interface width is passed as hdisplay parameter to
dsi_update_dsc_timing().
Currently only msm_dsc_get_slices_per_intf() is called within
dsi_update_dsc_timing() with the `hdisplay` argument which clearly
documents that it wants the width of a single interface (which, again,
in bonded DSI mode is half the total width of the mode). Thus pass the
bonded-mode-adjusted hdisplay parameter into dsi_update_dsc_timing()
otherwise all values written to registers by this function (i.e. the
number of slices per interface or packet, and derived from this the EOL
byte number) are twice too large.
Inversely the panel driver is expected to only set the slice width and
number of slices for half the panel, i.e. what will be sent by each
host individually, rather than fixing that up like hdisplay here.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c80be74cf10b..9d0c940dcb28 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -987,7 +987,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host,
bool is_bonded_dsi)
if (msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) {
if (msm_host->dsc)
- dsi_update_dsc_timing(msm_host, false, mode->hdisplay);
+ dsi_update_dsc_timing(msm_host, false, hdisplay);
dsi_write(msm_host, REG_DSI_ACTIVE_H,
DSI_ACTIVE_H_START(ha_start) |
@@ -1008,7 +1008,7 @@ static void dsi_timing_setup(struct msm_dsi_host
*msm_host, bool is_bonded_dsi)
DSI_ACTIVE_VSYNC_VPOS_END(vs_end));
} else {/* command mode */
if (msm_host->dsc)
- dsi_update_dsc_timing(msm_host, true, mode->hdisplay);
+ dsi_update_dsc_timing(msm_host, true, hdisplay);
/* image data and 1 byte write_memory_start cmd */
if (!msm_host->dsc)
--
2.44.0
[PATCH 1/7] drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk
When dual-DSI (bonded DSI) was added in commit ed9976a09b48
("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints
were not updated, leading to print the original mode->clock rather
than the adjusted (typically the mode clock divided by two, though more
recently also adjusted for DSC compression) msm_host->pixel_clk_rate
which is passed to clk_set_rate() just below. Fix that by printing the
actual pixel_clk_rate that is being set.
Fixes: ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9d86a6aca6f2..c80be74cf10b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -356,8 +356,8 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
{
int ret;
- DBG("Set clk rates: pclk=%d, byteclk=%lu",
- msm_host->mode->clock, msm_host->byte_clk_rate);
+ DBG("Set clk rates: pclk=%lu, byteclk=%lu",
+ msm_host->pixel_clk_rate, msm_host->byte_clk_rate);
ret = dev_pm_opp_set_rate(&msm_host->pdev->dev,
msm_host->byte_clk_rate);
@@ -430,9 +430,9 @@ int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host)
{
int ret;
- DBG("Set clk rates: pclk=%d, byteclk=%lu, esc_clk=%lu, dsi_src_clk=%lu",
- msm_host->mode->clock, msm_host->byte_clk_rate,
- msm_host->esc_clk_rate, msm_host->src_clk_rate);
+ DBG("Set clk rates: pclk=%lu, byteclk=%lu, esc_clk=%lu,
dsi_src_clk=%lu",
+ msm_host->pixel_clk_rate, msm_host->byte_clk_rate,
+ msm_host->esc_clk_rate, msm_host->src_clk_rate);
ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
if (ret) {
--
2.44.0
[PATCH 6/7] drm/msm/dsi: Set PHY usescase before registering DSI host
Ordering issues here cause an uninitalized (default STANDALONE) usecase to be programmed (which appears to be a MUX) in some cases when msm_dsi_host_register() is called, leading to the slave PLL in bonded-DSI mode to source from a clock parent (dsi1vco) that is off. This should seemingly not be a problem as the actual dispcc clocks from DSI1 that are muxed in the clock tree of DSI0 are way further down, this bit still seems to have an effect on them somehow and causes the right side of the panel controlled by DSI1 to not function. In an ideal world this code is refactored to no longer have such error-prone calls "across subsystems", and instead model the "PLL src" register field as a regular mux so that changing the clock parents programmatically or in DTS via `assigned-clock-parents` has the desired effect. But for the avid reader, the clocks that we *are* muxing into DSI0's tree are way further down, so if this bit turns out to be a simple mux between dsiXvco and out_div, that shouldn't have any effect as this whole tree is off anyway. Signed-off-by: Marijn Suijten --- drivers/gpu/drm/msm/dsi/dsi_manager.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c index af2a287cb3bd..17f43b3c0494 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c @@ -85,6 +85,17 @@ static int dsi_mgr_setup_components(int id) msm_dsi : other_dsi; struct msm_dsi *slave_link_dsi = IS_MASTER_DSI_LINK(id) ? other_dsi : msm_dsi; + + /* PLL0 is to drive both 2 DSI link clocks in bonded DSI mode. +* +* Set the usecase before calling msm_dsi_host_register() to prevent it from +* enabling and configuring the usecase (which is just a mux bit) first. +*/ + msm_dsi_phy_set_usecase(clk_master_dsi->phy, + MSM_DSI_PHY_MASTER); + msm_dsi_phy_set_usecase(clk_slave_dsi->phy, + MSM_DSI_PHY_SLAVE); + /* Register slave host first, so that slave DSI device * has a chance to probe, and do not block the master * DSI device's probe. @@ -100,10 +111,6 @@ static int dsi_mgr_setup_components(int id) return ret; /* PLL0 is to drive both 2 DSI link clocks in bonded DSI mode. */ - msm_dsi_phy_set_usecase(clk_master_dsi->phy, - MSM_DSI_PHY_MASTER); - msm_dsi_phy_set_usecase(clk_slave_dsi->phy, - MSM_DSI_PHY_SLAVE); msm_dsi_host_set_phy_mode(msm_dsi->host, msm_dsi->phy); msm_dsi_host_set_phy_mode(other_dsi->host, other_dsi->phy); } -- 2.44.0
[PATCH 5/7] drm/msm/dpu: Correct dual-ctl -> dual-intf typo in comment
This comment one line down references a single, "same CTL" that controls
two interfaces, so the comment should clearly describe two interfaces
used with a single active CTL and not "two CTLs".
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index d9e7dbf0499c..7e849fe74801 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -428,7 +428,7 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
dpu_encoder_phys_vid_setup_timing_engine(phys_enc);
/*
-* For single flush cases (dual-ctl or pp-split), skip setting the
+* For single flush cases (dual-intf or pp-split), skip setting the
* flush bit for the slave intf, since both intfs use same ctl
* and HW will only flush the master.
*/
--
2.44.0
[PATCH 7/7] drm/msm/dpu: Rename `ctx` parameter to `intf` to match other functions
All other functions in dpu_hw_intf name the "self" parameter `intf`,
except dpu_hw_intf_setup_timing_engine() and the recently added
dpu_hw_intf_program_intf_cmd_cfg(). Clean that up for consistency.
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 965692ef7892..34d0c4e04d27 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -96,11 +96,11 @@
#define INTF_CFG2_DCE_DATA_COMPRESS BIT(12)
-static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx,
+static void dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *intf,
const struct dpu_hw_intf_timing_params *p,
const struct dpu_format *fmt)
{
- struct dpu_hw_blk_reg_map *c = &ctx->hw;
+ struct dpu_hw_blk_reg_map *c = &intf->hw;
u32 hsync_period, vsync_period;
u32 display_v_start, display_v_end;
u32 hsync_start_x, hsync_end_x;
@@ -118,7 +118,7 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
/* read interface_cfg */
intf_cfg = DPU_REG_READ(c, INTF_CONFIG);
- if (ctx->cap->type == INTF_DP)
+ if (intf->cap->type == INTF_DP)
dp_intf = true;
hsync_period = p->hsync_pulse_width + p->h_back_porch + p->width +
@@ -223,7 +223,7 @@ static void dpu_hw_intf_setup_timing_engine(struct
dpu_hw_intf *ctx,
DPU_REG_WRITE(c, INTF_FRAME_LINE_COUNT_EN, 0x3);
DPU_REG_WRITE(c, INTF_CONFIG, intf_cfg);
DPU_REG_WRITE(c, INTF_PANEL_FORMAT, panel_format);
- if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
+ if (intf->cap->features & BIT(DPU_DATA_HCTL_EN)) {
/*
* DATA_HCTL_EN controls data timing which can be different from
* video timing. It is recommended to enable it for all cases,
except
@@ -518,10 +518,10 @@ static void dpu_hw_intf_disable_autorefresh(struct
dpu_hw_intf *intf,
}
-static void dpu_hw_intf_program_intf_cmd_cfg(struct dpu_hw_intf *ctx,
+static void dpu_hw_intf_program_intf_cmd_cfg(struct dpu_hw_intf *intf,
struct dpu_hw_intf_cmd_mode_cfg
*cmd_mode_cfg)
{
- u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
+ u32 intf_cfg2 = DPU_REG_READ(&intf->hw, INTF_CONFIG2);
if (cmd_mode_cfg->data_compress)
intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
@@ -529,7 +529,7 @@ static void dpu_hw_intf_program_intf_cmd_cfg(struct
dpu_hw_intf *ctx,
if (cmd_mode_cfg->wide_bus_en)
intf_cfg2 |= INTF_CFG2_DATABUS_WIDEN;
- DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
+ DPU_REG_WRITE(&intf->hw, INTF_CONFIG2, intf_cfg2);
}
struct dpu_hw_intf *dpu_hw_intf_init(struct drm_device *dev,
--
2.44.0
[PATCH 4/7] drm/msm/dpu: Allow configuring multiple active DSC blocks
Just like the active interface and writeback block in ctl_intf_cfg_v1(),
and later the rest of the blocks in followup active-CTL fixes or
reworks, multiple calls to this function should enable additional DSC
blocks instead of overwriting the blocks that are enabled.
This pattern is observed in an active-CTL scenario since DPU 5.0.0 where
for example bonded-DSI uses a single CTL to drive multiple INTFs, and
each encoder calls this function individually with the INTF (hence the
pre-existing update instead of overwrite of this bitmask) and DSC blocks
it wishes to be enabled, and expects them to be OR'd into the bitmask.
The reverse already exists in reset_intf_cfg_v1() where only specified
DSC blocks are removed out of the CTL_DSC_ACTIVE bitmask (same for all
other blocks and ACTIVE bitmasks), leaving the rest enabled.
Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index a06f69d0b257..2e50049f2f85 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -545,6 +545,7 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
{
struct dpu_hw_blk_reg_map *c = &ctx->hw;
u32 intf_active = 0;
+ u32 dsc_active = 0;
u32 wb_active = 0;
u32 mode_sel = 0;
@@ -560,6 +561,7 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
intf_active = DPU_REG_READ(c, CTL_INTF_ACTIVE);
wb_active = DPU_REG_READ(c, CTL_WB_ACTIVE);
+ dsc_active = DPU_REG_READ(c, CTL_DSC_ACTIVE);
if (cfg->intf)
intf_active |= BIT(cfg->intf - INTF_0);
@@ -567,17 +569,18 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
if (cfg->wb)
wb_active |= BIT(cfg->wb - WB_0);
+ if (cfg->dsc)
+ dsc_active |= cfg->dsc;
+
DPU_REG_WRITE(c, CTL_TOP, mode_sel);
DPU_REG_WRITE(c, CTL_INTF_ACTIVE, intf_active);
DPU_REG_WRITE(c, CTL_WB_ACTIVE, wb_active);
+ DPU_REG_WRITE(c, CTL_DSC_ACTIVE, dsc_active);
if (cfg->merge_3d)
DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
BIT(cfg->merge_3d - MERGE_3D_0));
- if (cfg->dsc)
- DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
-
if (cfg->cdm)
DPU_REG_WRITE(c, CTL_CDM_ACTIVE, cfg->cdm);
}
--
2.44.0
[PATCH 3/7] drm/msm/dpu: Always flush the slave INTF on the CTL
As we can clearly see in a downstream kernel [1], flushing the slave INTF
is skipped /only if/ the PPSPLIT topology is active.
However, when DPU was originally submitted to mainline PPSPLIT was no
longer part of it (seems to have been ripped out before submission), but
this clause was incorrectly ported from the original SDE driver. Given
that there is no support for PPSPLIT (currently), flushing the slave
INTF should /never/ be skipped (as the `if (ppsplit && !master) goto
skip;` clause downstream never becomes true).
[1]:
https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index fc1d5736d7fc..489be1c0c704 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -448,9 +448,6 @@ static void dpu_encoder_phys_cmd_enable_helper(
_dpu_encoder_phys_cmd_pingpong_config(phys_enc);
- if (!dpu_encoder_phys_cmd_is_master(phys_enc))
- return;
-
ctl = phys_enc->hw_ctl;
ctl->ops.update_pending_flush_intf(ctl, phys_enc->hw_intf->idx);
}
--
2.44.0
[PATCH 0/7] drm/msm: Initial fixes for DUALPIPE (+DSC) topology
This series covers a step-up towards supporting the DUALPIPE DSC topology, also known as 2:2:2 topology (on active-CTL hardware). It involves 2 layer mixers, 2 DSC compression encoders, and 2 interfaces (on DSI, this is called bonded-DSI) where bandwidth constraints (e.g. 4k panels at 120Hz) require two interfaces to transmit pixel data. Enabling this topology will be hard(er) than downstream as hacking a layout type in DTS won't be describing the hardware, but "dynamically" determining it at runtime may pose some of a challenge that is left to a future series. Such changes will also involve the 1:1:1 topology needed for constrained hardware like the Fairphone 5 on SC7280 with access to only one DSC encoder and thus ruled out of the current 2:2:1 topology. Likewise, the patches and discussions around improving active-CTL configuration to support bonded interfaces (that share a single CTL block) are still in full swing and hence elided from this series, apart from one patch to fix the ACTIVE_DSC register coding to support updates, so that it is not forgotten about. Note that some patches are applicable to DSC-less DUALPIPE bonded mode as well, such as the patch that allows the slave interface to always be flushed as that is only supposed to be excluded in the yet-unsupported PPSPLIT topology. This series also contains some patches that I'm not too sure about: drm/msm/dpu: Correct dual-ctl -> dual-intf typo in comment Downstream doesn't skip the slave INTF flush on active-CTL [1] (again, just like cmdmode, only when PPSPLIT is enabled [2]), and even added an extra comment [1] explaining this case. Hence a dual-intf but single-flush case doesn't seem to exist as there's only one CTL according to the remainder of the comment. Maybe the whole comment is wrong? drm/msm/dsi: Set PHY usescase before registering DSI host It seems intentional to only set the usecase after msm_dsi_host_register() in case it fails, so maybe a non-zero `ret` here should reset the usecase? Likewise should the function call be moved in !IS_BONDED_DSI() above? Ideally we also understand what I am doing differently (maybe wrongly) in my panel driver that makes the PLL turn on and configure before the usecase has been set, even though these calls are messy and error-prone nevertheless. [1]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_vid.c?ref_type=heads#L794-804 [2]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139 Signed-off-by: Marijn Suijten --- Marijn Suijten (7): drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk drm/msm/dsi: Pass bonded-DSI hdisplay/2 to DSC timing configuration drm/msm/dpu: Always flush the slave INTF on the CTL drm/msm/dpu: Allow configuring multiple active DSC blocks drm/msm/dpu: Correct dual-ctl -> dual-intf typo in comment drm/msm/dsi: Set PHY usescase before registering DSI host drm/msm/dpu: Rename `ctx` parameter to `intf` to match other functions drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 9 ++--- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 14 +++--- drivers/gpu/drm/msm/dsi/dsi_host.c | 14 +++--- drivers/gpu/drm/msm/dsi/dsi_manager.c| 15 +++ 6 files changed, 32 insertions(+), 25 deletions(-) --- base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e change-id: 20240416-drm-msm-initial-dualpipe-dsc-fixes-3f0715b03bf4 Best regards, -- Marijn Suijten
[PATCH] drm/i915/gt: Refactor uabi engine class/instance list creation
For the upcoming changes we need a cleaner way to build the list
of uabi engines.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
just sending this patch to unburden the coming series from this
single patch inherited from a previously sent series.
Andi
drivers/gpu/drm/i915/gt/intel_engine_user.c | 29 -
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 833987015b8b..11cc06c0c785 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -203,7 +203,7 @@ static void engine_rename(struct intel_engine_cs *engine,
const char *name, u16
void intel_engines_driver_register(struct drm_i915_private *i915)
{
- u16 name_instance, other_instance = 0;
+ u16 class_instance[I915_LAST_UABI_ENGINE_CLASS + 2] = { };
struct legacy_ring ring = {};
struct list_head *it, *next;
struct rb_node **p, *prev;
@@ -214,6 +214,8 @@ void intel_engines_driver_register(struct drm_i915_private
*i915)
prev = NULL;
p = &i915->uabi_engines.rb_node;
list_for_each_safe(it, next, &engines) {
+ u16 uabi_class;
+
struct intel_engine_cs *engine =
container_of(it, typeof(*engine), uabi_list);
@@ -222,15 +224,14 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes));
engine->uabi_class = uabi_classes[engine->class];
- if (engine->uabi_class == I915_NO_UABI_CLASS) {
- name_instance = other_instance++;
- } else {
- GEM_BUG_ON(engine->uabi_class >=
- ARRAY_SIZE(i915->engine_uabi_class_count));
- name_instance =
-
i915->engine_uabi_class_count[engine->uabi_class]++;
- }
- engine->uabi_instance = name_instance;
+
+ if (engine->uabi_class == I915_NO_UABI_CLASS)
+ uabi_class = I915_LAST_UABI_ENGINE_CLASS + 1;
+ else
+ uabi_class = engine->uabi_class;
+
+ GEM_BUG_ON(uabi_class >= ARRAY_SIZE(class_instance));
+ engine->uabi_instance = class_instance[uabi_class]++;
/*
* Replace the internal name with the final user and log facing
@@ -238,11 +239,15 @@ void intel_engines_driver_register(struct
drm_i915_private *i915)
*/
engine_rename(engine,
intel_engine_class_repr(engine->class),
- name_instance);
+ engine->uabi_instance);
- if (engine->uabi_class == I915_NO_UABI_CLASS)
+ if (uabi_class > I915_LAST_UABI_ENGINE_CLASS)
continue;
+ GEM_BUG_ON(uabi_class >=
+ ARRAY_SIZE(i915->engine_uabi_class_count));
+ i915->engine_uabi_class_count[uabi_class]++;
+
rb_link_node(&engine->uabi_node, prev, p);
rb_insert_color(&engine->uabi_node, &i915->uabi_engines);
--
2.43.0
Re: [PATCH 3/3] drm/fourcc: Add documentation around drm_format_info
Le 15/04/24 - 15:00, Pekka Paalanen a écrit :
> On Tue, 09 Apr 2024 12:04:07 +0200
> Louis Chauvet wrote:
>
> > Let's provide more details about the drm_format_info structure because
> > its content may not be straightforward for someone not used to video
> > formats and drm internals.
> >
> > Signed-off-by: Louis Chauvet
> > ---
> > include/drm/drm_fourcc.h | 45 ++---
> > 1 file changed, 38 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index ccf91daa4307..66cc30e28f79 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -58,6 +58,44 @@ struct drm_mode_fb_cmd2;
> >
> > /**
> > * struct drm_format_info - information about a DRM format
> > + *
> > + * A drm_format_info describes how planes and pixels are stored in memory.
> > + *
> > + * Some format like YUV can have multiple planes, counted in @num_planes.
> > It
> > + * means that a full pixel can be stored in multiple non-continuous
> > buffers.
> > + * For example, NV12 is a YUV format using two planes: one for the Y
> > values and
> > + * one for the UV values.
> > + *
> > + * On each plane, the "pixel" unit can be different in case of
> > subsampling. For
> > + * example with the NV12 format, a pixel in the UV plane is used for four
> > pixels
> > + * in the Y plane.
> > + * The fields @hsub and @vsub are the relation between the size of the main
> > + * plane and the size of the subsampled planes in pixels:
> > + * plane[0] width = hsub * plane[1] width
> > + * plane[0] height = vsub * plane[1] height
>
> This makes it sound like plane[1] would be the one determining the
> image size. It is plane[0] that determines the image size (I don't know
> of a format that would have it otherwise), and vsub and hsub are used
> as divisors. It's in their name, too: horizontal/vertical sub-sampling.
>
> This is important for images with odd dimensions. If plane[1]
> determined the image size, it would be impossible to have odd sized
> NV12 images, for instance.
>
> Odd dimensions also imply something about rounding the size of the
> sub-sampled planes. I guess the rounding is up, not down?
I will change the equation to:
plane[1] = plane[0] / hsub (round up)
Can a DRM maintainer confirm the rounding up?
> > + *
> > + * In some formats, pixels are not independent in memory. It can be a
> > packed
>
> "Independent in memory" sounds to me like it describes sub-sampling:
> some pixel components are shared between multiple pixels. Here you seem
> to refer to just packing: one pixel's data may take a fractional number
> of bytes.
* In some formats, pixels are not individually addressable. It ...
> > + * representation to store more pixels per byte (for example P030 uses 4
> > bytes
> > + * for three 10 bit pixels). It can also be used to represent tiled
> > formats,
>
> s/tiled/block/
>
> Tiling is given by format modifiers rather than formats.
Fixed in the v2.
> > + * where a continuous buffer in memory can represent a rectangle of pixels
> > (for
> > + * example, in DRM_FORMAT_Y0L0, a buffer of 8 bytes represents a 2x2 pixel
> > + * region of the picture).
> > + * The field @char_per_block is the size of a block on a specific plane, in
> > + * bytes.
> > + * The fields @block_w and @block_h are the size of a block in pixels.
> > + *
> > + * The older format representation (which only uses @cpp, kept for
> > historical
>
> Move the paren to: representation which only uses @cpp (kept
>
> so that the sentence is still understandable if one skips the
> parenthesised part.
Fixed in v2.
> > + * reasons because there are a lot of places in drivers where it's used) is
> > + * assuming that a block is always 1x1 pixel.
> > + *
> > + * To keep the compatibility with older format representations and treat
> > block
> > + * and non-block formats in the same way one should use:
> > + * - @char_per_block to access the size of a block on a specific plane, in
> > + * bytes.
> > + * - drm_format_info_block_width() to access the width of a block of a
> > + * specific plane, in pixels.
> > + * - drm_format_info_block_height() to access the height of a block of a
> > + * specific plane, in pixels.
> > */
> > struct drm_format_info {
> > /** @format: 4CC format identifier (DRM_FORMAT_*) */
> > @@ -97,13 +135,6 @@ struct drm_format_info {
> > * formats for which the memory needed for a single pixel is not
> > * byte aligned.
> > *
> > -* @cpp has been kept for historical reasons because there are
> > -* a lot of places in drivers where it's used. In drm core for
> > -* generic code paths the preferred way is to use
> > -* @char_per_block, drm_format_info_block_width() and
> > -* drm_format_info_block_height() which allows handling both
> > -* block and non-block formats in the same way.
> > -
Re: [PATCH 2/3] drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc
Le 15/04/24 - 21:28, Bagas Sanjaya a écrit : > On Tue, Apr 09, 2024 at 12:04:06PM +0200, Louis Chauvet wrote: > > @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); > > * > > * Rotation is the specified amount in degrees in counter clockwise > > direction, > > * the X and Y axis are within the source rectangle, i.e. the X/Y axis > > before > > - * rotation. After reflection, the rotation is applied to the image > > sampled from > > - * the source rectangle, before scaling it to fit the destination > > rectangle. > > + * rotation. > > + * > > + * Here are some examples of rotation and reflections: > > + * > > + * |o +| REFLECT_X |+ o| > > + * || > || > > + * || || > > + * > > + * |o | REFLECT_Y |+ | > > + * || > || > > + * |+ | |o | > > + * > > + * |o +| ROTATE_90 |+ | > > + * || > || > > + * || |o | > > + * > > + * |o | ROTATE_180 | +| > > + * || > || > > + * |+ | | o| > > + * > > + * |o | ROTATE_270 |+ o| > > + * || > || > > + * |+ | || > > + * > > + * Rotation and reflection can be combined to handle more situations. In > > this condition, the > > + * reflection is applied first and the rotation in second. > > + * > > + * For example the expected result for DRM_MODE_ROTATE_90 | > > DRM_MODE_REFLECT_X is: > > + * > > + * |o +| REFLECT_X |+ o| ROTATE_90 |o | > > + * || > || > || > > + * || || |+ | > > + * > > + * It is not possible to pass multiple rotation at the same time. (i.e > > ROTATE_90 | ROTATE_180 is > > + * not the same as ROTATE_270 and is not accepted). > > Sphinx reports htmldocs warnings on these transformation diagrams: > > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:265: ERROR: > Undefined substitution referenced: "o +". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:265: ERROR: > Undefined substitution referenced: "+ o". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:273: ERROR: > Undefined substitution referenced: "o +". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:277: ERROR: > Undefined substitution referenced: "o | ROTATE_180 | +". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:277: ERROR: > Undefined substitution referenced: "+ | | o". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:281: ERROR: > Undefined substitution referenced: "o | ROTATE_270 |+ o". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:290: ERROR: > Undefined substitution referenced: "o +". > Documentation/gpu/drm-kms:389: ./drivers/gpu/drm/drm_blend.c:290: ERROR: > Undefined substitution referenced: "+ o". > > I have to wrap them in literal blocks: > > >8 > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 6fbb8730d8b022..f2cbf8d8efbbbc 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -259,36 +259,36 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); > * the X and Y axis are within the source rectangle, i.e. the X/Y axis > before > * rotation. > * > - * Here are some examples of rotation and reflections: > + * Here are some examples of rotation and reflections:: > * > - * |o +| REFLECT_X |+ o| > - * || > || > - * || || > + * |o +| REFLECT_X |+ o| > + * || > || > + * || || > * > - * |o | REFLECT_Y |+ | > - * || > || > - * |+ | |o | > + * |o | REFLECT_Y |+ | > + * || > || > + * |+ | |o | > * > - * |o +| ROTATE_90 |+ | > - * || > || > - * || |o | > + * |o +| ROTATE_90 |+ | > + * || > || > + * || |o | > * > - * |o | ROTATE_180 | +| > - * || > || > - * |+ | | o| > + * |o | ROTATE_180 | +| > + * || > || > + * |+ | | o| > * > - * |o | ROTATE_270 |+ o| > - * || > || > - * |+ | || > + * |o | ROTATE_270 |+ o| > + * || > || > + * |+ | || > * > * Rotation and reflection can be combined to handle more situations. In > this condition, the > * reflection is applied first and the rotation in second. > * > - * For example the expected result for DRM_MODE_ROTATE_90 | > DRM_MODE_REFLECT_X is: > + * For example the expected result for DRM_MODE_ROTATE_90 | > DRM_MODE_REFLECT_X is:: > * > - * |o +| REFLECT_X |+ o| ROTATE_90 |o | > - * || > || > || > - * || || |+ | > + * |o +| REFLECT_X |+ o| ROTATE_90 |o
Re: [PATCH 2/3] drm: drm_blend.c: Improve drm_plane_create_rotation_property kernel doc
Le 15/04/24 - 14:36, Pekka Paalanen a écrit : > On Tue, 09 Apr 2024 12:04:06 +0200 > Louis Chauvet wrote: > > > The expected behavior of the rotation property was not very clear. Add > > more examples to explain what is the expected result. > > > > Signed-off-by: Louis Chauvet > > --- > > drivers/gpu/drm/drm_blend.c | 52 > > + > > 1 file changed, 38 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > index 8d4b317eb9d7..6fbb8730d8b0 100644 > > --- a/drivers/gpu/drm/drm_blend.c > > +++ b/drivers/gpu/drm/drm_blend.c > > @@ -104,6 +104,9 @@ > > * Without this property the rectangle is only scaled, but not rotated or > > * reflected. > > * > > + * See drm_plane_create_rotation_property() for details about the expected > > rotation and > > + * reflection behavior. > > I think internal function docs should be referring to UAPI docs, and > not vice versa. Internal functions can change, but UAPI cannot. > > > + * > > * Possbile values: > > * > > * "rotate-": > > @@ -114,18 +117,6 @@ > > * Signals that the contents of a drm plane is reflected along the > > * axis, in the same way as mirroring. > > * > > - * reflect-x:: > > - * > > - * |o || o| > > - * | | -> | | > > - * | v||v | > > - * > > - * reflect-y:: > > - * > > - * |o || ^| > > - * | | -> | | > > - * | v||o | > > - * > > * zpos: > > * Z position is set up with drm_plane_create_zpos_immutable_property() and > > * drm_plane_create_zpos_property(). It controls the visibility of > > overlapping > > @@ -266,8 +257,41 @@ EXPORT_SYMBOL(drm_plane_create_alpha_property); > > * > > * Rotation is the specified amount in degrees in counter clockwise > > direction, > > * the X and Y axis are within the source rectangle, i.e. the X/Y axis > > before > > - * rotation. After reflection, the rotation is applied to the image > > sampled from > > - * the source rectangle, before scaling it to fit the destination > > rectangle. > > + * rotation. > > + * > > + * Here are some examples of rotation and reflections: > > + * > > + * |o +| REFLECT_X |+ o| > > + * || > || > > + * || || > > + * > > + * |o | REFLECT_Y |+ | > > + * || > || > > + * |+ | |o | > > + * > > + * |o +| ROTATE_90 |+ | > > + * || > || > > + * || |o | > > + * > > + * |o | ROTATE_180 | +| > > + * || > || > > + * |+ | | o| > > + * > > + * |o | ROTATE_270 |+ o| > > + * || > || > > + * |+ | || > > + * > > + * Rotation and reflection can be combined to handle more situations. In > > this condition, the > > + * reflection is applied first and the rotation in second. > > When going in which direction? Is the first image the FB source > rectangle contents, and the second image what the plane looks like in > CRTC frame of reference? The first is the FB source, the second is the expected result on the CRTC output. I will add a sentence before the schemas: * Here are some examples of rotation and reflections, on the left it is * the content of the source frame buffer, on the right is the expected * result on the CRTC output. > > > + * > > + * For example the expected result for DRM_MODE_ROTATE_90 | > > DRM_MODE_REFLECT_X is: > > + * > > + * |o +| REFLECT_X |+ o| ROTATE_90 |o | > > + * || > || > || > > + * || || |+ | > > + * > > + * It is not possible to pass multiple rotation at the same time. (i.e > > ROTATE_90 | ROTATE_180 is > > + * not the same as ROTATE_270 and is not accepted). > > */ > > int drm_plane_create_rotation_property(struct drm_plane *plane, > >unsigned int rotation, > > > > These are definitely improvements. I think they should just be in the > UAPI section rather than implementation details. So, somewhere in [1]? It feel strange because this is in the `GPU Driver Developer’s Guide` section, not a `UAPI interfaces`. [1]: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html Thanks, Louis Chauvet > Disclaimer again to everyone else: I cannot tell if this is the correct > documentation or its inverse. > > > Thanks, > pq -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH v2 09/11] drm/dp_mst: Add drm_dp_mst_aux_for_parent()
Add a function to get the AUX device of the parent of an MST port, used
by a follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch
(Ankit)
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 16
include/drm/display/drm_dp_mst_helper.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 46b99d5fe0086..3577786b5db2c 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -6010,6 +6010,22 @@ static bool drm_dp_mst_is_virtual_dpcd(struct
drm_dp_mst_port *port)
return false;
}
+/**
+ * drm_dp_mst_aux_for_parent() - Get the AUX device for an MST port's parent
+ * @port: MST port whose parent's AUX device is returned
+ *
+ * Return the AUX device for @port's parent or NULL if port's parent is the
+ * root port.
+ */
+struct drm_dp_aux *drm_dp_mst_aux_for_parent(struct drm_dp_mst_port *port)
+{
+ if (!port->parent || !port->parent->port_parent)
+ return NULL;
+
+ return &port->parent->port_parent->aux;
+}
+EXPORT_SYMBOL(drm_dp_mst_aux_for_parent);
+
/**
* drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
* @port: The port to check. A leaf of the MST tree with an attached display.
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index f00e32b0315d7..3546b58a121bc 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -954,6 +954,7 @@ bool drm_dp_mst_port_is_logical(struct drm_dp_mst_port
*port)
return port->port_num >= DP_MST_LOGICAL_PORT_0;
}
+struct drm_dp_aux *drm_dp_mst_aux_for_parent(struct drm_dp_mst_port *port);
struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port);
static inline struct drm_dp_mst_topology_state *
--
2.43.3
[PATCH v2 11/11] drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR rates
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
monitor results in a blank screen, at least on MTL platforms on UHBR
link rates with some (<30) uncompressed bpp values. Enabling compression
fixes the problem, so do that for now. Windows enables DSC always if the
sink supports it and forcing it to enable the mode without compression
leads to the same problem above (which suggests a panel issue with
uncompressed mode).
The same 5k mode on non-UHBR link rates is not affected and lower
resolution modes are not affected either. The problem is similar to the
one fixed by the HBLANK expansion quirk on Synaptics hubs, with the
difference that the problematic mode has a longer HBLANK duration. Also
the monitor doesn't report supporting HBLANK expansion; either its
internal MST hub does the expansion internally - similarly to the
Synaptics hub - or the issue has another root cause, but still related
to the mode's short HBLANK duration. Enable the quirk for the monitor
adjusting the detection for the above differences.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Tested-by: Khaled Almahallawy
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 023907da98581..79a615667aab1 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2281,6 +2281,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
/* Synaptics DP1.4 MST hubs require DSC for some modes on which it
applies HBLANK expansion. */
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
+ /* MediaTek panels (at least in U3224KBA) require DSC for modes with a
short HBLANK on UHBR links. */
+ { OUI(0x00, 0x0C, 0xE7), DEVICE_ID_ANY, false,
BIT(DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC) },
/* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
};
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index fb5e167c3c659..71b01f7631919 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -421,15 +421,22 @@ static int mode_hblank_period_ns(const struct
drm_display_mode *mode)
static bool
hblank_expansion_quirk_needs_dsc(const struct intel_connector *connector,
-const struct intel_crtc_state *crtc_state)
+const struct intel_crtc_state *crtc_state,
+const struct link_config_limits *limits)
{
const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
+ bool is_uhbr_sink = connector->mst_port &&
+
drm_dp_uhbr_channel_coding_supported(connector->mst_port->dpcd);
+ int hblank_limit = is_uhbr_sink ? 500 : 300;
if (!connector->dp.dsc_hblank_expansion_quirk)
return false;
- if (mode_hblank_period_ns(adjusted_mode) > 300)
+ if (is_uhbr_sink && !drm_dp_is_uhbr_rate(limits->max_rate))
+ return false;
+
+ if (mode_hblank_period_ns(adjusted_mode) > hblank_limit)
return false;
return true;
@@ -445,7 +452,7 @@ adjust_limits_for_dsc_hblank_expansion_quirk(const struct
intel_connector *conne
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
int min_bpp_x16 = limits->link.min_bpp_x16;
- if (!hblank_expansion_quirk_needs_dsc(connector, crtc_state))
+ if (!hblank_expansion_quirk_needs_dsc(connector, crtc_state, limits))
return true;
if (!dsc) {
@@ -1604,7 +1611,14 @@ static bool detect_dsc_hblank_expansion_quirk(const
struct intel_connector *conn
DP_DPCD_QUIRK_HBLANK_EXPANSION_REQUIRES_DSC))
return false;
- if (!(dpcd[DP_RECEIVE_PORT_0_CAP_0] & DP_HBLANK_EXPANSION_CAPABLE))
+ /*
+* UHBR (MST sink) devices requiring this quirk doesn't advertise the
+* HBLANK expansion support. Presuming that they perform HBLANK
+* expansion internally, or are affected by this issue on modes with a
+* short HBLANK for other reasons.
+*/
+ if (!drm_dp_uhbr_channel_coding_supported(dpcd) &&
+ !(dpcd[DP_RECEIVE_PORT_0_CAP_0] & DP_HBLANK_EXPANSION_CAPABLE))
return false;
drm_dbg_kms(&i915->drm,
--
2.43.3
[PATCH v2 08/11] drm/dp_mst: Factor out drm_dp_mst_port_is_logical()
Factor out a function to check if an MST port is logical, used by a
follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next
patch. (Ankit)
Cc: Lyude Paul
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 6 +++---
include/drm/display/drm_dp_mst_helper.h | 6 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index c193be3577f7a..46b99d5fe0086 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2274,7 +2274,7 @@ drm_dp_mst_port_add_connector(struct drm_dp_mst_branch
*mstb,
if (port->pdt != DP_PEER_DEVICE_NONE &&
drm_dp_mst_is_end_device(port->pdt, port->mcs) &&
- port->port_num >= DP_MST_LOGICAL_PORT_0)
+ drm_dp_mst_port_is_logical(port))
port->cached_edid = drm_edid_read_ddc(port->connector,
&port->aux.ddc);
@@ -4219,7 +4219,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
case DP_PEER_DEVICE_SST_SINK:
ret = connector_status_connected;
/* for logical ports - cache the EDID */
- if (port->port_num >= DP_MST_LOGICAL_PORT_0 &&
!port->cached_edid)
+ if (drm_dp_mst_port_is_logical(port) && !port->cached_edid)
port->cached_edid = drm_edid_read_ddc(connector,
&port->aux.ddc);
break;
case DP_PEER_DEVICE_DP_LEGACY_CONV:
@@ -5983,7 +5983,7 @@ static bool drm_dp_mst_is_virtual_dpcd(struct
drm_dp_mst_port *port)
return false;
/* Virtual DP Sink (Internal Display Panel) */
- if (port->port_num >= 8)
+ if (drm_dp_mst_port_is_logical(port))
return true;
/* DP-to-HDMI Protocol Converter */
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index cbcb49cb6a460..f00e32b0315d7 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -948,6 +948,12 @@ int __must_check drm_dp_mst_root_conn_atomic_check(struct
drm_connector_state *n
void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port);
void drm_dp_mst_put_port_malloc(struct drm_dp_mst_port *port);
+static inline
+bool drm_dp_mst_port_is_logical(struct drm_dp_mst_port *port)
+{
+ return port->port_num >= DP_MST_LOGICAL_PORT_0;
+}
+
struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port);
static inline struct drm_dp_mst_topology_state *
--
2.43.3
[PATCH v2 07/11] drm/dp: Add drm_dp_uhbr_channel_coding_supported()
Factor out a function to check for UHBR channel coding support used by a
follow-up patch in the patchset.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Reviewed-by: Manasi Navare
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
include/drm/display/drm_dp_helper.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 23808e9d41d5d..41127069b55e4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -225,7 +225,7 @@ static void intel_dp_set_dpcd_sink_rates(struct intel_dp
*intel_dp)
* Sink rates for 128b/132b. If set, sink should support all 8b/10b
* rates and 10 Gbps.
*/
- if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B)
{
+ if (drm_dp_uhbr_channel_coding_supported(intel_dp->dpcd)) {
u8 uhbr_rates = 0;
BUILD_BUG_ON(ARRAY_SIZE(intel_dp->sink_rates) <
ARRAY_SIZE(dp_rates) + 3);
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index baf9949ff96fc..8a64fe8d97af2 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -251,6 +251,12 @@ drm_dp_channel_coding_supported(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
}
+static inline bool
+drm_dp_uhbr_channel_coding_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B;
+}
+
static inline bool
drm_dp_alternate_scrambler_reset_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
--
2.43.3
[PATCH v2 01/11] drm/i915/dp: Fix DSC line buffer depth programming
Fix the calculation of the DSC line buffer depth. This is limited both
by the source's and sink's maximum line buffer depth, but the former one
was not taken into account. On all Intel platform's the source's maximum
buffer depth is 13, so the overall limit is simply the minimum of the
source/sink's limit, regardless of the DSC version.
This leaves the DSI DSC line buffer depth calculation as-is, trusting
VBT.
On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16
the line buffer depth was incorrectly programmed as 0, leading to a
corruption in color gradients / lines on the decompressed screen image.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal
Reviewed-by: Manasi Navare
Acked-by: Maarten Lankhorst
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 16 ++--
include/drm/display/drm_dsc.h | 3 ---
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 163da48bc4065..23808e9d41d5d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -89,6 +89,9 @@
#define DP_DSC_MAX_ENC_THROUGHPUT_034
#define DP_DSC_MAX_ENC_THROUGHPUT_140
+/* Max DSC line buffer depth supported by HW. */
+#define INTEL_DP_DSC_MAX_LINE_BUF_DEPTH13
+
/* DP DSC FEC Overhead factor in ppm = 1/(0.972261) = 1.028530 */
#define DP_DSC_FEC_OVERHEAD_FACTOR 1028530
@@ -1705,7 +1708,6 @@ static int intel_dp_dsc_compute_params(const struct
intel_connector *connector,
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct drm_dsc_config *vdsc_cfg = &crtc_state->dsc.config;
- u8 line_buf_depth;
int ret;
/*
@@ -1734,20 +1736,14 @@ static int intel_dp_dsc_compute_params(const struct
intel_connector *connector,
connector->dp.dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP -
DP_DSC_SUPPORT] &
DP_DSC_RGB;
- line_buf_depth = drm_dp_dsc_sink_line_buf_depth(connector->dp.dsc_dpcd);
- if (!line_buf_depth) {
+ vdsc_cfg->line_buf_depth = min(INTEL_DP_DSC_MAX_LINE_BUF_DEPTH,
+
drm_dp_dsc_sink_line_buf_depth(connector->dp.dsc_dpcd));
+ if (!vdsc_cfg->line_buf_depth) {
drm_dbg_kms(&i915->drm,
"DSC Sink Line Buffer Depth invalid\n");
return -EINVAL;
}
- if (vdsc_cfg->dsc_version_minor == 2)
- vdsc_cfg->line_buf_depth = (line_buf_depth ==
DSC_1_2_MAX_LINEBUF_DEPTH_BITS) ?
- DSC_1_2_MAX_LINEBUF_DEPTH_VAL : line_buf_depth;
- else
- vdsc_cfg->line_buf_depth = (line_buf_depth >
DSC_1_1_MAX_LINEBUF_DEPTH_BITS) ?
- DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
-
vdsc_cfg->block_pred_enable =
connector->dp.dsc_dpcd[DP_DSC_BLK_PREDICTION_SUPPORT -
DP_DSC_SUPPORT] &
DP_DSC_BLK_PREDICTION_IS_SUPPORTED;
diff --git a/include/drm/display/drm_dsc.h b/include/drm/display/drm_dsc.h
index bc90273d06a62..bbbe7438473d3 100644
--- a/include/drm/display/drm_dsc.h
+++ b/include/drm/display/drm_dsc.h
@@ -40,9 +40,6 @@
#define DSC_PPS_RC_RANGE_MINQP_SHIFT 11
#define DSC_PPS_RC_RANGE_MAXQP_SHIFT 6
#define DSC_PPS_NATIVE_420_SHIFT 1
-#define DSC_1_2_MAX_LINEBUF_DEPTH_BITS 16
-#define DSC_1_2_MAX_LINEBUF_DEPTH_VAL 0
-#define DSC_1_1_MAX_LINEBUF_DEPTH_BITS 13
/**
* struct drm_dsc_rc_range_parameters - DSC Rate Control range parameters
--
2.43.3
Re: [PATCH v2 00/12] drm/imx/ipuv3: switch LDB and parallel-display driver to use drm_bridge_connector
On Sun, Mar 31, 2024 at 11:28:57PM +0300, Dmitry Baryshkov wrote: > The IPUv3 DRM i.MX driver contains several codepaths for different > usescases: both LDB and paralllel-display drivers handle next-bridge, > panel and the legacy display-timings DT node on their own. > > Drop unused ddc-i2c-bus and edid handling (none of the DT files merged > upstream ever used these features), switch to panel-bridge driver, > removing the need to handle drm_panel codepaths separately and finally > switch to drm_bridge_connector, removing requirement for the downstream > bridges to create drm_connector on their own. > > This has been tested on the iMX53 with the DPI panel attached to LDB via > LVDS decoder, using all possible usecases (lvds-codec + panel, panel > linked directly to LDB node and the display-timings node). > > Signed-off-by: Dmitry Baryshkov > --- > Changes in v2: > - Fixed drm_bridge_attach flags in imx/parallel-display driver. > - Moved the legacy bridge to drivers/gpu/drm/bridge > - Added missing EXPORT_SYMBOL_GPL to the iMX legacy bridge > - Link to v1: > https://lore.kernel.org/r/20240311-drm-imx-cleanup-v1-0-e104f05ca...@linaro.org Phillip, Shawn, Sascha, any comments on this patchset? -- With best wishes Dmitry
[linux-next:master] BUILD REGRESSION 66e4190e92ce0e4a50b2f6be0e5f5b2e47e072f4
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 66e4190e92ce0e4a50b2f6be0e5f5b2e47e072f4 Add linux-next specific files for 20240416 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404161933.izfqz32k-...@intel.com https://lore.kernel.org/oe-kbuild-all/202404170348.thxrbof1-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arc/include/asm/cmpxchg.h:50:26: error: implicit declaration of function 'cmpxchg_emu_u8' [-Werror=implicit-function-declaration] arch/mips/sgi-ip27/ip27-irq.c:280:13: warning: unused variable 'i' [-Wunused-variable] netdev.c:(.text+0x2288): undefined reference to `page_pool_create' netdev.c:(.text+0x378): undefined reference to `page_pool_alloc_pages' Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- alpha-randconfig-r112-20240416 | `-- kernel-bpf-verifier.c:sparse:sparse:cast-truncates-bits-from-constant-value-(fffc-becomes-) |-- arc-allmodconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-allnoconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-allyesconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-defconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-nsimosci_hs_smp_defconfig | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-randconfig-001-20240416 | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arc-randconfig-002-20240416 | `-- arch-arc-include-asm-cmpxchg.h:error:implicit-declaration-of-function-cmpxchg_emu_u8 |-- arm-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- arm-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- csky-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- csky-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- i386-randconfig-141-20240416 | |-- drivers-pwm-core.c-pwm_cdev_ioctl()-warn:possible-spectre-second-half.-pwm | `-- drivers-pwm-core.c-pwm_cdev_ioctl()-warn:potential-spectre-issue-cdata-pwm-r |-- loongarch-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- loongarch-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- microblaze-allmodconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- microblaze-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and | `-- drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size |-- mips-ip27_defconfig | `-- arch-mips-sgi-ip27-ip27-irq.c:warning:unused-variable-i |-- openrisc-allyesconfig | |-- drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-
Re: [PATCH v2 9/9] drm/xe: Add a shrinker for xe bos
Hi Thomas, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-xe/drm-xe-next] [also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.9-rc4 next-20240416] [cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-ttm-Allow-TTM-LRU-list-nodes-of-different-types/20240416-181717 base: https://gitlab.freedesktop.org/drm/xe/kernel.git drm-xe-next patch link: https://lore.kernel.org/r/20240416100730.-10-thomas.hellstrom%40linux.intel.com patch subject: [PATCH v2 9/9] drm/xe: Add a shrinker for xe bos config: i386-buildonly-randconfig-001-20240417 (https://download.01.org/0day-ci/archive/20240417/202404170528.tbjgqkcr-...@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240417/202404170528.tbjgqkcr-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202404170528.tbjgqkcr-...@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/xe/xe_bo.c:2420: >> drivers/gpu/drm/xe/tests/xe_bo.c:382:6: warning: format specifies type >> 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') >> [-Wformat] 381 | kunit_info(test, "Free ram is %lu bytes. Will allocate twice of that.\n", | ~~~ | %zu 382 |total); |^ include/kunit/test.h:546:39: note: expanded from macro 'kunit_info' 546 | kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__) | ~~~^~~ include/kunit/test.h:534:21: note: expanded from macro 'kunit_printk' 533 | kunit_log(lvl, test, KUNIT_SUBTEST_INDENT "# %s: " fmt, \ |~~~ 534 | (test)->name, ##__VA_ARGS__) | ^~~ include/kunit/test.h:527:21: note: expanded from macro 'kunit_log' 527 | printk(lvl fmt, ##__VA_ARGS__); \ |~~~^~~ include/linux/printk.h:457:60: note: expanded from macro 'printk' 457 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__) | ~~~ ^~~ include/linux/printk.h:429:19: note: expanded from macro 'printk_index_wrap' 429 | _p_func(_fmt, ##__VA_ARGS__); \ | ^~~ In file included from drivers/gpu/drm/xe/xe_bo.c:2420: >> drivers/gpu/drm/xe/tests/xe_bo.c:382:6: warning: format specifies type >> 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') >> [-Wformat] 381 | kunit_info(test, "Free ram is %lu bytes. Will allocate twice of that.\n", | ~~~ | %zu 382 |total); |^ include/kunit/test.h:546:39: note: expanded from macro 'kunit_info' 546 | kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__) | ~~~^~~ include/kunit/test.h:534:21: note: expanded from macro 'kunit_printk' 533 | kunit_log(lvl, test, KUNIT_SUBTEST_INDENT "# %s: " fmt, \ |~~~ 534 | (test)->name, ##__VA_ARGS__) | ^~~ include/kunit/test.h:529:8: note: expanded from macro 'kunit_log' 528 | kunit_log_append((test_or_suite)->log, fmt, \ | ~~~ 529 | ##__VA_ARGS__); \ |^~~ 2 warni
Re: [PATCH] drm/dp: correct struct member name in documentation
On Thu, Apr 11, 2024 at 12:55:29PM -0400, Golani, Mitulkumar Ajitkumar wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Wednesday, April 10, 2024 9:49 PM
> > To: Golani, Mitulkumar Ajitkumar ;
> > tzimmerm...@suse.de; mrip...@kernel.org;
> > maarten.lankho...@linux.intel.com
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org;
> > Nautiyal,
> > Ankit K ; Nikula, Jani ;
> > s...@canb.auug.org.au
> > Subject: Re: [PATCH] drm/dp: correct struct member name in documentation
> >
> > On Fri, Apr 05, 2024 at 12:21:59PM +0530, Mitul Golani wrote:
> > > Correct struct member name to 'mode' instead of 'operation mode'
> > > in 'drm_dp_as_sdp' structure description.
> > >
> > > Fixes: 0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
> >
> > Probably good to avoid this 'Fixes:' tag, and only use that for real code
> > bugs.
>
> Thank you for inputs.. I understood and I will take the future note. Please
> suggest if required to update the change with new revision or we can take
> care while merge.. ?
I can remove it while merging.
I just need an ack from drm or drm-misc maintainers to merge this through
drm-intel-next.
Sima, Dave?
>
> >
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> >
> > drm-misc folks, ack to get this through drm-intel-next, where the original
> > patch
> > is?
> >
> > Thanks,
> > Rodrigo
> >
> > > Cc: Mitul Golani
> > > Cc: Ankit Nautiyal
> > > Cc: Jani Nikula
> > > Signed-off-by: Mitul Golani
> >
> > > ---
> > > include/drm/display/drm_dp_helper.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/drm/display/drm_dp_helper.h
> > > b/include/drm/display/drm_dp_helper.h
> > > index baf9949ff96f..6799f57d635c 100644
> > > --- a/include/drm/display/drm_dp_helper.h
> > > +++ b/include/drm/display/drm_dp_helper.h
> > > @@ -112,7 +112,7 @@ struct drm_dp_vsc_sdp {
> > > * @target_rr: Target Refresh
> > > * @duration_incr_ms: Successive frame duration increase
> > > * @duration_decr_ms: Successive frame duration decrease
> > > - * @operation_mode: Adaptive Sync Operation Mode
> > > + * @mode: Adaptive Sync Operation Mode
> > > */
> > > struct drm_dp_as_sdp {
> > > unsigned char sdp_type;
> > > --
> > > 2.25.1
> > >
Re: [PATCH V2 2/2] arm64: dts: imx8mp-beacon-kit: Enable HDMI bridge HPD
On Mon, Mar 4, 2024 at 6:49 PM Adam Ford wrote:
>
> The DSI to HDMI bridge supports hot-plut-detect, but the
> driver didn't previously support a shared IRQ GPIO. With
> the driver updated, the interrupt can be added to the bridge.
>
> Signed-off-by: Adam Ford
> Reviewed-by: Laurent Pinchart
Shawn,
Patch 1/2 has been applied and sits in linux-next. Are you OK to
apply this to the IMX branch so the hot-plug detection can work?
Thank you,
adam
adam
> ---
> V2: No Change
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> index a08057410bde..fba8fd04398d 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-beacon-kit.dts
> @@ -304,6 +304,8 @@ adv_bridge: hdmi@3d {
> compatible = "adi,adv7535";
> reg = <0x3d>, <0x3c>, <0x3e>, <0x3f>;
> reg-names = "main", "cec", "edid", "packet";
> + interrupt-parent = <&gpio4>;
> + interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> adi,dsi-lanes = <4>;
> #sound-dai-cells = <0>;
>
> --
> 2.43.0
>
Re: [PATCH] drm: Fix no_vblank field references in documentation
On 4/16/24 2:00 PM, Marijn Suijten wrote: > Hi Randy, > > [..] > >> Do you see differences in the generated html for these changes? > > I have not yet generated the HTML locally to test this patch, but will surely > do > if that's a requirement. > >> "&struct somestruct" and "&somestruct" should both be OK AFAIK, although >> Documentation/doc-guide/kernel-doc.rst seems to say that using >> "&struct somestruct" is preferred. > > Keep in mind that this patch is about field/member references. Quoting the > relevant paragraph under "Highlights and cross-references": > > ``&struct_name->member`` or ``&struct_name.member`` > Structure or union member reference. The cross-reference will be to the > struct > or union definition, not the member directly. > > This lacks the struct tag entirely, and observation shows that links with them > don't highlight correctly (hence this patch) while member links without struct > tag are clickable and have an anchor link to their parent struct. Alrigthy. Thank you. -- #Randy https://people.kernel.org/tglx/notes-about-netiquette https://subspace.kernel.org/etiquette.html
Re: [PATCH] drm: Fix no_vblank field references in documentation
Hi Randy, [..] > Do you see differences in the generated html for these changes? I have not yet generated the HTML locally to test this patch, but will surely do if that's a requirement. > "&struct somestruct" and "&somestruct" should both be OK AFAIK, although > Documentation/doc-guide/kernel-doc.rst seems to say that using > "&struct somestruct" is preferred. Keep in mind that this patch is about field/member references. Quoting the relevant paragraph under "Highlights and cross-references": ``&struct_name->member`` or ``&struct_name.member`` Structure or union member reference. The cross-reference will be to the struct or union definition, not the member directly. This lacks the struct tag entirely, and observation shows that links with them don't highlight correctly (hence this patch) while member links without struct tag are clickable and have an anchor link to their parent struct. - Marijn
Re: [PATCH v3 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
On 2024-04-16 20:30:49, David Wronek wrote:
> Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
> Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
>
> Signed-off-by: David Wronek
> ---
> drivers/gpu/drm/panel/Kconfig | 14 +
> drivers/gpu/drm/panel/Makefile| 1 +
> drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367
> ++
> 3 files changed, 382 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 154f5bf82980..5b3eeb93b1a2 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
> Say Y here if you want to enable support for Raydium RM692E5-based
> display panels, such as the one found in the Fairphone 5 smartphone.
>
> +config DRM_PANEL_RAYDIUM_RM69380
> + tristate "Raydium RM69380-based DSI panel"
> + depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_DISPLAY_DP_HELPER
"DRM DisplayPort helpers"
But you said that this is a DSI device?
Looking in -next from yesterday, Raydium-RM692E5 and Visionox-R66451 get this
wrong as well.
> + depends on DRM_DISPLAY_HELPER
This also looks unused? The only helpers in the non-DP non-HDMI helper points
to more DP AUX code.
> + depends on DRM_MIPI_DSI
> + depends on OF
As I've shown in the SOFEF00 cleanup patch, devm_gpiod_get() is used which is
behind GPIOLIB. This should probably be a dependency.
> + help
> + Say Y here if you want to enable support for Raydium RM69380-based
> + display panels.
> +
> + This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
> + in combination with an EDO OLED panel.
> +
> config DRM_PANEL_RONBO_RB070D30
> tristate "Ronbo Electronics RB070D30 panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 24a02655d726..e2a2807d4ef0 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> panel-raspberrypi-touchscreen
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
> +obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
> obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> new file mode 100644
> index ..f89230c969b7
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
> @@ -0,0 +1,367 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
> tree.
> + * Copyright (c) 2024 David Wronek
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct rm69380_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi[2];
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static inline
> +struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
> +{
> + return container_of(panel, struct rm69380_panel, panel);
> +}
> +
> +static void rm69380_reset(struct rm69380_panel *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(15000, 16000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(1, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + msleep(30);
> +}
> +
> +static int rm69380_on(struct rm69380_panel *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi[0];
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> + if (ctx->dsi[1])
> + ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
> + mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
Is this MIPI_DCS_NOP? Strange to see that with a parameter.
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
> + mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
> + mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
> + mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
> + mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
> + mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x28);
Separate from this patch, I feel like we should document these bits. Their
meaning might be defined by a paywall, intersecting a few downstream DTS with
Re: [PATCH] drm: Fix no_vblank field references in documentation
Hi,
On 4/16/24 12:29 PM, Marijn Suijten wrote:
> Browsing the DRM documentation shows that drm_crtc_state.no_vblank
> is not turned into a reference to the no_vblank field, but rather a
> reference to `struct drm_crtc_state`. The only difference with other
> field references is that the struct name is prefixed by the literal
> `struct` tag, despite also already having a `&` reference prefix in two
> of the three cases. Remove the `struct` prefix to turn these references
> into proper links to the designated field.
>
> Fixes: 7beb691f1e6f ("drm: Initialize struct drm_crtc_state.no_vblank from
> device settings")
> Signed-off-by: Marijn Suijten
> ---
> Note that a simple regex like "&struct \w+\.\w+" shows that there are
> only a handful of violators, most of them inside DRM files. Let me know
> if you'd like a v2 that addresses all of them in one go (in separate
> patches or one combined change)?
>
> Kind regards,
> Marijn
> ---
> drivers/gpu/drm/drm_vblank.c| 2 +-
> include/drm/drm_crtc.h | 2 +-
> include/drm/drm_simple_kms_helper.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 702a12bc93bd..45504732f98e 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -140,7 +140,7 @@
> * must not call drm_vblank_init(). For such drivers, atomic helpers will
> * automatically generate fake vblank events as part of the display update.
> * This functionality also can be controlled by the driver by enabling and
> - * disabling struct drm_crtc_state.no_vblank.
> + * disabling &drm_crtc_state.no_vblank.
> */
>
> /* Retry timestamp calculation up to 3 times to satisfy
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 8b48a1974da3..eb75d0aec170 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -342,7 +342,7 @@ struct drm_crtc_state {
>*that case.
>*
>* For very simple hardware without VBLANK interrupt, enabling
> - * &struct drm_crtc_state.no_vblank makes DRM's atomic commit helpers
> + * &drm_crtc_state.no_vblank makes DRM's atomic commit helpers
>* send a fake VBLANK event at the end of the display update after all
>* hardware changes have been applied. See
>* drm_atomic_helper_fake_vblank().
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index b2486d073763..6e64d91819e7 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -102,7 +102,7 @@ struct drm_simple_display_pipe_funcs {
>* drm_crtc_arm_vblank_event(), when the driver supports vblank
>* interrupt handling, or drm_crtc_send_vblank_event() for more
>* complex case. In case the hardware lacks vblank support entirely,
> - * drivers can set &struct drm_crtc_state.no_vblank in
> + * drivers can set &drm_crtc_state.no_vblank in
>* &struct drm_simple_display_pipe_funcs.check and let DRM's
>* atomic helper fake a vblank event.
>*/
>
> ---
> base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
> change-id: 20240416-drm-no_vblank-kdoc-link-fea1b53008a3
Do you see differences in the generated html for these changes?
"&struct somestruct" and "&somestruct" should both be OK AFAIK, although
Documentation/doc-guide/kernel-doc.rst seems to say that using
"&struct somestruct" is preferred.
--
#Randy
https://people.kernel.org/tglx/notes-about-netiquette
https://subspace.kernel.org/etiquette.html
[PATCH v4 6/7] drm: xlnx: zynqmp_dpsub: Set input live format
Program live video input format according to selected media bus format.
In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
almost certainly supports a single media bus format as its output. Expect
this to be delivered via the new bridge atomic state. Program DPSUB
registers accordingly.
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 92 --
drivers/gpu/drm/xlnx/zynqmp_disp.h | 2 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 13 --
3 files changed, 90 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 8cdd74a9b772..13157da0089e 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -436,19 +436,29 @@ static void zynqmp_disp_avbuf_set_format(struct
zynqmp_disp *disp,
const struct zynqmp_disp_format *fmt)
{
unsigned int i;
- u32 val;
+ u32 val, reg;
- val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
- val &= zynqmp_disp_layer_is_video(layer)
- ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
- : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
- val |= fmt->buf_fmt;
- zynqmp_disp_avbuf_write(disp, ZYNQMP_DISP_AV_BUF_FMT, val);
+ layer->disp_fmt = fmt;
+ if (layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE) {
+ reg = ZYNQMP_DISP_AV_BUF_FMT;
+ val = zynqmp_disp_avbuf_read(disp, ZYNQMP_DISP_AV_BUF_FMT);
+ val &= zynqmp_disp_layer_is_video(layer)
+ ? ~ZYNQMP_DISP_AV_BUF_FMT_NL_VID_MASK
+ : ~ZYNQMP_DISP_AV_BUF_FMT_NL_GFX_MASK;
+ val |= fmt->buf_fmt;
+ zynqmp_disp_avbuf_write(disp, reg, val);
+ } else {
+ reg = zynqmp_disp_layer_is_video(layer)
+ ? ZYNQMP_DISP_AV_BUF_LIVE_VID_CONFIG
+ : ZYNQMP_DISP_AV_BUF_LIVE_GFX_CONFIG;
+ val = fmt->buf_fmt;
+ zynqmp_disp_avbuf_write(disp, reg, val);
+ }
for (i = 0; i < ZYNQMP_DISP_AV_BUF_NUM_SF; i++) {
- unsigned int reg = zynqmp_disp_layer_is_video(layer)
-? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
-: ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
+ reg = zynqmp_disp_layer_is_video(layer)
+ ? ZYNQMP_DISP_AV_BUF_VID_COMP_SF(i)
+ : ZYNQMP_DISP_AV_BUF_GFX_COMP_SF(i);
zynqmp_disp_avbuf_write(disp, reg, fmt->sf[i]);
}
@@ -926,6 +936,31 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer
*layer,
return NULL;
}
+/**
+ * zynqmp_disp_layer_find_live_format - Find format information for given
+ * media bus format
+ * @layer: The layer
+ * @drm_fmt: Media bus format to search
+ *
+ * Search display subsystem format information corresponding to the given media
+ * bus format @media_bus_format for the @layer, and return a pointer to the
+ * format descriptor.
+ *
+ * Return: A pointer to the format descriptor if found, NULL otherwise
+ */
+static const struct zynqmp_disp_format *
+zynqmp_disp_layer_find_live_format(struct zynqmp_disp_layer *layer,
+ u32 media_bus_format)
+{
+ unsigned int i;
+
+ for (i = 0; i < layer->info->num_formats; i++)
+ if (layer->info->formats[i].bus_fmt == media_bus_format)
+ return &layer->info->formats[i];
+
+ return NULL;
+}
+
/**
* zynqmp_disp_layer_drm_formats - Return the DRM formats supported by the
layer
* @layer: The layer
@@ -1040,6 +1075,9 @@ void zynqmp_disp_layer_disable(struct zynqmp_disp_layer
*layer)
* @layer: The layer
* @info: The format info
*
+ * NOTE: Use zynqmp_disp_layer_set_live_format() to set media bus format for
+ * live video layers.
+ *
* Set the format for @layer to @info. The layer must be disabled.
*/
void zynqmp_disp_layer_set_format(struct zynqmp_disp_layer *layer,
@@ -1047,14 +1085,16 @@ void zynqmp_disp_layer_set_format(struct
zynqmp_disp_layer *layer,
{
unsigned int i;
+ if (WARN_ON(layer->mode != ZYNQMP_DPSUB_LAYER_NONLIVE))
+ return;
+
layer->disp_fmt = zynqmp_disp_layer_find_format(layer, info->format);
+ if (WARN_ON(!layer->disp_fmt))
+ return;
layer->drm_fmt = info;
zynqmp_disp_avbuf_set_format(layer->disp, layer, layer->disp_fmt);
- if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
- return;
-
/*
* Set pconfig for each DMA channel to indicate they're part of a
* video group.
@@ -1074,6 +1114,32 @@ void zynqmp_disp_layer_set_format(struct
zynqmp_disp_layer *layer,
}
}
+/**
+ * zynqmp_disp_layer_set_live_format - Set the live video layer format
+ * @layer: The layer
+ * @info: The format info
+ *
+ * NOTE: This function should not be used to set for
[PATCH v4 7/7] drm/atomic-helper: Add select_output_bus_format callback
Add optional drm_crtc_helper_funcs.select_output_bus_format callback. This
callback allows to negotiate compatible media bus format on the link
between CRTC and connected DRM encoder or DRM bridge chain. A good usage
example is the CRTC implemented as FPGA soft IP. This kind of CRTC will
most certainly support a single output media bus format, as supporting
multiple runtime options consumes extra FPGA resources. A variety of
options for the FPGA designs are usually achieved by synthesizing IP with
different parameters.
Add drm_helper_crtc_select_output_bus_format that wraps
drm_crtc_helper_funcs.select_output_bus_format.
Incorporate select_output_bus_format callback into the format negotiation
stage to fix the input bus format of the first DRM bridge in the chain.
Save negotiated output media bus format in drm_crtc_state.
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/drm_bridge.c | 14 ++--
drivers/gpu/drm/drm_crtc_helper.c| 38
include/drm/drm_crtc.h | 11 +
include/drm/drm_crtc_helper.h| 5 +
include/drm/drm_modeset_helper_vtables.h | 30 +
5 files changed, 96 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 521a71c61b16..955ca108cd4b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -879,7 +880,8 @@ static int select_bus_fmt_recursive(struct drm_bridge
*first_bridge,
unsigned int i, num_in_bus_fmts = 0;
struct drm_bridge_state *cur_state;
struct drm_bridge *prev_bridge;
- u32 *in_bus_fmts;
+ struct drm_crtc *crtc = crtc_state->crtc;
+ u32 *in_bus_fmts, in_fmt;
int ret;
prev_bridge = drm_bridge_get_prev_bridge(cur_bridge);
@@ -933,7 +935,15 @@ static int select_bus_fmt_recursive(struct drm_bridge
*first_bridge,
return -ENOMEM;
if (first_bridge == cur_bridge) {
- cur_state->input_bus_cfg.format = in_bus_fmts[0];
+ in_fmt = drm_helper_crtc_select_output_bus_format(crtc,
+ crtc_state,
+ in_bus_fmts,
+ num_in_bus_fmts);
+ if (!in_fmt) {
+ kfree(in_bus_fmts);
+ return -ENOTSUPP;
+ }
+ cur_state->input_bus_cfg.format = in_fmt;
cur_state->output_bus_cfg.format = out_bus_fmt;
kfree(in_bus_fmts);
return 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 2dafc39a27cb..4d3aa39c8a82 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1055,3 +1055,41 @@ int drm_helper_force_disable_all(struct drm_device *dev)
return ret;
}
EXPORT_SYMBOL(drm_helper_force_disable_all);
+
+/**
+ * drm_helper_crtc_select_output_bus_format - Select output media bus format
+ * @crtc: The CRTC to query
+ * @crtc_state: The new CRTC state
+ * @supported_fmts: List of media bus format options to pick from
+ * @num_supported_fmts: Number of media bus formats in @supported_fmts list
+ *
+ * Encoder drivers may call this helper to give the connected CRTC a chance to
+ * select compatible or preffered media bus format to use over the CRTC encoder
+ * link. Encoders should provide list of supported input MEDIA_BUS_FMT_* for
+ * CRTC to pick from. CRTC driver is expected to select preferred media bus
+ * format from the list and, once enabled, generate the signal accordingly.
+ *
+ * Returns:
+ * Selected preferred media bus format or 0 if CRTC does not support any from
+ * @supported_fmts list.
+ */
+u32 drm_helper_crtc_select_output_bus_format(struct drm_crtc *crtc,
+struct drm_crtc_state *crtc_state,
+const u32 *supported_fmts,
+unsigned int num_supported_fmts)
+{
+ if (!crtc || !crtc_state || !supported_fmts || !num_supported_fmts)
+ return 0;
+
+ if (!crtc->helper_private ||
+ !crtc->helper_private->select_output_bus_format)
+ crtc_state->output_bus_format = supported_fmts[0];
+ else
+ crtc_state->output_bus_format =
+ crtc->helper_private->select_output_bus_format(crtc,
+ crtc_state,
+ supported_fmts,
+ num_supported_fmts);
+ return crtc_state->output_bus_format;
+}
+EXPORT_SYMBOL(drm_helper_crtc_select_output_bus_format);
diff --git a/include/drm/drm_c
[PATCH v4 5/7] drm: xlnx: zynqmp_dpsub: Minimize usage of global flag
Avoid usage of global zynqmp_dpsub.dma_enabled flag in DPSUB layer
context. This flag signals whether the driver runs in DRM CRTC or DRM
bridge mode, assuming that all display layers share the same live or
non-live mode of operation. Using per-layer mode instead of global flag
will simplify future support of the hybrid scenario.
Remove redundant checks in DMA request/release contexts as
zynqmp_disp_layer.info is well-defined for all layer types, including the
correct number of DMA channels required for each particular layer.
Signed-off-by: Anatoliy Klymenko
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 24f1f367b1d3..8cdd74a9b772 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1026,7 +1026,7 @@ void zynqmp_disp_layer_disable(struct zynqmp_disp_layer
*layer)
{
unsigned int i;
- if (layer->disp->dpsub->dma_enabled) {
+ if (layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE) {
for (i = 0; i < layer->drm_fmt->num_planes; i++)
dmaengine_terminate_sync(layer->dmas[i].chan);
}
@@ -1052,7 +1052,7 @@ void zynqmp_disp_layer_set_format(struct
zynqmp_disp_layer *layer,
zynqmp_disp_avbuf_set_format(layer->disp, layer, layer->disp_fmt);
- if (!layer->disp->dpsub->dma_enabled)
+ if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
return;
/*
@@ -1090,7 +1090,7 @@ int zynqmp_disp_layer_update(struct zynqmp_disp_layer
*layer,
const struct drm_format_info *info = layer->drm_fmt;
unsigned int i;
- if (!layer->disp->dpsub->dma_enabled)
+ if (layer->mode == ZYNQMP_DPSUB_LAYER_LIVE)
return 0;
for (i = 0; i < info->num_planes; i++) {
@@ -1140,9 +1140,6 @@ static void zynqmp_disp_layer_release_dma(struct
zynqmp_disp *disp,
{
unsigned int i;
- if (!layer->info || !disp->dpsub->dma_enabled)
- return;
-
for (i = 0; i < layer->info->num_channels; i++) {
struct zynqmp_disp_layer_dma *dma = &layer->dmas[i];
@@ -1183,9 +1180,6 @@ static int zynqmp_disp_layer_request_dma(struct
zynqmp_disp *disp,
unsigned int i;
int ret;
- if (!disp->dpsub->dma_enabled)
- return 0;
-
for (i = 0; i < layer->info->num_channels; i++) {
struct zynqmp_disp_layer_dma *dma = &layer->dmas[i];
char dma_channel_name[16];
--
2.25.1
[PATCH v4 4/7] drm: xlnx: zynqmp_dpsub: Anounce supported input formats
DPSUB in bridge mode supports multiple input media bus formats.
Announce the list of supported input media bus formats via
drm_bridge.atomic_get_input_bus_fmts callback. Introduce a set of live
input formats supported by DPSUB. Add safeguards to format list functions
to prevent their misuse in the different layer modes contexts.
Reviewed-by: Laurent Pinchart
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 110 +++--
drivers/gpu/drm/xlnx/zynqmp_disp.h | 2 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 31 +++
3 files changed, 139 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 891577475349..24f1f367b1d3 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,12 +78,14 @@ enum zynqmp_dpsub_layer_mode {
/**
* struct zynqmp_disp_format - Display subsystem format information
* @drm_fmt: DRM format (4CC)
+ * @bus_fmt: Media bus format
* @buf_fmt: AV buffer format
* @swap: Flag to swap R & B for RGB formats, and U & V for YUV formats
* @sf: Scaling factors for color components
*/
struct zynqmp_disp_format {
u32 drm_fmt;
+ u32 bus_fmt;
u32 buf_fmt;
bool swap;
const u32 *sf;
@@ -182,6 +185,12 @@ static const u32 scaling_factors_565[] = {
ZYNQMP_DISP_AV_BUF_5BIT_SF,
};
+static const u32 scaling_factors_666[] = {
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+ ZYNQMP_DISP_AV_BUF_6BIT_SF,
+};
+
static const u32 scaling_factors_888[] = {
ZYNQMP_DISP_AV_BUF_8BIT_SF,
ZYNQMP_DISP_AV_BUF_8BIT_SF,
@@ -364,6 +373,41 @@ static const struct zynqmp_disp_format avbuf_gfx_fmts[] = {
},
};
+/* List of live video layer formats */
+static const struct zynqmp_disp_format avbuf_live_fmts[] = {
+ {
+ .drm_fmt= DRM_FORMAT_RGB565,
+ .bus_fmt= MEDIA_BUS_FMT_RGB666_1X18,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_6 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
+ .sf = scaling_factors_666,
+ }, {
+ .drm_fmt= DRM_FORMAT_RGB888,
+ .bus_fmt= MEDIA_BUS_FMT_RGB888_1X24,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_YUV422,
+ .bus_fmt= MEDIA_BUS_FMT_UYVY8_1X16,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_YUV444,
+ .bus_fmt= MEDIA_BUS_FMT_VUY8_1X24,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_8 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444,
+ .sf = scaling_factors_888,
+ }, {
+ .drm_fmt= DRM_FORMAT_P210,
+ .bus_fmt= MEDIA_BUS_FMT_UYVY10_1X20,
+ .buf_fmt= ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_10 |
+ ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422,
+ .sf = scaling_factors_101010,
+ },
+};
+
static u32 zynqmp_disp_avbuf_read(struct zynqmp_disp *disp, int reg)
{
return readl(disp->avbuf.base + reg);
@@ -887,6 +931,11 @@ zynqmp_disp_layer_find_format(struct zynqmp_disp_layer
*layer,
* @layer: The layer
* @num_formats: Pointer to the returned number of formats
*
+ * NOTE: This function doesn't make sense for live video layers and will
+ * always return an empty list in such cases. zynqmp_disp_live_layer_formats()
+ * should be used to query a list of media bus formats supported by the live
+ * video input layer.
+ *
* Return: A newly allocated u32 array that stores all the DRM formats
* supported by the layer. The number of formats in the array is returned
* through the num_formats argument.
@@ -897,10 +946,17 @@ u32 *zynqmp_disp_layer_drm_formats(struct
zynqmp_disp_layer *layer,
unsigned int i;
u32 *formats;
+ if (WARN_ON(!layer->mode == ZYNQMP_DPSUB_LAYER_NONLIVE)) {
+ *num_formats = 0;
+ return NULL;
+ }
+
formats = kcalloc(layer->info->num_formats, sizeof(*formats),
GFP_KERNEL);
- if (!formats)
+ if (!formats) {
+ *num_formats = 0;
return NULL;
+ }
for (i = 0; i < layer->info->num_formats; ++i)
formats[i] = layer->info
[PATCH v4 1/7] drm: xlnx: zynqmp_dpsub: Set layer mode during creation
Set layer mode of operation (live or dma-based) during layer creation.
Each DPSUB layer mode of operation is defined by corresponding DT node port
connection, so it is possible to assign it during layer object creation.
Previously it was set in layer enable functions, although it is too late
as setting layer format depends on layer mode, and should be done before
given layer enabled.
Signed-off-by: Anatoliy Klymenko
Reviewed-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 21 +
drivers/gpu/drm/xlnx/zynqmp_disp.h | 13 +
drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
drivers/gpu/drm/xlnx/zynqmp_kms.c | 2 +-
4 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 8a39b3accce5..891577475349 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -64,6 +64,16 @@
#define ZYNQMP_DISP_MAX_NUM_SUB_PLANES 3
+/**
+ * enum zynqmp_dpsub_layer_mode - Layer mode
+ * @ZYNQMP_DPSUB_LAYER_NONLIVE: non-live (memory) mode
+ * @ZYNQMP_DPSUB_LAYER_LIVE: live (stream) mode
+ */
+enum zynqmp_dpsub_layer_mode {
+ ZYNQMP_DPSUB_LAYER_NONLIVE,
+ ZYNQMP_DPSUB_LAYER_LIVE,
+};
+
/**
* struct zynqmp_disp_format - Display subsystem format information
* @drm_fmt: DRM format (4CC)
@@ -902,15 +912,12 @@ u32 *zynqmp_disp_layer_drm_formats(struct
zynqmp_disp_layer *layer,
/**
* zynqmp_disp_layer_enable - Enable a layer
* @layer: The layer
- * @mode: Operating mode of layer
*
* Enable the @layer in the audio/video buffer manager and the blender. DMA
* channels are started separately by zynqmp_disp_layer_update().
*/
-void zynqmp_disp_layer_enable(struct zynqmp_disp_layer *layer,
- enum zynqmp_dpsub_layer_mode mode)
+void zynqmp_disp_layer_enable(struct zynqmp_disp_layer *layer)
{
- layer->mode = mode;
zynqmp_disp_avbuf_enable_video(layer->disp, layer);
zynqmp_disp_blend_layer_enable(layer->disp, layer);
}
@@ -1134,6 +1141,12 @@ static int zynqmp_disp_create_layers(struct zynqmp_disp
*disp)
layer->id = i;
layer->disp = disp;
layer->info = &layer_info[i];
+ /*
+* For now assume dpsub works in either live or non-live mode
for both layers.
+* Hybrid mode is not supported yet.
+*/
+ layer->mode = disp->dpsub->dma_enabled ?
ZYNQMP_DPSUB_LAYER_NONLIVE
+ :
ZYNQMP_DPSUB_LAYER_LIVE;
ret = zynqmp_disp_layer_request_dma(disp, layer);
if (ret)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.h
b/drivers/gpu/drm/xlnx/zynqmp_disp.h
index 123cffac08be..9b8b202224d9 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.h
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.h
@@ -42,16 +42,6 @@ enum zynqmp_dpsub_layer_id {
ZYNQMP_DPSUB_LAYER_GFX,
};
-/**
- * enum zynqmp_dpsub_layer_mode - Layer mode
- * @ZYNQMP_DPSUB_LAYER_NONLIVE: non-live (memory) mode
- * @ZYNQMP_DPSUB_LAYER_LIVE: live (stream) mode
- */
-enum zynqmp_dpsub_layer_mode {
- ZYNQMP_DPSUB_LAYER_NONLIVE,
- ZYNQMP_DPSUB_LAYER_LIVE,
-};
-
void zynqmp_disp_enable(struct zynqmp_disp *disp);
void zynqmp_disp_disable(struct zynqmp_disp *disp);
int zynqmp_disp_setup_clock(struct zynqmp_disp *disp,
@@ -62,8 +52,7 @@ void zynqmp_disp_blend_set_global_alpha(struct zynqmp_disp
*disp,
u32 *zynqmp_disp_layer_drm_formats(struct zynqmp_disp_layer *layer,
unsigned int *num_formats);
-void zynqmp_disp_layer_enable(struct zynqmp_disp_layer *layer,
- enum zynqmp_dpsub_layer_mode mode);
+void zynqmp_disp_layer_enable(struct zynqmp_disp_layer *layer);
void zynqmp_disp_layer_disable(struct zynqmp_disp_layer *layer);
void zynqmp_disp_layer_set_format(struct zynqmp_disp_layer *layer,
const struct drm_format_info *info);
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 1846c4971fd8..04b6bcac3b07 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -1295,7 +1295,7 @@ static void zynqmp_dp_disp_enable(struct zynqmp_dp *dp,
/* TODO: Make the format configurable. */
info = drm_format_info(DRM_FORMAT_YUV422);
zynqmp_disp_layer_set_format(layer, info);
- zynqmp_disp_layer_enable(layer, ZYNQMP_DPSUB_LAYER_LIVE);
+ zynqmp_disp_layer_enable(layer);
if (layer_id == ZYNQMP_DPSUB_LAYER_GFX)
zynqmp_disp_blend_set_global_alpha(dp->dpsub->disp, true, 255);
diff --git a/drivers/gpu/drm/xlnx/zynqmp_kms.c
b/drivers/gpu/drm/xlnx/zynqmp_kms.c
index db3bb4afbfc4..43bf416b33d5 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_kms.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_kms.c
@@ -122,7 +122,7 @@ static void
[PATCH v4 3/7] drm: xlnx: zynqmp_dpsub: Add connected live layer helper
Add a helper function capturing the first connected live display layer
discovery logic.
Signed-off-by: Anatoliy Klymenko
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/xlnx/zynqmp_dp.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c b/drivers/gpu/drm/xlnx/zynqmp_dp.c
index 04b6bcac3b07..7faeb010e1ae 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
@@ -1276,28 +1276,40 @@ static void zynqmp_dp_encoder_mode_set_stream(struct
zynqmp_dp *dp,
* DISP Configuration
*/
+/**
+ * zynqmp_dp_disp_connected_live_layer - Return the first connected live layer
+ * @dp: DisplayPort IP core structure
+ *
+ * Return: The first connected live display layer or NULL if none of the live
+ * layers are connected.
+ */
+static struct zynqmp_disp_layer *
+zynqmp_dp_disp_connected_live_layer(struct zynqmp_dp *dp)
+{
+ if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_VIDEO))
+ return dp->dpsub->layers[ZYNQMP_DPSUB_LAYER_VID];
+ else if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_GFX))
+ return dp->dpsub->layers[ZYNQMP_DPSUB_LAYER_GFX];
+ else
+ return NULL;
+}
+
static void zynqmp_dp_disp_enable(struct zynqmp_dp *dp,
struct drm_bridge_state *old_bridge_state)
{
- enum zynqmp_dpsub_layer_id layer_id;
struct zynqmp_disp_layer *layer;
const struct drm_format_info *info;
- if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_VIDEO))
- layer_id = ZYNQMP_DPSUB_LAYER_VID;
- else if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_GFX))
- layer_id = ZYNQMP_DPSUB_LAYER_GFX;
- else
+ layer = zynqmp_dp_disp_connected_live_layer(dp);
+ if (!layer)
return;
- layer = dp->dpsub->layers[layer_id];
-
/* TODO: Make the format configurable. */
info = drm_format_info(DRM_FORMAT_YUV422);
zynqmp_disp_layer_set_format(layer, info);
zynqmp_disp_layer_enable(layer);
- if (layer_id == ZYNQMP_DPSUB_LAYER_GFX)
+ if (layer == dp->dpsub->layers[ZYNQMP_DPSUB_LAYER_GFX])
zynqmp_disp_blend_set_global_alpha(dp->dpsub->disp, true, 255);
else
zynqmp_disp_blend_set_global_alpha(dp->dpsub->disp, false, 0);
@@ -1310,11 +1322,8 @@ static void zynqmp_dp_disp_disable(struct zynqmp_dp *dp,
{
struct zynqmp_disp_layer *layer;
- if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_VIDEO))
- layer = dp->dpsub->layers[ZYNQMP_DPSUB_LAYER_VID];
- else if (dp->dpsub->connected_ports & BIT(ZYNQMP_DPSUB_PORT_LIVE_GFX))
- layer = dp->dpsub->layers[ZYNQMP_DPSUB_LAYER_GFX];
- else
+ layer = zynqmp_dp_disp_connected_live_layer(dp);
+ if (!layer)
return;
zynqmp_disp_disable(dp->dpsub->disp);
--
2.25.1
[PATCH v4 2/7] drm: xlnx: zynqmp_dpsub: Update live format defines
Update live format defines to match DPSUB AV_BUF_LIVE_VID_CONFIG register layout. These defines were never referenced before, so no other changes required. Reviewed-by: Laurent Pinchart Signed-off-by: Anatoliy Klymenko --- drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h b/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h index f92a006d5070..fa3935384834 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h +++ b/drivers/gpu/drm/xlnx/zynqmp_disp_regs.h @@ -165,10 +165,10 @@ #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_10 0x2 #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_12 0x3 #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_BPC_MASKGENMASK(2, 0) -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB 0x0 -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444 0x1 -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422 0x2 -#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YONLY 0x3 +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_RGB (0x0 << 4) +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV444 (0x1 << 4) +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YUV422 (0x2 << 4) +#define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_YONLY (0x3 << 4) #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_FMT_MASKGENMASK(5, 4) #define ZYNQMP_DISP_AV_BUF_LIVE_CONFIG_CB_FIRSTBIT(8) #define ZYNQMP_DISP_AV_BUF_PALETTE_MEMORY 0x400 -- 2.25.1
[PATCH v4 0/7] Managing live video input format for ZynqMP DPSUB
Implement live video input format setting for ZynqMP DPSUB. ZynqMP DPSUB can operate in 2 modes: DMA-based and live. In the live mode, DPSUB receives a live video signal from FPGA-based CRTC. DPSUB acts as a DRM encoder bridge in such a scenario. To properly tune into the incoming video signal, DPSUB should be programmed with the proper media bus format. This patch series addresses this task. Patch 1/7: Set the DPSUB layer mode of operation prior to enabling the layer. Allows to use layer operational mode before its enablement. Patch 2/7: Update some IP register defines. Patch 3/7: Factor out some code into a helper function. Patch 4/7: Announce supported input media bus formats via drm_bridge_funcs.atomic_get_input_bus_fmts callback. Patch 5/7: Minimize usage of a global flag. Minor improvement. Patch 6/7: Program DPSUB live video input format based on selected bus config in the new atomic bridge state. Patch 7/7: New optional CRTC atomic helper proposal that will allow to negotiate video signal format between CRTC and connected encoder. Incorporate this callback into the DRM bridge format negotiation process. Save negotiated output format in drm_crtc_state. Reference usage of this API is available here: https://github.com/onotole/linux/tree/dpsub-live-in To: Laurent Pinchart To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann To: David Airlie To: Daniel Vetter To: Michal Simek To: Andrzej Hajda To: Neil Armstrong To: Robert Foss To: Jonas Karlman To: Jernej Skrabec To: Rob Herring To: Krzysztof Kozlowski To: Conor Dooley To: Mauro Carvalho Chehab Cc: Tomi Valkeinen Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-me...@vger.kernel.org Signed-off-by: Anatoliy Klymenko Changes in v4: - Replace controversial reference driver patches with the private repository link. - Split display layer format manipulation functions into 2 separate cases for diferet layer modes. - Address misc review comments (typos, comments, etc.) Link to v3: https://lore.kernel.org/r/20240321-dp-live-fmt-v3-0-d5090d796...@amd.com Changes in v3: - Add connected live layer helper - Include reference DRM format in zynqmp_disp_format for live layerss. - Add default bus format list for non-live case. - Explain removal of redundant checks in the commit message. - Minor fixes and improvements from review comments. Link to v2: https://lore.kernel.org/r/20240312-dp-live-fmt-v2-0-a9c35dc5c...@amd.com Changes in v2: - Factor out register defines update into separate patch. - Add some improvements minimizing ithe usage of a global flag. - Reuse existing format setting API instead of introducing new versions. - Add warning around NULL check on new bridge state within atomic enable callback. - Add drm_helper_crtc_select_output_bus_format() that wraps drm_crtc_helper_funcs.select_output_bus_format(). - Update API comments per review recommendations. - Address some minor review comments. - Add reference CRTC driver that demonstrates the usage of the proposed drm_crtc_helper_funcs.select_output_bus_format() API. - Link to v1: https://lore.kernel.org/r/20240226-dp-live-fmt-v1-0-b78c3f69c...@amd.com --- Anatoliy Klymenko (7): drm: xlnx: zynqmp_dpsub: Set layer mode during creation drm: xlnx: zynqmp_dpsub: Update live format defines drm: xlnx: zynqmp_dpsub: Add connected live layer helper drm: xlnx: zynqmp_dpsub: Anounce supported input formats drm: xlnx: zynqmp_dpsub: Minimize usage of global flag drm: xlnx: zynqmp_dpsub: Set input live format drm/atomic-helper: Add select_output_bus_format callback drivers/gpu/drm/drm_bridge.c | 14 +- drivers/gpu/drm/drm_crtc_helper.c| 38 + drivers/gpu/drm/xlnx/zynqmp_disp.c | 231 +++ drivers/gpu/drm/xlnx/zynqmp_disp.h | 17 +-- drivers/gpu/drm/xlnx/zynqmp_disp_regs.h | 8 +- drivers/gpu/drm/xlnx/zynqmp_dp.c | 81 --- drivers/gpu/drm/xlnx/zynqmp_kms.c| 2 +- include/drm/drm_crtc.h | 11 ++ include/drm/drm_crtc_helper.h| 5 + include/drm/drm_modeset_helper_vtables.h | 30 10 files changed, 372 insertions(+), 65 deletions(-) --- base-commit: bfa4437fd3938ae2e186e7664b2db65bb8775670 change-id: 20240226-dp-live-fmt-6415773b5a68 Best regards, -- Anatoliy Klymenko
Re: [PATCH v3 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
Le 16/04/2024 à 20:30, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367 ++
3 files changed, 382 insertions(+)
...
+static int rm69380_probe(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_host *dsi_sec_host;
+ struct rm69380_panel *ctx;
+ struct device *dev = &dsi->dev;
+ struct device_node *dsi_sec;
+ int ret, i;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx->supplies[0].supply = "vddio";
+ ctx->supplies[1].supply = "avdd";
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
+"Failed to get reset-gpios\n");
+
+ dsi_sec = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
+
+ if (dsi_sec) {
+ const struct mipi_dsi_device_info info = { "RM69380", 0,
+ dsi_sec };
+
+ dev_dbg(dev, "Using Dual-DSI: found `%s`\n", dsi_sec->name);
+
+ dsi_sec_host = of_find_mipi_dsi_host_by_node(dsi_sec);
+ of_node_put(dsi_sec);
+ if (!dsi_sec_host)
+ return dev_err_probe(dev, -EPROBE_DEFER,
+"Cannot get secondary DSI host\n");
+
+ ctx->dsi[1] =
+ devm_mipi_dsi_device_register_full(dev, dsi_sec_host,
&info);
+ if (IS_ERR(ctx->dsi[1]))
+ return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
+"Cannot get secondary DSI node\n");
+
+ dev_dbg(dev, "Second DSI name `%s`\n", ctx->dsi[1]->name);
+ mipi_dsi_set_drvdata(ctx->dsi[1], ctx);
+ } else {
+ dev_dbg(dev, "Using Single-DSI\n");
+ }
+
+ ctx->dsi[0] = dsi;
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ drm_panel_init(&ctx->panel, dev, &rm69380_panel_funcs,
+ DRM_MODE_CONNECTOR_DSI);
+ ctx->panel.prepare_prev_first = true;
+
+ ctx->panel.backlight = rm69380_create_backlight(dsi);
+ if (IS_ERR(ctx->panel.backlight))
+ return dev_err_probe(dev, PTR_ERR(ctx->panel.backlight),
+"Failed to create backlight\n");
+
+ drm_panel_add(&ctx->panel);
+
+ for (i = 0; i < ARRAY_SIZE(ctx->dsi); i++) {
+ if (!ctx->dsi[i])
+ continue;
+
+ dev_dbg(&ctx->dsi[i]->dev, "Binding DSI %d\n", i);
+
+ ctx->dsi[i]->lanes = 4;
+ ctx->dsi[i]->format = MIPI_DSI_FMT_RGB888;
+ ctx->dsi[i]->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS;
+
+ ret = mipi_dsi_attach(ctx->dsi[i]);
+ if (ret < 0) {
+ mipi_dsi_detach(ctx->dsi[i]);
I don't think this works.
if 'i' fails, you have to detach 0...i-1
maybe something like below (complety untested).
+ drm_panel_remove(&ctx->panel);
+ return dev_err_probe(dev, ret,
+"Failed to attach to DSI%d\n", i);
+ }
+ }
+
+ return 0;
+}
drm_panel_add(&ctx->panel);
for (i = 0; i < ARRAY_SIZE(ctx->dsi); i++) {
if (!ctx->dsi[i])
continue;
dev_dbg(&ctx->dsi[i]->dev, "Binding DSI %d\n", i);
ctx->dsi[i]->lanes = 4;
ctx->dsi[i]->format = MIPI_DSI_FMT_RGB888;
ctx->dsi[i]->mode_flags = MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_CLOCK_NON_CONTINUOUS;
ret = mipi_dsi_attach(ctx->dsi[i]);
if (ret < 0) {
dev_err_probe(dev, ret,
"Failed to attach to DSI%d\n", i);
goto err_detach_dsi;
}
}
return 0;
err_detach_dsi:
while (--i >= 0)
if (ctx->dsi[i])
mipi_dsi_detach(ctx->dsi[i]);
drm_panel_remove(&ctx->panel);
return ret;
}
Re: [PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
On 2024-04-15 19:50:49, Dmitry Baryshkov wrote:
> On Mon, Apr 15, 20
[...]
> > +static int rm69380_on(struct rm69380_panel *ctx)
[...]
> ret = mipi_dsi_dcs_set_display_brightness_large(dsi, 0x7ff);
Downstream may send this here, but why? As far as I've observed, update_status
also sets &backlight_properties.brightness which you configure below.
Try removing this line and maybe also set the initial brightness lower to the
benefit of users' eyes and OLED lifetime?
[...]
> > +
> > + if (dsi_sec) {
> > + dev_dbg(dev, "Using Dual-DSI\n");
> > +
> > + const struct mipi_dsi_device_info info = { "RM69380", 0,
Personally I'm never really sure what to put in the name here, maybe something
that signifies the second DSI interface of the panel?
> > + dsi_sec };
> > +
> > + dev_dbg(dev, "Found second DSI `%s`\n", dsi_sec->name);
> > +
> > + dsi_sec_host = of_find_mipi_dsi_host_by_node(dsi_sec);
> > + of_node_put(dsi_sec);
> > + if (!dsi_sec_host) {
> > + return dev_err_probe(dev, -EPROBE_DEFER,
> > +"Cannot get secondary DSI host\n");
> > + }
> > +
> > + ctx->dsi[1] =
> > + mipi_dsi_device_register_full(dsi_sec_host, &info);
>
> Either you should be using devm_mipi_dsi_device_register_full() here or
> you should call mipi_dsi_device_unregister() in the error and remove
> paths. I'd suggest the former.
There is also devm_mipi_dsi_attach() which may solve inadequate cleanup handling
in the error paths below, as pointed out by Christophe.
>
> > + if (IS_ERR(ctx->dsi[1])) {
> > + return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
> > +"Cannot get secondary DSI node\n");
> > + }
> > +
> > + dev_dbg(dev, "Second DSI name `%s`\n", ctx->dsi[1]->name);
It looks like you inerited /all/ my debug logging when copy-pasting this setup
from my in-progress dual-DSI dual-DSC Samsung ANA6707 panel driver. Since it's
all working now, I suggest to remove mostly-useless debug lines like this.
I'll continue the review on v3, as I mainly wanted to extend the initial devm_
suggestion from Dmitry done on v2.
- Marijn
Re: (subset) [PATCH 0/6] drm/panel: small fixes for visionox and novatek panel drivers
On Thu, 04 Apr 2024 13:07:58 +0300, Dmitry Baryshkov wrote: > While taking a glance at the novatek-nt36672e driver I stumbled upon a > call to unregister the DSI device for the panel, although it was not the > panel driver that registered the device. > > Remove this call and a similar call from the visionox-rm69299 driver. > While we are at it, also optimize regulator API calls in these two > drivers and in the novatek-nt36672a driver. > > [...] Applied to drm-misc-fixes, thanks! [1/6] drm/panel: visionox-rm69299: don't unregister DSI device commit: 9e4d3f4f34455abbaa9930bf6b7575a5cd081496 [2/6] drm/panel: novatek-nt36682e: don't unregister DSI device commit: 941c0bdbc176df825adf77052263b2d63db6fef7 Other four patches were not reviewed and they are not fixes, so they are still pending. Best regards, -- With best wishes Dmitry
Re: [PATCH v3 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
On Tue, Apr 16, 2024 at 08:30:49PM +0200, David Wronek wrote: > Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a > Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021. > > Signed-off-by: David Wronek > --- > drivers/gpu/drm/panel/Kconfig | 14 + > drivers/gpu/drm/panel/Makefile| 1 + > drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367 > ++ > 3 files changed, 382 insertions(+) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 1/4] drm/imagination: Convert to platform remove callback returning void
On 09/04/2024 10:02, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
> from emitting a warning) and this typically results in resource leaks.
>
> To improve here there is a quest to make the remove callback return
> void. In the first step of this quest all drivers are converted to
> .remove_new(), which already returns void. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Matt Coster
> ---
> drivers/gpu/drm/imagination/pvr_drv.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/imagination/pvr_drv.c
> b/drivers/gpu/drm/imagination/pvr_drv.c
> index 5c3b2d58d766..1a0cb7aa9cea 100644
> --- a/drivers/gpu/drm/imagination/pvr_drv.c
> +++ b/drivers/gpu/drm/imagination/pvr_drv.c
> @@ -1451,8 +1451,7 @@ pvr_probe(struct platform_device *plat_dev)
> return err;
> }
>
> -static int
> -pvr_remove(struct platform_device *plat_dev)
> +static void pvr_remove(struct platform_device *plat_dev)
> {
> struct drm_device *drm_dev = platform_get_drvdata(plat_dev);
> struct pvr_device *pvr_dev = to_pvr_device(drm_dev);
> @@ -1469,8 +1468,6 @@ pvr_remove(struct platform_device *plat_dev)
> pvr_watchdog_fini(pvr_dev);
> pvr_queue_device_fini(pvr_dev);
> pvr_context_device_fini(pvr_dev);
> -
> - return 0;
> }
>
> static const struct of_device_id dt_match[] = {
> @@ -1485,7 +1482,7 @@ static const struct dev_pm_ops pvr_pm_ops = {
>
> static struct platform_driver pvr_driver = {
> .probe = pvr_probe,
> - .remove = pvr_remove,
> + .remove_new = pvr_remove,
> .driver = {
> .name = PVR_DRIVER_NAME,
> .pm = &pvr_pm_ops,
OpenPGP_signature.asc
Description: OpenPGP digital signature
[PATCH] drm: Fix no_vblank field references in documentation
Browsing the DRM documentation shows that drm_crtc_state.no_vblank
is not turned into a reference to the no_vblank field, but rather a
reference to `struct drm_crtc_state`. The only difference with other
field references is that the struct name is prefixed by the literal
`struct` tag, despite also already having a `&` reference prefix in two
of the three cases. Remove the `struct` prefix to turn these references
into proper links to the designated field.
Fixes: 7beb691f1e6f ("drm: Initialize struct drm_crtc_state.no_vblank from
device settings")
Signed-off-by: Marijn Suijten
---
Note that a simple regex like "&struct \w+\.\w+" shows that there are
only a handful of violators, most of them inside DRM files. Let me know
if you'd like a v2 that addresses all of them in one go (in separate
patches or one combined change)?
Kind regards,
Marijn
---
drivers/gpu/drm/drm_vblank.c| 2 +-
include/drm/drm_crtc.h | 2 +-
include/drm/drm_simple_kms_helper.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 702a12bc93bd..45504732f98e 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -140,7 +140,7 @@
* must not call drm_vblank_init(). For such drivers, atomic helpers will
* automatically generate fake vblank events as part of the display update.
* This functionality also can be controlled by the driver by enabling and
- * disabling struct drm_crtc_state.no_vblank.
+ * disabling &drm_crtc_state.no_vblank.
*/
/* Retry timestamp calculation up to 3 times to satisfy
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8b48a1974da3..eb75d0aec170 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -342,7 +342,7 @@ struct drm_crtc_state {
*that case.
*
* For very simple hardware without VBLANK interrupt, enabling
-* &struct drm_crtc_state.no_vblank makes DRM's atomic commit helpers
+* &drm_crtc_state.no_vblank makes DRM's atomic commit helpers
* send a fake VBLANK event at the end of the display update after all
* hardware changes have been applied. See
* drm_atomic_helper_fake_vblank().
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index b2486d073763..6e64d91819e7 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -102,7 +102,7 @@ struct drm_simple_display_pipe_funcs {
* drm_crtc_arm_vblank_event(), when the driver supports vblank
* interrupt handling, or drm_crtc_send_vblank_event() for more
* complex case. In case the hardware lacks vblank support entirely,
-* drivers can set &struct drm_crtc_state.no_vblank in
+* drivers can set &drm_crtc_state.no_vblank in
* &struct drm_simple_display_pipe_funcs.check and let DRM's
* atomic helper fake a vblank event.
*/
---
base-commit: 6bd343537461b57f3efe5dfc5fc193a232dfef1e
change-id: 20240416-drm-no_vblank-kdoc-link-fea1b53008a3
Best regards,
--
Marijn Suijten
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
On Tue, 16 Apr 2024 20:30:48 +0200, David Wronek wrote:
> Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
> Add a dt-binding for it.
>
> Signed-off-by: David Wronek
> ---
> Note:
> Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
> dual-link schema")
> ---
> .../bindings/display/panel/raydium,rm69380.yaml| 91
> ++
> 1 file changed, 91 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml:
Error in referenced schema matching $id:
http://devicetree.org/schemas/display/panel/panel-common-dual.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/raydium,rm69380.example.dtb:
panel@0: False schema does not allow {'compatible':
['lenovo,j716f-edo-rm69380', 'raydium,rm69380'], 'reg': [[0]], 'avdd-supply':
[[4294967295]], 'vddio-supply': [[4294967295]], 'reset-gpios': [[4294967295,
75, 1]], 'ports': {'#address-cells': [[1]], '#size-cells': [[0]], 'port@0':
{'reg': [[0]], 'endpoint': {'remote-endpoint': [[4294967295]]}}, 'port@1':
{'reg': [[1]], 'endpoint': {'remote-endpoint': [[4294967295]]}}}, '$nodename':
['panel@0']}
from schema $id:
http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240416-raydium-rm69380-driver-v3-1-21600ac4c...@mainlining.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Tue, Apr 16, 2024 at 12:02:10PM -0700, Dixit, Ashutosh wrote:
> On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private
> > > *i915)
> > >
> > > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > > {
> > > - fetch_and_zero(&i915->hwmon);
> > > + struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
> > > + struct hwm_drvdata *ddat = &hwmon->ddat;
> > > + struct intel_gt *gt;
> > > + int i;
> > > +
> > > + if (!hwmon)
> > > + return;
> >
> > "that's too late", we are going to hear from static analyzer tools.
> >
> > beter to move ddat = &hwmon->ddat; after this return.
>
> Yeah, I worried a lot about it :/ But then finally decided (and verified)
> that we are never actually dereferencing the (possibly NULL) pointer.
yeap, another acceptable approach is to simply remove this check entirely.
>
> But not sure about static analyzer tools, maybe you are right, I'll move
> it.
>
> > with that,
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks a lot :)
>
> Ashutosh
>
> >
> > > +
> > > + for_each_gt(gt, i915, i) {
> > > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> > > +
> > > + if (ddat_gt->hwmon_dev) {
> > > + hwmon_device_unregister(ddat_gt->hwmon_dev);
> > > + ddat_gt->hwmon_dev = NULL;
> > > + }
> > > + }
> > > +
> > > + if (ddat->hwmon_dev)
> > > + hwmon_device_unregister(ddat->hwmon_dev);
> > > +
> > > + mutex_destroy(&hwmon->hwmon_lock);
> > > + kfree(hwmon);
> > > }
> > > --
> > > 2.41.0
> > >
Re: [PATCH] drm/xe: select X86_PLATFORM_DEVICES when ACPI_WMI is selected
On Mon, Apr 15, 2024 at 10:52:15AM GMT, Lu Yao wrote: ACPI_WMI is a subitem of X86_PLATFORM_DEVICES. And X86_PLATFORM_DEVICES is not selected in the current Kconfig, and may cause Kconfig warnings: WARNING: unmet direct dependencies detected for ACPI_WMI Depends on [n]: X86_PLATFORM_DEVICES [=n] && ACPI [=y] Selected by [m]: - DRM_XE [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && MMU [=y] && (m && MODULES [=y] || y && KUNIT [=y]=y) && X86 [=y] && ACPI [=y] Signed-off-by: Lu Yao Reviewed-by: Lucas De Marchi and pushed to drm-xe-next, thanks. Lucas De Marchi --- drivers/gpu/drm/xe/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig index 1a556d087e63..f483e69a5d0f 100644 --- a/drivers/gpu/drm/xe/Kconfig +++ b/drivers/gpu/drm/xe/Kconfig @@ -26,6 +26,7 @@ config DRM_XE select INPUT if ACPI select ACPI_VIDEO if X86 && ACPI select ACPI_BUTTON if ACPI + select X86_PLATFORM_DEVICES if X86 && ACPI select ACPI_WMI if X86 && ACPI select SYNC_FILE select IOSF_MBI -- 2.25.1
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Tue, 16 Apr 2024 11:55:20 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> >
> > void i915_hwmon_unregister(struct drm_i915_private *i915)
> > {
> > - fetch_and_zero(&i915->hwmon);
> > + struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
> > + struct hwm_drvdata *ddat = &hwmon->ddat;
> > + struct intel_gt *gt;
> > + int i;
> > +
> > + if (!hwmon)
> > + return;
>
> "that's too late", we are going to hear from static analyzer tools.
>
> beter to move ddat = &hwmon->ddat; after this return.
Yeah, I worried a lot about it :/ But then finally decided (and verified)
that we are never actually dereferencing the (possibly NULL) pointer.
But not sure about static analyzer tools, maybe you are right, I'll move
it.
> with that,
>
> Reviewed-by: Rodrigo Vivi
Thanks a lot :)
Ashutosh
>
> > +
> > + for_each_gt(gt, i915, i) {
> > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> > +
> > + if (ddat_gt->hwmon_dev) {
> > + hwmon_device_unregister(ddat_gt->hwmon_dev);
> > + ddat_gt->hwmon_dev = NULL;
> > + }
> > + }
> > +
> > + if (ddat->hwmon_dev)
> > + hwmon_device_unregister(ddat->hwmon_dev);
> > +
> > + mutex_destroy(&hwmon->hwmon_lock);
> > + kfree(hwmon);
> > }
> > --
> > 2.41.0
> >
Re: [PATCH v2] drm/i915/hwmon: Get rid of devm
On Mon, Apr 15, 2024 at 03:36:12PM -0700, Ashutosh Dixit wrote:
> When both hwmon and hwmon drvdata (on which hwmon depends) are device
> managed resources, the expectation, on device unbind, is that hwmon will be
> released before drvdata. However, in i915 there are two separate code
> paths, which both release either drvdata or hwmon and either can be
> released before the other. These code paths (for device unbind) are as
> follows (see also the bug referenced below):
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_group+0xb2/0x110
> component_unbind_all+0x8d/0xa0
> component_del+0xa5/0x140
> intel_pxp_tee_component_fini+0x29/0x40 [i915]
> intel_pxp_fini+0x33/0x80 [i915]
> i915_driver_remove+0x4c/0x120 [i915]
> i915_pci_remove+0x19/0x30 [i915]
> pci_device_remove+0x32/0xa0
> device_release_driver_internal+0x19c/0x200
> unbind_store+0x9c/0xb0
>
> and
>
> Call Trace:
> release_nodes+0x11/0x70
> devres_release_all+0x8a/0xc0
> device_unbind_cleanup+0x9/0x70
> device_release_driver_internal+0x1c1/0x200
> unbind_store+0x9c/0xb0
>
> This means that in i915, if use devm, we cannot gurantee that hwmon will
> always be released before drvdata. Which means that we have a uaf if hwmon
> sysfs is accessed when drvdata has been released but hwmon hasn't.
>
> The only way out of this seems to be do get rid of devm_ and release/free
> everything explicitly during device unbind.
>
> v2: Change commit message and other minor code changes
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10366
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 41 +++
> 1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 8c3f443c8347..46c24b1ee6df 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -792,7 +792,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!IS_DGFX(i915))
> return;
>
> - hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
> + hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
> if (!hwmon)
> return;
>
> @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> hwm_get_preregistration_info(i915);
>
> /* hwmon_dev points to device hwmon */
> - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
> - ddat,
> - &hwm_chip_info,
> - hwm_groups);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name,
> + ddat,
> + &hwm_chip_info,
> + hwm_groups);
> if (IS_ERR(hwmon_dev)) {
> i915->hwmon = NULL;
> return;
> @@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> if (!hwm_gt_is_visible(ddat_gt, hwmon_energy,
> hwmon_energy_input, 0))
> continue;
>
> - hwmon_dev = devm_hwmon_device_register_with_info(dev,
> ddat_gt->name,
> - ddat_gt,
> -
> &hwm_gt_chip_info,
> - NULL);
> + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name,
> + ddat_gt,
> + &hwm_gt_chip_info,
> + NULL);
> if (!IS_ERR(hwmon_dev))
> ddat_gt->hwmon_dev = hwmon_dev;
> }
> @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915)
>
> void i915_hwmon_unregister(struct drm_i915_private *i915)
> {
> - fetch_and_zero(&i915->hwmon);
> + struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon);
> + struct hwm_drvdata *ddat = &hwmon->ddat;
> + struct intel_gt *gt;
> + int i;
> +
> + if (!hwmon)
> + return;
"that's too late", we are going to hear from static analyzer tools.
beter to move ddat = &hwmon->ddat; after this return.
with that,
Reviewed-by: Rodrigo Vivi
> +
> + for_each_gt(gt, i915, i) {
> + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i;
> +
> + if (ddat_gt->hwmon_dev) {
> + hwmon_device_unregister(ddat_gt->hwmon_dev);
> + ddat_gt->hwmon_dev = NULL;
> + }
> + }
> +
> + if (ddat->hwmon_dev)
> + hwmon_device_unregister(ddat->hwmon_dev);
> +
> + mutex_destroy(&hwmon->hwmon_lock);
> + kfree(hwmon);
> }
> --
> 2.41.0
>
[PATCH v3 1/2] dt-bindings: display: panel: Add Raydium RM69380
Raydium RM69380 is a display driver IC used to drive OLED DSI panels.
Add a dt-binding for it.
Signed-off-by: David Wronek
---
Note:
Depends on commit 48a516363e29 ("dt-bindings: display: panel: add common
dual-link schema")
---
.../bindings/display/panel/raydium,rm69380.yaml| 91 ++
1 file changed, 91 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
new file mode 100644
index ..0ac7d033cbe0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/raydium,rm69380.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raydium RM6380-based DSI display panels
+
+maintainers:
+ - David Wronek
+
+description:
+ The Raydium RM69380 is a generic DSI panel IC used to control
+ OLED panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - lenovo,j716f-edo-rm69380
+ - const: raydium,rm69380
+description: This indicates the panel manufacturer of the panel
+ that is in turn using the RM69380 panel driver. The compatible
+ string determines how the RM69380 panel driver shall be configured
+ to work with the indicated panel. The raydium,rm69380 compatible shall
+ always be provided as a fallback.
+
+ avdd-supply:
+description: Analog voltage rail
+
+ vddio-supply:
+description: I/O voltage rail
+
+ reset-gpios:
+maxItems: 1
+description: phandle of gpio for reset line - This should be active low
+
+ ports: true
+ reg: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - vddio-supply
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "lenovo,j716f-edo-rm69380", "raydium,rm69380";
+reg = <0>;
+
+avdd-supply = <&panel_avdd_regulator>;
+vddio-supply = <&vreg_l14a>;
+reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+panel_in_0: endpoint {
+remote-endpoint = <&mdss_dsi0_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+panel_in_1: endpoint {
+remote-endpoint = <&mdss_dsi1_out>;
+};
+};
+};
+};
+};
+
+...
--
2.44.0
[PATCH v3 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro 2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367 ++
3 files changed, 382 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 154f5bf82980..5b3eeb93b1a2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -542,6 +542,20 @@ config DRM_PANEL_RAYDIUM_RM692E5
Say Y here if you want to enable support for Raydium RM692E5-based
display panels, such as the one found in the Fairphone 5 smartphone.
+config DRM_PANEL_RAYDIUM_RM69380
+ tristate "Raydium RM69380-based DSI panel"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_DISPLAY_DP_HELPER
+ depends on DRM_DISPLAY_HELPER
+ depends on DRM_MIPI_DSI
+ depends on OF
+ help
+ Say Y here if you want to enable support for Raydium RM69380-based
+ display panels.
+
+ This panel controller can be found in the Lenovo Xiaoxin Pad Pro 2021
+ in combination with an EDO OLED panel.
+
config DRM_PANEL_RONBO_RB070D30
tristate "Ronbo Electronics RB070D30 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 24a02655d726..e2a2807d4ef0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
+obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20) += panel-samsung-atna33xc20.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_DB7430) += panel-samsung-db7430.o
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm69380.c
b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
new file mode 100644
index ..f89230c969b7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-raydium-rm69380.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree.
+ * Copyright (c) 2024 David Wronek
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rm69380_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+};
+
+static inline
+struct rm69380_panel *to_rm69380_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct rm69380_panel, panel);
+}
+
+static void rm69380_reset(struct rm69380_panel *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ usleep_range(15000, 16000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+ usleep_range(1, 11000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ msleep(30);
+}
+
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+
+ ret = mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set tear on: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_set_display_brightness(dsi, 0x7ff);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display brightness: %d\n", ret);
+ return ret;
+ }
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return
[PATCH v3 0/2] Add driver for Raydium RM69380-based DSI panels
This patch adds support the 2560x1600@90Hz dual DSI command mode panel by EDO in combination with a Raydium RM69380 driver IC. This driver IC can be found in the following devices: * Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel * Lenovo Tab P11 Pro (TB-J706F) with EDO panel * Robo & Kala 2-in-1 Laptop with Sharp panel Signed-off-by: David Wronek --- Changes in v3: - Removed unneeded curly brackets from some if statments - Fix error handling code in probe function - Include video/mipi_display.h and make use of MIPI command definitions - Removed DRM_MODE_TYPE_PREFERRED - Dropped 'prepared' bool entirely - Register second DSI host using mipi_dsi_device_register_full() - Link to v2: https://lore.kernel.org/r/20240415-raydium-rm69380-driver-v2-0-524216461...@mainlining.org Changes in v2: - Fixed typo in Kconfig - Removed ctx->prepared = true; in prepare function - Switched to drm_connector_helper_get_modes_fixed in get_modes function - Changed dev_notice() to dev_dbg() - Add description for compatible and reset-gpio in the dt-binding - Always require 'ports' node in the dt-binding regardless of compatible - Link to v1: https://lore.kernel.org/r/20240414-raydium-rm69380-driver-v1-0-5e86ba249...@mainlining.org --- David Wronek (2): dt-bindings: display: panel: Add Raydium RM69380 drm/panel: Add driver for EDO RM69380 OLED panel .../bindings/display/panel/raydium,rm69380.yaml| 91 + drivers/gpu/drm/panel/Kconfig | 14 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-raydium-rm69380.c | 367 + 4 files changed, 473 insertions(+) --- base-commit: 66e4190e92ce0e4a50b2f6be0e5f5b2e47e072f4 change-id: 20240414-raydium-rm69380-driver-47f22b6f24fe Best regards, -- David Wronek
Re: [PATCH v2 2/2] drm/panel: add Khadas TS050 V2 panel support
On 15/04/2024 05:14, Jacobe Zang wrote:
This add Khadas TS050 V2 Panel and make it compatible with old one.
Controller of V2 panel is "Himax HX8399-C" and the old panel is "NT35596".
In driver file, the only different between them is the timing squence.
Signed-off-by: Jacobe Zang
---
drivers/gpu/drm/panel/panel-khadas-ts050.c | 1112 +++-
1 file changed, 590 insertions(+), 522 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
index b942a01622743..c54be0cc3f084 100644
--- a/drivers/gpu/drm/panel/panel-khadas-ts050.c
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -25,6 +25,7 @@ struct khadas_ts050_panel {
struct regulator *supply;
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+ struct khadas_ts050_panel_data *panel_data;
bool prepared;
bool enabled;
@@ -32,544 +33,601 @@ struct khadas_ts050_panel {
struct khadas_ts050_panel_cmd {
u8 cmd;
- u8 data;
+ u8 data[55];
+ u8 size;
+};
+
+struct khadas_ts050_panel_data {
+ struct khadas_ts050_panel_cmd *init_code;
+ int len;
+};
+
+static const struct khadas_ts050_panel_cmd ts050v2_init_code[] = {
+ {0xB9, {0xFF, 0x83, 0x99}, 0x03},
+ {0xBA, {0x63, 0x23, 0x68, 0xCF}, 0x04},
+ {0xD2, {0x55}, 0x01},
+ {0xB1, {0x02, 0x04, 0x70, 0x90, 0x01, 0x32, 0x33,
+ 0x11, 0x11, 0x4D, 0x57, 0x56, 0x73, 0x02, 0x02}, 0x0f},
+ {0xB2, {0x00, 0x80, 0x80, 0xAE, 0x0A, 0x0E, 0x75, 0x11, 0x00, 0x00,
0x00}, 0x0b},
+ {0xB4, {0x00, 0xFF, 0x04, 0xA4, 0x02, 0xA0, 0x00, 0x00, 0x10, 0x00,
0x00, 0x02,
+ 0x00, 0x24, 0x02, 0x04, 0x0A, 0x21, 0x03, 0x00,
0x00, 0x08, 0xA6, 0x88,
+ 0x04, 0xA4, 0x02, 0xA0, 0x00, 0x00, 0x10, 0x00,
0x00, 0x02, 0x00, 0x24,
+ 0x02, 0x04, 0x0A, 0x00, 0x00, 0x08, 0xA6, 0x00,
0x08, 0x11}, 0x2e},
+ {0xD3, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x18,
+ 0x18, 0x32, 0x10, 0x09, 0x00, 0x09, 0x32,
+ 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x11, 0x00, 0x02, 0x02, 0x03, 0x00, 0x00,
0x00, 0x0A,
+ 0x40}, 0x21},
+ {0xD5, {0x18, 0x18, 0x18, 0x18, 0x21, 0x20, 0x18, 0x18, 0x19, 0x19,
0x19,
+ 0x19, 0x18, 0x18, 0x18, 0x18, 0x03, 0x02, 0x01, 0x00,
0x2F, 0x2F,
+ 0x30, 0x30, 0x31, 0x31, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18}, 0x20},
+ {0xD6, {0x18, 0x18, 0x18, 0x18, 0x20, 0x21, 0x19, 0x19, 0x18, 0x18,
0x19,
+ 0x19, 0x18, 0x18, 0x18, 0x18, 0x00, 0x01, 0x02, 0x03,
0x2F, 0x2F,
+ 0x30, 0x30, 0x31, 0x31, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18}, 0x20},
+ {0xD8, {0x0A, 0xBE, 0xFA, 0xA0, 0x0A, 0xBE, 0xFA, 0xA0}, 0x08},
+ {0xBD, {0x01}, 0x01},
+ {0xD8, {0x0F, 0xFF, 0xFF, 0xE0, 0x0F, 0xFF, 0xFF, 0xE0}, 0x08},
+ {0xBD, {0x02}, 0x01},
+ {0xD8, {0x0F, 0xFF, 0xFF, 0xE0, 0x0F, 0xFF, 0xFF, 0xE0}, 0x08},
+ {0xBD, {0x00}, 0x01},
+ {0xE0, {0x01, 0x35, 0x41, 0x3B, 0x79, 0x81, 0x8C, 0x85, 0x8E,
+ 0x95, 0x9B, 0xA0, 0xA4, 0xAB, 0xB1, 0xB3, 0xB7, 0xC5,
0xBD, 0xC5,
+ 0xB6, 0xC2, 0xC2, 0x62, 0x5D, 0x66, 0x73, 0x01, 0x35,
0x41, 0x3B,
+ 0x79, 0x81, 0x8C, 0x85, 0x8E, 0x95, 0x9B, 0xA0, 0xA4,
0xAB, 0xB1,
+ 0xB3, 0xB7, 0xB5, 0xBD, 0xC5, 0xB6, 0xC2, 0xC2, 0x62,
0x5D, 0x66,
+ 0x73}, 0x36},
+ {0xB6, {0x97, 0x97}, 0x02},
+ {0xCC, {0xC8}, 0x02},
+ {0xBF, {0x40, 0x41, 0x50, 0x19}, 0x04},
+ {0xC6, {0xFF, 0xF9}, 0x02},
+ {0xC0, {0x25, 0x5A}, 0x02},
};
/* Only the CMD1 User Command set is documented */
-static const struct khadas_ts050_panel_cmd init_code[] = {
+static const struct khadas_ts050_panel_cmd ts050_init_code[] = {
/* Select Unknown CMD Page (Undocumented) */
- {0xff, 0xee},
+ {0xff, {0xee}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
- {0x1f, 0x45},
- {0x24, 0x4f},
- {0x38, 0xc8},
- {0x39, 0x27},
- {0x1e, 0x77},
- {0x1d, 0x0f},
- {0x7e, 0x71},
- {0x7c, 0x03},
- {0xff, 0x00},
- {0xfb, 0x01},
- {0x35, 0x01},
+ {0xfb, {0x01}, 0x01},
+ {0x1f, {0x45}, 0x01},
+ {0x24, {0x4f}, 0x01},
+ {0x38, {0xc8}, 0x01},
+ {0x39, {0x27}, 0x01},
+ {0x1e, {0x77}, 0x01},
+ {0x1d, {0x0f}, 0x01},
+ {0x7e, {0x71}, 0x01},
+ {0x7c, {0x03}, 0x01},
+ {0xff, {0x00}, 0x01},
+ {0xfb, {0x01}, 0x01},
+ {0x35, {0x01}, 0x01},
/* Select CMD2 Page0 (Undocumented) */
- {0xff, 0x01},
+ {0xff, {0x01}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
- {0x00, 0x01},
-
Re: [PATCH v3 8/9] drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
On 15/04/2024 23:49, Nícolas F. R. A. Prado wrote:
Given that failing to find a DSI host causes the driver to defer probe,
make use of dev_err_probe() to log the reason. This makes the defer
probe reason available and avoids alerting userspace about something
that is not necessarily an error.
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
index 648ce9201426..028fdac293f7 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
@@ -556,10 +556,8 @@ static int nt35950_probe(struct mipi_dsi_device *dsi)
}
dsi_r_host = of_find_mipi_dsi_host_by_node(dsi_r);
of_node_put(dsi_r);
- if (!dsi_r_host) {
- dev_err(dev, "Cannot get secondary DSI host\n");
- return -EPROBE_DEFER;
- }
+ if (!dsi_r_host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "Cannot get
secondary DSI host\n");
nt->dsi[1] = mipi_dsi_device_register_full(dsi_r_host, info);
if (!nt->dsi[1]) {
Reviewed-by: Neil Armstrong
Re: [PATCH 03/15] drm/panel-edp: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Douglas Anderson
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-edp.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index d29bacf25c12..ece1e3553c1f 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -242,7 +242,7 @@ struct panel_edp {
const struct edp_panel_entry *detected_panel;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
struct drm_display_mode override_mode;
@@ -617,13 +617,16 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (p->ddc) {
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, p->ddc);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, p->ddc);
+
+ drm_edid_connector_update(connector, p->drm_edid);
+
/*
* If both edid and hard-coded modes exists, skip edid modes to
* avoid multiple preferred modes.
*/
- if (p->edid && !has_hard_coded_modes) {
+ if (p->drm_edid && !has_hard_coded_modes) {
if (has_override_edid_mode) {
/*
* override_edid_mode is specified. Use
@@ -632,7 +635,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
num += panel_edp_override_edid_mode(p,
connector,
p->detected_panel->override_edid_mode);
} else {
- num += drm_add_edid_modes(connector, p->edid);
+ num += drm_edid_connector_add_modes(connector);
}
}
@@ -981,8 +984,8 @@ static void panel_edp_remove(struct device *dev)
if (panel->ddc && (!panel->aux || panel->ddc != &panel->aux->ddc))
put_device(&panel->ddc->dev);
- kfree(panel->edid);
- panel->edid = NULL;
+ drm_edid_free(panel->drm_edid);
+ panel->drm_edid = NULL;
}
static void panel_edp_shutdown(struct device *dev)
Reviewed-by: Neil Armstrong
Re: [PATCH 02/15] drm/panel-samsung-atna33xc20: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-samsung-atna33xc20.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
index 6828a4f24d14..a9f0d214a900 100644
--- a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
+++ b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
@@ -36,7 +36,7 @@ struct atana33xc20_panel {
struct gpio_desc *el_on3_gpio;
struct drm_dp_aux *aux;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
ktime_t powered_off_time;
ktime_t powered_on_time;
@@ -253,9 +253,12 @@ static int atana33xc20_get_modes(struct drm_panel *panel,
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, &aux_ep->aux->ddc);
- num = drm_add_edid_modes(connector, p->edid);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, &aux_ep->aux->ddc);
+
+ drm_edid_connector_update(connector, p->drm_edid);
+
+ num = drm_edid_connector_add_modes(connector);
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -351,7 +354,7 @@ static void atana33xc20_remove(struct dp_aux_ep_device
*aux_ep)
drm_panel_disable(&panel->base);
drm_panel_unprepare(&panel->base);
- kfree(panel->edid);
+ drm_edid_free(panel->drm_edid);
}
static void atana33xc20_shutdown(struct dp_aux_ep_device *aux_ep)
Reviewed-by: Neil Armstrong
Re: [PATCH 01/15] drm/panel: simple: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 7215cf767898..d3264fa2f3ff 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -151,7 +151,7 @@ struct panel_simple {
struct gpio_desc *enable_gpio;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
struct drm_display_mode override_mode;
@@ -309,8 +309,8 @@ static int panel_simple_suspend(struct device *dev)
regulator_disable(p->supply);
p->unprepared_time = ktime_get_boottime();
- kfree(p->edid);
- p->edid = NULL;
+ drm_edid_free(p->drm_edid);
+ p->drm_edid = NULL;
return 0;
}
@@ -399,11 +399,12 @@ static int panel_simple_get_modes(struct drm_panel *panel,
if (p->ddc) {
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, p->ddc);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, p->ddc);
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ drm_edid_connector_update(connector, p->drm_edid);
+
+ num += drm_edid_connector_add_modes(connector);
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
Reviewed-by: Neil Armstrong
Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On 4/16/24 10:21, Conor Dooley wrote: On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote: On 4/16/24 02:30, Stefan Wahren wrote: Hi Maíra, Am 16.04.24 um 03:02 schrieb Maíra Canal: On 4/15/24 13:54, Andre Przywara wrote: On Mon, 15 Apr 2024 13:00:39 -0300 Maíra Canal wrote: Hi, RPi 0-3 is packed with a GPU that provides 3D rendering capabilities to the RPi. Currently, the downstream kernel uses an overlay to enable the GPU and use GPU hardware acceleration. When deploying a mainline kernel to the RPi 0-3, we end up without any GPU hardware acceleration (essentially, we can't use the OpenGL driver). Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. So I think Krzysztof's initial comment still stands: What does that patch actually change? If I build those DTBs as of now, none of them has a status property in the v3d node. Which means it's enabled: https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status So adding an explicit 'status = "okay";' doesn't make a difference. What do I miss here? As mentioned by Stefan in the last version, in Raspberry Pi OS, there is a systemd script which is trying to check for the V3D driver (/usr/lib /systemd/scripts/gldriver_test.sh). Within the first check, "raspi- config nonint is_kms" is called, which always seems to fail. What "raspi-config" does is check if /proc/device-tree/soc/v3d@7ec0/status is equal to "okay". As /proc/device-tree/soc/v3d@7ec0/status doesn't exists, it returns false. yes, but i also mention that the V3D driver starts without this patch. The commit message of this patch suggests this is a DT issue, which is not. I hadn't the time to update my SD card to Bookworm yet. Does the issue still exists with this version? I'm using a 32-bit kernel and the recommended OS for 32-bit is Bullseye. But I checked the Bookworm code and indeed, Bookworm doesn't check the device tree [1]. I'm thinking about sending a patch to the Bullseye branch to fix this issue. I think you should, sounds like they're making invalid assumptions about the status property. Agreed, fix the script, not the DTSes. -- Florian smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2 2/2] drm/panel: Add driver for EDO RM69380 OLED panel
W dniu 2024-04-15 19:55, Christophe JAILLET napisał(a):
Le 15/04/2024 à 18:10, David Wronek a écrit :
Add support for the 2560x1600@90Hz OLED panel by EDO bundled with a
Raydium RM69380 controller, as found on the Lenovo Xiaoxin Pad Pro
2021.
Signed-off-by: David Wronek
---
drivers/gpu/drm/panel/Kconfig | 14 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-raydium-rm69380.c | 366
++
3 files changed, 381 insertions(+)
...
+static int rm69380_on(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags |= MIPI_DSI_MODE_LPM;
+
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd4);
+ mipi_dsi_dcs_write_seq(dsi, 0x00, 0x80);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0xd0);
+ mipi_dsi_dcs_write_seq(dsi, 0x48, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x26);
+ mipi_dsi_dcs_write_seq(dsi, 0x75, 0x3f);
+ mipi_dsi_dcs_write_seq(dsi, 0x1d, 0x1a);
+ mipi_dsi_dcs_write_seq(dsi, 0xfe, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x53, 0x28);
+ mipi_dsi_dcs_write_seq(dsi, 0xc2, 0x08);
+ mipi_dsi_dcs_write_seq(dsi, 0x35, 0x00);
+ mipi_dsi_dcs_write_seq(dsi, 0x51, 0x07, 0xff);
+
+ ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ ret = mipi_dsi_dcs_set_display_on(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display on: %d\n", ret);
+ return ret;
+ }
+ msleep(36);
36 and 35 below are un-usual values for msleep.
Why 2 different values?
Would using a #define for this(these) value(s) make sense here?
I am not sure of that either. This is how the panel is being set up in
Android, as well as the bootloader.
See lines 67 and 92 here:
https://github.com/ungeskriptet/QcomXblBinaries/blob/master/J716F/BOOT.XF.3.2-00354-SM8250-1/RawFiles/Panel_rm69380_amoled_2k_cmd.xml
+
+ return 0;
+}
+
+static int rm69380_off(struct rm69380_panel *ctx)
+{
+ struct mipi_dsi_device *dsi = ctx->dsi[0];
+ struct device *dev = &dsi->dev;
+ int ret;
+
+ dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+ if (ctx->dsi[1])
+ ctx->dsi[1]->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+ ret = mipi_dsi_dcs_set_display_off(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to set display off: %d\n", ret);
+ return ret;
+ }
+ msleep(35);
(here)
+
+ ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enter sleep mode: %d\n", ret);
+ return ret;
+ }
+ msleep(20);
+
+ return 0;
+}
...
+static int rm69380_probe(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_host *dsi_sec_host;
+ struct rm69380_panel *ctx;
+ struct device *dev = &dsi->dev;
+ struct device_node *dsi_sec;
+ int ret, i;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx->supplies[0].supply = "vddio";
+ ctx->supplies[1].supply = "avdd";
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to get regulators\n");
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
+"Failed to get reset-gpios\n");
+
+ dsi_sec = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
+
+ if (dsi_sec) {
+ dev_dbg(dev, "Using Dual-DSI\n");
This should be after de 'info' variable below, so...
+
+ const struct mipi_dsi_device_info info = { "RM69380", 0,
+ dsi_sec };
+
+ dev_dbg(dev, "Found second DSI `%s`\n", dsi_sec->name);
... maybe merge the 2 messages into something like:
dev_dbg(dev, "Using Dual-DSI: found `%s`\n", dsi_sec->name);
+
+ dsi_sec_host = of_find_mipi_dsi_host_by_node(dsi_sec);
+ of_node_put(dsi_sec);
+ if (!dsi_sec_host) {
+ return dev_err_probe(dev, -EPROBE_DEFER,
+"Cannot get secondary DSI host\n");
+ }
+
Nit: unneeded { }
+ ctx->dsi[1] =
+ mipi_dsi_device_register_full(dsi_sec_host, &info);
+ if (IS_ERR(ctx->dsi[1])) {
+ return dev_err_probe(dev, PTR_ERR(ctx
Re: [PATCH v2] ARM: dts: bcm2835: Enable 3D rendering through V3D
On Tue, Apr 16, 2024 at 07:13:51AM -0300, Maíra Canal wrote: > On 4/16/24 02:30, Stefan Wahren wrote: > > Hi Maíra, > > > > Am 16.04.24 um 03:02 schrieb Maíra Canal: > > > On 4/15/24 13:54, Andre Przywara wrote: > > > > On Mon, 15 Apr 2024 13:00:39 -0300 > > > > Maíra Canal wrote: > > > > > > > > Hi, > > > > > > > > > RPi 0-3 is packed with a GPU that provides 3D rendering capabilities > > > > > to > > > > > the RPi. Currently, the downstream kernel uses an overlay to enable > > > > > the > > > > > GPU and use GPU hardware acceleration. When deploying a mainline > > > > > kernel > > > > > to the RPi 0-3, we end up without any GPU hardware acceleration > > > > > (essentially, we can't use the OpenGL driver). > > > > > > > > > > Therefore, enable the V3D core for the RPi 0-3 in the mainline kernel. > > > > > > > > So I think Krzysztof's initial comment still stands: What does that > > > > patch > > > > actually change? If I build those DTBs as of now, none of them has a > > > > status property in the v3d node. Which means it's enabled: > > > > https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter2-devicetree-basics.rst#status > > > > > > > > So adding an explicit 'status = "okay";' doesn't make a difference. > > > > > > > > What do I miss here? > > > > > > As mentioned by Stefan in the last version, in Raspberry Pi OS, there is > > > a systemd script which is trying to check for the V3D driver (/usr/lib > > > /systemd/scripts/gldriver_test.sh). Within the first check, "raspi- > > > config nonint is_kms" is called, which always seems to fail. What > > > "raspi-config" does is check if > > > /proc/device-tree/soc/v3d@7ec0/status is equal to "okay". As > > > /proc/device-tree/soc/v3d@7ec0/status doesn't exists, it returns > > > false. > > yes, but i also mention that the V3D driver starts without this patch. > > The commit message of this patch suggests this is a DT issue, which is not. > > > > I hadn't the time to update my SD card to Bookworm yet. Does the issue > > still exists with this version? > > I'm using a 32-bit kernel and the recommended OS for 32-bit is Bullseye. > But I checked the Bookworm code and indeed, Bookworm doesn't check > the device tree [1]. > > I'm thinking about sending a patch to the Bullseye branch to fix this > issue. I think you should, sounds like they're making invalid assumptions about the status property. signature.asc Description: PGP signature
Re: [PATCH v5 1/9] drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_ENCRYPTED flag
I would argue 'restricted' is the proper name since that was what was
settled on for the dma-buf code. :) But you are definitely right
that this memory is not encrypted.
On Tue, Apr 16, 2024 at 7:09 AM Nicolas Dufresne wrote:
>
> Hi,
>
> Le mercredi 03 avril 2024 à 18:26 +0800, Shawn Sung a écrit :
> > From: "Jason-JH.Lin"
> >
> > Add DRM_MTK_GEM_CREATE_ENCRYPTED flag to allow user to allocate
>
> Is "ENCRYPTED" a proper naming ? My expectation is that this would hold data
> in
> a PROTECTED memory region but that no cryptographic algorithm will be
> involved.
>
> Nicolas
>
> > a secure buffer to support secure video path feature.
> >
> > Signed-off-by: Jason-JH.Lin
> > Signed-off-by: Hsiao Chien Sung
> > ---
> > include/uapi/drm/mediatek_drm.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/include/uapi/drm/mediatek_drm.h
> > b/include/uapi/drm/mediatek_drm.h
> > index b0dea00bacbc4..e9125de3a24ad 100644
> > --- a/include/uapi/drm/mediatek_drm.h
> > +++ b/include/uapi/drm/mediatek_drm.h
> > @@ -54,6 +54,7 @@ struct drm_mtk_gem_map_off {
> >
> > #define DRM_MTK_GEM_CREATE 0x00
> > #define DRM_MTK_GEM_MAP_OFFSET 0x01
> > +#define DRM_MTK_GEM_CREATE_ENCRYPTED 0x02
> >
> > #define DRM_IOCTL_MTK_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
> > DRM_MTK_GEM_CREATE, struct drm_mtk_gem_create)
>
>
Re: [PATCH v3] drm/i915/vma: Fix UAF on reopen vs destroy race
On Tue, Apr 16, 2024 at 10:09:46AM +0200, Janusz Krzysztofik wrote:
> Hi Rodrigo,
>
> On Tuesday, 16 April 2024 03:16:31 CEST Rodrigo Vivi wrote:
> > On Mon, Apr 15, 2024 at 09:53:09PM +0200, Janusz Krzysztofik wrote:
> > > We defer actually closing, unbinding and destroying a VMA until next idle
> > > point, or until the object is freed in the meantime. By postponing the
> > > unbind, we allow for the VMA to be reopened by the client, avoiding the
> > > work required to rebind the VMA.
> > >
> > > It was assumed that as long as a GT is held idle, no VMA would be reopened
> > > while we destroy them. That assumption is no longer true in multi-GT
> > > configurations, where a VMA we reopen may be handled by a GT different
> > > from the one that we already keep active via its engine while we set up
> > > an execbuf request.
> > >
> > > <4> [260.290809] [ cut here ]
> > > <4> [260.290988] list_del corruption. prev->next should be
> > > 888118c5d990, but was 888118c5a510. (prev=888118c5a510)
> > > <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62
> > > __list_del_entry_valid_or_report+0xb7/0xe0
> > > ..
> > > <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0
> > > ...
> > > <4> [260.291087] Call Trace:
> > > <4> [260.291089]
> > > <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915]
> > > <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915]
> > > <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915]
> > > <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [260.292301]
> > > ...
> > > <4> [260.292506] ---[ end trace ]---
> > > <4> [260.292782] general protection fault, probably for non-canonical
> > > address 0x6b6b6b6b6b6b6ca3: [#1] PREEMPT SMP NOPTI
> > > <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: GW
> > > 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1
> > > <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client
> > > Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918
> > > 01/31/2024
> > > <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915]
> > > ...
> > > <4> [260.428756] Call Trace:
> > > <4> [260.431192]
> > > <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915]
> > > <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915]
> > > ...
> > > <4> [639.411134]
> > > ...
> > > <4> [639.449979] ---[ end trace ]---
> > >
> > > As soon as we start unbinding and destroying a VMA, marked it as parked,
> > > and also keep it marked as closed for the rest of its life. When a VMA
> > > to be opened occurs closed, reopen it only if not yet parked.
> > >
> > > v3: Fix misplaced brackets.
> > > v2: Since we no longer re-init the VMA closed list link on VMA park so it
> > > looks like still on a list, don't try to delete it from the list again
> > > after the VMA has been marked as parked.
> > >
> > > Fixes: b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()")
> >
> > what about reverting that?
>
> I didn't think of that. Why you think that might be a better approach?
well, I thought of that mainly because...
>
> Anyway, that's a 4 years old patch and a few things have changed since then,
> so simple revert won't work. Moreover, I've just checked that patch was
> supposed to fix another patch, 77853186e547 ("drm/i915: Claim vma while under
> closed_lock in i915_vma_parked()"), which in turn was supposed to fix
> aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events"), and that
> one also referenced still another, cb6c3d45f948 ("drm/i915/gem: Avoid parking
> the vma as we unbind") from December 2019, which finally wasn't a fix but an
> improvement.
... because of histories like that ^ and I was afraid of this patch here now
just put us into a different corner case.
I have a feeling that without locks there we might just hit another
race soon with the the park and only using the atomic checks.
> Then, we would have to consider new fixes alternative to at least
> some of those three, I guess.
Indeed.. I didn't think that deep on that...
> I'd rather not dig that deep, unless we invest
> in a completely new solution (e.g. backport VMA handling from xe if more
> effective while compatible to some extent?). Even then, we need a fix for
> now.
yeap, not sure if that would help. was also not designed to
the park unpark.
>
> Alternatively, we can try to revert my 1f33dc0c1189 ("drm/i915: Remove extra
> multi-gt pm-references") which was a manual revert of f56fe3e91787
> ("drm/i915:
> Fix a VMA UAF for multi-gt platform") -- a workaround that wa
Re: [PATCH v2 20/43] drm/vkms: Use fbdev-shmem
On 4/10/24 10:02, Thomas Zimmermann wrote: Implement fbdev emulation with fbdev-shmem. Avoids the overhead of fbdev-generic's additional shadow buffering. No functional changes. Signed-off-by: Thomas Zimmermann Acked-by: Maíra Canal Best Regards, - Maíra Cc: Rodrigo Siqueira Cc: Melissa Wen Cc: "Maíra Canal" Cc: Haneen Mohammed Cc: Daniel Vetter --- drivers/gpu/drm/vkms/vkms_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c index dd0af086e7fa9..8dc9dc13896e9 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.c +++ b/drivers/gpu/drm/vkms/vkms_drv.c @@ -17,7 +17,7 @@ #include #include #include -#include +#include #include #include #include @@ -223,7 +223,7 @@ static int vkms_create(struct vkms_config *config) if (ret) goto out_devres; - drm_fbdev_generic_setup(&vkms_device->drm, 0); + drm_fbdev_shmem_setup(&vkms_device->drm, 0); return 0;
[PATCH v2 16/18] arm64: defconfig: enable display connector support
Enable this feature for the i350-evk HDMI connector support. Signed-off-by: Alexandre Mergnat --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index fce98a150014..1df337882835 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -872,6 +872,7 @@ CONFIG_DRM_PANEL_STARTEK_KD070FHFID015=m CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m CONFIG_DRM_PANEL_VISIONOX_VTDR6130=m CONFIG_DRM_FSL_LDB=m +CONFIG_DRM_DISPLAY_CONNECTOR=m CONFIG_DRM_LONTIUM_LT8912B=m CONFIG_DRM_LONTIUM_LT9611=m CONFIG_DRM_LONTIUM_LT9611UXC=m -- 2.25.1
[PATCH v2 18/18] arm64: dts: mediatek: add display support for mt8365-evk
MIPI DSI:
- Add "vsys_lcm_reg" regulator support and setup the "mt6357_vsim1_reg",
to power the pannel plugged to the DSI connector.
- Setup the Display Parallel Interface.
- Add the startek kd070fhfid015 pannel support.
HDMI:
- Add HDMI connector support.
- Add the "ite,it66121" HDMI bridge support, driven by I2C1.
- Setup the Display Parallel Interface.
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 182
1 file changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
index 50cbaefa1a99..4afdcbefc481 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -26,6 +26,18 @@ chosen {
stdout-path = "serial0:921600n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "d";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_connector_out>;
+ };
+ };
+ };
+
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -86,6 +98,56 @@ optee_reserved: optee@4320 {
reg = <0 0x4320 0 0x00c0>;
};
};
+
+ vsys_lcm_reg: regulator-vsys-lcm {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&pio 129 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <500>;
+ regulator-min-microvolt = <500>;
+ regulator-name = "vsys_lcm";
+ };
+};
+
+&dpi0 {
+ pinctrl-0 = <&dpi_default_pins>;
+ pinctrl-1 = <&dpi_idle_pins>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&it66121_in>;
+ };
+ };
+};
+
+&dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ panel@0 {
+ compatible = "startek,kd070fhfid015";
+ status = "okay";
+ reg = <0>;
+ enable-gpios = <&pio 67 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&pio 20 GPIO_ACTIVE_HIGH>;
+ iovcc-supply = <&mt6357_vsim1_reg>;
+ power-supply = <&vsys_lcm_reg>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+
+ port {
+ dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
};
&cpu0 {
@@ -138,6 +200,50 @@ &i2c0 {
status = "okay";
};
+&i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-div = <2>;
+ clock-frequency = <10>;
+ pinctrl-0 = <&i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ it66121hdmitx: it66121hdmitx@4c {
+ #sound-dai-cells = <0>;
+ compatible = "ite,it66121";
+ interrupt-parent = <&pio>;
+ interrupts = <68 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-0 = <&ite_pins>;
+ pinctrl-names = "default";
+ reg = <0x4c>;
+ reset-gpios = <&pio 69 GPIO_ACTIVE_LOW>;
+ vcn18-supply = <&mt6357_vsim2_reg>;
+ vcn33-supply = <&mt6357_vibr_reg>;
+ vrf12-supply = <&mt6357_vrf12_reg>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ it66121_in: endpoint {
+ bus-width = <12>;
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ hdmi_connector_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+};
+
&mmc0 {
assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL>;
assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
@@ -180,7 +286,55 @@ &mt6357_pmic {
#interrupt-cells = <2>;
};
+&mt6357_vsim1_reg {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+};
+
&pio {
+ dpi_default_pins: dpi-default-pins {
+ pins {
+ pinmux = ,
+,
+,
+,
+
[PATCH v2 15/18] drm/mediatek: add MT8365 SoC support
From: Fabien Parent
Add DRM support for MT8365 SoC.
Signed-off-by: Fabien Parent
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Alexandre Mergnat
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 74832c213092..427b601309c4 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -230,6 +230,22 @@ static const unsigned int mt8195_mtk_ddp_ext[] = {
DDP_COMPONENT_DP_INTF1,
};
+static const unsigned int mt8365_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_DITHER0,
+ DDP_COMPONENT_DSI0,
+};
+
+static const unsigned int mt8365_mtk_ddp_ext[] = {
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI0,
+};
+
static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -317,6 +333,14 @@ static const struct mtk_mmsys_driver_data
mt8195_vdosys1_driver_data = {
.mmsys_dev_num = 2,
};
+static const struct mtk_mmsys_driver_data mt8365_mmsys_driver_data = {
+ .main_path = mt8365_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt8365_mtk_ddp_main),
+ .ext_path = mt8365_mtk_ddp_ext,
+ .ext_len = ARRAY_SIZE(mt8365_mtk_ddp_ext),
+ .mmsys_dev_num = 1,
+};
+
static const struct of_device_id mtk_drm_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmsys",
.data = &mt2701_mmsys_driver_data},
@@ -344,6 +368,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
.data = &mt8195_vdosys0_driver_data},
{ .compatible = "mediatek,mt8195-vdosys1",
.data = &mt8195_vdosys1_driver_data},
+ { .compatible = "mediatek,mt8365-mmsys",
+ .data = &mt8365_mmsys_driver_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
@@ -729,6 +755,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8195-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt8365-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-od",
.data = (void *)MTK_DISP_OD },
{ .compatible = "mediatek,mt2701-disp-ovl",
@@ -793,6 +821,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8188-dsi",
.data = (void *)MTK_DSI },
+ { .compatible = "mediatek,mt8365-dpi",
+ .data = (void *)MTK_DPI },
{ }
};
--
2.25.1
[PATCH v2 12/18] dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC
Add a compatible string for MediaTek Genio 350 MT8365's display PWM block: this is the same as MT8183. Reviewed-by: AngeloGioacchino Del Regno Acked-by: Uwe Kleine-König Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index f8988af05287..180dd8366935 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -31,6 +31,7 @@ properties: - mediatek,mt8188-disp-pwm - mediatek,mt8192-disp-pwm - mediatek,mt8195-disp-pwm + - mediatek,mt8365-disp-pwm - const: mediatek,mt8183-disp-pwm reg: -- 2.25.1
[PATCH v2 13/18] drm/mediatek: dsi: Improves the DSI lane setup robustness
Currently, mtk_dsi_lane_ready (which setup the DSI lane) is triggered before mtk_dsi_poweron. lanes_ready flag toggle to true during mtk_dsi_lane_ready function, and the DSI module is set up during mtk_dsi_poweron. Later, during panel driver init, mtk_dsi_lane_ready is triggered but does nothing because lanes are considered ready. Unfortunately, when the panel driver try to communicate, the DSI returns a timeout. The solution found here is to put lanes_ready flag to false after the DSI module setup into mtk_dsi_poweron to init the DSI lanes after the power / setup of the DSI module. Signed-off-by: Alexandre Mergnat --- drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index 9501f4019199..b3f33d4d3d5c 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -642,6 +642,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi) mtk_dsi_config_vdo_timing(dsi); mtk_dsi_set_interrupt_enable(dsi); + dsi->lanes_ready = false; + return 0; err_disable_engine_clk: clk_disable_unprepare(dsi->engine_clk); -- 2.25.1
[PATCH v2 05/18] dt-bindings: display: mediatek: dsi: add compatible for MT8365 SoC
Document the Display Serial Interface on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml index 8611319bed2e..a7aa8fcb0dd1 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml @@ -37,6 +37,7 @@ properties: - items: - enum: - mediatek,mt8195-dsi + - mediatek,mt8365-dsi - const: mediatek,mt8183-dsi reg: -- 2.25.1
[PATCH v2 14/18] drm/mediatek: add mt8365 dpi support
- Add compatibles and platform data into the Mediatek DPI driver.
- Fix the DPI0 parent clock to be consistent.
This SoC is compatible with the mt8183 calculate factor.
Signed-off-by: Alexandre Mergnat
---
drivers/clk/mediatek/clk-mt8365-mm.c | 2 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mt8365-mm.c
b/drivers/clk/mediatek/clk-mt8365-mm.c
index 01a2ef8f594e..3f62ec750733 100644
--- a/drivers/clk/mediatek/clk-mt8365-mm.c
+++ b/drivers/clk/mediatek/clk-mt8365-mm.c
@@ -53,7 +53,7 @@ static const struct mtk_gate mm_clks[] = {
GATE_MM0(CLK_MM_MM_DSI0, "mm_dsi0", "mm_sel", 17),
GATE_MM0(CLK_MM_MM_DISP_RDMA1, "mm_disp_rdma1", "mm_sel", 18),
GATE_MM0(CLK_MM_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 19),
- GATE_MM0(CLK_MM_DPI0_DPI0, "mm_dpi0_dpi0", "vpll_dpix", 20),
+ GATE_MM0(CLK_MM_DPI0_DPI0, "mm_dpi0_dpi0", "dpi0_sel", 20),
GATE_MM0(CLK_MM_MM_FAKE, "mm_fake", "mm_sel", 21),
GATE_MM0(CLK_MM_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 22),
GATE_MM0(CLK_MM_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 23),
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..a4f9376ee472 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -997,6 +997,23 @@ static const struct mtk_dpi_conf mt8195_dpintf_conf = {
.csc_enable_bit = DPINTF_CSC_ENABLE,
};
+static const struct mtk_dpi_conf mt8365_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+ .max_clock_khz = 15,
+ .output_fmts = mt8183_output_fmts,
+ .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+ .pixels_per_iter = 1,
+ .is_ck_de_pol = true,
+ .swap_input_support = true,
+ .support_direct_pin = true,
+ .dimension_mask = HPW_MASK,
+ .hvsize_mask = HSIZE_MASK,
+ .channel_swap_shift = CH_SWAP,
+ .yuv422_en_bit = YUV422_EN,
+ .csc_enable_bit = CSC_ENABLE,
+};
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1092,6 +1109,7 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8188-dp-intf", .data = &mt8195_dpintf_conf
},
{ .compatible = "mediatek,mt8192-dpi", .data = &mt8192_conf },
{ .compatible = "mediatek,mt8195-dp-intf", .data = &mt8195_dpintf_conf
},
+ { .compatible = "mediatek,mt8365-dpi", .data = &mt8365_conf },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
--
2.25.1
[PATCH v2 17/18] arm64: dts: mediatek: add display blocks support for the MT8365 SoC
- Add aliases for each display components to help display drivers.
- Add the Display Pulse Width Modulation (DISP_PWM) to provide PWM signals
for the LED driver of mobile LCM.
- Add the MIPI Display Serial Interface (DSI) PHY support. (up to 4-lane
output)
- Add the display mutex support.
- Add the following display component support:
- OVL0 (Overlay)
- RDMA0 (Data Path Read DMA)
- Color0
- CCorr0 (Color Correction)
- AAL0 (Adaptive Ambient Light)
- GAMMA0
- Dither0
- DSI0 (Display Serial Interface)
- RDMA1 (Data Path Read DMA)
- DPI0 (Display Parallel Interface)
Signed-off-by: Alexandre Mergnat
---
arch/arm64/boot/dts/mediatek/mt8365.dtsi | 146 +++
1 file changed, 146 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
index 24581f7410aa..a95f90da4491 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,6 +18,19 @@ / {
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ aal0 = &aal0;
+ ccorr0 = &ccorr0;
+ color0 = &color0;
+ dither0 = &dither0;
+ dpi0 = &dpi0;
+ dsi0 = &dsi0;
+ gamma0 = &gamma0;
+ ovl0 = &ovl0;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -607,6 +621,17 @@ spi: spi@1100a000 {
status = "disabled";
};
+ disp_pwm: pwm@1100e000 {
+ compatible = "mediatek,mt8365-disp-pwm",
+"mediatek,mt8183-disp-pwm";
+ reg = <0 0x1100e000 0 0x1000>;
+ clock-names = "main", "mm";
+ clocks = <&topckgen CLK_TOP_DISP_PWM_SEL>,
+<&infracfg CLK_IFR_DISP_PWM>;
+ power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ #pwm-cells = <2>;
+ };
+
i2c3: i2c@1100f000 {
compatible = "mediatek,mt8365-i2c",
"mediatek,mt8168-i2c";
reg = <0 0x1100f000 0 0xa0>, <0 0x11000200 0 0x80>;
@@ -703,6 +728,15 @@ ethernet: ethernet@112a {
status = "disabled";
};
+ mipi_tx0: dsi-phy@11c0 {
+ compatible = "mediatek,mt8365-mipi-tx",
"mediatek,mt8183-mipi-tx";
+ reg = <0 0x11c0 0 0x800>;
+ clock-output-names = "mipi_tx0_pll";
+ clocks = <&clk26m>;
+ #clock-cells = <0>;
+ #phy-cells = <0>;
+ };
+
u3phy: t-phy@11cc {
compatible = "mediatek,mt8365-tphy",
"mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -732,6 +766,13 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
+ mutex: mutex@14001000 {
+ compatible = "mediatek,mt8365-disp-mutex";
+ reg = <0 0x14001000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ };
+
smi_common: smi@14002000 {
compatible = "mediatek,mt8365-smi-common";
reg = <0 0x14002000 0 0x1000>;
@@ -755,6 +796,111 @@ larb0: larb@14003000 {
mediatek,larb-id = <0>;
};
+ ovl0: ovl@1400b000 {
+ compatible = "mediatek,mt8365-disp-ovl",
+"mediatek,mt8192-disp-ovl";
+ reg = <0 0x1400b000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MM_DISP_OVL0>;
+ interrupts = ;
+ iommus = <&iommu M4U_PORT_DISP_OVL0>;
+ power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ };
+
+ rdma0: rdma@1400d000 {
+ compatible = "mediatek,mt8365-disp-rdma",
+"mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400d000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MM_DISP_RDMA0>;
+ interrupts = ;
+ iommus = <&iommu M4U_PORT_DISP_RDMA0>;
+ mediatek,rdma-fifo-size = <5120>;
+ power-domains = <&spm MT8365_POWER_DOMAIN_MM>;
+ };
+
+ color0: color@1400f000 {
+ compatible = "mediatek,mt8365-disp-color",
+"mediatek,mt8173-dis
[PATCH v2 08/18] dt-bindings: display: mediatek: gamma: add compatible for MT8365 SoC
Document the display Gamma on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml index c6641acd75d6..f447f4320e8b 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -34,6 +34,7 @@ properties: - mediatek,mt8188-disp-gamma - mediatek,mt8192-disp-gamma - mediatek,mt8195-disp-gamma + - mediatek,mt8365-disp-gamma - const: mediatek,mt8183-disp-gamma reg: -- 2.25.1
[PATCH v2 10/18] dt-bindings: display: mediatek: rdma: add compatible for MT8365 SoC
Document the display Data Path Read DMA on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml index 39dbb5c8bcf8..4cadb245d028 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -45,6 +45,7 @@ properties: - enum: - mediatek,mt8186-disp-rdma - mediatek,mt8192-disp-rdma + - mediatek,mt8365-disp-rdma - const: mediatek,mt8183-disp-rdma reg: -- 2.25.1
[PATCH v2 06/18] dt-bindings: display: mediatek: dpi: add power-domains property
From: Fabien Parent
DPI is part of the display / multimedia block in MediaTek SoCs, and
always have a power-domain (at least in the upstream device-trees).
Add the power-domains property to the binding documentation.
Signed-off-by: Fabien Parent
Signed-off-by: Alexandre Mergnat
---
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..e126486e8eac 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,6 +64,9 @@ properties:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ power-domains:
+maxItems: 1
+
required:
- compatible
- reg
@@ -78,11 +81,13 @@ examples:
- |
#include
#include
+#include
dpi0: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = ;
+power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DPI_PIXEL>,
<&mmsys CLK_MM_DPI_ENGINE>,
<&apmixedsys CLK_APMIXED_TVDPLL>;
--
2.25.1
[PATCH v2 11/18] dt-bindings: pwm: mediatek,pwm-disp: add power-domains property
According to the Mediatek MT8365 datasheet, the display PWM block has a power domain. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml index afcdeed4e88a..f8988af05287 100644 --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -52,6 +52,12 @@ properties: - const: main - const: mm + power-domains: +maxItems: 1 +description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + required: - compatible - reg -- 2.25.1
[PATCH v2 07/18] dt-bindings: display: mediatek: dpi: add compatible for MT8365
Add dt-binding documentation of dpi for MediaTek MT8365 SoC. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index e126486e8eac..ebb61bc4eab7 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -27,6 +27,7 @@ properties: - mediatek,mt8188-dp-intf - mediatek,mt8192-dpi - mediatek,mt8195-dp-intf + - mediatek,mt8365-dpi - items: - enum: - mediatek,mt6795-dpi -- 2.25.1
[PATCH v2 09/18] dt-bindings: display: mediatek: ovl: add compatible for MT8365 SoC
Document the display Overlay on MT8365, which is compatible with that of the MT8192. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index c471a181d125..d55611c7ce5e 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -44,6 +44,7 @@ properties: - items: - enum: - mediatek,mt8186-disp-ovl + - mediatek,mt8365-disp-ovl - const: mediatek,mt8192-disp-ovl reg: -- 2.25.1
[PATCH v2 02/18] dt-bindings: display: mediatek: ccorr: add compatible for MT8365 SoC
Document the display Color Correction on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index 8c2a737237f2..9f8366763831 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -24,6 +24,9 @@ properties: - enum: - mediatek,mt8183-disp-ccorr - mediatek,mt8192-disp-ccorr + - items: + - const: mediatek,mt8365-disp-ccorr + - const: mediatek,mt8183-disp-ccorr - items: - enum: - mediatek,mt8186-disp-ccorr -- 2.25.1
[PATCH v2 03/18] dt-bindings: display: mediatek: color: add compatible for MT8365 SoC
Document the display Color on MT8365, which is compatible with that of the MT8173. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index b886ca0d89ea..7df786bbad20 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -40,6 +40,7 @@ properties: - mediatek,mt8188-disp-color - mediatek,mt8192-disp-color - mediatek,mt8195-disp-color + - mediatek,mt8365-disp-color - const: mediatek,mt8173-disp-color reg: maxItems: 1 -- 2.25.1
[PATCH v2 04/18] dt-bindings: display: mediatek: dither: add compatible for MT8365 SoC
Document the display Dither on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml index 1588b3f7cec7..6fceb1f95d2a 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt8188-disp-dither - mediatek,mt8192-disp-dither - mediatek,mt8195-disp-dither + - mediatek,mt8365-disp-dither - const: mediatek,mt8183-disp-dither reg: -- 2.25.1
[PATCH v2 01/18] dt-bindings: display: mediatek: aal: add compatible for MT8365 SoC
Document the display Adaptive Ambient Light on MT8365, which is compatible with that of the MT8183. Signed-off-by: Alexandre Mergnat --- Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index b4c28e96dd55..cf24434854ff 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -36,6 +36,7 @@ properties: - mediatek,mt8188-disp-aal - mediatek,mt8192-disp-aal - mediatek,mt8195-disp-aal + - mediatek,mt8365-disp-aal - const: mediatek,mt8183-disp-aal reg: -- 2.25.1
[PATCH v2 00/18] Add display support for the MT8365-EVK board
The purpose of this series is to add the display support for the mt8365-evk. This is the list of HWs / IPs support added: - Connectors (HW): - HDMI - MIPI DSI (Mobile Industry Processor Interface Display Serial Interface) - HDMI bridge (it66121) - DSI pannel (startek,kd070fhfid015) - SoC display blocks (IP): - OVL0 (Overlay) - RDMA0 (Data Path Read DMA) - Color0 - CCorr0 (Color Correction) - AAL0 (Adaptive Ambient Light) - GAMMA0 - Dither0 - DSI0 (Display Serial Interface) - RDMA1 (Data Path Read DMA) - DPI0 (Display Parallel Interface) The Mediatek DSI, DPI and DRM drivers are also improved. Regards, Alex Signed-off-by: Alexandre Mergnat --- Changes in v2: - s/binding/compatible/ in commit messages/titles. - Improve commit messages as Conor suggest. - pwm-disp: Set power domain property for MT8365. This one is optionnal and can be used for other SoC. - Fix mediatek,dsi.yaml issue. - Remove the extra clock in the DPI node/driver and fix the dpi clock parenting to be consistent with the DPI clock assignement. - Link to v1: https://lore.kernel.org/r/20231023-display-support-v1-0-5c860ed5c...@baylibre.com --- Alexandre Mergnat (16): dt-bindings: display: mediatek: aal: add compatible for MT8365 SoC dt-bindings: display: mediatek: ccorr: add compatible for MT8365 SoC dt-bindings: display: mediatek: color: add compatible for MT8365 SoC dt-bindings: display: mediatek: dither: add compatible for MT8365 SoC dt-bindings: display: mediatek: dsi: add compatible for MT8365 SoC dt-bindings: display: mediatek: dpi: add compatible for MT8365 dt-bindings: display: mediatek: gamma: add compatible for MT8365 SoC dt-bindings: display: mediatek: ovl: add compatible for MT8365 SoC dt-bindings: display: mediatek: rdma: add compatible for MT8365 SoC dt-bindings: pwm: mediatek,pwm-disp: add power-domains property dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC drm/mediatek: dsi: Improves the DSI lane setup robustness drm/mediatek: add mt8365 dpi support arm64: defconfig: enable display connector support arm64: dts: mediatek: add display blocks support for the MT8365 SoC arm64: dts: mediatek: add display support for mt8365-evk Fabien Parent (2): dt-bindings: display: mediatek: dpi: add power-domains property drm/mediatek: add MT8365 SoC support .../bindings/display/mediatek/mediatek,aal.yaml| 1 + .../bindings/display/mediatek/mediatek,ccorr.yaml | 3 + .../bindings/display/mediatek/mediatek,color.yaml | 1 + .../bindings/display/mediatek/mediatek,dither.yaml | 1 + .../bindings/display/mediatek/mediatek,dpi.yaml| 6 + .../bindings/display/mediatek/mediatek,dsi.yaml| 1 + .../bindings/display/mediatek/mediatek,gamma.yaml | 1 + .../bindings/display/mediatek/mediatek,ovl.yaml| 1 + .../bindings/display/mediatek/mediatek,rdma.yaml | 1 + .../devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 7 + arch/arm64/boot/dts/mediatek/mt8365-evk.dts| 182 + arch/arm64/boot/dts/mediatek/mt8365.dtsi | 146 + arch/arm64/configs/defconfig | 1 + drivers/clk/mediatek/clk-mt8365-mm.c | 2 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 drivers/gpu/drm/mediatek/mtk_dsi.c | 2 + 17 files changed, 403 insertions(+), 1 deletion(-) --- base-commit: 890c94ce8a456aa4d7ead5f5fd2603b98dfe7b7e change-id: 20231023-display-support-c6418b30e419 Best regards, -- Alexandre Mergnat
Re: [PATCH] drm/fb_dma: Fix parameter name in htmldocs
On 16/04/2024 14:12, Thomas Zimmermann wrote:
Hi
Am 16.04.24 um 11:05 schrieb Jocelyn Falempe:
The parameter name is 'sb' and not 'drm_scanout_buffer'.
It fixes the following warnings:
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function
parameter 'drm_scanout_buffer' description in
'drm_fb_dma_get_scanout_buffer'
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Function parameter
or struct member 'sb' not described in 'drm_fb_dma_get_scanout_buffer'
drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function
parameter 'drm_scanout_buffer' description in
'drm_fb_dma_get_scanout_buffer'
Fixes: 879b3b6511fe ("drm/fb_dma: Add generic get_scanout_buffer() for
drm_panic")
Reported-by: Stephen Rothwell
Signed-off-by: Jocelyn Falempe
Reviewed-by: Thomas Zimmermann
pushed to drm-misc-next
Thanks,
--
Jocelyn
Best regards
Thomas
---
drivers/gpu/drm/drm_fb_dma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_dma_helper.c
b/drivers/gpu/drm/drm_fb_dma_helper.c
index c79b5078303f..96e5ab960f12 100644
--- a/drivers/gpu/drm/drm_fb_dma_helper.c
+++ b/drivers/gpu/drm/drm_fb_dma_helper.c
@@ -153,7 +153,7 @@ EXPORT_SYMBOL_GPL(drm_fb_dma_sync_non_coherent);
/**
* drm_fb_dma_get_scanout_buffer - Provide a scanout buffer in case
of panic
* @plane: DRM primary plane
- * @drm_scanout_buffer: scanout buffer for the panic handler
+ * @sb: scanout buffer for the panic handler
* Returns: 0 or negative error code
*
* Generic get_scanout_buffer() implementation, for drivers that
uses the
base-commit: 7b0062036c3b71b4a69e244ecf0502c06c4cf5f0
Re: [PATCH 14/18] drm/mediatek: dpi: add support for dpi clock
On 24/10/2023 11:12, AngeloGioacchino Del Regno wrote: Il 23/10/23 16:40, amerg...@baylibre.com ha scritto: From: Fabien Parent MT8365 requires an additional clock for DPI. Add support for that additional clock. Signed-off-by: Fabien Parent Signed-off-by: Alexandre Mergnat I'm not convinced that this is right... at all. From a fast check of the MT8365 DPI clocks, I can see that the DPI0 clock declares parent VPLL_DPIX (a fixed clock), but nothing ever has VPLL_DPIX_EN (which is the GATE clock, enabling output of DPIx VPLL?). But then, there's even more: no clock ever references the CLK_TOP_DPI0_SEL nor the CLK_TOP_DPI1_SEL gate, which is a PLL parent selector... in other platforms, that is muxing through the TVDPLL, but on MT8365 that is LVDSPLL?! AFAI see into mt8365 documentation, there is no TVDPLL, only LVDSPLL I have many questions now: * Two PLLs are apparently brought up, but which one is the right one?! * Is the LVDS PLL really used for DisplayPort? (dpi0_sel) Seems to be LVDS enable prepare protect duty hardware clock countcountcountrate accuracy phase cycleenable --- clk26m 18 1912600 0 0 Y vpll_dpix 1107500 0 0 5 Y mm_flvdstx_pxl 0007500 0 0 5 N mm_dpi0_dpi0 1107500 0 0 5 Y vpll_dpix_en 0007500 0 0 5 N lvdspll 110 283999497 0 0 5 Y lvdspll_d1600017749968 0 0 5 Y lvdspll_d8 00035499937 0 0 5 Y lvdspll_d4 00070999874 0 0 5 Y lvdspll_d2 110 141999748 0 0 5 Y dpi0_sel110 141999748 0 0 5 Y dpi1_sel000 141999748 0 0 5 N mmpll 110 45609 0 0 5 Y mmpll_ck 110 45609 0 0 5 Y mm_sel 15 150 45609 0 0 5 Y mm_dpi0 110 45609 0 0 5 Y * Are you sure that CLK_MM_DPI0_DPI0's parent shouldn't be dpi0_sel instead? I'm agree with you. After few change, it works. - GATE_MM0(CLK_MM_DPI0_DPI0, "mm_dpi0_dpi0", "vpll_dpix", 20), + GATE_MM0(CLK_MM_DPI0_DPI0, "mm_dpi0_dpi0", "dpi0_sel", 20), - clocks = <&topckgen CLK_TOP_DPI0_SEL>, + clocks = <&mmsys CLK_MM_DPI0_DPI0>, enable prepare protect duty hardware clock countcountcountrate accuracy phase cycleenable --- vpll_dpix0 0075000 0 5 Y mm_flvdstx_pxl0 0075000 0 5 N vpll_dpix_en 0 0075000 0 5 N lvdspll 1 10283999497 0 0 5 Y lvdspll_d16 0 00177499680 0 5 Y lvdspll_d80 00354999370 0 5 Y lvdspll_d40 00709998740 0 5 Y lvdspll_d21 10141999748 0 0 5 Y dpi0_sel 1 10141999748 0 0 5 Y mm_dpi0_dpi01 10141999748 0 0 5 Y dpi1_sel 0 00141999748 0 0 5 N mmpll1 1045609 0 0 5
