From: iamjoonsoo.kim@lge.com (Joonsoo Kim)
To: linux-arm-kernel@lists.infradead.org
Subject: n900 in next-20170901
Date: Tue, 7 Nov 2017 14:33:14 +0900 [thread overview]
Message-ID: <20171107053313.GA12447@js1304-P5Q-DELUXE> (raw)
In-Reply-To: <20171026141627.GD21504@atomide.com>
Hello,
Sorry for dealy. I was on vacation during last week.
On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim <iamjoonsoo.kim@lge.com> [171025 21:45]:
> > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote:
> > > Great, this branch boots on n900! Early parts of the dmesg attached
> > > below.
> >
> > Sound good. Perhaps, problem is due to the cache management. With my
> > patchset, direct mapping for CMA area is cleared in
> > dma_contiguous_remap() if CONFIG_HIGHMEM. I guess that proper cache
> > operation is required there.
> >
> > Could you test my newly updated branch again? I re-enable
> > dma_contiguous_remap() to clear direct mapping for CMA area and add
> > proper(?) cache operation although I'm not the expert on that area.
> >
> > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901
>
> Yeah that one boots too, dmesg below. I wonder why flushing the range
> with dmac_flush_range() and outer_flush_range() no longer seems enough
> though?
I don't know the reason. AFAIK, it should be enough to flush cpu cache
before clearing page table entry, however, it doesn't work for n900.
flush_cache_all() has not only d-cache flushing but also i-cache
flushing. So, I'd like to test effect of i-cache flushing.
Could you test follwing updated branch?
https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901
It has three relevant commits on top and enables CMA memory use.
"arm/dma: remove i-cache flush"
"arm/dma: flush i-cache and d-cache separately"
"arm/dma: call flush_cache_all() and don't do outer cache operation"
I think that flush_cache_all() here looks fine because size of CMA
area is usually large enough to use flush_cache_all() but
understanding root cause would be important so I ask this test. If u
don't mind, please test each commit with reverting one by one and let
me know the result of each test.
> Reverting the arch/arm/mm/dma-mapping.c changes in your patch
> "arm/dma: re-enable to remap the CMA area and flush cache before
> remapping" also boots, but produces the following build warnings:
>
> arch/arm/mm/dma-mapping.c: In function 'dma_contiguous_remap':
> arch/arm/mm/dma-mapping.c:503:20: warning: passing argument 1 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);
> ^~~
> arch/arm/mm/dma-mapping.c:503:20: note: expected 'const void *' but
> argument is of type 'long unsigned int'
> arch/arm/mm/dma-mapping.c:503:33: warning: passing argument 2 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);
Thanks for info.
I think that incorrect type would not be related to this problem.
Thanks.
next prev parent reply other threads:[~2017-11-07 5:33 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-03 20:37 n900 in next-20170901 Pavel Machek
2017-09-05 20:13 ` Tony Lindgren
2017-09-05 20:27 ` Vlastimil Babka
2017-09-05 20:32 ` Tony Lindgren
2017-09-05 23:32 ` Joonsoo Kim
2017-09-06 13:30 ` Tony Lindgren
2017-09-07 7:30 ` Joonsoo Kim
2017-09-07 16:16 ` Tony Lindgren
2017-09-13 7:55 ` Joonsoo Kim
2017-09-13 16:31 ` Tony Lindgren
2017-09-15 6:56 ` Joonsoo Kim
2017-09-21 17:28 ` Tony Lindgren
2017-09-25 8:08 ` Joonsoo Kim
2017-09-25 14:54 ` Tony Lindgren
2017-10-18 8:29 ` Joonsoo Kim
2017-10-19 18:30 ` Tony Lindgren
2017-10-20 1:55 ` Joonsoo Kim
2017-10-20 17:31 ` Tony Lindgren
2017-10-23 4:53 ` Joonsoo Kim
2017-10-25 17:31 ` Tony Lindgren
2017-10-26 4:48 ` Joonsoo Kim
2017-10-26 14:16 ` Tony Lindgren
2017-11-07 5:33 ` Joonsoo Kim [this message]
2017-11-07 15:48 ` Tony Lindgren
2017-11-08 7:46 ` Joonsoo Kim
2017-11-08 16:34 ` Tony Lindgren
2017-11-09 0:08 ` Joonsoo Kim
2017-11-09 0:11 ` Tony Lindgren
2017-11-09 0:36 ` Joonsoo Kim
2017-11-09 3:50 ` Joonsoo Kim
2017-11-09 15:08 ` Tony Lindgren
2017-11-10 0:13 ` Joonsoo Kim
2017-11-10 3:26 ` Tony Lindgren
2017-11-10 6:19 ` Tony Lindgren
2017-11-10 6:23 ` Tony Lindgren
2017-11-10 6:46 ` Joonsoo Kim
2017-11-10 15:37 ` Tony Lindgren
2017-11-10 6:37 ` Joonsoo Kim
2017-11-10 15:36 ` Tony Lindgren
2017-11-13 21:15 ` Tony Lindgren
2017-11-14 6:40 ` Joonsoo Kim
2017-11-14 6:37 ` Joonsoo Kim
2017-11-14 17:37 ` Tony Lindgren
2017-11-14 19:31 ` Tero Kristo
2017-11-14 19:44 ` Tony Lindgren
2017-11-14 20:01 ` Tero Kristo
2017-11-14 20:54 ` Tony Lindgren
2017-11-15 0:51 ` Joonsoo Kim
2017-11-15 2:04 ` Tony Lindgren
2017-11-15 2:48 ` Joonsoo Kim
2017-11-15 2:53 ` Tony Lindgren
2017-09-15 13:18 ` Pavel Machek
2017-09-18 2:01 ` Joonsoo Kim
2017-09-18 8:11 ` Linux-next broken for 2 weeks was " Pavel Machek
2017-09-18 22:00 ` Stephen Rothwell
2017-09-18 22:16 ` Pavel Machek
2017-09-15 13:28 ` Pali Rohár
2017-09-18 2:07 ` Joonsoo Kim
2017-09-08 9:31 ` Pavel Machek
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=20171107053313.GA12447@js1304-P5Q-DELUXE \
--to=iamjoonsoo.kim@lge.com \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).