All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: jacopo mondi <jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Cc: dalias-8zAoT0mYgF4@public.gmane.org,
	ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org,
	linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
	laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
	Jacopo Mondi
	<jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()
Date: Mon, 09 Apr 2018 11:11:22 +0000	[thread overview]
Message-ID: <7da3f31e-e4ad-7f1a-e66c-0d3e0fb8b27d@arm.com> (raw)
In-Reply-To: <20180409072547.GU20945@w540>

Hi Jacopo,

On 09/04/18 08:25, jacopo mondi wrote:
> Hi Robin, Laurent,
>      a long time passed, sorry about this.
> 
> On Wed, Nov 15, 2017 at 01:38:23PM +0000, Robin Murphy wrote:
>> On 14/11/17 17:08, Jacopo Mondi wrote:
>>> On SH4 architecture, with SPARSEMEM memory model, translating page to
>>> pfn hangs the CPU. Post-pone translation to pfn after
>>> dma_mmap_from_dev_coherent() function call as it succeeds and make page
>>> translation not necessary.
>>>
>>> This patch was suggested by Laurent Pinchart and he's working to submit
>>> a proper fix mainline. Not sending for inclusion at the moment.
>>
>> Y'know, I think this patch does have some merit by itself - until we know
>> that cpu_addr *doesn't* represent some device-private memory which is not
>> guaranteed to be backed by a struct page, calling virt_to_page() on it is
>> arguably semantically incorrect, even if it might happen to be benign in
>> most cases.
> 
> I still need to carry this patch in my trees to have a working dma memory mapping
> on SH4 platforms. My understanding from your comment is that there may
> be a way forward for this patch, do you still think the same? Have you
> got any suggestion on how to improve this eventually for inclusion?

As before, the change itself does seem reasonable; it might be worth 
rewording the commit message in more general terms rather than making it 
sound like an SH-specific workaround (which I really don't think it is), 
but otherwise I'd say just repost it as a non-RFC patch.

Robin.

> 
> Thanks
>     j
> 
>>
>> Robin.
>>
>>> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> ---
>>>   drivers/base/dma-mapping.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>>> index e584edd..73d64d3 100644
>>> --- a/drivers/base/dma-mapping.c
>>> +++ b/drivers/base/dma-mapping.c
>>> @@ -227,8 +227,8 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
>>>   	unsigned long user_count = vma_pages(vma);
>>>   	unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>>> -	unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   	unsigned long off = vma->vm_pgoff;
>>> +	unsigned long pfn;
>>>
>>>   	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>
>>> @@ -236,6 +236,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   		return ret;
>>>
>>>   	if (off < count && user_count <= (count - off)) {
>>> +		pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   		ret = remap_pfn_range(vma, vma->vm_start,
>>>   				      pfn + off,
>>>   				      user_count << PAGE_SHIFT,
>>> --
>>> 2.7.4
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: jacopo mondi <jacopo@jmondi.org>
Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>,
	ysato@users.sourceforge.jp, dalias@libc.org,
	laurent.pinchart@ideasonboard.com, geert@linux-m68k.org,
	linux-renesas-soc@vger.kernel.org,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-sh@vger.kernel.org
Subject: Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()
Date: Mon, 9 Apr 2018 12:11:22 +0100	[thread overview]
Message-ID: <7da3f31e-e4ad-7f1a-e66c-0d3e0fb8b27d@arm.com> (raw)
In-Reply-To: <20180409072547.GU20945@w540>

Hi Jacopo,

On 09/04/18 08:25, jacopo mondi wrote:
> Hi Robin, Laurent,
>      a long time passed, sorry about this.
> 
> On Wed, Nov 15, 2017 at 01:38:23PM +0000, Robin Murphy wrote:
>> On 14/11/17 17:08, Jacopo Mondi wrote:
>>> On SH4 architecture, with SPARSEMEM memory model, translating page to
>>> pfn hangs the CPU. Post-pone translation to pfn after
>>> dma_mmap_from_dev_coherent() function call as it succeeds and make page
>>> translation not necessary.
>>>
>>> This patch was suggested by Laurent Pinchart and he's working to submit
>>> a proper fix mainline. Not sending for inclusion at the moment.
>>
>> Y'know, I think this patch does have some merit by itself - until we know
>> that cpu_addr *doesn't* represent some device-private memory which is not
>> guaranteed to be backed by a struct page, calling virt_to_page() on it is
>> arguably semantically incorrect, even if it might happen to be benign in
>> most cases.
> 
> I still need to carry this patch in my trees to have a working dma memory mapping
> on SH4 platforms. My understanding from your comment is that there may
> be a way forward for this patch, do you still think the same? Have you
> got any suggestion on how to improve this eventually for inclusion?

As before, the change itself does seem reasonable; it might be worth 
rewording the commit message in more general terms rather than making it 
sound like an SH-specific workaround (which I really don't think it is), 
but otherwise I'd say just repost it as a non-RFC patch.

Robin.

> 
> Thanks
>     j
> 
>>
>> Robin.
>>
>>> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>> ---
>>>   drivers/base/dma-mapping.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>>> index e584edd..73d64d3 100644
>>> --- a/drivers/base/dma-mapping.c
>>> +++ b/drivers/base/dma-mapping.c
>>> @@ -227,8 +227,8 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
>>>   	unsigned long user_count = vma_pages(vma);
>>>   	unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>>> -	unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   	unsigned long off = vma->vm_pgoff;
>>> +	unsigned long pfn;
>>>
>>>   	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>
>>> @@ -236,6 +236,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   		return ret;
>>>
>>>   	if (off < count && user_count <= (count - off)) {
>>> +		pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   		ret = remap_pfn_range(vma, vma->vm_start,
>>>   				      pfn + off,
>>>   				      user_count << PAGE_SHIFT,
>>> --
>>> 2.7.4
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu@lists.linux-foundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: jacopo mondi <jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Cc: dalias-8zAoT0mYgF4@public.gmane.org,
	ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org,
	linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
	laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
	Jacopo Mondi
	<jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap()
Date: Mon, 9 Apr 2018 12:11:22 +0100	[thread overview]
Message-ID: <7da3f31e-e4ad-7f1a-e66c-0d3e0fb8b27d@arm.com> (raw)
In-Reply-To: <20180409072547.GU20945@w540>

Hi Jacopo,

On 09/04/18 08:25, jacopo mondi wrote:
> Hi Robin, Laurent,
>      a long time passed, sorry about this.
> 
> On Wed, Nov 15, 2017 at 01:38:23PM +0000, Robin Murphy wrote:
>> On 14/11/17 17:08, Jacopo Mondi wrote:
>>> On SH4 architecture, with SPARSEMEM memory model, translating page to
>>> pfn hangs the CPU. Post-pone translation to pfn after
>>> dma_mmap_from_dev_coherent() function call as it succeeds and make page
>>> translation not necessary.
>>>
>>> This patch was suggested by Laurent Pinchart and he's working to submit
>>> a proper fix mainline. Not sending for inclusion at the moment.
>>
>> Y'know, I think this patch does have some merit by itself - until we know
>> that cpu_addr *doesn't* represent some device-private memory which is not
>> guaranteed to be backed by a struct page, calling virt_to_page() on it is
>> arguably semantically incorrect, even if it might happen to be benign in
>> most cases.
> 
> I still need to carry this patch in my trees to have a working dma memory mapping
> on SH4 platforms. My understanding from your comment is that there may
> be a way forward for this patch, do you still think the same? Have you
> got any suggestion on how to improve this eventually for inclusion?

As before, the change itself does seem reasonable; it might be worth 
rewording the commit message in more general terms rather than making it 
sound like an SH-specific workaround (which I really don't think it is), 
but otherwise I'd say just repost it as a non-RFC patch.

Robin.

> 
> Thanks
>     j
> 
>>
>> Robin.
>>
>>> Suggested-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>> Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
>>> ---
>>>   drivers/base/dma-mapping.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>>> index e584edd..73d64d3 100644
>>> --- a/drivers/base/dma-mapping.c
>>> +++ b/drivers/base/dma-mapping.c
>>> @@ -227,8 +227,8 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   #ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
>>>   	unsigned long user_count = vma_pages(vma);
>>>   	unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
>>> -	unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   	unsigned long off = vma->vm_pgoff;
>>> +	unsigned long pfn;
>>>
>>>   	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>>>
>>> @@ -236,6 +236,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
>>>   		return ret;
>>>
>>>   	if (off < count && user_count <= (count - off)) {
>>> +		pfn = page_to_pfn(virt_to_page(cpu_addr));
>>>   		ret = remap_pfn_range(vma, vma->vm_start,
>>>   				      pfn + off,
>>>   				      user_count << PAGE_SHIFT,
>>> --
>>> 2.7.4
>>>
>>> _______________________________________________
>>> iommu mailing list
>>> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>>

  reply	other threads:[~2018-04-09 11:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-14 17:08 [PATCH v2 0/2] Migo-R: reserve memory block with memblock APIs Jacopo Mondi
2017-11-14 17:08 ` Jacopo Mondi
2017-11-14 17:08 ` [PATCH v2 1/2] sh: migor: Reserve memory block for CEU Jacopo Mondi
2017-11-14 17:08   ` Jacopo Mondi
2017-11-14 17:08 ` [RFC v2 2/2] base: dma-mapping: Postpone page_to_pfn() on mmap() Jacopo Mondi
2017-11-14 17:08   ` Jacopo Mondi
2017-11-15 13:38   ` Robin Murphy
2018-04-09  7:25     ` jacopo mondi
2018-04-09  7:25       ` jacopo mondi
2018-04-09 11:11       ` Robin Murphy [this message]
2018-04-09 11:11         ` Robin Murphy
2018-04-09 11:11         ` Robin Murphy
2018-04-09 13:06         ` Laurent Pinchart
2018-04-09 13:06           ` Laurent Pinchart
2018-04-09 15:11           ` Rich Felker
2018-04-09 15:11             ` Rich Felker
2018-04-09 15:18             ` Laurent Pinchart
2018-04-09 15:18               ` Laurent Pinchart

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=7da3f31e-e4ad-7f1a-e66c-0d3e0fb8b27d@arm.com \
    --to=robin.murphy@arm.com \
    --cc=dalias-8zAoT0mYgF4@public.gmane.org \
    --cc=geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org \
    --cc=jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ysato-Rn4VEauK+AKRv+LV9MX5uooqe+aC9MnS@public.gmane.org \
    /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.