Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1283707 > unrolled thread

Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for  DMA_MEMORY_MAP Catalin Marinas <catalin.marinas@arm.com> - 2015-12-04 12:00 +0100
    Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP Dan Williams <dan.j.williams@intel.com> - 2015-12-04 18:00 +0100
      Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for  DMA_MEMORY_MAP Catalin Marinas <catalin.marinas@arm.com> - 2015-12-04 18:20 +0100
        Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for  DMA_MEMORY_MAP Brian Starkey <brian.starkey@arm.com> - 2015-12-07 14:30 +0100
          Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP Dan Williams <dan.j.williams@intel.com> - 2015-12-07 17:20 +0100
            Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for  DMA_MEMORY_MAP Catalin Marinas <catalin.marinas@arm.com> - 2015-12-07 17:50 +0100

#1283707 — Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
> directly should be returned, so use ioremap_wc() instead of ioremap().
> Also, ensure that the correct memset operation is used in
> dma_alloc_from_coherent() with respect to the region's flags.
> 
> This fixes the below alignment fault on arm64, caused by invalid use
> of memset() on Device memory.

This is indeed affecting both arm32 and arm64 systems.

> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
> index 55b8398..45358d0 100644
> --- a/drivers/base/dma-coherent.c
> +++ b/drivers/base/dma-coherent.c
> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
>  	if (!size)
>  		goto out;
>  
> -	mem_base = ioremap(phys_addr, size);
> +	if (flags & DMA_MEMORY_MAP)
> +		mem_base = ioremap_wc(phys_addr, size);
> +	else
> +		mem_base = ioremap(phys_addr, size);

I wonder whether a memremap() approach for the DMA_MEMORY_MAP case would
be better. This API was added recently by commit 92281dee825f ("arch:
introduce memremap()"). It only supports write-back and write-through
but we could add a MEMREMAP_WC flag for this case.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1284018 — Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
>> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
>> directly should be returned, so use ioremap_wc() instead of ioremap().
>> Also, ensure that the correct memset operation is used in
>> dma_alloc_from_coherent() with respect to the region's flags.
>>
>> This fixes the below alignment fault on arm64, caused by invalid use
>> of memset() on Device memory.
>
> This is indeed affecting both arm32 and arm64 systems.
>
>> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>> index 55b8398..45358d0 100644
>> --- a/drivers/base/dma-coherent.c
>> +++ b/drivers/base/dma-coherent.c
>> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
>>       if (!size)
>>               goto out;
>>
>> -     mem_base = ioremap(phys_addr, size);
>> +     if (flags & DMA_MEMORY_MAP)
>> +             mem_base = ioremap_wc(phys_addr, size);
>> +     else
>> +             mem_base = ioremap(phys_addr, size);
>
> I wonder whether a memremap() approach for the DMA_MEMORY_MAP case would
> be better. This API was added recently by commit 92281dee825f ("arch:
> introduce memremap()"). It only supports write-back and write-through
> but we could add a MEMREMAP_WC flag for this case.

I originally included both MEMREMAP_WC and MEMREAMP_UC as potential
flags to this api, but ultimately decided against it.  The memremap()
api is meant for memory that is known to have no i/o side effects.  As
far as I can see WC and UC usages are a muddy mix of "sometimes
there's I/O side effects, but it depends by arch and driver".  In
other words we can't drop the "__iomem" annotation from WC and UC
mappings by default.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1284066

On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote:
> On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
> >> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
> >> directly should be returned, so use ioremap_wc() instead of ioremap().
> >> Also, ensure that the correct memset operation is used in
> >> dma_alloc_from_coherent() with respect to the region's flags.
> >>
> >> This fixes the below alignment fault on arm64, caused by invalid use
> >> of memset() on Device memory.
> >
> > This is indeed affecting both arm32 and arm64 systems.
> >
> >> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
> >> index 55b8398..45358d0 100644
> >> --- a/drivers/base/dma-coherent.c
> >> +++ b/drivers/base/dma-coherent.c
> >> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
> >>       if (!size)
> >>               goto out;
> >>
> >> -     mem_base = ioremap(phys_addr, size);
> >> +     if (flags & DMA_MEMORY_MAP)
> >> +             mem_base = ioremap_wc(phys_addr, size);
> >> +     else
> >> +             mem_base = ioremap(phys_addr, size);
> >
> > I wonder whether a memremap() approach for the DMA_MEMORY_MAP case would
> > be better. This API was added recently by commit 92281dee825f ("arch:
> > introduce memremap()"). It only supports write-back and write-through
> > but we could add a MEMREMAP_WC flag for this case.
> 
> I originally included both MEMREMAP_WC and MEMREAMP_UC as potential
> flags to this api, but ultimately decided against it.  The memremap()
> api is meant for memory that is known to have no i/o side effects.  As
> far as I can see WC and UC usages are a muddy mix of "sometimes
> there's I/O side effects, but it depends by arch and driver".  In
> other words we can't drop the "__iomem" annotation from WC and UC
> mappings by default.

In this context, the dma_declare_coherent_memory(DMA_MEMORY_MAP)
implementation is aimed at normal RAM with no side effects as later
returned by dma_alloc_coherent(). To me it looks like memremap is better
suited here for the DMA_MEMORY_MAP case. As per the
Documentation/DMA-API.txt:

  DMA_MEMORY_MAP - request that the memory returned from
  dma_alloc_coherent() be directly writable.

which means no __iomem. Of course, we still need ioremap for
DMA_MEMORY_IO which is supposed to be written with memcpy_toio() etc.

Which memory type should be used is left to the driver and it should
pass the corresponding DMA_MEMORY_* flag.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1285298

On Fri, Dec 04, 2015 at 05:15:54PM +0000, Catalin Marinas wrote:
>On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote:
>> On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
>> >> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
>> >> directly should be returned, so use ioremap_wc() instead of ioremap().
>> >> Also, ensure that the correct memset operation is used in
>> >> dma_alloc_from_coherent() with respect to the region's flags.
>> >>
>> >> This fixes the below alignment fault on arm64, caused by invalid use
>> >> of memset() on Device memory.
>> >
>> > This is indeed affecting both arm32 and arm64 systems.
>> >
>> >> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>> >> index 55b8398..45358d0 100644
>> >> --- a/drivers/base/dma-coherent.c
>> >> +++ b/drivers/base/dma-coherent.c
>> >> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
>> >>       if (!size)
>> >>               goto out;
>> >>
>> >> -     mem_base = ioremap(phys_addr, size);
>> >> +     if (flags & DMA_MEMORY_MAP)
>> >> +             mem_base = ioremap_wc(phys_addr, size);
>> >> +     else
>> >> +             mem_base = ioremap(phys_addr, size);
>> >
>> > I wonder whether a memremap() approach for the DMA_MEMORY_MAP case would
>> > be better. This API was added recently by commit 92281dee825f ("arch:
>> > introduce memremap()"). It only supports write-back and write-through
>> > but we could add a MEMREMAP_WC flag for this case.
>>
>> I originally included both MEMREMAP_WC and MEMREAMP_UC as potential
>> flags to this api, but ultimately decided against it.  The memremap()
>> api is meant for memory that is known to have no i/o side effects.  As
>> far as I can see WC and UC usages are a muddy mix of "sometimes
>> there's I/O side effects, but it depends by arch and driver".  In
>> other words we can't drop the "__iomem" annotation from WC and UC
>> mappings by default.

The DMA_MEMORY_MAP flag is pretty much a statement of "no side-
effects", so as Catalin says it would fit OK here. That said, if it's
not possible to deprecate ioremap_wc() in the same way as
ioremap_cache() then I wonder if there's even much benefit in adding
it to memremap().

>
>In this context, the dma_declare_coherent_memory(DMA_MEMORY_MAP)
>implementation is aimed at normal RAM with no side effects as later
>returned by dma_alloc_coherent(). To me it looks like memremap is better
>suited here for the DMA_MEMORY_MAP case. As per the
>Documentation/DMA-API.txt:
>
>  DMA_MEMORY_MAP - request that the memory returned from
>  dma_alloc_coherent() be directly writable.
>
>which means no __iomem. Of course, we still need ioremap for
>DMA_MEMORY_IO which is supposed to be written with memcpy_toio() etc.
>
>Which memory type should be used is left to the driver and it should
>pass the corresponding DMA_MEMORY_* flag.
>

This can still be achieved without adding _WC to memremap(). I can
look at adding _WC to memremap() if that's deemed the preferred
approach, but if that isn't clear-cut, then it would be nice to get
this bug fixed now and worry about adding it to memremap() later.

-Brian

>-- Catalin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1285760 — Re: [PATCH] drivers: dma-coherent: use ioremap_wc() for DMA_MEMORY_MAP

On Mon, Dec 7, 2015 at 5:28 AM, Brian Starkey <brian.starkey@arm.com> wrote:
> On Fri, Dec 04, 2015 at 05:15:54PM +0000, Catalin Marinas wrote:
>>
>> On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote:
>>>
>>> On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.marinas@arm.com>
>>> wrote:
>>> > On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
>>> >> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
>>> >> directly should be returned, so use ioremap_wc() instead of ioremap().
>>> >> Also, ensure that the correct memset operation is used in
>>> >> dma_alloc_from_coherent() with respect to the region's flags.
>>> >>
>>> >> This fixes the below alignment fault on arm64, caused by invalid use
>>> >> of memset() on Device memory.
>>> >
>>> > This is indeed affecting both arm32 and arm64 systems.
>>> >
>>> >> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
>>> >> index 55b8398..45358d0 100644
>>> >> --- a/drivers/base/dma-coherent.c
>>> >> +++ b/drivers/base/dma-coherent.c
>>> >> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t
>>> >> phys_addr, dma_addr_t device_add
>>> >>       if (!size)
>>> >>               goto out;
>>> >>
>>> >> -     mem_base = ioremap(phys_addr, size);
>>> >> +     if (flags & DMA_MEMORY_MAP)
>>> >> +             mem_base = ioremap_wc(phys_addr, size);
>>> >> +     else
>>> >> +             mem_base = ioremap(phys_addr, size);
>>> >
>>> > I wonder whether a memremap() approach for the DMA_MEMORY_MAP case
>>> > would
>>> > be better. This API was added recently by commit 92281dee825f ("arch:
>>> > introduce memremap()"). It only supports write-back and write-through
>>> > but we could add a MEMREMAP_WC flag for this case.
>>>
>>> I originally included both MEMREMAP_WC and MEMREAMP_UC as potential
>>> flags to this api, but ultimately decided against it.  The memremap()
>>> api is meant for memory that is known to have no i/o side effects.  As
>>> far as I can see WC and UC usages are a muddy mix of "sometimes
>>> there's I/O side effects, but it depends by arch and driver".  In
>>> other words we can't drop the "__iomem" annotation from WC and UC
>>> mappings by default.
>
>
> The DMA_MEMORY_MAP flag is pretty much a statement of "no side-
> effects", so as Catalin says it would fit OK here. That said, if it's
> not possible to deprecate ioremap_wc() in the same way as
> ioremap_cache() then I wonder if there's even much benefit in adding
> it to memremap().

I don't see a problem adding a _WC option to memremap.

The only difference is that it can't replace ioremap_wc.  I.e. unlike
_WB, and _WT case where ioremap_cache and ioremap_wt are now
deprecated we'd have ioremap_wc continuing to live alongside
memremap(..., MEMREMAP_WC).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1285794

On Mon, Dec 07, 2015 at 08:19:27AM -0800, Dan Williams wrote:
> On Mon, Dec 7, 2015 at 5:28 AM, Brian Starkey <brian.starkey@arm.com> wrote:
> > On Fri, Dec 04, 2015 at 05:15:54PM +0000, Catalin Marinas wrote:
> >>
> >> On Fri, Dec 04, 2015 at 08:59:10AM -0800, Dan Williams wrote:
> >>>
> >>> On Fri, Dec 4, 2015 at 2:50 AM, Catalin Marinas <catalin.marinas@arm.com>
> >>> wrote:
> >>> > On Fri, Nov 20, 2015 at 02:20:26PM +0000, Brian Starkey wrote:
> >>> >> When the DMA_MEMORY_MAP flag is used, memory which can be accessed
> >>> >> directly should be returned, so use ioremap_wc() instead of ioremap().
> >>> >> Also, ensure that the correct memset operation is used in
> >>> >> dma_alloc_from_coherent() with respect to the region's flags.
> >>> >>
> >>> >> This fixes the below alignment fault on arm64, caused by invalid use
> >>> >> of memset() on Device memory.
> >>> >
> >>> > This is indeed affecting both arm32 and arm64 systems.
> >>> >
> >>> >> diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
> >>> >> index 55b8398..45358d0 100644
> >>> >> --- a/drivers/base/dma-coherent.c
> >>> >> +++ b/drivers/base/dma-coherent.c
> >>> >> @@ -31,7 +31,10 @@ static int dma_init_coherent_memory(phys_addr_t
> >>> >> phys_addr, dma_addr_t device_add
> >>> >>       if (!size)
> >>> >>               goto out;
> >>> >>
> >>> >> -     mem_base = ioremap(phys_addr, size);
> >>> >> +     if (flags & DMA_MEMORY_MAP)
> >>> >> +             mem_base = ioremap_wc(phys_addr, size);
> >>> >> +     else
> >>> >> +             mem_base = ioremap(phys_addr, size);
> >>> >
> >>> > I wonder whether a memremap() approach for the DMA_MEMORY_MAP case
> >>> > would
> >>> > be better. This API was added recently by commit 92281dee825f ("arch:
> >>> > introduce memremap()"). It only supports write-back and write-through
> >>> > but we could add a MEMREMAP_WC flag for this case.
> >>>
> >>> I originally included both MEMREMAP_WC and MEMREAMP_UC as potential
> >>> flags to this api, but ultimately decided against it.  The memremap()
> >>> api is meant for memory that is known to have no i/o side effects.  As
> >>> far as I can see WC and UC usages are a muddy mix of "sometimes
> >>> there's I/O side effects, but it depends by arch and driver".  In
> >>> other words we can't drop the "__iomem" annotation from WC and UC
> >>> mappings by default.
> >
> >
> > The DMA_MEMORY_MAP flag is pretty much a statement of "no side-
> > effects", so as Catalin says it would fit OK here. That said, if it's
> > not possible to deprecate ioremap_wc() in the same way as
> > ioremap_cache() then I wonder if there's even much benefit in adding
> > it to memremap().
> 
> I don't see a problem adding a _WC option to memremap.
> 
> The only difference is that it can't replace ioremap_wc.  I.e. unlike
> _WB, and _WT case where ioremap_cache and ioremap_wt are now
> deprecated we'd have ioremap_wc continuing to live alongside
> memremap(..., MEMREMAP_WC).

I think that's fine. The difference is that memory returned by
ioremap_wc() should (in theory) only be accessed with I/O accessors
while the range returned by memremap(MEMREMAP_WC) will be directly
accessible.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web