From: Tony Lindgren <tony@atomide.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Eduardo Valentin <edubezval@gmail.com>, linux-omap@vger.kernel.org
Subject: Re: FOR COMMENT: void __iomem * and similar casts are Bad News
Date: Thu, 4 Sep 2008 09:29:19 -0700 [thread overview]
Message-ID: <20080904162917.GR23085@atomide.com> (raw)
In-Reply-To: <20080904161248.GC2309@flint.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [080904 09:13]:
> On Thu, Sep 04, 2008 at 09:10:34AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [080904 02:47]:
> > > On Wed, Sep 03, 2008 at 11:33:51AM -0400, Eduardo Valentin wrote:
> > > > > @@ -159,7 +159,7 @@ static struct omap_mcbsp_platform_data omap730_mcbsp_pdata[] = {
> > > > > #ifdef CONFIG_ARCH_OMAP15XX
> > > > > static struct omap_mcbsp_platform_data omap15xx_mcbsp_pdata[] = {
> > > > > {
> > > > > - .virt_base = OMAP1510_MCBSP1_BASE,
> > > > > + .virt_base = OMAP1510_MCBSP1_BASE, /* FIXME: virtual or physical */
> > > > AFAIK, OMAP1510_MCBSP1_BASE is physical. So, I'd say:
> > > > + .virt_base = IO_ADDRESS(OMAP1510_MCBSP1_BASE),
> > > >
> > > > Because, plat-omap/mcbsp.c expect .virt_base to be a virtual address.
> > >
> > > And today, the story is completely different, having looked through more
> > > of the code and some documentation.
> > >
> > > - OMAPxxxx_MCBSPx_BASE are all physical addresses. Fine.
> > > - physical addresses > 0xfffb0000 are subject to an offset (IO_OFFSET)
> > > but others for the DSP located and DSP shared peripherals aren't.
> > >
> > > So, applying the IO_OFFSET via IO_ADDRESS() or io_p2v() to all addresses
> > > breaks. Meaning it's completely random whether something should be put
> > > through IO_ADDRESS() and similar.
> > >
> > > This isn't obvious. It isn't readable. It isn't maintainable. It doesn't
> > > lend itself to compile time checking.
> >
> > Ouch. Looking at the history of the mcbsp.c the MCBSPX_BASE defines have
> > been a mix of virt and phys addresses to start with.
> >
> > Looks like in the short term we need to define both virt_base and phys_base
> > for omap_mcbsp_platform_data.
> >
> > Then define __arch_ioremap that understands also the DSP mappings and get
> > rid of the remaining hardcoded virtual DSP defines.
> >
> > At that point we can also remove the virt_base from omap_mcbsp_platform_data.
>
> Already done. ;)
That was fast :) Sounds we'll have a patch to test soon.
Tony
next prev parent reply other threads:[~2008-09-04 16:29 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-27 22:08 FOR COMMENT: void __iomem * and similar casts are Bad News Russell King
2008-08-31 21:47 ` David Brownell
2008-09-02 22:15 ` Tony Lindgren
2008-09-03 7:55 ` Russell King - ARM Linux
2008-09-03 16:40 ` Tony Lindgren
2008-09-03 19:34 ` Russell King - ARM Linux
2008-09-03 19:48 ` Tony Lindgren
2008-09-03 21:09 ` David Brownell
2008-09-03 23:02 ` Russell King - ARM Linux
2008-09-03 19:58 ` Woodruff, Richard
2008-09-03 20:30 ` Russell King - ARM Linux
2008-09-03 21:19 ` Woodruff, Richard
2008-09-03 20:32 ` Tony Lindgren
2008-09-03 21:32 ` Woodruff, Richard
2008-09-03 21:35 ` Tony Lindgren
2008-09-03 21:38 ` Russell King - ARM Linux
2008-09-03 21:46 ` Multi-Boot: Was " Woodruff, Richard
2008-09-03 21:18 ` David Brownell
2008-09-03 21:40 ` Woodruff, Richard
2008-09-03 22:05 ` David Brownell
2008-09-03 22:56 ` Russell King - ARM Linux
2008-09-04 0:28 ` Tony Lindgren
2008-09-04 1:06 ` David Brownell
2008-09-04 7:25 ` Arun KS
2008-09-03 15:07 ` Eduardo Valentin
2008-09-03 18:01 ` Tony Lindgren
2008-09-04 0:16 ` David Brownell
2008-09-03 15:33 ` Eduardo Valentin
2008-09-03 18:48 ` Russell King
2008-09-03 19:33 ` Eduardo Valentin
2008-09-03 19:48 ` Russell King - ARM Linux
2008-09-03 20:04 ` Eduardo Valentin
2008-09-03 20:45 ` Russell King - ARM Linux
2008-09-03 20:50 ` Tony Lindgren
2008-09-03 20:56 ` Tony Lindgren
2008-09-03 21:07 ` Russell King - ARM Linux
2008-09-03 21:13 ` Tony Lindgren
2008-09-03 21:00 ` Koen Kooi
2008-09-03 20:37 ` Tony Lindgren
2008-09-03 21:04 ` Russell King - ARM Linux
2008-09-03 21:26 ` Eduardo Valentin
2008-09-03 21:48 ` Tony Lindgren
2008-09-03 21:35 ` David Brownell
2008-09-03 23:16 ` Russell King - ARM Linux
2008-09-04 9:46 ` Russell King - ARM Linux
2008-09-04 16:10 ` Tony Lindgren
2008-09-04 16:12 ` Russell King - ARM Linux
2008-09-04 16:29 ` Tony Lindgren [this message]
2008-09-04 17:07 ` Russell King - ARM Linux
2008-09-04 17:58 ` Tony Lindgren
2008-09-04 21:01 ` Russell King - ARM Linux
2008-09-04 21:20 ` Tony Lindgren
2008-09-05 1:07 ` Tony Lindgren
2008-09-05 5:17 ` Paul Walmsley
2008-09-05 5:58 ` Paul Walmsley
2008-09-29 5:16 ` Arun KS
2008-09-29 7:44 ` Jarkko Nikula
2008-09-29 9:24 ` Arun KS
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=20080904162917.GR23085@atomide.com \
--to=tony@atomide.com \
--cc=edubezval@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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