linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Xi Ruoyao <xry111@xry111.site>, WANG Xuerui <kernel@xen0n.name>,
	Icenowy Zheng <uwu@icenowy.me>,
	Huacai Chen <chenhuacai@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Mike Rapoport (IBM)" <rppt@kernel.org>,
	Baoquan He <bhe@redhat.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	David Hildenbrand <david@redhat.com>,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Zhihong Dong <donmor3000@hotmail.com>,
	loongarch@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as same as ioremap_wc
Date: Tue, 3 Dec 2024 00:23:07 +0800	[thread overview]
Message-ID: <dfc53da9-a1ab-4ab3-aba2-d100f7f28b9b@linux.dev> (raw)
In-Reply-To: <8373ccfd93b0402caf9f5c06a2d9b93b3c0d0b49.camel@xry111.site>

Hi,

On 10/10/23 20:26, Xi Ruoyao wrote:
> On Tue, 2023-10-10 at 11:02 +0800, Sui Jingfeng wrote:
> 
>>
>> On LoongArch, cached mapping and uncached mappings are DMA-coherent and guaranteed by
>> the hardware. While WC mappings is *NOT* DMA-coherent when 3D GPU is involved. Therefore,
>> On downstream kernel, We disable write combine(WC) mappings at the drm drivers side.
> 
> Why it's only an issue when 3D GPU is involved? 

No one saying that only 3D GPU is suffer from this kind of issue,
I just meant that the issue is there at least for GPU

> What's the difference between 3D GPUs and other devices?  Is it possible that the other
> devices (say neural accelerators) start to perform DMA accesses in a
> similar way and then suddenly broken?

You, the patch contributor or the maintainer or whatever stuff
should carry on the test, right?

We are not intended to against the patch though.

>> - For buffers at VRAM(device memory), we replace the WC mappings with uncached mappings.
>> - For buffers reside in RAM, we replace the WC mappings with cached mappings.
>>
>> By this way, we were able to minimum the side effects, and meet the usable requirements
>> for all of the GPU drivers.
> 
> AFAIK there has been some clear NAK from DRM maintainers towards this
> "approach".  So it's not possible to be applied upstream.

That's your guys problems, stealing other programmer's patch.
And then, submit it to upstream without knowing and/or presenting
decent hardware details.


>> For DMA non-coherent buffers, we should try to implement arch-specific dma_map_ops,
>> invalidate the CPU cache and flush the CPU write buffer before the device do DMA. Instead
>> of pretend to be DMA coherent for all buffers, a kernel cmdline is not a system level
>> solution for all of GPU drivers and OS release.
> 
> IIUC this is a hardware bug of 7A1000 and 7A2000, so the proper location
> of the workaround is in the bridge chip driver.  Or am I
> misunderstanding something?
> 

You are misunderstanding everything and ranting like a dog.

The write buffers are inside the CPU, and the write-combine is related
to *both* the CPU side and the GPU side. The GPU side could choose
no snooping access mode, while the CPU side have to address such request
properly.

What's we arguing is that if this is a hardware bug of north bridge, we
at least still should be able to use WC at the CPU side, that is, WC on
system pages should be usable without any issue. While the weird commit
disable everything.



  parent reply	other threads:[~2024-12-02 16:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20231009042841.635366-1-uwu@icenowy.me>
2023-10-09 14:32 ` [PATCH v2] loongarch/mm: disable WUC for pgprot_writecombine as same as ioremap_wc Sui Jingfeng
2023-10-10  0:15   ` WANG Xuerui
2023-10-10  3:02     ` Sui Jingfeng
2023-10-10 12:26       ` Xi Ruoyao
2023-10-13 11:12         ` Sui Jingfeng
2023-10-13 12:51         ` Sui Jingfeng
2023-10-13 13:15           ` Xi Ruoyao
2023-10-13 13:53             ` Xi Ruoyao
2025-01-21  9:19               ` Sui Jingfeng
2024-12-02 16:23         ` Sui Jingfeng [this message]
2024-12-17 18:18           ` Shuah
2024-12-18  3:24             ` Sui Jingfeng
2024-12-18  6:23               ` Icenowy Zheng
2024-12-18 10:05                 ` Sui Jingfeng
2024-12-18 12:37                   ` Icenowy Zheng
2024-12-19  3:17                     ` Sui Jingfeng
2024-12-19  4:54                       ` Icenowy Zheng
2024-12-20 16:43               ` Shuah
2024-12-17 23:44           ` Icenowy Zheng
2024-12-18  3:05             ` Sui Jingfeng
2024-12-18  5:47               ` Icenowy Zheng
2024-12-18 10:29                 ` Sui Jingfeng
2024-12-18 12:43                   ` Icenowy Zheng
2024-12-19  2:54                     ` Sui Jingfeng
2024-12-19  4:49                       ` Icenowy Zheng
2024-12-19  5:49                         ` Sui Jingfeng
2024-12-19  6:34                           ` Icenowy Zheng
2024-12-19  7:46                             ` Sui Jingfeng
2024-12-19  6:38                           ` Icenowy Zheng
2024-12-19 10:39                             ` Sui Jingfeng
2023-10-10  0:50   ` Icenowy Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfc53da9-a1ab-4ab3-aba2-d100f7f28b9b@linux.dev \
    --to=sui.jingfeng@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=chenhuacai@kernel.org \
    --cc=david@redhat.com \
    --cc=donmor3000@hotmail.com \
    --cc=kernel@xen0n.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loongarch@lists.linux.dev \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thunder.leizhen@huawei.com \
    --cc=uwu@icenowy.me \
    --cc=willy@infradead.org \
    --cc=xry111@xry111.site \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).