[PATCH 0/2] drm/komeda: Fix GLB_CORE_ID parsing and initialize encoder clone masks

[PATCH 0/2] drm/komeda: Fix GLB_CORE_ID parsing and initialize encoder clone masks

[Raveendra Talabattula]

Komeda currently decodes GLB_CORE_ID with bit definitions that do not
match the hardware register layout, which leads to incorrect hardware
version reporting.

Patch 1 fixes the GLB_CORE_ID field definitions so the reported product
version matches the hardware specification.

Komeda also leaves encoder->possible_clones unset, so it remains zero
for all encoders. As a result, DRM clone-mask validation can reject
writeback configurations because no encoder is advertised as
clone-compatible.

Patch 2 initializes encoder->possible_clones after encoder
registration, making the clone-mask setup explicit for registered
encoders.

Cc: liviu.dudau@arm.com
Cc: maarten.lankhorst@linux.intel.com
Cc: mripard@kernel.org
Cc: tzimmermann@suse.de
Cc: airlied@gmail.com
Cc: simona@ffwll.ch
Cc: james.qian.wang@arm.com
Cc: vincenzo.frascino@arm.com
Cc: nayden.kanchev@arm.com
Cc: charvi.mehta@arm.com
Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>

Raveendra Talabattula (2):
  drm/komeda: Fix bits parsing of GLB_CORE_ID
  drm/komeda: Initialize encoder possible_clones

 .../drm/arm/display/include/malidp_product.h  | 12 +++++++----
 .../gpu/drm/arm/display/komeda/komeda_kms.c   | 20 +++++++++++++++++++
 2 files changed, 28 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH 1/2] drm/komeda: Fix bits parsing of GLB_CORE_ID

[Raveendra Talabattula]

GLB_CORE_ID contains the product and version information returned by the
hardware. The current macros parses VERSION_MINOR as a 4-bit field and
VERSION_STATUS as an 8-bit field, which does not match the register
layout. As a result, the driver reports an incorrect version number.

Fix the parsing macros to match the hardware specification:
- VERSION_MINOR is 8 bits at [11:4]
- VERSION_STATUS is 4 bits at [3:0]

Fixes: bd628c1bed79 ("drm/komeda: komeda_dev/pipeline/component definition and initialzation")
Signed-off-by: Asad Malik <asad.malik@arm.com>
Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
---
 drivers/gpu/drm/arm/display/include/malidp_product.h | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h b/drivers/gpu/drm/arm/display/include/malidp_product.h
index 6f954bcdf40e..bf63c4e05c3e 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_product.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
@@ -8,14 +8,18 @@
 #define _MALIDP_PRODUCT_H_
 
 /* Product identification */
+/* GLB_CORE_ID fields as per HW specification:
+ * MINOR is 8 bits ([11:4]) and STATUS is 4 bits ([3:0]).
+ * Update masks/shifts accordingly.
+ */
 #define MALIDP_CORE_ID(__product, __major, __minor, __status) \
 	((((__product) & 0xFFFF) << 16) | (((__major) & 0xF) << 12) | \
-	(((__minor) & 0xF) << 8) | ((__status) & 0xFF))
+	(((__minor) & 0xFF) << 4) | ((__status) & 0xF))
 
-#define MALIDP_CORE_ID_PRODUCT_ID(__core_id) ((__u32)(__core_id) >> 16)
+#define MALIDP_CORE_ID_PRODUCT_ID(__core_id) (((__u32)(__core_id) >> 16) & 0xFFFF)
 #define MALIDP_CORE_ID_MAJOR(__core_id)      (((__u32)(__core_id) >> 12) & 0xF)
-#define MALIDP_CORE_ID_MINOR(__core_id)      (((__u32)(__core_id) >> 8) & 0xF)
-#define MALIDP_CORE_ID_STATUS(__core_id)     (((__u32)(__core_id)) & 0xFF)
+#define MALIDP_CORE_ID_MINOR(__core_id)      (((__u32)(__core_id) >>  4) & 0xFF)
+#define MALIDP_CORE_ID_STATUS(__core_id)     (((__u32)(__core_id) >>  0) & 0xF)
 
 /* Mali-display product IDs */
 #define MALIDP_D71_PRODUCT_ID	0x0071
-- 
2.43.0

Re: [PATCH 1/2] drm/komeda: Fix bits parsing of GLB_CORE_ID

[Liviu Dudau]

On Tue, Jul 21, 2026 at 02:52:26PM +0100, Raveendra Talabattula wrote:
> GLB_CORE_ID contains the product and version information returned by the
> hardware. The current macros parses VERSION_MINOR as a 4-bit field and
> VERSION_STATUS as an 8-bit field, which does not match the register
> layout. As a result, the driver reports an incorrect version number.
> 
> Fix the parsing macros to match the hardware specification:
> - VERSION_MINOR is 8 bits at [11:4]
> - VERSION_STATUS is 4 bits at [3:0]
> 
> Fixes: bd628c1bed79 ("drm/komeda: komeda_dev/pipeline/component definition and initialzation")
> Signed-off-by: Asad Malik <asad.malik@arm.com>
> Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
> ---
>  drivers/gpu/drm/arm/display/include/malidp_product.h | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h b/drivers/gpu/drm/arm/display/include/malidp_product.h
> index 6f954bcdf40e..bf63c4e05c3e 100644
> --- a/drivers/gpu/drm/arm/display/include/malidp_product.h
> +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> @@ -8,14 +8,18 @@
>  #define _MALIDP_PRODUCT_H_
>  
>  /* Product identification */
> +/* GLB_CORE_ID fields as per HW specification:
> + * MINOR is 8 bits ([11:4]) and STATUS is 4 bits ([3:0]).
> + * Update masks/shifts accordingly.
> + */
>  #define MALIDP_CORE_ID(__product, __major, __minor, __status) \
>  	((((__product) & 0xFFFF) << 16) | (((__major) & 0xF) << 12) | \
> -	(((__minor) & 0xF) << 8) | ((__status) & 0xFF))
> +	(((__minor) & 0xFF) << 4) | ((__status) & 0xF))
>  
> -#define MALIDP_CORE_ID_PRODUCT_ID(__core_id) ((__u32)(__core_id) >> 16)
> +#define MALIDP_CORE_ID_PRODUCT_ID(__core_id) (((__u32)(__core_id) >> 16) & 0xFFFF)

This change is redundant.

>  #define MALIDP_CORE_ID_MAJOR(__core_id)      (((__u32)(__core_id) >> 12) & 0xF)
> -#define MALIDP_CORE_ID_MINOR(__core_id)      (((__u32)(__core_id) >> 8) & 0xF)
> -#define MALIDP_CORE_ID_STATUS(__core_id)     (((__u32)(__core_id)) & 0xFF)
> +#define MALIDP_CORE_ID_MINOR(__core_id)      (((__u32)(__core_id) >>  4) & 0xFF)
> +#define MALIDP_CORE_ID_STATUS(__core_id)     (((__u32)(__core_id) >>  0) & 0xF)

Shift by zero is unnecessary. Simple bitwise AND is enough.


Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

>  
>  /* Mali-display product IDs */
>  #define MALIDP_D71_PRODUCT_ID	0x0071
> -- 
> 2.43.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH 2/2] drm/komeda: Initialize encoder possible_clones

[Raveendra Talabattula]

Komeda leaves encoder->possible_clones unset, so it stays at 0 for every
encoder. When userspace asks for writeback, the DRM atomic checks
reject the configuration because no encoder is marked as clone-compatible,
leading to errors such as:

	crtc96 failed valid clone check for mask 0x5

Komeda does not impose per-encoder clone restrictions, so initialize
possible_clones for all registered encoders to the full encoder mask
after encoder creation. This fixes writeback validation.

Signed-off-by: Asad Malik <asad.malik@arm.com>
Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
---
 .../gpu/drm/arm/display/komeda/komeda_kms.c   | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 6ed504099188..0dcc8c05e86b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -276,7 +276,10 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
 {
 	struct komeda_kms_dev *kms;
 	struct drm_device *drm;
+	struct drm_encoder *encoder;
 	int err;
+	/* Bitmap of all encoders, assigned to each encoder's possible_clones. */
+	u32 clone_mask = 0;
 
 	kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
 				 struct komeda_kms_dev, base);
@@ -311,6 +314,23 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
 
 	drm_mode_config_reset(drm);
 
+	/*
+	 * Build the full possible_clones mask once. drm_encoder_index()
+	 * returns the bit position assigned to each encoder and BIT() converts
+	 * that index into the corresponding mask value.
+	 *
+	 * Komeda does not have per-encoder clone restrictions, so every encoder
+	 * gets the same mask and is advertised as clone-compatible with all
+	 * other registered encoders.
+	 */
+	drm_for_each_encoder(encoder, drm) {
+		clone_mask |= BIT(drm_encoder_index(encoder));
+	}
+
+	drm_for_each_encoder(encoder, drm) {
+		encoder->possible_clones = clone_mask;
+	}
+
 	err = devm_request_irq(drm->dev, mdev->irq,
 			       komeda_kms_irq_handler, IRQF_SHARED,
 			       drm->driver->name, drm);
-- 
2.43.0

Re: [PATCH 2/2] drm/komeda: Initialize encoder possible_clones

[Liviu Dudau]

On Tue, Jul 21, 2026 at 02:52:27PM +0100, Raveendra Talabattula wrote:
> Komeda leaves encoder->possible_clones unset, so it stays at 0 for every
> encoder. When userspace asks for writeback, the DRM atomic checks

Can you tell me more about this? What are you trying to do with the writeback?

Please note that there is a patch series that changes the way encoders get
created for the writeback connectors, so that can potentially affect your
use case.

> reject the configuration because no encoder is marked as clone-compatible,
> leading to errors such as:
> 
> 	crtc96 failed valid clone check for mask 0x5

The error you're seeing here is due to the encoder having a non-zero "possible_clones"
which shows there is an error in your setup earlier and nothing to do with komeda.

> 
> Komeda does not impose per-encoder clone restrictions, [...]

Komeda doesn't care about the encoders at all as it is meant to be agnostic
to whatever encoder is used.

> [...] so initialize
> possible_clones for all registered encoders to the full encoder mask
> after encoder creation. This fixes writeback validation.
> 
> Signed-off-by: Asad Malik <asad.malik@arm.com>
> Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
> ---
>  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 20 +++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index 6ed504099188..0dcc8c05e86b 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -276,7 +276,10 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
>  {
>  	struct komeda_kms_dev *kms;
>  	struct drm_device *drm;
> +	struct drm_encoder *encoder;
>  	int err;
> +	/* Bitmap of all encoders, assigned to each encoder's possible_clones. */
> +	u32 clone_mask = 0;
>  
>  	kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
>  				 struct komeda_kms_dev, base);
> @@ -311,6 +314,23 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
>  
>  	drm_mode_config_reset(drm);
>  
> +	/*
> +	 * Build the full possible_clones mask once. drm_encoder_index()
> +	 * returns the bit position assigned to each encoder and BIT() converts
> +	 * that index into the corresponding mask value.
> +	 *
> +	 * Komeda does not have per-encoder clone restrictions, so every encoder
> +	 * gets the same mask and is advertised as clone-compatible with all
> +	 * other registered encoders.
> +	 */
> +	drm_for_each_encoder(encoder, drm) {
> +		clone_mask |= BIT(drm_encoder_index(encoder));
> +	}
> +
> +	drm_for_each_encoder(encoder, drm) {
> +		encoder->possible_clones = clone_mask;
> +	}

You're modifying all the encoders in the system here which is not the right thing.

Best regards,
Liviu

> +
>  	err = devm_request_irq(drm->dev, mdev->irq,
>  			       komeda_kms_irq_handler, IRQF_SHARED,
>  			       drm->driver->name, drm);
> -- 
> 2.43.0
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH 2/2] drm/komeda: Initialize encoder possible_clones

[Raveendra Talabattula]

Hi Liviu,

Thanks for your review.

On 7/28/26 15:20, Liviu Dudau wrote:
> On Tue, Jul 21, 2026 at 02:52:27PM +0100, Raveendra Talabattula wrote:
>> Komeda leaves encoder->possible_clones unset, so it stays at 0 for every
>> encoder. When userspace asks for writeback, the DRM atomic checks
> 
> Can you tell me more about this? What are you trying to do with the writeback?

We are trying to use the Komeda writeback connector to capture the composed
CRTC output while the same CRTC is also driving the display connector.

In this configuration, both the display encoder and the writeback encoder 
are included in the CRTC encoder mask. The atomic validation then reports:

crtc96 failed valid clone check for mask 0x5

The intention is only to support the display and writeback outputs concurrently.

> 
> Please note that there is a patch series that changes the way encoders get
> created for the writeback connectors, so that can potentially affect your
> use case.
> 

Could you please point me to the patch series you are referring to?
I would like to check whether it changes how the Komeda writeback encoder
should be created or how its possible_clones mask should be initialized

>> reject the configuration because no encoder is marked as clone-compatible,
>> leading to errors such as:
>>
>> 	crtc96 failed valid clone check for mask 0x5
> 
> The error you're seeing here is due to the encoder having a non-zero "possible_clones"
> which shows there is an error in your setup earlier and nothing to do with komeda.
> 

Understood. I identified that the failure is exposed by the following upstream commit:

41b4b11da021 ("drm: Add valid clones check")

This commit added validation of the clone masks for all encoders attached to a CRTC.
Therefore, the commit is exposing an issue in the earlier encoder setup rather than
introducing a Komeda-specific failure.

I will investigate where the display and writeback encoder clone relationship
should be configured correctly. 

>>
>> Komeda does not impose per-encoder clone restrictions, [...]
> 
> Komeda doesn't care about the encoders at all as it is meant to be agnostic
> to whatever encoder is used.
> 
>> [...] so initialize
>> possible_clones for all registered encoders to the full encoder mask
>> after encoder creation. This fixes writeback validation.
>>
>> Signed-off-by: Asad Malik <asad.malik@arm.com>
>> Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
>> ---
>>  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 20 +++++++++++++++++++
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
>> index 6ed504099188..0dcc8c05e86b 100644
>> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
>> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
>> @@ -276,7 +276,10 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
>>  {
>>  	struct komeda_kms_dev *kms;
>>  	struct drm_device *drm;
>> +	struct drm_encoder *encoder;
>>  	int err;
>> +	/* Bitmap of all encoders, assigned to each encoder's possible_clones. */
>> +	u32 clone_mask = 0;
>>  
>>  	kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
>>  				 struct komeda_kms_dev, base);
>> @@ -311,6 +314,23 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
>>  
>>  	drm_mode_config_reset(drm);
>>  
>> +	/*
>> +	 * Build the full possible_clones mask once. drm_encoder_index()
>> +	 * returns the bit position assigned to each encoder and BIT() converts
>> +	 * that index into the corresponding mask value.
>> +	 *
>> +	 * Komeda does not have per-encoder clone restrictions, so every encoder
>> +	 * gets the same mask and is advertised as clone-compatible with all
>> +	 * other registered encoders.
>> +	 */
>> +	drm_for_each_encoder(encoder, drm) {
>> +		clone_mask |= BIT(drm_encoder_index(encoder));
>> +	}
>> +
>> +	drm_for_each_encoder(encoder, drm) {
>> +		encoder->possible_clones = clone_mask;
>> +	}
> 
> You're modifying all the encoders in the system here which is not the right thing.
> 

I understand the concern. My intention was to follow the approach used by:

2e012e76ad59 ("drm: mali-dp: Set encoder possible_clones")

The code only updates encoders registered with this DRM device. 
Since Komeda does not impose any per-encoder clone restrictions, 
the full encoder mask represents the intended capability and
allows the display and writeback encoders to be used concurrently.

Please let me know if there is a specific encoder in this setup 
that should not be marked as clone-compatible.

> Best regards,
> Liviu
> 
>> +
>>  	err = devm_request_irq(drm->dev, mdev->irq,
>>  			       komeda_kms_irq_handler, IRQF_SHARED,
>>  			       drm->driver->name, drm);
>> -- 
>> 2.43.0
>>
> 

Thanks,
Raveendra

Re: [PATCH 2/2] drm/komeda: Initialize encoder possible_clones

[Liviu Dudau]

On Thu, Jul 30, 2026 at 02:43:53PM +0100, Raveendra Talabattula wrote:
> Hi Liviu,
> 
> Thanks for your review.
> 
> On 7/28/26 15:20, Liviu Dudau wrote:
> > On Tue, Jul 21, 2026 at 02:52:27PM +0100, Raveendra Talabattula wrote:
> >> Komeda leaves encoder->possible_clones unset, so it stays at 0 for every
> >> encoder. When userspace asks for writeback, the DRM atomic checks
> > 
> > Can you tell me more about this? What are you trying to do with the writeback?
> 
> We are trying to use the Komeda writeback connector to capture the composed
> CRTC output while the same CRTC is also driving the display connector.
> 
> In this configuration, both the display encoder and the writeback encoder 
> are included in the CRTC encoder mask. The atomic validation then reports:
> 
> crtc96 failed valid clone check for mask 0x5
> 
> The intention is only to support the display and writeback outputs concurrently.
> 
> > 
> > Please note that there is a patch series that changes the way encoders get
> > created for the writeback connectors, so that can potentially affect your
> > use case.
> > 
> 
> Could you please point me to the patch series you are referring to?
> I would like to check whether it changes how the Komeda writeback encoder
> should be created or how its possible_clones mask should be initialized

I'm talking about this:
https://lore.kernel.org/all/20260714042805.77934-1-suraj.kandpal@intel.com/

> 
> >> reject the configuration because no encoder is marked as clone-compatible,
> >> leading to errors such as:
> >>
> >> 	crtc96 failed valid clone check for mask 0x5
> > 
> > The error you're seeing here is due to the encoder having a non-zero "possible_clones"
> > which shows there is an error in your setup earlier and nothing to do with komeda.
> > 
> 
> Understood. I identified that the failure is exposed by the following upstream commit:
> 
> 41b4b11da021 ("drm: Add valid clones check")
> 
> This commit added validation of the clone masks for all encoders attached to a CRTC.
> Therefore, the commit is exposing an issue in the earlier encoder setup rather than
> introducing a Komeda-specific failure.

That commit is not the issue, the issue is that encoder's possible_clones doesn't match
CRTC's state->encoder_mask.

> 
> I will investigate where the display and writeback encoder clone relationship
> should be configured correctly.

The possible_clones should be setup where the encoder is created, so that would be in
komeda_wb_connector_add(), using the code that you've tried to add it into komeda_kms_attach()
but this time only for the writeback encoder.

Best regards,
Liviu

> 
> >>
> >> Komeda does not impose per-encoder clone restrictions, [...]
> > 
> > Komeda doesn't care about the encoders at all as it is meant to be agnostic
> > to whatever encoder is used.
> > 
> >> [...] so initialize
> >> possible_clones for all registered encoders to the full encoder mask
> >> after encoder creation. This fixes writeback validation.
> >>
> >> Signed-off-by: Asad Malik <asad.malik@arm.com>
> >> Signed-off-by: Raveendra Talabattula <raveendra.talabattula@arm.com>
> >> ---
> >>  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 20 +++++++++++++++++++
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> >> index 6ed504099188..0dcc8c05e86b 100644
> >> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> >> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> >> @@ -276,7 +276,10 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
> >>  {
> >>  	struct komeda_kms_dev *kms;
> >>  	struct drm_device *drm;
> >> +	struct drm_encoder *encoder;
> >>  	int err;
> >> +	/* Bitmap of all encoders, assigned to each encoder's possible_clones. */
> >> +	u32 clone_mask = 0;
> >>  
> >>  	kms = devm_drm_dev_alloc(mdev->dev, &komeda_kms_driver,
> >>  				 struct komeda_kms_dev, base);
> >> @@ -311,6 +314,23 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev)
> >>  
> >>  	drm_mode_config_reset(drm);
> >>  
> >> +	/*
> >> +	 * Build the full possible_clones mask once. drm_encoder_index()
> >> +	 * returns the bit position assigned to each encoder and BIT() converts
> >> +	 * that index into the corresponding mask value.
> >> +	 *
> >> +	 * Komeda does not have per-encoder clone restrictions, so every encoder
> >> +	 * gets the same mask and is advertised as clone-compatible with all
> >> +	 * other registered encoders.
> >> +	 */
> >> +	drm_for_each_encoder(encoder, drm) {
> >> +		clone_mask |= BIT(drm_encoder_index(encoder));

BTW, you can use drm_encoder_mask(encoder) here.

> >> +	}
> >> +
> >> +	drm_for_each_encoder(encoder, drm) {
> >> +		encoder->possible_clones = clone_mask;
> >> +	}
> > 
> > You're modifying all the encoders in the system here which is not the right thing.
> > 
> 
> I understand the concern. My intention was to follow the approach used by:
> 
> 2e012e76ad59 ("drm: mali-dp: Set encoder possible_clones")
> 
> The code only updates encoders registered with this DRM device. 
> Since Komeda does not impose any per-encoder clone restrictions, 
> the full encoder mask represents the intended capability and
> allows the display and writeback encoders to be used concurrently.
> 
> Please let me know if there is a specific encoder in this setup 
> that should not be marked as clone-compatible.
> 
> > Best regards,
> > Liviu
> > 
> >> +
> >>  	err = devm_request_irq(drm->dev, mdev->irq,
> >>  			       komeda_kms_irq_handler, IRQF_SHARED,
> >>  			       drm->driver->name, drm);
> >> -- 
> >> 2.43.0
> >>
> > 
> 
> Thanks,
> Raveendra

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯