* 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