On Wed, Feb 19, 2025 at 04:26:55PM +0000, Richard Fitzgerald wrote:
On 13/02/2025 3:16 pm, Thomas Weißschuh wrote:
On Thu, Feb 13, 2025 at 03:06:59PM +0000, Mark Brown wrote:There are 3 suspicious regmap_raw_read(). The others are all integers,
On Thu, Feb 13, 2025 at 02:28:06PM +0000, Richard Fitzgerald wrote:
On 11/02/2025 5:21 pm, Richard Fitzgerald wrote:
Not tested on real hardware.
This came up while porting kunit to mips64.
Apparently GFP_DMA does not work there, but IMO the usage of GFP_DMA by
I would say that is a bug in mips64 that should be fixed in mips64.
It is not reasonable to expect generic drivers to have special cases for
platforms that don't handle GFP_DMA.
Indeed, I did that, too.
What specifically is the issue? If it's a build time issue I'd
definitely agree that we should just be able to assume that platforms at
least build. IIRC there is a Kconfig you can depend on for DMA but it
seems more trouble than it's worth to fix all users.
More details in [0], It's only a runtime issue.
I'm still wondering how all the on-stack buffers used with regmap_raw_read()
and regmap_raw_write() by cs_dsp are satisfying the DMA requirements.
which are guaranteed not to cross a page boundary.
However, it looks like it might be safe to remove the GFP_DMA flags
now. regmap_raw_read() calls spi_write_then_read() which specifically
says that the buffers do not need to be DMA-safe and internally uses a
DMA-safe buffer. regmap_raw_write() uses either a temporary physically
contiguous buffer or GFP_DMA buffer (the implementation is terrifyingly
complex so it's difficult to determine exactly what it does).
(Some older systems could only use certain special memory areas for DMA
but we haven't seen any of those used with cs_dsp.)
We also need to consider what the I2C subsystem does, I have a
vague memory of thinking the SPI system will attempt to remap
buffers but I2C will just use them as is. cs_dsp will be used
with both, although SPI is slightly more common for obvious
reasons.
Thanks,
Charles