From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Christian König" <christian.koenig@amd.com>,
"Icenowy Zheng" <uwu@icenowy.me>, "Huang Rui" <ray.huang@amd.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available
Date: Tue, 02 Jul 2024 18:03:37 +0800 [thread overview]
Message-ID: <fd1d0a97-7075-4936-b58b-e99bab9afc58@app.fastmail.com> (raw)
In-Reply-To: <ae7085fd-3bca-4a4a-b465-5e4941011877@amd.com>
在2024年7月2日七月 下午5:27,Christian König写道:
> Am 02.07.24 um 11:06 schrieb Icenowy Zheng:
>> [SNIP] However I don't think the definition of the AGP spec could apply on all
>> PCI(e) implementations. The AGP spec itself don't apply on
>> implementations that do not implement AGP (which is the most PCI(e)
>> implementations today), and it's not in the reference list of the PCIe
>> spec, so it does no help on this context.
> No, exactly that is not correct.
>
> See as I explained the No-Snoop extension to PCIe was created to help
> with AGP support and later merged into the base PCIe specification.
>
> So the AGP spec is now part of the PCIe spec.
We don't really buy this theory.
Keyword "AGP" doesn't appear in "PCI Express Base 4.0 Base Specification" even
once.
If PCIe is a predecessor of AGP, where does AGP specific software interface like
AGP aperture goes? PCIe GPUs are only borrowing software concepts from AGP,
but they didn't inherit any hardware properties.
[...]
> We seem to have a misunderstanding here, this is not a software issue.
> The hardware platform is considered broken by the hardware vendor!
It's up to the specification text to define compliance means. So far as per analysis
from Icenowy of PCIe specification text itself it's not prohibited.
>
> In other words people have stitched together hardware in a way which is
> not supported by the creator of that hardware.
>
> So as long as you can't convince anybody from ARM or the RISC-V team or
> whoever created that hardware to confirm that the hardware actually
> works you won't get any support for that.
Well we are trying to support them on our own in mainline, we are not asking
for any support.
Thanks
- Jiaxun
>
> Regards,
> Christian.
--
- Jiaxun
next prev parent reply other threads:[~2024-07-02 10:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-29 5:22 [RFC PATCH 0/2] drm/ttm: support device w/o coherency Icenowy Zheng
2024-06-29 5:22 ` [RFC PATCH 1/2] drm/ttm: save the device's DMA coherency status in ttm_device Icenowy Zheng
2024-06-29 5:22 ` [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available Icenowy Zheng
2024-06-29 19:57 ` Jiaxun Yang
2024-06-29 20:51 ` Icenowy Zheng
2024-07-01 11:40 ` Christian König
2024-07-01 11:52 ` Jiaxun Yang
2024-07-01 12:10 ` Christian König
2024-07-02 1:46 ` Icenowy Zheng
[not found] ` <ff1bf596-83cb-4b3e-a33a-621ac2c8171c@amd.com>
2024-07-02 9:06 ` Icenowy Zheng
[not found] ` <ae7085fd-3bca-4a4a-b465-5e4941011877@amd.com>
2024-07-02 10:01 ` Icenowy Zheng
2024-07-02 10:03 ` Jiaxun Yang [this message]
2024-07-03 8:52 ` PCIe coherency in spec (was: [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available) Jiaxun Yang
2024-07-03 21:08 ` Bjorn Helgaas
2024-07-04 2:00 ` Icenowy Zheng
2024-07-04 6:11 ` Christoph Hellwig
2024-07-04 6:40 ` Icenowy Zheng
2024-07-04 6:44 ` Christoph Hellwig
[not found] ` <4e958aa5-2a56-4754-b3dd-273da95f1d14@amd.com>
2024-07-02 9:36 ` [RFC PATCH 2/2] drm/ttm: downgrade cached to write_combined when snooping not available Icenowy Zheng
2024-06-30 6:52 ` Icenowy Zheng
2024-07-01 11:37 ` [RFC PATCH 0/2] drm/ttm: support device w/o coherency Christian König
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=fd1d0a97-7075-4936-b58b-e99bab9afc58@app.fastmail.com \
--to=jiaxun.yang@flygoat.com \
--cc=airlied@gmail.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=tzimmermann@suse.de \
--cc=uwu@icenowy.me \
/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
all inboxes | Powered by JetHome®