* Re: [PATCH v3 4/4] devfreq: Refcount governor modules while in use
From: zhenglifeng (A) @ 2026-05-21 8:13 UTC (permalink / raw)
To: Jie Zhan, cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park,
linux-pm, linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-5-zhanjie9@hisilicon.com>
On 5/19/2026 7:32 PM, Jie Zhan wrote:
> A governor module can be inserted or removed dynamically when built as a
> kernel module. 'devfreq->governor' would become NULL if the governor
> module is removed when it's in use.
>
> Add a refcount mechanism for governor modules to prevent the governor
> module from being removed (except for force unload):
> 1. Add an optional 'owner' member to struct devfreq_governor so the devfreq
> core can identify the module that holds the governor code.
> 2. Get and put a refcount of the governor module when starting and stopping
> the governor.
>
> The new 'owner' field is optional:
> - Common governor modules (performance, powersave, simple_ondemand,
> userspace, passive) set 'owner' to THIS_MODULE.
> - Governors that are bundled into a device driver module must leave 'owner'
> NULL. The device's lifetime already pins that module, and setting
> 'owner' would create a self-reference that blocks the driver from being
> unloaded.
>
> As a result, a non-forced rmmod of an in-use stand-alone governor now
> fails with -EBUSY, e.g.:
>
> $ cat governor
> performance
> $ rmmod governor_performance
> rmmod: ERROR: Module governor_performance is in use
>
> Force unloads (rmmod -f, if configured) can't be blocked.
>
> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
> ---
> drivers/devfreq/devfreq.c | 17 ++++++++++++++++-
> drivers/devfreq/governor_passive.c | 1 +
> drivers/devfreq/governor_performance.c | 1 +
> drivers/devfreq/governor_powersave.c | 1 +
> drivers/devfreq/governor_simpleondemand.c | 1 +
> drivers/devfreq/governor_userspace.c | 1 +
> include/linux/devfreq-governor.h | 11 +++++++++++
> 7 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 9e3e6a7348f8..1cee43636ded 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -345,24 +345,37 @@ static int devfreq_set_governor(struct devfreq *df,
> __func__, df->governor->name, ret);
> return ret;
> }
> + module_put(old_gov->owner);
> }
>
> /* Start the new governor */
> + if (!try_module_get(new_gov->owner)) {
> + df->governor = NULL;
Shouldn't the old governor be restored here?
> + return -EINVAL;
> + }
> +
> df->governor = new_gov;
> ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> if (ret) {
> dev_warn(dev, "%s: Governor %s not started(%d)\n",
> __func__, df->governor->name, ret);
> + module_put(new_gov->owner);
>
> /* Restore previous governor */
> df->governor = old_gov;
> if (!df->governor)
> return ret;
>
> + if (!try_module_get(old_gov->owner)) {
> + df->governor = NULL;
> + return -EINVAL;
> + }
> +
> ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> if (ret) {
> dev_err(dev, "%s: restore Governor %s failed (%d)\n",
> __func__, df->governor->name, ret);
> + module_put(old_gov->owner);
> df->governor = NULL;
> return ret;
> }
> @@ -1040,9 +1053,11 @@ int devfreq_remove_device(struct devfreq *devfreq)
>
> devfreq_cooling_unregister(devfreq->cdev);
>
> - if (devfreq->governor)
> + if (devfreq->governor) {
> devfreq->governor->event_handler(devfreq,
> DEVFREQ_GOV_STOP, NULL);
> + module_put(devfreq->governor->owner);
> + }
> device_unregister(&devfreq->dev);
>
> return 0;
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index d7feecd900f1..3e63dd200a04 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -449,6 +449,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
> static struct devfreq_governor devfreq_passive = {
> .name = DEVFREQ_GOV_PASSIVE,
> .flags = DEVFREQ_GOV_FLAG_IMMUTABLE,
> + .owner = THIS_MODULE,
> .get_target_freq = devfreq_passive_get_target_freq,
> .event_handler = devfreq_passive_event_handler,
> };
> diff --git a/drivers/devfreq/governor_performance.c b/drivers/devfreq/governor_performance.c
> index fdb22bf512cf..0a08b067ea6b 100644
> --- a/drivers/devfreq/governor_performance.c
> +++ b/drivers/devfreq/governor_performance.c
> @@ -37,6 +37,7 @@ static int devfreq_performance_handler(struct devfreq *devfreq,
>
> static struct devfreq_governor devfreq_performance = {
> .name = DEVFREQ_GOV_PERFORMANCE,
> + .owner = THIS_MODULE,
> .get_target_freq = devfreq_performance_func,
> .event_handler = devfreq_performance_handler,
> };
> diff --git a/drivers/devfreq/governor_powersave.c b/drivers/devfreq/governor_powersave.c
> index ee2d6ec8a512..3ae296d55e3e 100644
> --- a/drivers/devfreq/governor_powersave.c
> +++ b/drivers/devfreq/governor_powersave.c
> @@ -37,6 +37,7 @@ static int devfreq_powersave_handler(struct devfreq *devfreq,
>
> static struct devfreq_governor devfreq_powersave = {
> .name = DEVFREQ_GOV_POWERSAVE,
> + .owner = THIS_MODULE,
> .get_target_freq = devfreq_powersave_func,
> .event_handler = devfreq_powersave_handler,
> };
> diff --git a/drivers/devfreq/governor_simpleondemand.c b/drivers/devfreq/governor_simpleondemand.c
> index ac9c5e9e51a4..46287b279ded 100644
> --- a/drivers/devfreq/governor_simpleondemand.c
> +++ b/drivers/devfreq/governor_simpleondemand.c
> @@ -119,6 +119,7 @@ static struct devfreq_governor devfreq_simple_ondemand = {
> .name = DEVFREQ_GOV_SIMPLE_ONDEMAND,
> .attrs = DEVFREQ_GOV_ATTR_POLLING_INTERVAL
> | DEVFREQ_GOV_ATTR_TIMER,
> + .owner = THIS_MODULE,
> .get_target_freq = devfreq_simple_ondemand_func,
> .event_handler = devfreq_simple_ondemand_handler,
> };
> diff --git a/drivers/devfreq/governor_userspace.c b/drivers/devfreq/governor_userspace.c
> index 3906ebedbae8..b1acccc79f7f 100644
> --- a/drivers/devfreq/governor_userspace.c
> +++ b/drivers/devfreq/governor_userspace.c
> @@ -135,6 +135,7 @@ static int devfreq_userspace_handler(struct devfreq *devfreq,
>
> static struct devfreq_governor devfreq_userspace = {
> .name = DEVFREQ_GOV_USERSPACE,
> + .owner = THIS_MODULE,
> .get_target_freq = devfreq_userspace_func,
> .event_handler = devfreq_userspace_handler,
> };
> diff --git a/include/linux/devfreq-governor.h b/include/linux/devfreq-governor.h
> index dfdd0160a29f..ae1721e58401 100644
> --- a/include/linux/devfreq-governor.h
> +++ b/include/linux/devfreq-governor.h
> @@ -12,6 +12,7 @@
> #define __LINUX_DEVFREQ_DEVFREQ_H__
>
> #include <linux/devfreq.h>
> +struct module;
>
> #define DEVFREQ_NAME_LEN 16
>
> @@ -53,6 +54,15 @@
> * @name: Governor's name
> * @attrs: Governor's sysfs attribute flags
> * @flags: Governor's feature flags
> + * @owner: Optional, module that owns this governor.
> + * When set (typically to THIS_MODULE), the devfreq core
> + * takes a reference on @owner while this governor is in
> + * use so that the governor module cannot be removed,
> + * except by a forced unload. Governors that are bundled
> + * into a device driver module must leave @owner NULL: the
> + * device's lifetime already pins that module, and setting
> + * @owner would create a self-reference that prevents the
> + * driver from being unloaded.
> * @get_target_freq: Returns desired operating frequency for the device.
> * Basically, get_target_freq will run
> * devfreq_dev_profile.get_dev_status() to get the
> @@ -70,6 +80,7 @@ struct devfreq_governor {
> const char name[DEVFREQ_NAME_LEN];
> const u64 attrs;
> const u64 flags;
> + struct module *owner;
> int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
> int (*event_handler)(struct devfreq *devfreq,
> unsigned int event, void *data);
^ permalink raw reply
* [PATCH 2/2] KVM: arm64: Add fail-safe for refcounted pages in __pkvm_hyp_donate_host
From: Vincent Donnefort @ 2026-05-21 8:12 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
In-Reply-To: <20260521081250.655226-1-vdonnefort@google.com>
A previous bug in __pkvm_init_vm error path showed that the hypervisor
could leak refcounted pages, (i.e. losing access to a page while its
refcount is still elevated). This poses a threat to the pKVM state
machine.
Address this by introducing a fail-safe in n __pkvm_hyp_donate_host.
Transitions are not a hot path so added security is worth the extra
check.
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 1e17973f24bb..dd168879431f 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -856,6 +856,16 @@ static int __hyp_check_page_state_range(phys_addr_t phys, u64 size, enum pkvm_pa
return 0;
}
+static int __hyp_check_page_count_range(phys_addr_t phys, u64 size)
+{
+ for_each_hyp_page(page, phys, size) {
+ if (page->refcount)
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
static bool guest_pte_is_poisoned(kvm_pte_t pte)
{
if (kvm_pte_valid(pte))
@@ -1054,7 +1064,6 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu *vcpu, u64 gfn)
int __pkvm_host_unshare_hyp(u64 pfn)
{
u64 phys = hyp_pfn_to_phys(pfn);
- u64 virt = (u64)__hyp_va(phys);
u64 size = PAGE_SIZE;
int ret;
@@ -1067,10 +1076,9 @@ int __pkvm_host_unshare_hyp(u64 pfn)
ret = __hyp_check_page_state_range(phys, size, PKVM_PAGE_SHARED_BORROWED);
if (ret)
goto unlock;
- if (hyp_page_count((void *)virt)) {
- ret = -EBUSY;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
goto unlock;
- }
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(__host_set_page_state_range(phys, size, PKVM_PAGE_OWNED));
@@ -1133,6 +1141,10 @@ int __pkvm_hyp_donate_host(u64 pfn, u64 nr_pages)
if (ret)
goto unlock;
+ ret = __hyp_check_page_count_range(phys, size);
+ if (ret)
+ goto unlock;
+
__hyp_set_page_state_range(phys, size, PKVM_NOPAGE);
WARN_ON(kvm_pgtable_hyp_unmap(&pkvm_pgtable, virt, size) != size);
WARN_ON(host_stage2_set_owner_locked(phys, size, PKVM_ID_HOST));
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH 1/2] KVM: arm64: Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 8:12 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort, Sashiko
In-Reply-To: <20260521081250.655226-1-vdonnefort@google.com>
In the unlikely case where insert_vm_table_entry fails, __pkvm_init_vm
release the memory donated by the host for the PGD, but as the stage-2
is still set-up the hypervisor keeps a refcount on those pages,
effectively leaking the references.
Fix the rollback with the newly added kvm_guest_destroy_stage2().
Fixes: 256b4668cd89 ("KVM: arm64: Introduce separate hypercalls for pKVM VM reservation and initialization")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
diff --git a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
index 3cbfae0e3dda..4f2b871199cb 100644
--- a/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
+++ b/arch/arm64/kvm/hyp/include/nvhe/mem_protect.h
@@ -56,6 +56,7 @@ int host_stage2_idmap_locked(phys_addr_t addr, u64 size, enum kvm_pgtable_prot p
int host_stage2_set_owner_locked(phys_addr_t addr, u64 size, u8 owner_id);
int kvm_host_prepare_stage2(void *pgt_pool_base);
int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd);
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm);
void handle_host_mem_abort(struct kvm_cpu_context *host_ctxt);
int hyp_pin_shared_mem(void *from, void *to);
diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 25f04629014e..1e17973f24bb 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -306,16 +306,21 @@ int kvm_guest_prepare_stage2(struct pkvm_hyp_vm *vm, void *pgd)
return 0;
}
+void kvm_guest_destroy_stage2(struct pkvm_hyp_vm *vm)
+{
+ guest_lock_component(vm);
+ kvm_pgtable_stage2_destroy(&vm->pgt);
+ vm->kvm.arch.mmu.pgd_phys = 0ULL;
+ guest_unlock_component(vm);
+}
+
void reclaim_pgtable_pages(struct pkvm_hyp_vm *vm, struct kvm_hyp_memcache *mc)
{
struct hyp_page *page;
void *addr;
/* Dump all pgtable pages in the hyp_pool */
- guest_lock_component(vm);
- kvm_pgtable_stage2_destroy(&vm->pgt);
- vm->kvm.arch.mmu.pgd_phys = 0ULL;
- guest_unlock_component(vm);
+ kvm_guest_destroy_stage2(vm);
/* Drain the hyp_pool into the memcache */
addr = hyp_alloc_pages(&vm->pool, 0);
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..3b2c4fbc34d8 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -853,10 +853,12 @@ int __pkvm_init_vm(struct kvm *host_kvm, unsigned long vm_hva,
/* Must be called last since this publishes the VM. */
ret = insert_vm_table_entry(handle, hyp_vm);
if (ret)
- goto err_remove_mappings;
+ goto err_destroy_stage2;
return 0;
+err_destroy_stage2:
+ kvm_guest_destroy_stage2(hyp_vm);
err_remove_mappings:
unmap_donated_memory(hyp_vm, vm_size);
unmap_donated_memory(pgd, pgd_size);
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH 0/2] Fix __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-05-21 8:12 UTC (permalink / raw)
To: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
Cc: linux-arm-kernel, kvmarm, kernel-team, qperret, tabba,
Vincent Donnefort
Sashiko reported a potential refcount leak in the unlikely case where
insert_vm_table_entry fails.
While at it, I have added a fail-safe to __pkvm_hyp_donate_host to ensure this
function doesn't allow leaking refcounted pages.
Vincent Donnefort (2):
KVM: arm64: Fix __pkvm_init_vm error path
KVM: arm64: Add fail-safe for refcounted pages in
__pkvm_hyp_donate_host
arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 1 +
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 33 ++++++++++++++-----
arch/arm64/kvm/hyp/nvhe/pkvm.c | 4 ++-
3 files changed, 29 insertions(+), 9 deletions(-)
base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply
* Re: [PATCH v6 04/22] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Maxime Ripard @ 2026-05-21 8:10 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260520-dw-hdmi-qp-scramb-v6-4-24b74603b782@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 6904 bytes --]
On Wed, May 20, 2026 at 09:38:15PM +0300, Cristian Ciocaltea wrote:
> Add drm_scdc_start_scrambling(), drm_scdc_stop_scrambling() and
> drm_scdc_sync_status() helpers to manage the full lifecycle of HDMI 2.0
> SCDC scrambling on both source and sink sides.
>
> drm_scdc_start_scrambling() configures SCDC scrambling and high TMDS
> clock ratio and starts a periodic work item that monitors the sink's
> SCDC scrambling status, retrying setup when the sink loses state.
>
> drm_scdc_stop_scrambling() tears down scrambling on both sides and
> cancels the monitoring work.
>
> drm_scdc_sync_status() triggers a CRTC reset on reconnection to restore
> SCDC state lost during sink disconnects within an active display
> pipeline.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/gpu/drm/display/drm_scdc_helper.c | 235 +++++++++++++++++++++++++++++-
> include/drm/display/drm_scdc_helper.h | 6 +-
> 2 files changed, 236 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c b/drivers/gpu/drm/display/drm_scdc_helper.c
> index cb6632346aad..5bacb886d373 100644
> --- a/drivers/gpu/drm/display/drm_scdc_helper.c
> +++ b/drivers/gpu/drm/display/drm_scdc_helper.c
> @@ -21,16 +21,22 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> +#include <linux/delay.h>
> #include <linux/export.h>
> #include <linux/i2c.h>
> +#include <linux/minmax.h>
> #include <linux/slab.h>
> -#include <linux/delay.h>
>
> -#include <drm/display/drm_scdc_helper.h>
> +#include <drm/drm_atomic.h>
> +#include <drm/drm_atomic_helper.h>
> +#include <drm/drm_bridge_helper.h>
> #include <drm/drm_connector.h>
> +#include <drm/drm_crtc.h>
> #include <drm/drm_device.h>
> #include <drm/drm_print.h>
>
> +#include <drm/display/drm_scdc_helper.h>
> +
> /**
> * DOC: scdc helpers
> *
> @@ -50,10 +56,14 @@
> * has to track the connector status changes using interrupts and
> * restore the SCDC status. The typical solution for this is to trigger an
> * empty modeset in drm_connector_helper_funcs.detect_ctx(), like what vc4 does
> - * in vc4_hdmi_reset_link().
> + * in vc4_hdmi_reset_link(). Alternatively, use the HDMI connector framework
> + * which ensures drm_scdc_sync_status() is called in the context of
> + * drm_atomic_helper_connector_hdmi_hotplug_ctx().
> */
>
> -#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +#define SCDC_MAX_SOURCE_VERSION 0x1
> +#define SCDC_STATUS_POLL_DELAY_MS 3000
>
> #define drm_scdc_dbg(connector, fmt, ...) \
> drm_dbg_kms((connector)->dev, "[CONNECTOR:%d:%s] " fmt, \
> @@ -270,3 +280,220 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct drm_connector *connector,
> return true;
> }
> EXPORT_SYMBOL(drm_scdc_set_high_tmds_clock_ratio);
> +
> +static int drm_scdc_setup_scrambler(struct drm_connector *connector)
> +{
> + bool done;
> +
> + done = drm_scdc_set_high_tmds_clock_ratio(connector, true);
> + if (!done)
> + return -EIO;
> +
> + done = drm_scdc_set_scrambling(connector, true);
> + if (!done)
> + return -EIO;
> +
> + schedule_delayed_work(&connector->hdmi.scdc_work,
> + msecs_to_jiffies(SCDC_STATUS_POLL_DELAY_MS));
> + return 0;
> +}
There's a very tight deadline in the spec to enable the scrambler
relative to the video. Debouncing (I assume?) for three seconds break
it. Drivers might not be able to do better, but it's really not
something we should entertain at the framework level and we should call
the callback straight-away.
> +static void drm_scdc_monitor_scrambler(struct drm_connector *connector)
> +{
> + if (READ_ONCE(connector->hdmi.scrambler_enabled) &&
> + !drm_scdc_get_scrambling_status(connector))
> + drm_scdc_setup_scrambler(connector);
> +}
> +
> +static int drm_scdc_reset_crtc(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct drm_crtc *crtc;
> + u8 config;
> + int ret;
> +
> + if (!ctx || !connector->state)
> + return 0;
> +
> + crtc = connector->state->crtc;
> + if (!crtc || !crtc->state || !crtc->state->active)
> + return 0;
> +
> + ret = drm_scdc_readb(connector->ddc, SCDC_TMDS_CONFIG, &config);
> + if (ret) {
> + drm_scdc_dbg(connector, "Failed to read TMDS config: %d\n", ret);
> + return ret;
> + }
> +
> + if ((config & SCDC_SCRAMBLING_ENABLE) &&
> + (config & SCDC_TMDS_BIT_CLOCK_RATIO_BY_40))
> + return 0;
> +
> + /*
> + * Reset the CRTC to suspend TMDS transmission, conforming to HDMI 2.0
> + * spec which requires scrambled data not to be sent before the sink is
> + * configured, and TMDS clock to be suspended while changing the clock
> + * ratio. The disable/re-enable cycle triggered by the reset should
> + * call drm_scdc_start_scrambling() during re-enable, properly
> + * configuring the sink before data transmission resumes.
> + */
> +
> + drm_scdc_dbg(connector, "Resetting CRTC to restore SCDC status\n");
> +
> + ret = drm_atomic_helper_reset_crtc(crtc, ctx);
> + if (ret && ret != -EDEADLOCK)
> + drm_scdc_dbg(connector, "Failed to reset CRTC: %d\n", ret);
> +
> + return ret;
> +}
locking is a bit more involved than that, I'd suggest to take
vc4_hdmi_reset_link() and turn it into a helper.
> +/**
> + * drm_scdc_start_scrambling - activate scrambling and monitor SCDC status
> + * @connector: connector
> + *
> + * Enables scrambling and high TMDS clock ratio on both source and sink sides.
> + * Additionally, use a delayed work item to monitor the scrambling status on
> + * the sink side and retry the operation, as some displays refuse to set the
> + * scrambling bit right away.
> + *
> + * Returns:
> + * Zero if scrambling is set successfully, an error code otherwise.
> + */
> +int drm_scdc_start_scrambling(struct drm_connector *connector)
> +{
> + struct drm_display_info *info = &connector->display_info;
> + struct drm_connector_hdmi *hdmi = &connector->hdmi;
> + int ret;
> + u8 ver;
> +
> + if (!hdmi->funcs ||
> + !hdmi->funcs->scrambler_src_enable ||
> + !hdmi->funcs->scrambler_src_disable) {
> + drm_scdc_dbg(connector, "Function not implemented, bailing.\n");
> + return -EINVAL;
> + }
This case shouldn't be a thing. The driver must not probe if it's not set.
> + if (!info->is_hdmi ||
> + !info->hdmi.scdc.supported ||
> + !info->hdmi.scdc.scrambling.supported) {
> + drm_scdc_dbg(connector, "Sink doesn't support scrambling.\n");
> + return -EINVAL;
> + }
You should also compute whether we actually need to enable the scrambler
here, based on the mode, format and bpc.
I'd also like to see what a !bridge user of this would look like. The
vc4 driver has all the infrastructure you need already, so converting it
to it would be great.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH v6 08/10] drm/bridge: analogix_dp: Rename and simplify is_rockchip()
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Rename inline helper is_rockchip() to analogix_dp_is_rockchip()
to follow driver namespace convention consistently across code.
Replace chained equality comparisons with switch-case layout
to improve readability and simplify adding new SoC entries later.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Suggested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
.../gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +++++++++---------
include/drm/bridge/analogix_dp.h | 11 +++++++++--
3 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8cf6b73bceac..116de3bd83a3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -870,7 +870,7 @@ static int analogix_dp_bridge_atomic_check(struct drm_bridge *bridge,
struct drm_display_info *di = &conn_state->connector->display_info;
u32 mask = BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) | BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422);
- if (is_rockchip(dp->plat_data->dev_type)) {
+ if (analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
if ((di->color_formats & mask)) {
DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
di->color_formats &= ~mask;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 38fd8d5014d2..6207ded7ffd5 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -72,7 +72,7 @@ void analogix_dp_init_analog_param(struct analogix_dp_device *dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg = REF_CLK_24M;
if (dp->plat_data->dev_type == RK3288_DP)
reg ^= REF_CLK_MASK;
@@ -123,7 +123,7 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
analogix_dp_stop_video(dp);
analogix_dp_enable_video_mute(dp, 0);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N |
SW_FUNC_EN_N;
else
@@ -233,7 +233,7 @@ void analogix_dp_set_pll_power_down(struct analogix_dp_device *dp, bool enable)
u32 mask = DP_PLL_PD;
u32 pd_addr = ANALOGIX_DP_PLL_CTL;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
pd_addr = ANALOGIX_DP_PD;
mask = RK_PLL_PD;
}
@@ -254,12 +254,12 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
u32 mask;
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = RK_AUX_PD;
else
mask = AUX_PD;
@@ -317,7 +317,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
* to power off everything instead of DP_PHY_PD in
* Rockchip
*/
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
mask = DP_INC_BG;
else
mask = DP_PHY_PD;
@@ -329,7 +329,7 @@ void analogix_dp_set_analog_power_down(struct analogix_dp_device *dp,
reg &= ~mask;
writel(reg, dp->reg_base + phy_pd_addr);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
usleep_range(10, 15);
break;
case POWER_ALL:
@@ -465,7 +465,7 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp)
analogix_dp_reset_aux(dp);
/* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type))
reg = 0;
else
reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3);
@@ -837,7 +837,7 @@ void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp)
u32 reg;
reg = readl(dp->reg_base + ANALOGIX_DP_FUNC_EN_1);
- if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) {
+ if (dp->plat_data && analogix_dp_is_rockchip(dp->plat_data->dev_type)) {
reg &= ~(RK_VID_CAP_FUNC_EN_N | RK_VID_FIFO_FUNC_EN_N);
} else {
reg &= ~(MASTER_VID_FUNC_EN_N | SLAVE_VID_FUNC_EN_N);
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 854af692229b..7b670dd769e9 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -19,9 +19,16 @@ enum analogix_dp_devtype {
RK3588_EDP,
};
-static inline bool is_rockchip(enum analogix_dp_devtype type)
+static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
{
- return type == RK3288_DP || type == RK3399_EDP || type == RK3588_EDP;
+ switch (type) {
+ case RK3288_DP:
+ case RK3399_EDP:
+ case RK3588_EDP:
+ return true;
+ default:
+ return false;
+ }
}
struct analogix_dp_plat_data {
--
2.34.1
^ permalink raw reply related
* [PATCH v6 10/10] drm/rockchip: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
RK3576 integrates Analogix eDP 1.3 TX and Samsung combo PHY
hardware blocks that fully match the proven RK3588 design.
Add dedicated chip data table and device tree matching entry
to bring up basic eDP functionality for the RK3576 platform.
Support is limited to RGB output up to 4K@60Hz for now; audio,
PSR and other advanced eDP 1.3 features remain unvalidated.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
Changes in v2:
- Split out a separate patch to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d2af5eb29dbb..d4c5dd61e95b 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -522,6 +522,14 @@ static const struct rockchip_dp_chip_data rk3288_dp[] = {
{ /* sentinel */ }
};
+static const struct rockchip_dp_chip_data rk3576_edp[] = {
+ {
+ .chip_type = RK3576_EDP,
+ .reg = 0x27dc0000,
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_dp_chip_data rk3588_edp[] = {
{
.edp_mode = GRF_REG_FIELD(0x0000, 0, 0),
@@ -539,6 +547,7 @@ static const struct rockchip_dp_chip_data rk3588_edp[] = {
static const struct of_device_id rockchip_dp_dt_ids[] = {
{.compatible = "rockchip,rk3288-dp", .data = &rk3288_dp },
{.compatible = "rockchip,rk3399-edp", .data = &rk3399_edp },
+ {.compatible = "rockchip,rk3576-edp", .data = &rk3576_edp },
{.compatible = "rockchip,rk3588-edp", .data = &rk3588_edp },
{}
};
--
2.34.1
^ permalink raw reply related
* [PATCH v6 09/10] drm/bridge: analogix_dp: Add support for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Add RK3576_EDP device type entry and extend Rockchip check
to match existing hardware capabilities shared with RK3588.
Set identical maximum link rate and lane count parameters
for RK3576 eDP controller to reuse existing RK3588 config.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v3:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
include/drm/bridge/analogix_dp.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 116de3bd83a3..c8eb3511f92a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1249,6 +1249,7 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
video_info->max_link_rate = 0x0A;
video_info->max_lane_count = 0x04;
break;
+ case RK3576_EDP:
case RK3588_EDP:
video_info->max_link_rate = 0x14;
video_info->max_lane_count = 0x04;
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index 7b670dd769e9..0e0b87abee59 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -16,6 +16,7 @@ enum analogix_dp_devtype {
EXYNOS_DP,
RK3288_DP,
RK3399_EDP,
+ RK3576_EDP,
RK3588_EDP,
};
@@ -24,6 +25,7 @@ static inline bool analogix_dp_is_rockchip(enum analogix_dp_devtype type)
switch (type) {
case RK3288_DP:
case RK3399_EDP:
+ case RK3576_EDP:
case RK3588_EDP:
return true;
default:
--
2.34.1
^ permalink raw reply related
* [PATCH v6 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v6 00/10] Add eDP support for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
Patch 1-5 are to add missing clock "hclk" for RK3588 eDP nodes.
Patch 6-7 are to add the RK3576 eDP node.
Patch 8~10 are to support the RK3576 Analogix DP controller.
This series is followed by the [0] series.
[0] https://lore.kernel.org/all/20260409065301.446670-1-damon.ding@rock-chips.com/
Damon Ding (10):
dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock
for RK3588
dt-bindings: display: rockchip: analogix-dp: Add per-clock
descriptions
arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
drm/rockchip: analogix_dp: Enable hclk for RK3588
dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
arm64: dts: rockchip: Add eDP node for RK3576
drm/bridge: analogix_dp: Rename and simplify is_rockchip()
drm/bridge: analogix_dp: Add support for RK3576
drm/rockchip: analogix_dp: Add support for RK3576
.../rockchip/rockchip,analogix-dp.yaml | 44 ++++++++++++++++---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 +-
.../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 4 +-
.../drm/bridge/analogix/analogix_dp_core.c | 3 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 ++++----
.../gpu/drm/rockchip/analogix_dp-rockchip.c | 15 +++++++
include/drm/bridge/analogix_dp.h | 13 +++++-
8 files changed, 108 insertions(+), 21 deletions(-)
---
Changes in v2:
- Split out separate patches to add the "hclk" clock reference.
- Split out separate patches to enable the "hclk" clock.
- Add Reviewed-by tag.
Changes in v3:
- Add a patch to expand descriptions for clocks of the eDP node.
- Add Reviewed-by tag.
Changes in v4:
- Modify commit msg.
Changes in v5:
- Enforce the correct third clock name on a per-compatible basis.
- Modify the commit msg simultaneously.
- Add Acked-by tag.
Changes in v6:
- Expand more detail commit msg about using hclk instead of grf clock.
--
2.34.1
^ permalink raw reply
* [PATCH v6 02/10] dt-bindings: display: rockchip: analogix-dp: Add per-clock descriptions
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding,
Conor Dooley
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Supplement dedicated description for each clock in the clocks
property, clarifying the function of each clock input for the
Analogix DP controller binding.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
Changes in v5:
- Add Acked-by tag.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index 8001c1facf98..d679da70947d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -19,7 +19,10 @@ properties:
clocks:
minItems: 2
- maxItems: 3
+ items:
+ - description: Reference clock
+ - description: APB bus clock
+ - description: GRF or AHB bus clock
clock-names:
minItems: 2
--
2.34.1
^ permalink raw reply related
* [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
registers and enable the video datapath.
Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
phandle reference, which allowed the eDP to work without explicitly
managing the hclk_vo1 clock. However, this is not safe or explicit.
To make the clock dependency explicit, enforce per-SoC clock-names
requirements:
- RK3288: 2 clocks (dp, pclk)
- RK3399: 3 clocks (dp, pclk, grf)
- RK3588: 3 clocks (dp, pclk, hclk)
Do not reuse the 'grf' clock name for RK3588 because it represents
a different clock with distinct control logic:
- The 'grf' clock is only for GRF register access and is toggled
dynamically during register access.
- The 'hclk' clock controls both GRF access and video datapath
gating, and must remain enabled during probe.
Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
Changes in v5:
- Enforce the correct third clock name on a per-compatible basis.
- Modify the commit msg simultaneously.
Changes in v6:
- Expand more detail commit msg about using hclk instead of grf clock.
---
.../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d99b23b88cc5..8001c1facf98 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -23,10 +23,7 @@ properties:
clock-names:
minItems: 2
- items:
- - const: dp
- - const: pclk
- - const: grf
+ maxItems: 3
power-domains:
maxItems: 1
@@ -60,6 +57,33 @@ required:
allOf:
- $ref: /schemas/display/bridge/analogix,dp.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3288-dp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3399-edp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: grf
+
- if:
properties:
compatible:
@@ -68,6 +92,11 @@ allOf:
- rockchip,rk3588-edp
then:
properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: hclk
resets:
minItems: 2
reset-names:
--
2.34.1
^ permalink raw reply related
* [PATCH v6 03/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP0 node with
corresponding clock-name "hclk". This clock is necessary for the
eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: dc79d3d5e7c7 ("arm64: dts: rockchip: Add eDP0 node for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 4fb8888c281c..24a5ccbac08c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1712,8 +1712,8 @@ hdmi0_out: port@1 {
edp0: edp@fdec0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfdec0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy0>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v6 05/10] drm/rockchip: analogix_dp: Enable hclk for RK3588
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Acquire and enable the HCLK_VO1 bus clock explicitly for RK3588
eDP controller to guarantee register and datapath access.
The clock was previously enabled implicitly via rockchip,vo-grf
phandle reference, which relies on side effect and is fragile.
Fetch optional "hclk" clock in driver to align with updated device
tree binding and keep consistent with hardware clock dependency.
Fixes: 729f8eefdcad ("drm/rockchip: analogix_dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 06072efd7fca..d2af5eb29dbb 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -311,6 +311,7 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
struct device_node *np = dev->of_node;
+ struct clk *clk;
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf))
@@ -327,6 +328,11 @@ static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
return dev_err_probe(dev, PTR_ERR(dp->pclk),
"failed to get pclk property\n");
+ clk = devm_clk_get_optional_enabled(dev, "hclk");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get hclk property\n");
+
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst))
return dev_err_probe(dev, PTR_ERR(dp->rst),
--
2.34.1
^ permalink raw reply related
* [PATCH v6 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding,
Conor Dooley
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
RK3576 integrates an eDP TX controller compatible with the existing
RK3588 hardware design, reuse the same binding configuration directly.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Split out a separate patch to add the "hclk" clock reference.
Chanegs in v4:
- Modify the commit msg.
Changes in v5:
- Add Acked-by tag.
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d679da70947d..bb75d898a5c5 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -15,6 +15,7 @@ properties:
enum:
- rockchip,rk3288-dp
- rockchip,rk3399-edp
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
clocks:
@@ -92,6 +93,7 @@ allOf:
compatible:
contains:
enum:
+ - rockchip,rk3576-edp
- rockchip,rk3588-edp
then:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v6 07/10] arm64: dts: rockchip: Add eDP node for RK3576
From: Damon Ding @ 2026-05-21 8:08 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521080835.1362416-1-damon.ding@rock-chips.com>
Add full device tree definition for the integrated eDP controller
on RK3576, following the existing RK3588 hardware layout.
Configure required register range, clocks, interrupt, phy, power
domain, reset and grf properties to fully describe the controller.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v2:
- Add Reviewed-by tag.
Changes in v4:
- Modify the commit msg.
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 ++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index 28175d8200d5..733449cb88b1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1496,6 +1496,34 @@ hdmi_out: port@1 {
};
};
+ edp: edp@27dc0000 {
+ compatible = "rockchip,rk3576-edp";
+ reg = <0x0 0x27dc0000 0x0 0x1000>;
+ clocks = <&cru CLK_EDP0_24M>, <&cru PCLK_EDP0>, <&cru HCLK_VO0_ROOT>;
+ clock-names = "dp", "pclk", "hclk";
+ interrupts = <GIC_SPI 365 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&hdptxphy>;
+ phy-names = "dp";
+ power-domains = <&power RK3576_PD_VO0>;
+ resets = <&cru SRST_EDP0_24M>, <&cru SRST_P_EDP0>;
+ reset-names = "dp", "apb";
+ rockchip,grf = <&vo0_grf>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp_in: port@0 {
+ reg = <0>;
+ };
+
+ edp_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
dp: dp@27e40000 {
compatible = "rockchip,rk3576-dp";
reg = <0x0 0x27e40000 0x0 0x30000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-05-21 8:00 UTC (permalink / raw)
To: Cristian Marussi
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sudeep Holla,
Magnus Damm, Saravana Kannan, Michael Turquette, Stephen Boyd,
Philipp Zabel, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Florian Fainelli, Wolfram Sang, Marek Vasut, Kuninori Morimoto,
arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel
In-Reply-To: <agor5HJ0JFBoX3sZ@pluto>
Hi Cristian,
On Sun, 17 May 2026 at 22:58, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 15, 2026 at 05:39:45PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > > > Currently non-SCMI drivers cannot find out what the specific versions of
> > > > each SCMI provider implementation on the running system are.
> > >
> > > Thanks for your patches....this is not a proper full review of the series,
> > > BUT this patch catched my eye..
> > >
> > > Indeed, yes, it is deliberate that the SCMI version information is NOT
> > > exposed out of the SCMI world, since being the SCMI an attempt to
> > > standardize a common FW interface (as in [1] of course), you should not
> > > know what runs inside the black-box, it should be irrelevant...
> > >
> > > ...indeed the versioning is used inside the SCMI stack to deal properly
> > > with different protocol versions implemented by the server OR to apply
> > > proper quirks when needed, but all the rest should be standard....
> >
> > [...]
> >
> > > I watched a bit of the LPC discussions around this (from Marek I think)
> > > but sincerely most of those problems had one (not necessarily simple)
> > > solution: fix your firmwares AND/OR apply quirks in the meantime...
> >
> > So let's forward to the future, where the firmware is fixed, is fully
> > compliant with the SCMI spec, and all IDs are stable, so no quirks are
> > needed.
> >
> > Where do we specify the SCMI IDs to use? Unless when using the
> > remapping driver proposed in this patch series, they must end up in the
> > DTB. Existing upstream users put them either in the SoC-specific .dtsi,
> > or in board-specific .dts.
> >
> > The SCMI server is supposed to expose to an agent (e.g. Linux) a
> > sequential and contiguous list of IDs that represent only resources that
> > the agent is allowed to use.
> > - We cannot put the SCMI IDs in the SoC-specific .dtsi, as that
> > describes all hardware in the SoC, which is typically much more than
> > Linux can or even wants to use when running on a specific board.
> > - You would think we could put the SCMI IDs in the board-specific
> > .dts. However, that would limit actual use cases later, which do
> > not necessarily depend on the board solely.
> > - E.g. when moving control of the CAN-FD controller from Linux to
> > the Realtime OS, the CAN-FD node must be disabled in the DTB (by
> > overriding status to "reserved", or by just deleting the CAN-FD
> > node, both of which can be done by the boot loader). However,
> > with SCMI, the IDs corresponding to CAN-FD resources must be
> > removed from the ID space, causing a full renumbering. Who is
> > supposed to update the IDs in the DTB?
>
> As per my previous email, after such a breaking change I would expect a
> new DTB describing the new HW to be needed anyway.
The underlying hardware would still be the same...
> > - E.g. when partitioning a single Linux system in multiple VMs,
> > and distributing hardware across these VMs, all VMs need
> > different DTBs, each describing a subset of the hardware. With
> > SCMI, each VM needs different SCMI ID spaces, causing not a
> > simple partitioning of the devices in the DTB, but also a
> > renumbering of all IDs.
>
> Ok now I am lost..why do you need a distinct IDs space for each VM ?
Aren't the different VMs different SCMI agents? If not, how do you
prevent them from stepping on each other's resources?
> In a virtualized env, I would expect to leverage the SCMI stack to
> realize the exact opposite: same set of IDs advertised to each VM (and
> so same DTB potentially) by the server which in turn can decide to
> assign the same device (and handle the sharing) to some ID or assign
> different devices to the same or different IDs on each VM: i.e. you
> have a set of virtual_IDs that is what the server exposes to each VM
> SCMI agent, and then a bunch of real physical IDs, without any contraint
> on their numbering, that the server uses in the backstage to refer to
> the real resources and that it properly remaps to each per-VM set of
> exposed virtual_IDs during the build and/or boot board configuration
> phase....i.e. when the FW adapts and reconfigures to the specific
> board that is finally running on.
Again[1], how would that work? Clock, resets, and power domains are
not the final resources that are used by the OS. They are merely
resources for devices that are described in DTB with other resources
(MMIO register ranges, interrupt numbers, ...) which are not handled
by SCMI. If the server remaps e.g. a clock to a different clock,
it will no longer work with the corresponding device described in DT.
[1] https://lore.kernel.org/all/CAMuHMdVunEehM01pLa3t5a6o0NmMOCQRwh7n5J+OkDk2YR9kUA@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 3/4] devfreq: Factor out devfreq_set_governor()
From: zhenglifeng (A) @ 2026-05-21 8:06 UTC (permalink / raw)
To: Jie Zhan, cwchoi00, cw00.choi, myungjoo.ham, kyungmin.park,
linux-pm, linux-arm-kernel
Cc: linuxarm, tianyaxiong, zhangpengjie2, lihuisong, prime.zeng
In-Reply-To: <20260519113251.3745140-4-zhanjie9@hisilicon.com>
On 5/19/2026 7:32 PM, Jie Zhan wrote:
> governor_store() and devfreq_add_device() contain similar logic for setting
> a governor when devfreq->governor is NULL. Merge this into a common
> function, devfreq_set_governor(), to reduce code duplication and unify the
> entry of setting governors.
>
> This also prepares for further changes that get / put a module refcount of
> the active governor and prevent the governor module from being unloaded
> while it's in use.
>
> Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
> ---
> drivers/devfreq/devfreq.c | 117 ++++++++++++++++++--------------------
> 1 file changed, 56 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 53c40d795a13..9e3e6a7348f8 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -318,6 +318,59 @@ static struct devfreq_governor *try_then_request_governor(const char *name)
> return governor;
> }
>
> +static int devfreq_set_governor(struct devfreq *df,
> + const struct devfreq_governor *new_gov)
> +{
> + const struct devfreq_governor *old_gov;
> + struct device *dev;
> + int ret;
> +
> + lockdep_assert_held(&devfreq_list_lock);
> +
> + old_gov = df->governor;
> + dev = &df->dev;
> +
> + if (old_gov) {
> + if (old_gov == new_gov)
> + return 0;
> +
> + if (IS_SUPPORTED_FLAG(old_gov->flags, IMMUTABLE) ||
> + IS_SUPPORTED_FLAG(new_gov->flags, IMMUTABLE))
> + return -EINVAL;
> +
> + /* Stop the current governor */
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_STOP, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not stopped(%d)\n",
> + __func__, df->governor->name, ret);
> + return ret;
> + }
> + }
> +
> + /* Start the new governor */
> + df->governor = new_gov;
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_warn(dev, "%s: Governor %s not started(%d)\n",
> + __func__, df->governor->name, ret);
> +
> + /* Restore previous governor */
> + df->governor = old_gov;
> + if (!df->governor)
> + return ret;
> +
> + ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
> + if (ret) {
> + dev_err(dev, "%s: restore Governor %s failed (%d)\n",
> + __func__, df->governor->name, ret);
> + df->governor = NULL;
> + return ret;
> + }
> + }
> +
> + return sysfs_update_group(&df->dev.kobj, &gov_attr_group);
Here is a little problem which is not introduced by this patch. When
starting new governor fails but restoring old governor succeeds, this
function will return 0. This might lead users to believe that the governor
has been successfully modified.
^ permalink raw reply
* Re: [PATCH v5 8/8] ARM: defconfig: Add a zx29 defconfig file
From: Stefan Dösinger @ 2026-05-21 8:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <30b96e0d-f296-4c31-8701-a15c568ebffc@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]
Hi Arnd,
I saw your reply to my defconfig pull request, but apparently never received your original reply. I only found this mail here. It looks like I have to look for a better E-Mail provider as gmail is choking on the volume of the linux-arm-kernel mailing list.
To answer your questions I found at https://lore.kernel.org/all/61452117-0cdc-4ec2-83eb-dc03ccbd410b@app.fastmail.com/ :
> Either way, the patch description above should at least explain
> why you think you need your own defconfig, as we don't normally
> take those.
It was more cluelessness / being new to kernel development that gave me the impression that boards should have defconfigs. Since then I ran across scripts/dt_to_config. I haven't tested it yet on my DT, but if it does the right thing I don't think this board needs a defconfig.
>> +CONFIG_CMDLINE="console=ttyAMA0 earlyprintk root=/dev/ram rw"
> A definconfig should normall not rely on earlyprintk, just add
> that when you actually need to debug the super-early boot
> stages. With "earlycon" it should pick up the right console
> from the stdout path and work almost as early.
>> +CONFIG_BINFMT_FLAT=y
> Are you actually using flat binaries? I wasn't aware that this
> is still possible on MMU-enabled kernels.
>> +CONFIG_BLK_DEV_RAM=y
>> +CONFIG_BLK_DEV_RAM_COUNT=4
> The old ramdisk boot is going away in the future, please use
> initramfs instead. This should also save a good amount of RAM.
I'll fix those in my tree and keep the defconfig around just in case, but otherwise drop it from the submission. We can revisit it later when the board is more complete.
>> +CONFIG_DEVTMPFS=y # FIXME: This is specific to my initrd. Remove
>> before upstream
>stale comment?
I believe I removed this in later versions though :-)
Cheers,
Stefan
> Am 24.04.2026 um 11:54 schrieb Arnd Bergmann <arnd@arndb.de>:
>
> On Fri, Apr 24, 2026, at 09:13, Linus Walleij wrote:
>> On Tue, Apr 21, 2026 at 10:24 PM Stefan Dösinger
>> <stefandoesinger@gmail.com> wrote:
>>
>>> This enables existing drivers that already are (UART) or will be (USB,
>>> GPIO) necessary to operate this board even if they aren't declared in
>>> the DTS yet.
>>>
>>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>>
>> *I* personally (as SoC maintainer) think that having a few more defconfigs
>> is fine, even helpful.
>>
>> But I would defer this to the more senior SoC maintainers because I think
>> their stance is something like:
>>
>> - We have multi_v7_defconfig for compile testing
>>
>> - We know that binary gets way to big for your system: it's for build
>> testing and perhaps booting in QEMU or systems with many MB of
>> RAM, not for actually running it on products.
>>
>> - You are encouraged to keep your own defconfig out-of-tree.
>
> Right, we clearly need to do something better than what we are with
> the general defconfigs, as I'm sure many of the existing ones are
> never actually used for booting a machine, and are horribly out of
> date with the Kconfig options.
>
> I wouldn't object to adding another defconfig for a new (or revived)
> soc family, but I don't want to have more per-board ones.
> Overall, we have about 70 defconfigs and 55 soc families that have their
> own mach-* directory (plus a few without code), and the number of
> defconfigs alone makes it hard to keep them up to date.
>
>> However I even challenged this myself by adding a defconfig for memory
>> constrained Broadcoms a while back (NACKed/ignored ;) so if it was all
>> up to me I would merge this.
>
> I don't even remember that discussion ;-)
>
> One idea might be to have a tiny base defconfig, plus platform
> specific fragments that add drivers. The problem is agreeing
> what bits are essential enough to still get enabled in the
> tiny config.
>
> Arnd
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-05-21 7:53 UTC (permalink / raw)
To: Cristian Marussi
Cc: Sudeep Holla, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Saravana Kannan, Michael Turquette, Stephen Boyd,
Philipp Zabel, Ulf Hansson, Rafael J . Wysocki, Kevin Hilman,
Florian Fainelli, Wolfram Sang, Marek Vasut, Kuninori Morimoto,
arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel
In-Reply-To: <agooKghZJw3iElvp@pluto>
Hi Cristian,
On Sun, 17 May 2026 at 22:42, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, May 08, 2026 at 12:26:19PM +0200, Geert Uytterhoeven wrote:
> > On Mon, 27 Apr 2026 at 01:03, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > > > Also because this should be one of the selling point of the SCMI stack
> > > > > in a virtualized environment: you can ship the same kernel drivers with
> > > > > the same DT and you know that ID=<N> will always identify the specific
> > > > > resource that is needed by your driver without worrying about the fact
> > > > > that in reality in the backstage the effectively managed physical resource
> > > > > could be different across different platforms, because that does not matter
> > > >
> > > > This sounds strange to me, do I understand it correctly?
> > > > So the ID should (1) be tied to the use-case, and not to the underlying
> > > > hardware, and (2) be the same for different platforms?
> > > >
> > > > For (1): Then we must not put these IDs in DT at all, as DT is supposed
> > > > to describe the hardware (and firmware IDs in DT were IMHO already
> > > > a stretch before).
> > > > For (2): How can there be a contiguous list of IDs, as not all platforms
> > > > may have the same underlying hardware?
> > >
> > > I would NOT say that an SCMI FW must behave like this regarding IDs, but it
> > > is a possible SCMI deployed setup that can be useful in virtualized setups
> > >
> > > I mean, the DT describes the hardware of course BUT when you refer to
> > > some of this hardware DT bits from some other subsystem by referencing a
> > > phandle, even in the non-SCMI world, you are in fact selecting a specific
> > > resource that fit you use case, right ? Can we say this ?
> > > I mean you needed that specific clock or regulator that you described
> > > previously so as to be able to enable some other piece of HW...
> > >
> > > Now, the SCMI provides an abstraction on top of this, since you really
> > > discover domain IDs of a specific class (clocks/regulators etc) you are
> > > in fact describing an HW abstraction that you then refer with the usual
> > > phandle...also because there is NOT so much SCMI hardware to describe,
> > > given that the HW is handled transparently (opaquely really :P) by the
> > > driver on the FW side...
> > >
> > > ...you basically obtain such domain ID, usable as phandles through dynamic
> > > SCMI enumeration so that you can use it all over your DT to make use of such
> > > resources...
> > >
> > > ...on top of this, consider that the SCMI server CAN provide to its agents
> > > a per-agent-view of the world, IOW it can (and should) expose to a specific
> > > agent ONLY the resources needed by that agent, i.e. it can expose the set
> > > of resources 1-N to two distinct agents and that does NOT mean that the
> > > underlying physical resource mapped by ID=3 in both agents has to be
> > > effectively the same piece of hardware: it could be the case, and this
> > > would be useful to exposed and managed properly a shared resource, or
> > > it could also be that the same ID=3 could refer to completely distinct
> > > pieces of the same class of hardware...(same protocol same class of
> > > resource...)
> >
> > Exposing only the clocks/reset/power domains the agent can use,
> > in a contiguous list of IDS, means that the number space changes,
> > depending on which resources are exposed.
>
> Yes, potentially, it depedns on how the HW/FW stack was designed I
> suppose...
>
> > Suppose you have a system where you want to assign a specific hardware
> > block in the SoC to the realtime CPU core instead of the application
> > CPU core running Linux.
>
> Ok, so this is definitely a considerable change.
>
> > That means all resources used by that block must no longer be exposed
> > to the Linux agent, and the corresponding IDs must be removed from
> > the ID space exposed to Linux. As the ID space must be sequential
> > and contiguous, the IDs must be renumbered, impacting resources that
> > are exposed to Linux. As these IDs are used in the SoC .dtsi, they
> > must be changed there, too, However, these IDs have become part of
> > the stable DT ABI, and thus cannot be changed.
>
> Well, you have to ship a final DTB blob that is crafted to describe the
> actual HW at the end, right ?
>
> I mean, in your example, it seems to me that you have changed considerably
> the HW surface by moving a clock (and its related resources) away from the
> reach of Linux as a whole, so should not be expected to have an updated
> DTB shipped ?
It is not necessary to ship an updated DTB.
The bootloader stack can just change the "status" properties of devices
nodes that are be taken away from Linux from "okay" to "reserved":
Devicetree Specification, Release v0.4, Table 2.4: Values for statu
property states:
Value: "reserved"
Description:
Indicates that the device is operational, but should not be
used. Typically this is used for devices that are controlled
by another software component, such as platform firmware.
When all SCMI IDs change, too, much more work needs to be done.
The remap driver could also help here: it could scan for device nodes
that are marked "reserved", remove SCMI IDs used in these nodes from
its internal tables, and adjust all later (higher) IDs.
E.g. the existing drivers/clk/renesas/renesas-cpg-mssr.c already handles
(ignores) clocks used by reserved nodes.
> And I am NOT saying to do this by changing the base SoC dtsi, but via build
> time overrides and/or runtime overlays so as to derive from that same SoC
> base dtsi a properly reviewed final DTB that describes how the HW has actually
> changed, becasue beside the renumbering that you mention there will be
> also a bunch of HW pieces that were relying on that clock that now will
> have to be removed from the DTB if no more usable (or remapped to use a
> different, maybe non SCMI resource)
>
> I maybe too naive and not used to very complex DTBs, but why all of the
> above cannot be done along the lines of how is done as an example in
> JUNO [1], where some initial base dtsi was overriden by virtue of includes
> and overrides to properly describe the board at hand (r0/r1/r2), even going
> to the extreme, funny enough, to move from the old SCPI to SCMI.
>
> [1]: https://elixir.bootlin.com/linux/v7.0.8/source/arch/arm64/boot/dts/arm/juno-scmi.dts
As long as the IDs in arch/arm64/boot/dts/arm/juno-scmi.dtsi
match the actual SCMI implementation, that works...
> > This patch series fixes that issue, too, by describing the actual
> > hardware in DT, and doing the mapping to exposed SCMI features in the
> > kernel, based on which firmware version is running on the SCP.
>
> Which seems to me to go in the opposite direction to what SCMI expects:
> but I understand that we have to deal and cope with the existing already
> shipped FW, so my concern is not really around enabling this in particular,
> is much more the fact that we open the door and normalize this kind of
> design even with future, still to be developed, SCMI FWs.
>
> ...otherwise...have the spec changed/clarified to allow for such
> non-contiguos IDs...
>
> ...anyway let's hear Sudeep opinion on this general issue of contiguos
> remapped IDs and being able to peek into SCMI version from outside the
> SCMI world...
As long as the ID space becomes stable.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Andrea Righi @ 2026-05-21 7:56 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Changwoo Min, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Kumar Kartikeya Dwivedi,
Peter Zijlstra, Catalin Marinas, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, Andrew Morton,
David Hildenbrand, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <20260520235052.4180316-8-tj@kernel.org>
Hi Tejun,
On Wed, May 20, 2026 at 01:50:51PM -1000, Tejun Heo wrote:
> Build a per-scheduler sub-allocator on top of pages claimed from the BPF
> arena registered in the previous patch. Subsequent kernel-managed
> arena-resident structures (e.g. per-CPU set_cmask cmask) carve their storage
> from this pool.
>
> scx_arena_pool_init() creates a gen_pool. scx_arena_alloc() returns the
> kernel VA. On exhaustion, the pool grows by claiming more pages via
> bpf_arena_alloc_pages_sleepable(). Chunks are added at the kernel-side
> mapping address; callers translate to the BPF-arena form themselves if
> needed.
>
> Allocations sleep (GFP_KERNEL) - they may grow the pool through vzalloc and
> arena page allocation. All current consumers run from the enable path (after
> ops.init() and the kernel-side arena auto-discovery, before validate_ops()),
> where sleeping is fine.
>
> scx_arena_pool_destroy() walks each chunk, returns outstanding ranges to the
> gen_pool with gen_pool_free() and then calls gen_pool_destroy(). The
> underlying arena pages are released when the arena map itself is torn down,
> so the pool destroy doesn't free them explicitly.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
...
> +/*
> + * Allocate @size bytes from the arena pool. Returns kernel VA on success, NULL
> + * on failure. May grow the pool via scx_arena_grow() which sleeps. Caller must
> + * be in a GFP_KERNEL context.
> + */
> +void *scx_arena_alloc(struct scx_sched *sch, size_t size)
> +{
> + unsigned long kern_va;
> + u32 page_cnt;
> +
> + might_sleep();
> +
> + if (!sch->arena_pool)
> + return NULL;
> +
> + kern_va = gen_pool_alloc(sch->arena_pool, size);
> + if (!kern_va) {
> + page_cnt = max_t(u32, SCX_ARENA_GROW_PAGES,
> + (size + PAGE_SIZE - 1) >> PAGE_SHIFT);
> + if (scx_arena_grow(sch, page_cnt))
> + return NULL;
> + kern_va = gen_pool_alloc(sch->arena_pool, size);
> + if (!kern_va)
> + return NULL;
IIUC, since @page_cnt is sized to cover @size and the new chunk is added empty
to the pool, gen_pool_alloc() here should always succeed. Should we do:
if (WARN_ON_ONCE(!kern_va))
return NULL;
to catch potential logical bugs / future concurrency / exotic configurations?
Thanks,
-Andrea
^ permalink raw reply
* Re: [PATCH v6 02/22] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Maxime Ripard @ 2026-05-21 7:52 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260520-dw-hdmi-qp-scramb-v6-2-24b74603b782@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]
Hi,
Thanks for working on this!
On Wed, May 20, 2026 at 09:38:13PM +0300, Cristian Ciocaltea wrote:
> Add the connector-level infrastructure to support HDMI 2.0 scrambling:
>
> - .scrambler_src_{enable|disable}() callbacks in
> drm_connector_hdmi_funcs for source-side scrambling control
> - A delayed work item (scdc_work) with an associated callback (scdc_cb)
> for periodic monitoring of sink-side scrambling status
> - A scrambler_enabled flag to track whether scrambling is currently
> active
>
> These are intended to be used by SCDC scrambling helpers to coordinate
> scrambling setup and teardown between the source driver and the DRM
> core.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/gpu/drm/drm_connector.c | 14 +++++++++++
> include/drm/drm_connector.h | 52 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 66 insertions(+)
So we would need kunit tests for this.
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 3fa4d2082cd7..91e58362fbc0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
> }
> }
>
> +static void drm_connector_hdmi_scdc_work(struct work_struct *work)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_hdmi *hdmi;
> +
> + hdmi = container_of(to_delayed_work(work), struct drm_connector_hdmi,
> + scdc_work);
> + connector = container_of(hdmi, struct drm_connector, hdmi);
> +
> + if (hdmi->scdc_cb)
> + hdmi->scdc_cb(connector);
> +}
> +
> static int drm_connector_init_only(struct drm_device *dev,
> struct drm_connector *connector,
> const struct drm_connector_funcs *funcs,
> @@ -285,6 +298,7 @@ static int drm_connector_init_only(struct drm_device *dev,
> mutex_init(&connector->edid_override_mutex);
> mutex_init(&connector->hdmi.infoframes.lock);
> mutex_init(&connector->hdmi_audio.lock);
> + INIT_DELAYED_WORK(&connector->hdmi.scdc_work, drm_connector_hdmi_scdc_work);
> connector->edid_blob_ptr = NULL;
> connector->epoch_counter = 0;
> connector->tile_blob_ptr = NULL;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5ad62c207d00..49eaa30b1329 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -28,6 +28,7 @@
> #include <linux/ctype.h>
> #include <linux/hdmi.h>
> #include <linux/notifier.h>
> +#include <linux/workqueue.h>
> #include <drm/drm_mode_object.h>
> #include <drm/drm_util.h>
> #include <drm/drm_property.h>
> @@ -1358,6 +1359,36 @@ struct drm_connector_hdmi_funcs {
> */
> const struct drm_edid *(*read_edid)(struct drm_connector *connector);
>
> + /**
> + * @scrambler_src_enable:
> + *
> + * This callback is invoked through @drm_scdc_start_scrambling during
> + * a commit to setup SCDC scrambling and high TMDS clock ratio on
> + * source side.
> + *
> + * The @scrambler_src_enable callback is mandatory if HDMI 2.0 is
> + * to be supported.
> + *
> + * Returns:
> + * 0 on success, a negative error code otherwise
> + */
> + int (*scrambler_src_enable)(struct drm_connector *connector);
> +
> + /**
> + * @scrambler_src_disable:
> + *
> + * This callback is invoked through @drm_scdc_stop_scrambling during
> + * a commit to disable SCDC scrambling and high TMDS clock ratio on
> + * source side.
> + *
> + * The @scrambler_src_disable callback is mandatory if HDMI 2.0 is
> + * to be supported.
> + *
> + * Returns:
> + * 0 on success, a negative error code otherwise
> + */
> + int (*scrambler_src_disable)(struct drm_connector *connector);
> +
> /**
> * @avi:
> *
> @@ -1944,6 +1975,27 @@ struct drm_connector_hdmi {
> */
> unsigned long supported_formats;
>
> + /**
> + * @scrambler_enabled: Tracks whether HDMI 2.0 scrambler is currently enabled.
> + */
> + bool scrambler_enabled;
> +
> + /**
> + * @scdc_work: Work item currently used to monitor sink-side scrambling
> + * status and retry setup if the sink resets it.
> + */
> + struct delayed_work scdc_work;
> +
> + /** @scdc_cb: Callback to be invoked as part of @scdc_work.
> + *
> + * Currently used to monitor sink-side scrambling status and retry
> + * setup if the sink resets it.
> + *
> + * This is assigned by the framework when making use of
> + * drm_scdc_start_scrambling() helper.
> + */
> + void (*scdc_cb)(struct drm_connector *connector);
> +
I'm really not sure what the monitor thing is about. If we have setup
the scrambler at enable time, and we set it again on hotplugging, why
would we need to monitor anything?
Also, scrambling is only relevant for HDMI 2.0. We need a way to expose
that somehow and make sure that HDMI 2.0 drivers actually have
scrambling setup.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] mfd: max77620: override PSCI poweroff handler on Pixel C
From: Thierry Reding @ 2026-05-21 7:52 UTC (permalink / raw)
To: Diogo Ivo
Cc: Mark Rutland, Lorenzo Pieralisi, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, linux-arm-kernel, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20260514-smaug-poweroff-v1-3-30f9a4688966@tecnico.ulisboa.pt>
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
On Thu, May 14, 2026 at 04:47:21PM +0200, Diogo Ivo wrote:
> On Pixel C, shutdown must be handled by the MAX77620 PMIC rather
> than the PSCI SYSTEM_OFF call, whose firmware implementation is:
>
> __dead2 void tegra_system_off(void)
> {
> ERROR("Tegra System Off: operation not handled.\n");
> panic();
> }
Ugh... sounds very familiar. We have similar stub implementations on
Jetson TX1 and/or Nano, if I remember correctly. Luckily newer platforms
seem to have proper implementations for these.
Thanks for doing this. I might want to take inspiration from this for
these older Jetson platforms.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Maxime Ripard @ 2026-05-21 7:47 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou, dri-devel, linux-kernel, linux-usb, intel-gfx,
intel-xe, linux-amlogic, linux-arm-kernel, linux-arm-msm,
freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-1-086857017f16@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 3098 bytes --]
On Wed, May 13, 2026 at 09:23:21PM +0300, Dmitry Baryshkov wrote:
> The DisplayPort standard defines a special kind of events called IRQ.
> These events are used to notify DP Source about the events on the Sink
> side. It is extremely important for DP MST handling, where the MST
> events are reported through this IRQ.
>
> In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> events are ported through the bits in the AltMode VDOs.
>
> Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> events to the DisplayPort Sink drivers.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/drm_connector.c | 5 ++++-
> drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
> include/drm/drm_connector.h | 19 ++++++++++++++++++-
> 3 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..edee9daccd51 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> * @connector_fwnode: fwnode_handle to report the event on
> * @status: hot plug detect logical state
> + * @extra_status: additional information provided by the sink without changing
> + * the HPD state (or in addition to such a change).
> *
> * On some hardware a hotplug event notification may come from outside the display
> * driver / device. An example of this is some USB Type-C setups where the hardware
> @@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * a drm_connector reference through calling drm_connector_find_by_fwnode().
> */
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_connector *connector;
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index 35d9c3086990..7182a8e2e710 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
> } else {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> hpd ? connector_status_connected :
> - connector_status_disconnected);
> + connector_status_disconnected,
> + (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
Since the extra status itself, and what the options mean, are DP specific, do we really want to
extend drm_connector_oob_hotplug_event()? I think I'd prefer to have a DP specific variant, with its
own set of parameters.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v8 2/5] dt-bindings: phy: Add documentation for Airoha AN7581 USB PHY
From: Krzysztof Kozlowski @ 2026-05-21 7:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-3-ansuelsmth@gmail.com>
On Wed, May 20, 2026 at 05:09:07PM +0200, Christian Marangi wrote:
> Add documentation for Airoha AN7581 USB PHY that describe the USB PHY
> for the USB controller.
>
> Airoha AN7581 SoC support a maximum of 2 USB port. The USB 2.0 mode is
> always supported. The USB 3.0 mode is optional and depends on the Serdes
> mode currently configured on the system for the relevant USB port.
>
> To correctly calibrate, the USB 2.0 port require correct value in
> "airoha,usb2-monitor-clk-sel" property. Both the 2 USB 2.0 port permit
> selecting one of the 4 monitor clock for calibration (internal clock not
> exposed to the system) but each port have only one of the 4 actually
> connected in HW hence the correct value needs to be specified in DT
> based on board and the physical port. Normally it's monitor clock 1 for
> USB1 and monitor clock 2 for USB2.
>
> To correctly setup the Serdes mode attached to the USB 3.0 mode, a phys
> property is required with the phandle pointing to the correct Serdes port
> provided by the SCU node.
^^^ here - required but:
> + phys:
> + items:
> + - description: phandle to Serdes PHY
> +
> + '#phy-cells':
> + description: The cell contains the mode, PHY_TYPE_USB2 or PHY_TYPE_USB3,
> + as defined in dt-bindings/phy/phy.h.
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - airoha,usb2-monitor-clk-sel
'phys' is not required? I think you need it to configure the serdes
correctly, no?
> + - '#phy-cells'
> +
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox