* Ecovec (SH7724) board doesn't work on latest linus tree
@ 2011-06-09 6:21 Kuninori Morimoto
2011-06-09 6:31 ` Paul Mundt
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: Kuninori Morimoto @ 2011-06-09 6:21 UTC (permalink / raw)
To: linux-sh
Dear Paul
Ecovec (SH7724) board doesn't work on latest linus tree.
But if I revert below patch, it works.
I attached kernel dead log
--- I reverted this patch from linus/master -----
commit 3f9b8520b06013939ad247ba08b69529b5f14be1
Author: Paul Mundt <lethal@linux-sh.org>
Date: Tue May 31 14:38:29 2011 +0900
sh64: Move from P1SEG to CAC_ADDR for consistent sync.
sh64 doesn't define a P1SEGADDR, resulting in a build failure. The proper
mapping can be attained for both sh32 and 64 via the CAC_ADDR macro, so
switch to that instead.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
------- kernel dead log ----------
...
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: SH7724
Performance Events: sh4a support registered
NET: Registered protocol family 16
vpu: forcing memory chunk size to 0x00800000
Unable to handle kernel paging request at virtual address 6e000000
pc = 8800ef82
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:
Pid : 1, Comm: swapper
CPU : 0 Not tainted (3.0.0-rc2+ #910)
PC is at sh4__flush_purge_region+0x30/0x8a
PR is at dma_cache_sync+0x32/0x54
PC : 8800ef82 SP : 8f029eec SR : 40008000 TEA : 6e000000
R0 : 00040000 R1 : 6e000000 R2 : 6e000000 R3 : 00000100
R4 : 00008000 R5 : 000000a0 R6 : 000000c0 R7 : 000000e0
R8 : 00000080 R9 : 0000000b R10 : 8e000000 R11 : 00800000
R12 : 007fffff R13 : 883d3e0e R14 : 8f029eec
MACH: 00000000 MACL: 00000000 GBR : 00000000 PR : 8800e422
Call trace:
[<8800e510>] dma_generic_alloc_coherent+0x54/0x11c
[<883d3e0e>] platform_resource_setup_memory+0xda/0x15c
[<88138cd4>] strstr+0x0/0x6c
[<882882ee>] _raw_spin_unlock_irqrestore+0x1e/0x58
[<883d2f46>] sh7724_devices_setup+0x16/0x94
[<883d3d34>] platform_resource_setup_memory+0x0/0x15c
[<880020ea>] do_one_initcall+0x9a/0x15c
[<883d2f30>] sh7724_devices_setup+0x0/0x94
[<883d1242>] kernel_init+0x72/0x138
[<88002050>] do_one_initcall+0x0/0x15c
[<88003d34>] kernel_thread_helper+0x8/0x14
[<883d11d0>] kernel_init+0x0/0x138
[<88003d2c>] kernel_thread_helper+0x0/0x14
INFO: lockdep is turned off.
Process: swapper (pid: 1, stack limit = 8f028001)
Stack: (0x8f029eec to 0x8f02a000)
9ee0: 8f029ef8 0000000b 80000000 8800e510 8f029f00
9f00: 00000004 8f029f2c 883d3e0e 8f029f28 88138cd4 8839b040 8f029f2c 00800000
9f20: 8832ec3c 8839dfc4 882882ee 8f029f34 883d2f46 8f029f50 00000000 00000000
9f40: 00000000 883f03cc 00200000 883d3d34 880020ea 8f029f60 883d2f30 883eff48
9f60: 883ac1a0 8f029f68 883d1242 8f029f88 00000000 00000000 00000000 883f03cc
9f80: 88002050 883eff48 88003d34 8f029f9c 00000000 00000000 00000000 00000000
9fa0: 00000000 00000000 00000000 00000000 00000000 00000000 883d11d0 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 8f029fa4 88003d2c 00000000 40008000 00000000 00000000 00000000 00000000
---[ end trace 4eaa2a86a8e2da22 ]---
Kernel panic - not syncing: Attempted to kill init!
Stack: (0x8f029ce0 to 0x8f02a000)
9ce0: 882850c6 8f029cf0 88330b0c 8813b808 88285130 8f029cf8 8f029d20 8f029d00
9d00: 8f029d24 880196d2 8f029d30 00000000 00000000 883ab46c 8f029d14 8f027080
9d20: 8f027080 00000001 88019904 8f0271b4 883f3f0c 8833a328 883a9d6c 88285248
9d40: 00000001 00000000 8f029d48 8f029d48 8f0271b4 88005d6e 8f029d74 00000000
9d60: 00000000 88285248 8832ff18 00000000 8f029e90 8800f574 8f029d8c 00000000
9d80: 88285248 6e000000 8f029e90 8f029d90 00000000 880070f4 8f029dfc 400080f1
9da0: 00000000 8e556000 00000064 00000000 8e555c60 00000000 00000c80 ffe00000
9dc0: 00000800 0000000b 00000555 88285dcc 8f029dec 888ab000 887d6dac 888b5aa0
9de0: 00000555 882856cc 10000000 88058d8e 8f029dfc 0000000b 00000800 8f030060
9e00: 8f027080 00008000 00000000 0000000c 00000000 8f029e1c 00000000 00000000
9e20: 883d037c fffff800 00000000 00000000 883cfff4 00000010 00000000 00000000
9e40: 883cfd14 883cffac 00000000 000280d0 883cfcf8 88058fec 8f029e84 00000000
9e60: 007fffff 883d0378 00000000 0000000b 880070ec 8f029eec 883d3e0e 007fffff
9e80: 00800000 880070ec 880070ec 00000000 00040000 6e000000 6e000000 00000100
9ea0: 00008000 000000a0 000000c0 000000e0 00000080 0000000b 8e000000 00800000
9ec0: 007fffff 883d3e0e 8f029eec 8f029eec 8800ef82 8800e422 40008000 00000000
9ee0: 00000000 00000000 ffffffff 8f029ef8 0000000b 80000000 8800e510 8f029f00
9f00: 00000004 8f029f2c 883d3e0e 8f029f28 88138cd4 8839b040 8f029f2c 00800000
9f20: 8832ec3c 8839dfc4 882882ee 8f029f34 883d2f46 8f029f50 00000000 00000000
9f40: 00000000 883f03cc 00200000 883d3d34 880020ea 8f029f60 883d2f30 883eff48
9f60: 883ac1a0 8f029f68 883d1242 8f029f88 00000000 00000000 00000000 883f03cc
9f80: 88002050 883eff48 88003d34 8f029f9c 00000000 00000000 00000000 00000000
9fa0: 00000000 00000000 00000000 00000000 00000000 00000000 883d11d0 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 8f029fa4 88003d2c 00000000 40008000 00000000 00000000 00000000 00000000
Call trace:
[<882850c6>] dump_stack+0xe/0x1c
[<8813b808>] bust_spinlocks+0x0/0x4c
[<88285130>] panic+0x5c/0x174
[<880196d2>] do_exit+0x6a/0x5cc
[<88019904>] do_exit+0x29c/0x5cc
[<88285248>] printk+0x0/0x30
[<88005d6e>] die+0xf2/0x164
[<88285248>] printk+0x0/0x30
[<8800f574>] do_page_fault+0x29c/0x350
[<88285248>] printk+0x0/0x30
[<880070f4>] ret_from_irq+0x0/0x10
[<88285dcc>] preempt_schedule+0x2c/0x58
[<882856cc>] schedule+0x0/0x480
[<88058d8e>] get_page_from_freelist+0x35a/0x40c
[<88058fec>] __alloc_pages_nodemask+0xbc/0x4c0
[<880070ec>] ret_from_exception+0x0/0x8
[<883d3e0e>] platform_resource_setup_memory+0xda/0x15c
[<880070ec>] ret_from_exception+0x0/0x8
[<880070ec>] ret_from_exception+0x0/0x8
[<883d3e0e>] platform_resource_setup_memory+0xda/0x15c
[<8800ef82>] sh4__flush_purge_region+0x30/0x8a
[<8800e422>] dma_cache_sync+0x32/0x54
[<8800e510>] dma_generic_alloc_coherent+0x54/0x11c
[<883d3e0e>] platform_resource_setup_memory+0xda/0x15c
[<88138cd4>] strstr+0x0/0x6c
[<882882ee>] _raw_spin_unlock_irqrestore+0x1e/0x58
[<883d2f46>] sh7724_devices_setup+0x16/0x94
[<883d3d34>] platform_resource_setup_memory+0x0/0x15c
[<880020ea>] do_one_initcall+0x9a/0x15c
[<883d2f30>] sh7724_devices_setup+0x0/0x94
[<883d1242>] kernel_init+0x72/0x138
[<88002050>] do_one_initcall+0x0/0x15c
[<88003d34>] kernel_thread_helper+0x8/0x14
[<883d11d0>] kernel_init+0x0/0x138
[<88003d2c>] kernel_thread_helper+0x0/0x14
INFO: lockdep is turned off.
Best regards
--
Kuninori Morimoto
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
@ 2011-06-09 6:31 ` Paul Mundt
2011-06-09 6:42 ` Kuninori Morimoto
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Paul Mundt @ 2011-06-09 6:31 UTC (permalink / raw)
To: linux-sh
On Thu, Jun 09, 2011 at 03:21:17PM +0900, Kuninori Morimoto wrote:
> Unable to handle kernel paging request at virtual address 6e000000
> pc = 8800ef82
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in:
>
> Pid : 1, Comm: swapper
> CPU : 0 Not tainted (3.0.0-rc2+ #910)
>
> PC is at sh4__flush_purge_region+0x30/0x8a
> PR is at dma_cache_sync+0x32/0x54
Grr. Can you try with the following debug patch?
---
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index f251b5f..01bb4ee 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -84,6 +84,10 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
addr = __in_29bit_mode() ?
(void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
+ printk_once("%s: vaddr %p, CAC %08lx, P1SEG %08lx\n", __func__, vaddr,
+ CAC_ADDR((unsigned long)vaddr),
+ P1SEGADDR((unsigned long)vaddr));
+
switch (direction) {
case DMA_FROM_DEVICE: /* invalidate only */
__flush_invalidate_region(addr, size);
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
2011-06-09 6:31 ` Paul Mundt
@ 2011-06-09 6:42 ` Kuninori Morimoto
2011-07-05 7:52 ` kuninori.morimoto.gx
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Kuninori Morimoto @ 2011-06-09 6:42 UTC (permalink / raw)
To: linux-sh
Dear Paul
> Grr. Can you try with the following debug patch?
(snip)
> + printk_once("%s: vaddr %p, CAC %08lx, P1SEG %08lx\n", __func__, vaddr,
> + CAC_ADDR((unsigned long)vaddr),
> + P1SEGADDR((unsigned long)vaddr));
> +
It say
dma_cache_sync: vaddr 8e000000, CAC 6e000000, P1SEG 8e000000
Best regards
--
Kuninori Morimoto
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
2011-06-09 6:31 ` Paul Mundt
2011-06-09 6:42 ` Kuninori Morimoto
@ 2011-07-05 7:52 ` kuninori.morimoto.gx
2011-08-31 15:07 ` Yutaro Ebihara
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kuninori.morimoto.gx @ 2011-07-05 7:52 UTC (permalink / raw)
To: linux-sh
Dear Paul
Ecovec board still doesn't work on latest linus tree.
Because of below commit.
----------------
commit 3f9b8520b06013939ad247ba08b69529b5f14be1
Author: Paul Mundt <lethal@linux-sh.org>
Date: Tue May 31 14:38:29 2011 +0900
sh64: Move from P1SEG to CAC_ADDR for consistent sync.
sh64 doesn't define a P1SEGADDR, resulting in a build failure. The proper
mapping can be attained for both sh32 and 64 via the CAC_ADDR macro, so
switch to that instead.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
----------------
The output of below patch was
dma_cache_sync: vaddr 8e000000, CAC 6e000000, P1SEG 8e000000
------
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index f251b5f..01bb4ee 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -84,6 +84,10 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
addr = __in_29bit_mode() ?
(void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
+ printk_once("%s: vaddr %p, CAC %08lx, P1SEG %08lx\n", __func__, vaddr,
+ CAC_ADDR((unsigned long)vaddr),
+ P1SEGADDR((unsigned long)vaddr));
+
switch (direction) {
case DMA_FROM_DEVICE: /* invalidate only */
__flush_invalidate_region(addr, size);
Best regards
---
Kuninori Morimoto
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (2 preceding siblings ...)
2011-07-05 7:52 ` kuninori.morimoto.gx
@ 2011-08-31 15:07 ` Yutaro Ebihara
2011-09-01 1:28 ` Kuninori Morimoto
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Yutaro Ebihara @ 2011-08-31 15:07 UTC (permalink / raw)
To: linux-sh
hello.
i think you can run linux-3.0.4 kernel on your Ecovec (SH7724) board
in this debug-code.
void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction direction)
{
void *addr;
addr = __in_29bit_mode() ?
- (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
+ (void *)P1SEGADDR((unsigned long)vaddr) : vaddr;
CAC_ADDR((unsigned long)vaddr) : vaddr;
must be fail.
>@@ -84,6 +84,10 @@ void dma_cache_sync(struct device *dev, void *vaddr,
>size_t size,
> addr = __in_29bit_mode() ?
> (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
>
>Dear Paul
>
>Ecovec board still doesn't work on latest linus tree.
>Because of below commit.
>
>----------------
>commit 3f9b8520b06013939ad247ba08b69529b5f14be1
>Author: Paul Mundt <lethal@linux-sh.org>
>Date: Tue May 31 14:38:29 2011 +0900
>
> sh64: Move from P1SEG to CAC_ADDR for consistent sync.
>
> sh64 doesn't define a P1SEGADDR, resulting in a build failure. The proper
> mapping can be attained for both sh32 and 64 via the CAC_ADDR macro, so
> switch to that instead.
>
> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
>----------------
>
>The output of below patch was
>
>dma_cache_sync: vaddr 8e000000, CAC 6e000000, P1SEG 8e000000
>
>------
>diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
>index f251b5f..01bb4ee 100644
>--- a/arch/sh/mm/consistent.c
>+++ b/arch/sh/mm/consistent.c
>@@ -84,6 +84,10 @@ void dma_cache_sync(struct device *dev, void *vaddr,
>size_t size,
> addr = __in_29bit_mode() ?
> (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
>
>+ printk_once("%s: vaddr %p, CAC %08lx, P1SEG %08lx\n", __func__, vaddr,
>+ CAC_ADDR((unsigned long)vaddr),
>+ P1SEGADDR((unsigned long)vaddr));
>+
> switch (direction) {
> case DMA_FROM_DEVICE: /* invalidate only */
> __flush_invalidate_region(addr, size);
>
>
>Best regards
>---
>Kuninori Morimoto
>--
>To unsubscribe from this list: send the line "unsubscribe linux-sh" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (3 preceding siblings ...)
2011-08-31 15:07 ` Yutaro Ebihara
@ 2011-09-01 1:28 ` Kuninori Morimoto
2011-09-01 1:45 ` Kuninori Morimoto
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Kuninori Morimoto @ 2011-09-01 1:28 UTC (permalink / raw)
To: linux-sh
Hi Ebihara-san, and Paul
Thank you for your report.
> i think you can run linux-3.0.4 kernel on your Ecovec (SH7724) board
> in this debug-code.
>
>
> void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
> enum dma_data_direction direction)
> {
> void *addr;
>
> addr = __in_29bit_mode() ?
> - (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
> + (void *)P1SEGADDR((unsigned long)vaddr) : vaddr;
Paul
I guess your patch tried to share code for sh32/sh64.
and CAC_ADDR() should be equal P1SEGADDR(), correct ?
I'm not filmier with memory control, but
on Ecovec case, 1st (and crash case) dma_cache_sync() caller is
${LINUX}/arch/sh/mm/consistent.c :: dma_generic_alloc_coherent()
it tried
ret = (void *)__get_free_pages(gfp, order);
(snip)
dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
This "ret" is "8e000000" for now.
but CAC_ADDR(xx)/P1SEGADDR(xx) is defined as below
CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
P1SEGADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | P1SEG))
I guess this "ret" should be uncached area if dma_cache_sync(xx) use CAC_ADDR(xx).
If I apply below patch, Ecovec start works without crash, but I'm not sure.
Is this correct patch ?
--------------------
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index f251b5f..198234a 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -48,7 +48,7 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t si
* Pages from the page allocator may have data present in
* cache. So flush the cache before using uncached memory.
*/
- dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
+ dma_cache_sync(dev, UNCAC_ADDR(ret), size, DMA_BIDIRECTIONAL);
ret_nocache = (void __force *)ioremap_nocache(virt_to_phys(ret), size);
if (!ret_nocache) {
-------------------------
But I'm afraid below comment of dma_generic_alloc_coherent()
/*
* Pages from the page allocator may have data present in
* cache. So flush the cache before using uncached memory.
*/
dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
Best regards
---
Kuninori Morimoto
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (4 preceding siblings ...)
2011-09-01 1:28 ` Kuninori Morimoto
@ 2011-09-01 1:45 ` Kuninori Morimoto
2011-09-08 8:52 ` Nobuhiro Iwamatsu
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Kuninori Morimoto @ 2011-09-01 1:45 UTC (permalink / raw)
To: linux-sh
Hi Paul
> I guess your patch tried to share code for sh32/sh64.
> and CAC_ADDR() should be equal P1SEGADDR(), correct ?
>
> I'm not filmier with memory control, but
> on Ecovec case, 1st (and crash case) dma_cache_sync() caller is
> ${LINUX}/arch/sh/mm/consistent.c :: dma_generic_alloc_coherent()
>
> it tried
>
> ret = (void *)__get_free_pages(gfp, order);
> (snip)
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
>
> This "ret" is "8e000000" for now.
>
> but CAC_ADDR(xx)/P1SEGADDR(xx) is defined as below
>
> CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
> P1SEGADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | P1SEG))
>
> I guess this "ret" should be uncached area if dma_cache_sync(xx) use CAC_ADDR(xx).
>
> If I apply below patch, Ecovec start works without crash, but I'm not sure.
> Is this correct patch ?
>
> --------------------
> diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
> index f251b5f..198234a 100644
> --- a/arch/sh/mm/consistent.c
> +++ b/arch/sh/mm/consistent.c
> @@ -48,7 +48,7 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t si
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> - dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
> + dma_cache_sync(dev, UNCAC_ADDR(ret), size, DMA_BIDIRECTIONAL);
>
> ret_nocache = (void __force *)ioremap_nocache(virt_to_phys(ret), size);
> if (!ret_nocache) {
> -------------------------
>
> But I'm afraid below comment of dma_generic_alloc_coherent()
>
> /*
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
dma_cache_sync(xx) should not expect vaddr is in uncached area ?
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (5 preceding siblings ...)
2011-09-01 1:45 ` Kuninori Morimoto
@ 2011-09-08 8:52 ` Nobuhiro Iwamatsu
2011-09-20 0:54 ` Paul Mundt
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Nobuhiro Iwamatsu @ 2011-09-08 8:52 UTC (permalink / raw)
To: linux-sh
Hi,
Your patch does not seem to have a meaning.
In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
to easily revise this.
I attached my patch.
Best regards,
Nobuhiro
From b1f83e75a2dc5a61671d18e8f472450561c9eea7 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Thu, 8 Sep 2011 17:37:24 +0900
Subject: [PATCH] sh: Fix address calculation of CAC_ADDR and
UNCAC_ADDR in 29bit mode
In the case of 29bit mode, CAC/UNCAC_ADDR does not return a right address.
This revises this problem by using P1SEGADDR and P2SEGADDR in 29bit mode.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
arch/sh/include/asm/page.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/sh/include/asm/page.h b/arch/sh/include/asm/page.h
index 822d608..abcc4dc 100644
--- a/arch/sh/include/asm/page.h
+++ b/arch/sh/include/asm/page.h
@@ -141,8 +141,13 @@ typedef struct page *pgtable_t;
#endif /* !__ASSEMBLY__ */
#ifdef CONFIG_UNCACHED_MAPPING
+#if defined(CONFIG_29BIT)
+#define UNCAC_ADDR(addr) P2SEGADDR(addr)
+#define CAC_ADDR(addr) P1SEGADDR(addr)
+#else
#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + uncached_start)
#define CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
+#endif
#else
#define UNCAC_ADDR(addr) ((addr))
#define CAC_ADDR(addr) ((addr))
--
1.7.5.4
2011/9/1 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
>
> Hi Ebihara-san, and Paul
>
> Thank you for your report.
>
>> i think you can run linux-3.0.4 kernel on your Ecovec (SH7724) board
>> in this debug-code.
>>
>>
>> void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
>> enum dma_data_direction direction)
>> {
>> void *addr;
>>
>> addr = __in_29bit_mode() ?
>> - (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
>> + (void *)P1SEGADDR((unsigned long)vaddr) : vaddr;
>
> Paul
>
> I guess your patch tried to share code for sh32/sh64.
> and CAC_ADDR() should be equal P1SEGADDR(), correct ?
>
> I'm not filmier with memory control, but
> on Ecovec case, 1st (and crash case) dma_cache_sync() caller is
> ${LINUX}/arch/sh/mm/consistent.c :: dma_generic_alloc_coherent()
>
> it tried
>
> ret = (void *)__get_free_pages(gfp, order);
> (snip)
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
>
> This "ret" is "8e000000" for now.
>
> but CAC_ADDR(xx)/P1SEGADDR(xx) is defined as below
>
> CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
> P1SEGADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | P1SEG))
>
> I guess this "ret" should be uncached area if dma_cache_sync(xx) use CAC_ADDR(xx).
>
> If I apply below patch, Ecovec start works without crash, but I'm not sure.
> Is this correct patch ?
>
> --------------------
> diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
> index f251b5f..198234a 100644
> --- a/arch/sh/mm/consistent.c
> +++ b/arch/sh/mm/consistent.c
> @@ -48,7 +48,7 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t si
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> - dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
> + dma_cache_sync(dev, UNCAC_ADDR(ret), size, DMA_BIDIRECTIONAL);
>
> ret_nocache = (void __force *)ioremap_nocache(virt_to_phys(ret), size);
> if (!ret_nocache) {
> -------------------------
>
> But I'm afraid below comment of dma_generic_alloc_coherent()
>
> /*
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
>
>
> Best regards
> ---
> Kuninori Morimoto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Nobuhiro Iwamatsu
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (6 preceding siblings ...)
2011-09-08 8:52 ` Nobuhiro Iwamatsu
@ 2011-09-20 0:54 ` Paul Mundt
2011-09-20 2:08 ` Kuninori Morimoto
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Paul Mundt @ 2011-09-20 0:54 UTC (permalink / raw)
To: linux-sh
On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> Your patch does not seem to have a meaning.
> In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
> I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
> to easily revise this.
> I attached my patch.
>
Morimoto-san, does this fix your issue? If you can provide your Tested-by
for this then I'll queue it up and get it off to Linus.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (7 preceding siblings ...)
2011-09-20 0:54 ` Paul Mundt
@ 2011-09-20 2:08 ` Kuninori Morimoto
2011-09-20 3:10 ` Paul Mundt
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Kuninori Morimoto @ 2011-09-20 2:08 UTC (permalink / raw)
To: linux-sh
Hi Paul, Iwamatsu-san
> On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > Your patch does not seem to have a meaning.
> > In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
> > I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
> > to easily revise this.
> > I attached my patch.
> >
> Morimoto-san, does this fix your issue? If you can provide your Tested-by
> for this then I'll queue it up and get it off to Linus.
Thank you.
I tested this patch on linus/master.
And this patch solved Ecovec board boot issue.
# I tested it on mackerel (SH7372) board too.
# It works well
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Best regards
---
Kuninori Morimoto
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (8 preceding siblings ...)
2011-09-20 2:08 ` Kuninori Morimoto
@ 2011-09-20 3:10 ` Paul Mundt
2011-10-04 23:16 ` Simon Horman
2011-11-04 13:23 ` Paul Mundt
11 siblings, 0 replies; 13+ messages in thread
From: Paul Mundt @ 2011-09-20 3:10 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 19, 2011 at 07:08:18PM -0700, Kuninori Morimoto wrote:
> > On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > > Your patch does not seem to have a meaning.
> > > In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
> > > I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
> > > to easily revise this.
> > > I attached my patch.
> > >
> > Morimoto-san, does this fix your issue? If you can provide your Tested-by
> > for this then I'll queue it up and get it off to Linus.
>
> Thank you.
>
> I tested this patch on linus/master.
> And this patch solved Ecovec board boot issue.
>
> # I tested it on mackerel (SH7372) board too.
> # It works well
>
> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Great, I'll queue it up, thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (9 preceding siblings ...)
2011-09-20 3:10 ` Paul Mundt
@ 2011-10-04 23:16 ` Simon Horman
2011-11-04 13:23 ` Paul Mundt
11 siblings, 0 replies; 13+ messages in thread
From: Simon Horman @ 2011-10-04 23:16 UTC (permalink / raw)
To: linux-sh
On Mon, Sep 19, 2011 at 07:08:18PM -0700, Kuninori Morimoto wrote:
>
> Hi Paul, Iwamatsu-san
>
> > On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > > Your patch does not seem to have a meaning.
> > > In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
> > > I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
> > > to easily revise this.
> > > I attached my patch.
> > >
> > Morimoto-san, does this fix your issue? If you can provide your Tested-by
> > for this then I'll queue it up and get it off to Linus.
>
> Thank you.
>
> I tested this patch on linus/master.
> And this patch solved Ecovec board boot issue.
>
> # I tested it on mackerel (SH7372) board too.
> # It works well
>
> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
FWIW, this resolved a failure to boot on Ecovec for me too.
Tested-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
` (10 preceding siblings ...)
2011-10-04 23:16 ` Simon Horman
@ 2011-11-04 13:23 ` Paul Mundt
11 siblings, 0 replies; 13+ messages in thread
From: Paul Mundt @ 2011-11-04 13:23 UTC (permalink / raw)
To: linux-sh
On Wed, Oct 05, 2011 at 08:16:10AM +0900, Simon Horman wrote:
> On Mon, Sep 19, 2011 at 07:08:18PM -0700, Kuninori Morimoto wrote:
> >
> > Hi Paul, Iwamatsu-san
> >
> > > On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > > > Your patch does not seem to have a meaning.
> > > > In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
> > > > I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
> > > > to easily revise this.
> > > > I attached my patch.
> > > >
> > > Morimoto-san, does this fix your issue? If you can provide your Tested-by
> > > for this then I'll queue it up and get it off to Linus.
> >
> > Thank you.
> >
> > I tested this patch on linus/master.
> > And this patch solved Ecovec board boot issue.
> >
> > # I tested it on mackerel (SH7372) board too.
> > # It works well
> >
> > Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> FWIW, this resolved a failure to boot on Ecovec for me too.
>
> Tested-by: Simon Horman <horms@verge.net.au>
Seem to have somehow missed this one, too. Applied now, thanks everyone.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-11-04 13:23 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-09 6:21 Ecovec (SH7724) board doesn't work on latest linus tree Kuninori Morimoto
2011-06-09 6:31 ` Paul Mundt
2011-06-09 6:42 ` Kuninori Morimoto
2011-07-05 7:52 ` kuninori.morimoto.gx
2011-08-31 15:07 ` Yutaro Ebihara
2011-09-01 1:28 ` Kuninori Morimoto
2011-09-01 1:45 ` Kuninori Morimoto
2011-09-08 8:52 ` Nobuhiro Iwamatsu
2011-09-20 0:54 ` Paul Mundt
2011-09-20 2:08 ` Kuninori Morimoto
2011-09-20 3:10 ` Paul Mundt
2011-10-04 23:16 ` Simon Horman
2011-11-04 13:23 ` Paul Mundt
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.