[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
> > > >