[v3,0/4] Use dma_default_coherent for devicetree default coherency

Message

Jiaxun Yang March 21, 2023, 11:08 a.m. UTC

Hi all,

This series split out second half of my previous series
"[PATCH 0/4] MIPS DMA coherence fixes".

It intends to use dma_default_coherent to determine the default coherency of
devicetree probed devices instead of hardcoding it with Kconfig options.

For some MIPS systems, dma_default_coherent is determined with either
bootloader or hardware registers in platform initilization code, and devicetree
does not explicility specify the coherency of the device, so we need the ability
to change the default coherency of devicetree probed devices.

For other platforms that supports noncoherent, dma_default_coherent is a fixed
value set by arch code. It's defaulted to false for most archs except RISC-V.

Thanks
- Jiaxun
---
v2:
  - Add PATCH 1 to help with backporting
  - Use Kconfig option to set dma_default_coherent 

v3:
  - Style fixes
  - Squash setting ARCH_DMA_DEFAULT_COHERENT into PATCH 4
  - Setting ARCH_DMA_DEFAULT_COHERENT for PowerPC

Jiaxun Yang (4):
  of: address: Fix default coherency for MIPS
  dma-mapping: Provide a fallback dma_default_coherent
  dma-mapping: Provide CONFIG_ARCH_DMA_DEFAULT_COHERENT
  of: address: Always use dma_default_coherent for default coherency

 arch/powerpc/Kconfig        | 2 +-
 arch/riscv/Kconfig          | 2 +-
 drivers/of/Kconfig          | 4 ----
 drivers/of/address.c        | 2 +-
 include/linux/dma-map-ops.h | 2 ++
 kernel/dma/Kconfig          | 7 +++++++
 kernel/dma/mapping.c        | 6 +++++-
 7 files changed, 17 insertions(+), 8 deletions(-)

Comments

Christoph Hellwig March 23, 2023, 7:29 a.m. UTC | #1

The series looks fine to me.  How should we merge it?

Jiaxun Yang March 23, 2023, 9:07 p.m. UTC | #2

> 2023年3月23日 07:29，Christoph Hellwig <[e-mail]> 写道：
> 
> The series looks fine to me.  How should we merge it?

Perhaps go through dma-mapping tree?

Thanks
- Jiaxun

Christoph Hellwig March 23, 2023, 9:39 p.m. UTC | #3

On Thu, Mar 23, 2023 at 09:07:31PM +0000, Jiaxun Yang wrote:
> 
> 
> > 2023年3月23日 07:29，Christoph Hellwig <[e-mail]> 写道：
> > 
> > The series looks fine to me.  How should we merge it?
> 
> Perhaps go through dma-mapping tree?

Is patch a 6.3 candidate or should all of it go into 6.4?

Jiaxun Yang March 24, 2023, 9:17 a.m. UTC | #4

> 2023年3月23日 21:39，Christoph Hellwig <[e-mail]> 写道：
> 
> On Thu, Mar 23, 2023 at 09:07:31PM +0000, Jiaxun Yang wrote:
>> 
>> 
>>> 2023年3月23日 07:29，Christoph Hellwig <[e-mail]> 写道：
>>> 
>>> The series looks fine to me.  How should we merge it?
>> 
>> Perhaps go through dma-mapping tree?
> 
> Is patch a 6.3 candidate or should all of it go into 6.4?

Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4.

Thanks
Jiaxun

Christoph Hellwig March 28, 2023, 1:18 a.m. UTC | #5

On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote:
> > 
> > Is patch a 6.3 candidate or should all of it go into 6.4?
> 
> Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4.

Ok.  I'll really need review from the MIPS and drivers/of/ maintainers,
through.

Thomas Bogendoerfer March 28, 2023, 7:45 a.m. UTC | #6

On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote:
> On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote:
> > > 
> > > Is patch a 6.3 candidate or should all of it go into 6.4?
> > 
> > Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4.
> 
> Ok.  I'll really need review from the MIPS and drivers/of/ maintainers,
> through.

I don't see any MIPS changes in the series besides the ifdef CONFIG_MIPS
part in patch 1, which gets removed again in patch 4 (chance to drop
that completely ?).

I've merged the corresponding MIPS patches into mips-next last week.

Thomas.

Jiaxun Yang March 28, 2023, 1:02 p.m. UTC | #7

> 2023年3月28日 08:45，Thomas Bogendoerfer <[e-mail]> 写道：
> 
> On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote:
>> On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote:
>>>> 
>>>> Is patch a 6.3 candidate or should all of it go into 6.4?
>>> 
>>> Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4.
>> 
>> Ok.  I'll really need review from the MIPS and drivers/of/ maintainers,
>> through.

+cc devicetree foks.

> 
> I don't see any MIPS changes in the series besides the ifdef CONFIG_MIPS
> part in patch 1, which gets removed again in patch 4 (chance to drop
> that completely ?).

It was suggested by DMA folks to have that patch.

> I've merged the corresponding MIPS patches into mips-next last week.

Thanks
- Jiaxun

> 
> Thomas.
> 
> -- 
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea.                                                [ RFC1925, 2.3 ]