[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46F8FA5F.3050907@scram.de>
Date: Tue, 25 Sep 2007 14:09:03 +0200
From: Jochen Friedrich <jochen@...am.de>
To: Scott Wood <scottwood@...escale.com>
CC: linuxppc-embedded@...abs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
Hi Scott,
> Yikes. Please don't change cpm_uart_cpm1.h, as it's correct for
> arch/powerpc, and there are numerous other places that assume cpmp is
> virtual (including in the very same function that assigns it a
> physical address).
I'm still not convinced cpm_uart_cpm1.h is correct:
pinfo->rx_bd_base and pinfo->tx_bd_base are both initialized with an
address obtained by cpm_dpram_addr(). In both ppc and powerpc, this is
an address relative to dpram_vbase in commproc.c
In cpm_uart_core.c, the operation "pinfo->rx_bd_base - DPRAM_BASE" is
used to calculate the DPRAM offset. So DPRAM_BASE must be relative to
dpram_vbase in commproc.c as well. However, cpm_uart_cpm1.h uses cpmp in
commproc.c to initialize DPRAM_BASE.
On ARCH=ppc, cpmp is a physical address with 1:1 virtual mapping ("well
known address"). On ARC=powerpc, this is an address obtained by
ioremap(), however it's a different ioremap() call than dpram_vbase is
obtained from, so noone can guarantee
cpmp is always the same as dpram_vbase even on ARCH=powerpc.
To me, it looks like setting DPRAM_BASE to cpm_dpram_addr(0) is the fix
as it makes the DPRAM offset a defined result.
Thanks,
Jochen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists