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

[Conor Dooley <conor@kernel.org>]

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