[RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[Icenowy Zheng]

This patchset tries to address the lack of uncached mapping support on
several SiFive-core-based SoCs, currently targeting JH7110 but EIC7700
would have the same problem (although it uses DC8000 display controller
instead of DC8200 and real display support is pending).

Because other users (either SoCs with Xuantie cores, which have
Xtheadmae extensions or non-RISC-V SoCs) of the driver have proper
writecombine support, a helper is added to check whether coherent
(cache-bypassing) mapping is available. This helper currently returns
true for all architectures except RISC-V, and checks whether
pgprot_writecombine() is a no-op on RISC-V.

The patch really enabling manual cache maintenance for the verisilicon
driver is picked from Dominique, and reworked to check both
dma-noncoherent property and the platform's mapping capaibility.

Tested on VisionFive 2 with the display enablement patchset at [1] (and
its dependency).

Also tested on Lichee Pi 4A (TH1520, which has Xtheadmae), operation is
not affected, map_noncoherent isn't set and Xorg says kernel dirty
updates aren't required.

[1] https://patch.msgid.link/20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com

Dominique Belhachemi (1):
  drm: verisilicon: support non-coherent DMA framebuffers

Icenowy Zheng (1):
  drm: add a helper function to check availbility of coherent mapping

 drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
 drivers/gpu/drm/verisilicon/vs_drm.c          | 32 ++++++++++++++++++-
 drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
 .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
 include/drm/drm_cache.h                       | 21 ++++++++++++
 5 files changed, 77 insertions(+), 1 deletion(-)

-- 
2.55.0

[RFC PATCH 1/2] drm: add a helper function to check availbility of coherent mapping

[Icenowy Zheng]

On some early SiFive RISC-V cores, there're no architectural way to map
the framebuffer coherently (bypassing the cache).

Add a helper function to check this situation for drivers to enable
dirty-tracking-based cache maintenance, which is more than returning
true currently on all architectures other than RISC-V.

Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 include/drm/drm_cache.h | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 08e0e3ffad131..001a6d89afead 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -34,6 +34,9 @@
 #define _DRM_CACHE_H_
 
 #include <linux/scatterlist.h>
+#if defined(CONFIG_RISCV)
+#include <linux/pgtable.h>
+#endif
 
 struct iosys_map;
 
@@ -80,6 +83,24 @@ static inline bool drm_arch_can_wc_memory(void)
 #endif
 }
 
+static inline bool drm_arch_can_map_coherent(void)
+{
+#if defined(CONFIG_RISCV)
+	/*
+	 * Early ratified versions of RISC-V privileged architecture manual
+	 * lacks any standardized way to override the cacheability of the
+	 * main memory region, from which framebuffers are allocated.
+	 *
+	 * In this case pgprot_writecombine() would just be a noop and manual
+	 * cache maintenance is required.
+	 */
+	return pgprot_val(pgprot_writecombine(PAGE_KERNEL)) !=
+	       pgprot_val(PAGE_KERNEL);
+#else
+	return true;
+#endif
+}
+
 void drm_memcpy_init_early(void);
 
 void drm_memcpy_from_wc(struct iosys_map *dst,
-- 
2.55.0

[RFC PATCH 2/2] drm: verisilicon: support non-coherent DMA framebuffers

[Icenowy Zheng]

From: Dominique Belhachemi <domibel@debian.org>

Wire up the standard non-coherent path matching the ingenic DRM
driver.

Tested on StarFive JH7110 (VisionFive 2 v1.3B).

Signed-off-by: Dominique Belhachemi <domibel@debian.org>
[Icenowy: add can_map_coherent check, rename vs_drm field to
 map_noncoherent, adapt for cursor planes]
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
 drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
 drivers/gpu/drm/verisilicon/vs_drm.c          | 32 ++++++++++++++++++-
 drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
 .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
 4 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/verisilicon/vs_cursor_plane.c b/drivers/gpu/drm/verisilicon/vs_cursor_plane.c
index 725921ac25d48..7216eaa6ef355 100644
--- a/drivers/gpu/drm/verisilicon/vs_cursor_plane.c
+++ b/drivers/gpu/drm/verisilicon/vs_cursor_plane.c
@@ -13,6 +13,7 @@
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_blend.h>
 #include <drm/drm_crtc.h>
+#include <drm/drm_fb_dma_helper.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_atomic_helper.h>
@@ -23,6 +24,7 @@
 #include "vs_crtc.h"
 #include "vs_plane.h"
 #include "vs_dc.h"
+#include "vs_drm.h"
 #include "vs_hwdb.h"
 #include "vs_cursor_plane_regs.h"
 
@@ -140,6 +142,8 @@ static void vs_cursor_plane_atomic_disable(struct drm_plane *plane,
 static void vs_cursor_plane_atomic_update(struct drm_plane *plane,
 					   struct drm_atomic_commit *atomic_state)
 {
+	struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(atomic_state,
+									   plane);
 	struct drm_plane_state *state = drm_atomic_get_new_plane_state(atomic_state,
 								       plane);
 	struct drm_framebuffer *fb = state->fb;
@@ -154,6 +158,8 @@ static void vs_cursor_plane_atomic_update(struct drm_plane *plane,
 		return;
 	}
 
+	drm_fb_dma_sync_non_coherent(plane->dev, old_state, state);
+
 	vcrtc = drm_crtc_to_vs_crtc(crtc);
 	output = vcrtc->id;
 	dc = vcrtc->dc;
@@ -275,5 +281,8 @@ struct drm_plane *vs_cursor_plane_init(struct drm_device *drm_dev,
 	drm_plane_helper_add(plane, &vs_cursor_plane_helper_funcs);
 	drm_plane_create_blend_mode_property(plane, BIT(DRM_MODE_BLEND_COVERAGE));
 
+	if (to_vs_drm_dev(drm_dev)->map_noncoherent)
+		drm_plane_enable_fb_damage_clips(plane);
+
 	return plane;
 }
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
index fd259d53f49f1..6cde0ba7ef6a4 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.c
+++ b/drivers/gpu/drm/verisilicon/vs_drm.c
@@ -5,6 +5,7 @@
 
 #include <linux/aperture.h>
 #include <linux/dma-mapping.h>
+#include <linux/of_address.h>
 #include <linux/platform_device.h>
 #include <linux/module.h>
 #include <linux/regmap.h>
@@ -12,6 +13,7 @@
 
 #include <drm/clients/drm_client_setup.h>
 #include <drm/drm_atomic_helper.h>
+#include <drm/drm_cache.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_dumb_buffers.h>
 #include <drm/drm_fbdev_dma.h>
@@ -49,6 +51,31 @@ static int vs_gem_dumb_create(struct drm_file *file_priv,
 
 DEFINE_DRM_GEM_FOPS(vs_drm_driver_fops);
 
+static struct drm_gem_object *vs_gem_create_object(struct drm_device *drm,
+						   size_t size)
+{
+	struct drm_gem_dma_object *obj;
+
+	obj = kzalloc_obj(*obj);
+	if (!obj)
+		return ERR_PTR(-ENOMEM);
+
+	obj->map_noncoherent = to_vs_drm_dev(drm)->map_noncoherent;
+
+	return &obj->base;
+}
+
+static struct drm_framebuffer *
+vs_gem_fb_create(struct drm_device *drm, struct drm_file *file,
+		 const struct drm_format_info *info,
+		 const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+	if (to_vs_drm_dev(drm)->map_noncoherent)
+		return drm_gem_fb_create_with_dirty(drm, file, info, mode_cmd);
+
+	return drm_gem_fb_create(drm, file, info, mode_cmd);
+}
+
 static const struct drm_driver vs_drm_driver = {
 	.driver_features	= DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
 	.fops			= &vs_drm_driver_fops,
@@ -58,12 +85,13 @@ static const struct drm_driver vs_drm_driver = {
 	.minor	= DRIVER_MINOR,
 
 	/* GEM Operations */
+	.gem_create_object	= vs_gem_create_object,
 	DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(vs_gem_dumb_create),
 	DRM_FBDEV_DMA_DRIVER_OPS,
 };
 
 static const struct drm_mode_config_funcs vs_mode_config_funcs = {
-	.fb_create		= drm_gem_fb_create,
+	.fb_create		= vs_gem_fb_create,
 	.atomic_check		= drm_atomic_helper_check,
 	.atomic_commit		= drm_atomic_helper_commit,
 };
@@ -98,6 +126,8 @@ int vs_drm_initialize(struct vs_dc *dc, struct platform_device *pdev)
 
 	drm = &vdrm->base;
 	vdrm->dc = dc;
+	vdrm->map_noncoherent = !of_dma_is_coherent(dev->of_node) &&
+				!drm_arch_can_map_coherent();
 	dc->drm_dev = vdrm;
 
 	ret = drmm_mode_config_init(drm);
diff --git a/drivers/gpu/drm/verisilicon/vs_drm.h b/drivers/gpu/drm/verisilicon/vs_drm.h
index 606338206a427..ee6a3317cc556 100644
--- a/drivers/gpu/drm/verisilicon/vs_drm.h
+++ b/drivers/gpu/drm/verisilicon/vs_drm.h
@@ -18,8 +18,15 @@ struct vs_drm_dev {
 
 	struct vs_dc *dc;
 	struct vs_crtc *crtcs[VSDC_MAX_OUTPUTS];
+
+	bool map_noncoherent;
 };
 
+static inline struct vs_drm_dev *to_vs_drm_dev(struct drm_device *drm)
+{
+	return container_of(drm, struct vs_drm_dev, base);
+}
+
 int vs_drm_initialize(struct vs_dc *dc, struct platform_device *pdev);
 void vs_drm_finalize(struct vs_dc *dc);
 void vs_drm_shutdown_handler(struct vs_dc *dc);
diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
index 594d56bf32410..633e46638dc2b 100644
--- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
+++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
@@ -8,6 +8,7 @@
 #include <drm/drm_atomic.h>
 #include <drm/drm_atomic_helper.h>
 #include <drm/drm_crtc.h>
+#include <drm/drm_fb_dma_helper.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_gem_atomic_helper.h>
@@ -18,6 +19,7 @@
 #include "vs_crtc.h"
 #include "vs_plane.h"
 #include "vs_dc.h"
+#include "vs_drm.h"
 #include "vs_primary_plane_regs.h"
 
 static int vs_primary_plane_atomic_check(struct drm_plane *plane,
@@ -102,6 +104,8 @@ static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
 static void vs_primary_plane_atomic_update(struct drm_plane *plane,
 					   struct drm_atomic_commit *atomic_state)
 {
+	struct drm_plane_state *old_state = drm_atomic_get_old_plane_state(atomic_state,
+									   plane);
 	struct drm_plane_state *state = drm_atomic_get_new_plane_state(atomic_state,
 								       plane);
 	struct vs_plane_state *vs_state = to_vs_plane_state(state);
@@ -117,6 +121,8 @@ static void vs_primary_plane_atomic_update(struct drm_plane *plane,
 		return;
 	}
 
+	drm_fb_dma_sync_non_coherent(plane->dev, old_state, state);
+
 	vcrtc = drm_crtc_to_vs_crtc(crtc);
 	output = vcrtc->id;
 	dc = vcrtc->dc;
@@ -184,5 +190,8 @@ struct drm_plane *vs_primary_plane_init(struct drm_device *drm_dev, struct vs_dc
 
 	drm_plane_helper_add(plane, &vs_primary_plane_helper_funcs);
 
+	if (to_vs_drm_dev(drm_dev)->map_noncoherent)
+		drm_plane_enable_fb_damage_clips(plane);
+
 	return plane;
 }
-- 
2.55.0

Re: [RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Wed, Sep 30, 2026 at 03:35:26PM +0800, Icenowy Zheng wrote:
> This patchset tries to address the lack of uncached mapping support on
> several SiFive-core-based SoCs, currently targeting JH7110 but EIC7700
> would have the same problem (although it uses DC8000 display controller
> instead of DC8200 and real display support is pending).
> 
> Because other users (either SoCs with Xuantie cores, which have
> Xtheadmae extensions or non-RISC-V SoCs) of the driver have proper
> writecombine support, a helper is added to check whether coherent
> (cache-bypassing) mapping is available. This helper currently returns
> true for all architectures except RISC-V, and checks whether
> pgprot_writecombine() is a no-op on RISC-V.
> 
> The patch really enabling manual cache maintenance for the verisilicon
> driver is picked from Dominique, and reworked to check both
> dma-noncoherent property and the platform's mapping capaibility.
> 
> Tested on VisionFive 2 with the display enablement patchset at [1] (and
> its dependency).
> 
> Also tested on Lichee Pi 4A (TH1520, which has Xtheadmae), operation is
> not affected, map_noncoherent isn't set and Xorg says kernel dirty
> updates aren't required.
> 
> [1] https://patch.msgid.link/20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com

Out of curiosity, have you seen Bo Gan's series from a few months ago
that creates an extension/erratum to get these devices working?
https://lore.kernel.org/linux-riscv/20260316060328.1173634-1-ganboing@gmail.com/

I've been meaning to reply to it over and over again for the last number
of months, but I just haven't had the time to actually understand the
detail of the EIC7700 solution or check whether it works yet. I know
this is just one driver because the JH7110 only has this problem for the 
display pipeline, but according to Bo Gan this applies to all
peripherals on the EIC7700. 

> 
> Dominique Belhachemi (1):
>   drm: verisilicon: support non-coherent DMA framebuffers
> 
> Icenowy Zheng (1):
>   drm: add a helper function to check availbility of coherent mapping
> 
>  drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
>  drivers/gpu/drm/verisilicon/vs_drm.c          | 32 ++++++++++++++++++-
>  drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
>  .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
>  include/drm/drm_cache.h                       | 21 ++++++++++++
>  5 files changed, 77 insertions(+), 1 deletion(-)
> 
> -- 
> 2.55.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[Icenowy Zheng]

在 2026-09-30三的 15:18 +0100，Conor Dooley写道：
> On Wed, Sep 30, 2026 at 03:35:26PM +0800, Icenowy Zheng wrote:
> > This patchset tries to address the lack of uncached mapping support
> > on
> > several SiFive-core-based SoCs, currently targeting JH7110 but
> > EIC7700
> > would have the same problem (although it uses DC8000 display
> > controller
> > instead of DC8200 and real display support is pending).
> > 
> > Because other users (either SoCs with Xuantie cores, which have
> > Xtheadmae extensions or non-RISC-V SoCs) of the driver have proper
> > writecombine support, a helper is added to check whether coherent
> > (cache-bypassing) mapping is available. This helper currently
> > returns
> > true for all architectures except RISC-V, and checks whether
> > pgprot_writecombine() is a no-op on RISC-V.
> > 
> > The patch really enabling manual cache maintenance for the
> > verisilicon
> > driver is picked from Dominique, and reworked to check both
> > dma-noncoherent property and the platform's mapping capaibility.
> > 
> > Tested on VisionFive 2 with the display enablement patchset at [1]
> > (and
> > its dependency).
> > 
> > Also tested on Lichee Pi 4A (TH1520, which has Xtheadmae),
> > operation is
> > not affected, map_noncoherent isn't set and Xorg says kernel dirty
> > updates aren't required.
> > 
> > [1]
> > https://patch.msgid.link/20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com
> 
> Out of curiosity, have you seen Bo Gan's series from a few months ago
> that creates an extension/erratum to get these devices working?
> https://lore.kernel.org/linux-riscv/20260316060328.1173634-1-ganboing@gmail.com/
> 
> I've been meaning to reply to it over and over again for the last
> number
> of months, but I just haven't had the time to actually understand the
> detail of the EIC7700 solution or check whether it works yet. I know
> this is just one driver because the JH7110 only has this problem for
> the 

I personally think his EIC7700 solution unacceptable -- it's not
running directly on EIC7700, but some custom hypervisor (because the
uncached offset of EIC7700 doesn't behave as a simple OR opertaion),
which requires 3rd party code and prohibits KVM usage of the kernel.

> display pipeline, but according to Bo Gan this applies to all
> peripherals on the EIC7700. 

In fact JH7100 suffers from the same problem too, so JH7110 put some
DMA peripherals to the L2 front AXI bus; however although this bus
keeps coherency with the CPU, its bandwidth is questionable (I think
the bottleneck could be exhibited if you attach a not-too-bad NVMe SSD
on JH7110's PCIe).

Thanks,
Icenowy

> 
> > 
> > Dominique Belhachemi (1):
> >   drm: verisilicon: support non-coherent DMA framebuffers
> > 
> > Icenowy Zheng (1):
> >   drm: add a helper function to check availbility of coherent
> > mapping
> > 
> >  drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
> >  drivers/gpu/drm/verisilicon/vs_drm.c          | 32
> > ++++++++++++++++++-
> >  drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
> >  .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
> >  include/drm/drm_cache.h                       | 21 ++++++++++++
> >  5 files changed, 77 insertions(+), 1 deletion(-)
> > 
> > -- 
> > 2.55.0
> > 

Re: [RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4770 bytes --]

On Wed, Sep 30, 2026 at 10:38:07PM +0800, Icenowy Zheng wrote:
> 在 2026-09-30三的 15:18 +0100，Conor Dooley写道：
> > On Wed, Sep 30, 2026 at 03:35:26PM +0800, Icenowy Zheng wrote:
> > > This patchset tries to address the lack of uncached mapping support
> > > on
> > > several SiFive-core-based SoCs, currently targeting JH7110 but
> > > EIC7700
> > > would have the same problem (although it uses DC8000 display
> > > controller
> > > instead of DC8200 and real display support is pending).
> > > 
> > > Because other users (either SoCs with Xuantie cores, which have
> > > Xtheadmae extensions or non-RISC-V SoCs) of the driver have proper
> > > writecombine support, a helper is added to check whether coherent
> > > (cache-bypassing) mapping is available. This helper currently
> > > returns
> > > true for all architectures except RISC-V, and checks whether
> > > pgprot_writecombine() is a no-op on RISC-V.
> > > 
> > > The patch really enabling manual cache maintenance for the
> > > verisilicon
> > > driver is picked from Dominique, and reworked to check both
> > > dma-noncoherent property and the platform's mapping capaibility.
> > > 
> > > Tested on VisionFive 2 with the display enablement patchset at [1]
> > > (and
> > > its dependency).
> > > 
> > > Also tested on Lichee Pi 4A (TH1520, which has Xtheadmae),
> > > operation is
> > > not affected, map_noncoherent isn't set and Xorg says kernel dirty
> > > updates aren't required.
> > > 
> > > [1]
> > > https://patch.msgid.link/20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com
> > 
> > Out of curiosity, have you seen Bo Gan's series from a few months ago
> > that creates an extension/erratum to get these devices working?
> > https://lore.kernel.org/linux-riscv/20260316060328.1173634-1-ganboing@gmail.com/
> > 
> > I've been meaning to reply to it over and over again for the last
> > number
> > of months, but I just haven't had the time to actually understand the
> > detail of the EIC7700 solution or check whether it works yet. I know
> > this is just one driver because the JH7110 only has this problem for
> > the 
> 
> I personally think his EIC7700 solution unacceptable -- it's not
> running directly on EIC7700, but some custom hypervisor (because the
> uncached offset of EIC7700 doesn't behave as a simple OR opertaion),
> which requires 3rd party code and prohibits KVM usage of the kernel.

I was actually reading through Bo Gan's patchset when I noticed this
series, trying to get my thoughts in order and figured a second set of
eyes and thoughts would be helpful to me.

I've got a similar opinion to yours about the EIC7700 solution, it's
quite invasive (it'd only be 3rd party if it wasn't accepted) but I
would consider something invasive firmware wise to be worthwhile if no
peripheral on the device worked without it.

> > display pipeline, but according to Bo Gan this applies to all
> > peripherals on the EIC7700. 

And, as I said, Bo Gan was of the opinion that all of the peripherals
require it. Of course I suspect that actually meant all DMA capable
peripherals require it, not all peripherals (especially given there's
been patchsets adding simpler peripherals).

That said, Samuel's solution does exist and if the feedback was
implemented by someone that cared about the eic7700 it'd be much more
acceptable. The fact that you've got a solution here at at least works
on an interim basis for the JH7110 (although I have no idea what the DRM
folks will think of it) is another point in Samuel's method's favour.

Thanks. I've got a much better idea of what to say to Bo Gan now.

Conor.

> In fact JH7100 suffers from the same problem too, so JH7110 put some
> DMA peripherals to the L2 front AXI bus; however although this bus
> keeps coherency with the CPU, its bandwidth is questionable (I think
> the bottleneck could be exhibited if you attach a not-too-bad NVMe SSD
> on JH7110's PCIe).
> 
> Thanks,
> Icenowy
> 
> > 
> > > 
> > > Dominique Belhachemi (1):
> > >   drm: verisilicon: support non-coherent DMA framebuffers
> > > 
> > > Icenowy Zheng (1):
> > >   drm: add a helper function to check availbility of coherent
> > > mapping
> > > 
> > >  drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
> > >  drivers/gpu/drm/verisilicon/vs_drm.c          | 32
> > > ++++++++++++++++++-
> > >  drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
> > >  .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
> > >  include/drm/drm_cache.h                       | 21 ++++++++++++
> > >  5 files changed, 77 insertions(+), 1 deletion(-)
> > > 
> > > -- 
> > > 2.55.0
> > > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [RFC PATCH 0/2] drm: add a noncoherent mapping checking helper

[Icenowy Zheng]

在 2026-09-30三的 17:30 +0100，Conor Dooley写道：
> On Wed, Sep 30, 2026 at 10:38:07PM +0800, Icenowy Zheng wrote:
> > 在 2026-09-30三的 15:18 +0100，Conor Dooley写道：
> > > On Wed, Sep 30, 2026 at 03:35:26PM +0800, Icenowy Zheng wrote:
> > > > This patchset tries to address the lack of uncached mapping
> > > > support
> > > > on
> > > > several SiFive-core-based SoCs, currently targeting JH7110 but
> > > > EIC7700
> > > > would have the same problem (although it uses DC8000 display
> > > > controller
> > > > instead of DC8200 and real display support is pending).
> > > > 
> > > > Because other users (either SoCs with Xuantie cores, which have
> > > > Xtheadmae extensions or non-RISC-V SoCs) of the driver have
> > > > proper
> > > > writecombine support, a helper is added to check whether
> > > > coherent
> > > > (cache-bypassing) mapping is available. This helper currently
> > > > returns
> > > > true for all architectures except RISC-V, and checks whether
> > > > pgprot_writecombine() is a no-op on RISC-V.
> > > > 
> > > > The patch really enabling manual cache maintenance for the
> > > > verisilicon
> > > > driver is picked from Dominique, and reworked to check both
> > > > dma-noncoherent property and the platform's mapping
> > > > capaibility.
> > > > 
> > > > Tested on VisionFive 2 with the display enablement patchset at
> > > > [1]
> > > > (and
> > > > its dependency).
> > > > 
> > > > Also tested on Lichee Pi 4A (TH1520, which has Xtheadmae),
> > > > operation is
> > > > not affected, map_noncoherent isn't set and Xorg says kernel
> > > > dirty
> > > > updates aren't required.
> > > > 
> > > > [1]
> > > > https://patch.msgid.link/20260929-jh7110-clean-send-v5-0-82b4d8e3c6c7@samsung.com
> > > 
> > > Out of curiosity, have you seen Bo Gan's series from a few months
> > > ago
> > > that creates an extension/erratum to get these devices working?
> > > https://lore.kernel.org/linux-riscv/20260316060328.1173634-1-ganboing@gmail.com/
> > > 
> > > I've been meaning to reply to it over and over again for the last
> > > number
> > > of months, but I just haven't had the time to actually understand
> > > the
> > > detail of the EIC7700 solution or check whether it works yet. I
> > > know
> > > this is just one driver because the JH7110 only has this problem
> > > for
> > > the 
> > 
> > I personally think his EIC7700 solution unacceptable -- it's not
> > running directly on EIC7700, but some custom hypervisor (because
> > the
> > uncached offset of EIC7700 doesn't behave as a simple OR
> > opertaion),
> > which requires 3rd party code and prohibits KVM usage of the
> > kernel.
> 
> I was actually reading through Bo Gan's patchset when I noticed this
> series, trying to get my thoughts in order and figured a second set
> of
> eyes and thoughts would be helpful to me.
> 
> I've got a similar opinion to yours about the EIC7700 solution, it's
> quite invasive (it'd only be 3rd party if it wasn't accepted) but I

It'd always be 3rd party if Eswin doesn't accept it. The Linux kernel
cannot deliver such a hacked firmware.

> would consider something invasive firmware wise to be worthwhile if
> no
> peripheral on the device worked without it.
> 
> > > display pipeline, but according to Bo Gan this applies to all
> > > peripherals on the EIC7700. 
> 
> And, as I said, Bo Gan was of the opinion that all of the peripherals
> require it. Of course I suspect that actually meant all DMA capable
> peripherals require it, not all peripherals (especially given there's
> been patchsets adding simpler peripherals).

All DMA peripherals on EIC7700 is non-coherent, but some of them will
still work without uncached mapping.

Only peripherals that really share the same buffer between CPU and the
device will be affected, because otherwise the coherency is kept by
cache maintenance instead of uncached mapping. (Display framebuffer is
a borderline situation -- it is accessed by the CPU and the DC in the
same time, but the DC does read-only access, so manual cache
maintenance is still doable although with price).

> 
> That said, Samuel's solution does exist and if the feedback was
> implemented by someone that cared about the eic7700 it'd be much more
> acceptable. The fact that you've got a solution here at at least
> works
> on an interim basis for the JH7110 (although I have no idea what the
> DRM
> folks will think of it) is another point in Samuel's method's favour.

I think the major problem of Samuel's method is that it's invasive to
other kernel subsystems, which would make the review time much much
longer; but I still expect it.

(A minor problem is that his mail server is too strict -- on SPF rules,
which prevented his mails to be forwarded by mailing lists.)

Thanks,
Icenowy

> 
> Thanks. I've got a much better idea of what to say to Bo Gan now.
> 
> Conor.
> 
> > In fact JH7100 suffers from the same problem too, so JH7110 put
> > some
> > DMA peripherals to the L2 front AXI bus; however although this bus
> > keeps coherency with the CPU, its bandwidth is questionable (I
> > think
> > the bottleneck could be exhibited if you attach a not-too-bad NVMe
> > SSD
> > on JH7110's PCIe).
> > 
> > Thanks,
> > Icenowy
> > 
> > > 
> > > > 
> > > > Dominique Belhachemi (1):
> > > >   drm: verisilicon: support non-coherent DMA framebuffers
> > > > 
> > > > Icenowy Zheng (1):
> > > >   drm: add a helper function to check availbility of coherent
> > > > mapping
> > > > 
> > > >  drivers/gpu/drm/verisilicon/vs_cursor_plane.c |  9 ++++++
> > > >  drivers/gpu/drm/verisilicon/vs_drm.c          | 32
> > > > ++++++++++++++++++-
> > > >  drivers/gpu/drm/verisilicon/vs_drm.h          |  7 ++++
> > > >  .../gpu/drm/verisilicon/vs_primary_plane.c    |  9 ++++++
> > > >  include/drm/drm_cache.h                       | 21
> > > > ++++++++++++
> > > >  5 files changed, 77 insertions(+), 1 deletion(-)
> > > > 
> > > > -- 
> > > > 2.55.0
> > > >