All of lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	mpe@ellerman.id.au, paul.walmsley@sifive.com, palmer@dabbelt.com,
	Rob Herring <robh+dt@kernel.org>, Christoph Hellwig <hch@lst.de>,
	m.szyprowski@samsung.com, robin.murphy@arm.com,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/3] riscv: Set dma_default_coherent to true
Date: Wed, 22 Feb 2023 16:59:36 +0000	[thread overview]
Message-ID: <Y/ZJ+N4m6UUmIpL0@spud> (raw)
In-Reply-To: <E46E0161-24E3-4185-B408-9357C49F1B51@flygoat.com>

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

On Wed, Feb 22, 2023 at 04:20:16PM +0000, Jiaxun Yang wrote:
> > 2023年2月22日 16:02,Conor Dooley <conor@kernel.org> 写道:
> > On Wed, Feb 22, 2023 at 03:55:19PM +0000, Jiaxun Yang wrote:
> >>> 2023年2月22日 14:50,Conor Dooley <conor@kernel.org> 写道:
> >>> On Wed, Feb 22, 2023 at 01:37:11PM +0000, Jiaxun Yang wrote:
> >>>> For riscv our assumption is unless a device states it is non-coherent,
> >>>> we take it to be DMA coherent.
> >>>> 
> >>>> For devicetree probed devices that have been true since very begining
> >>>> with OF_DMA_DEFAULT_COHERENT selected.
> >>>> 
> >>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> >>>> ---
> >>>> arch/riscv/kernel/setup.c | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>> 
> >>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>>> index 376d2827e736..34b371180976 100644
> >>>> --- a/arch/riscv/kernel/setup.c
> >>>> +++ b/arch/riscv/kernel/setup.c
> >>>> @@ -300,6 +300,9 @@ void __init setup_arch(char **cmdline_p)
> >>>> riscv_init_cbom_blocksize();
> >>>> riscv_fill_hwcap();
> >>>> apply_boot_alternatives();
> >>>> +#ifdef CONFIG_RISCV_DMA_NONCOHERENT
> >>>> + dma_default_coherent = true;
> >>>> +#endif
> >>> 
> >>> Do we really need to add ifdeffery for this here?
> >>> It's always coherent by default, so why do we need to say set it in
> >>> setup_arch() when we know that, regardless of options, it is true?
> >> 
> >> Because this symbol is only a variable when:
> >> 
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
> >> 
> >> Which is only true if  CONFIG_RISCV_DMA_NONCOHERENT is selected.
> >> 
> >> Otherwise this symbol is defined to true and we can’t make a assignment to it.

> > Maybe I am just slow today, but I don't get why you need to add
> > ifdeffery to setup_arch() to do something that is always true.
> > Why can't you just set this in riscv/mm/dma-noncoherent.c? What am I
> > missing?
> 
> Hmm that sounds like a good idea but I was unable to find a place for this.
> 
> riscv/mm/dma-noncoherent.c are just a bunch of callbacks, there is no initialisation
> function that will always run on every boot. riscv_noncoherent_supported is only
> called conditionally.

Right, that's fair. riscv_noncoherent_supported() is for when we know we
can support non-coherent DMA, not to detect whether we can, hence the
conditional nature.
Apologies for sending you on a wild goose chase there.

> Perhaps I can add a initcall in dma-noncoherent.c but it seems to be a little bit
> overkilling.

Yah, probably would be.

> Actually I’d prefer to have a config option for the default value but it seems like
> it’s not in Christoph’s flavour.

We already have a config option that sets things up nicely for RISC-V
that you're getting rid of! ;)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: "linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	mpe@ellerman.id.au, paul.walmsley@sifive.com, palmer@dabbelt.com,
	Rob Herring <robh+dt@kernel.org>, Christoph Hellwig <hch@lst.de>,
	m.szyprowski@samsung.com, robin.murphy@arm.com,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH 2/3] riscv: Set dma_default_coherent to true
Date: Wed, 22 Feb 2023 16:59:36 +0000	[thread overview]
Message-ID: <Y/ZJ+N4m6UUmIpL0@spud> (raw)
In-Reply-To: <E46E0161-24E3-4185-B408-9357C49F1B51@flygoat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2952 bytes --]

On Wed, Feb 22, 2023 at 04:20:16PM +0000, Jiaxun Yang wrote:
> > 2023年2月22日 16:02,Conor Dooley <conor@kernel.org> 写道:
> > On Wed, Feb 22, 2023 at 03:55:19PM +0000, Jiaxun Yang wrote:
> >>> 2023年2月22日 14:50,Conor Dooley <conor@kernel.org> 写道:
> >>> On Wed, Feb 22, 2023 at 01:37:11PM +0000, Jiaxun Yang wrote:
> >>>> For riscv our assumption is unless a device states it is non-coherent,
> >>>> we take it to be DMA coherent.
> >>>> 
> >>>> For devicetree probed devices that have been true since very begining
> >>>> with OF_DMA_DEFAULT_COHERENT selected.
> >>>> 
> >>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> >>>> ---
> >>>> arch/riscv/kernel/setup.c | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>> 
> >>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>>> index 376d2827e736..34b371180976 100644
> >>>> --- a/arch/riscv/kernel/setup.c
> >>>> +++ b/arch/riscv/kernel/setup.c
> >>>> @@ -300,6 +300,9 @@ void __init setup_arch(char **cmdline_p)
> >>>> riscv_init_cbom_blocksize();
> >>>> riscv_fill_hwcap();
> >>>> apply_boot_alternatives();
> >>>> +#ifdef CONFIG_RISCV_DMA_NONCOHERENT
> >>>> + dma_default_coherent = true;
> >>>> +#endif
> >>> 
> >>> Do we really need to add ifdeffery for this here?
> >>> It's always coherent by default, so why do we need to say set it in
> >>> setup_arch() when we know that, regardless of options, it is true?
> >> 
> >> Because this symbol is only a variable when:
> >> 
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
> >> 
> >> Which is only true if  CONFIG_RISCV_DMA_NONCOHERENT is selected.
> >> 
> >> Otherwise this symbol is defined to true and we can’t make a assignment to it.

> > Maybe I am just slow today, but I don't get why you need to add
> > ifdeffery to setup_arch() to do something that is always true.
> > Why can't you just set this in riscv/mm/dma-noncoherent.c? What am I
> > missing?
> 
> Hmm that sounds like a good idea but I was unable to find a place for this.
> 
> riscv/mm/dma-noncoherent.c are just a bunch of callbacks, there is no initialisation
> function that will always run on every boot. riscv_noncoherent_supported is only
> called conditionally.

Right, that's fair. riscv_noncoherent_supported() is for when we know we
can support non-coherent DMA, not to detect whether we can, hence the
conditional nature.
Apologies for sending you on a wild goose chase there.

> Perhaps I can add a initcall in dma-noncoherent.c but it seems to be a little bit
> overkilling.

Yah, probably would be.

> Actually I’d prefer to have a config option for the default value but it seems like
> it’s not in Christoph’s flavour.

We already have a config option that sets things up nicely for RISC-V
that you're getting rid of! ;)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	palmer@dabbelt.com, paul.walmsley@sifive.com,
	robin.murphy@arm.com, linux-riscv@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org, Christoph Hellwig <hch@lst.de>,
	m.szyprowski@samsung.com
Subject: Re: [PATCH 2/3] riscv: Set dma_default_coherent to true
Date: Wed, 22 Feb 2023 16:59:36 +0000	[thread overview]
Message-ID: <Y/ZJ+N4m6UUmIpL0@spud> (raw)
In-Reply-To: <E46E0161-24E3-4185-B408-9357C49F1B51@flygoat.com>

[-- Attachment #1: Type: text/plain, Size: 2952 bytes --]

On Wed, Feb 22, 2023 at 04:20:16PM +0000, Jiaxun Yang wrote:
> > 2023年2月22日 16:02,Conor Dooley <conor@kernel.org> 写道:
> > On Wed, Feb 22, 2023 at 03:55:19PM +0000, Jiaxun Yang wrote:
> >>> 2023年2月22日 14:50,Conor Dooley <conor@kernel.org> 写道:
> >>> On Wed, Feb 22, 2023 at 01:37:11PM +0000, Jiaxun Yang wrote:
> >>>> For riscv our assumption is unless a device states it is non-coherent,
> >>>> we take it to be DMA coherent.
> >>>> 
> >>>> For devicetree probed devices that have been true since very begining
> >>>> with OF_DMA_DEFAULT_COHERENT selected.
> >>>> 
> >>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> >>>> ---
> >>>> arch/riscv/kernel/setup.c | 3 +++
> >>>> 1 file changed, 3 insertions(+)
> >>>> 
> >>>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> >>>> index 376d2827e736..34b371180976 100644
> >>>> --- a/arch/riscv/kernel/setup.c
> >>>> +++ b/arch/riscv/kernel/setup.c
> >>>> @@ -300,6 +300,9 @@ void __init setup_arch(char **cmdline_p)
> >>>> riscv_init_cbom_blocksize();
> >>>> riscv_fill_hwcap();
> >>>> apply_boot_alternatives();
> >>>> +#ifdef CONFIG_RISCV_DMA_NONCOHERENT
> >>>> + dma_default_coherent = true;
> >>>> +#endif
> >>> 
> >>> Do we really need to add ifdeffery for this here?
> >>> It's always coherent by default, so why do we need to say set it in
> >>> setup_arch() when we know that, regardless of options, it is true?
> >> 
> >> Because this symbol is only a variable when:
> >> 
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
> >> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
> >> 
> >> Which is only true if  CONFIG_RISCV_DMA_NONCOHERENT is selected.
> >> 
> >> Otherwise this symbol is defined to true and we can’t make a assignment to it.

> > Maybe I am just slow today, but I don't get why you need to add
> > ifdeffery to setup_arch() to do something that is always true.
> > Why can't you just set this in riscv/mm/dma-noncoherent.c? What am I
> > missing?
> 
> Hmm that sounds like a good idea but I was unable to find a place for this.
> 
> riscv/mm/dma-noncoherent.c are just a bunch of callbacks, there is no initialisation
> function that will always run on every boot. riscv_noncoherent_supported is only
> called conditionally.

Right, that's fair. riscv_noncoherent_supported() is for when we know we
can support non-coherent DMA, not to detect whether we can, hence the
conditional nature.
Apologies for sending you on a wild goose chase there.

> Perhaps I can add a initcall in dma-noncoherent.c but it seems to be a little bit
> overkilling.

Yah, probably would be.

> Actually I’d prefer to have a config option for the default value but it seems like
> it’s not in Christoph’s flavour.

We already have a config option that sets things up nicely for RISC-V
that you're getting rid of! ;)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-02-22 16:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 13:37 [PATCH 0/3] Use dma_default_coherent for devicetree default coherency Jiaxun Yang
2023-02-22 13:37 ` Jiaxun Yang
2023-02-22 13:37 ` Jiaxun Yang
2023-02-22 13:37 ` [PATCH 1/3] dma-mapping: Provide a fallback dma_default_coherent Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 13:37 ` [PATCH 2/3] riscv: Set dma_default_coherent to true Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 14:50   ` Conor Dooley
2023-02-22 14:50     ` Conor Dooley
2023-02-22 14:50     ` Conor Dooley
2023-02-22 15:55     ` Jiaxun Yang
2023-02-22 15:55       ` Jiaxun Yang
2023-02-22 15:55       ` Jiaxun Yang
2023-02-22 16:02       ` Conor Dooley
2023-02-22 16:02         ` Conor Dooley
2023-02-22 16:02         ` Conor Dooley
2023-02-22 16:20         ` Jiaxun Yang
2023-02-22 16:20           ` Jiaxun Yang
2023-02-22 16:20           ` Jiaxun Yang
2023-02-22 16:59           ` Conor Dooley [this message]
2023-02-22 16:59             ` Conor Dooley
2023-02-22 16:59             ` Conor Dooley
2023-02-22 13:37 ` [PATCH 3/3] of: address: Use dma_default_coherent to determine default coherency Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 13:37   ` Jiaxun Yang
2023-02-22 17:24   ` Robin Murphy
2023-02-22 17:24     ` Robin Murphy
2023-02-22 17:24     ` Robin Murphy
2023-02-22 17:57     ` Jiaxun Yang
2023-02-22 17:57       ` Jiaxun Yang
2023-02-22 17:57       ` Jiaxun Yang

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=Y/ZJ+N4m6UUmIpL0@spud \
    --to=conor@kernel.org \
    --cc=hch@lst.de \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tsbogend@alpha.franken.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.