From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 02/17] SPEAr13xx: Add PCIe host controller base driver support.
Date: Mon, 11 Apr 2011 17:22:18 +0200 [thread overview]
Message-ID: <201104111722.18309.arnd@arndb.de> (raw)
In-Reply-To: <4DA2F36C.3010707@st.com>
On Monday 11 April 2011, pratyush wrote:
> On 3/23/2011 1:58 PM, Arnd Bergmann wrote:
> > On Wednesday 23 March 2011, Viresh Kumar wrote:
> >
> > The way I would recommend is to reserve a part of the system's virtual
> > address space for all I/O windows, and using iotable_init() to map
> > them contiguously. The first port will then be the only one that
> > can hold ISA ranges (needed for legacy VGA mode, for instance).
> >
>
> Sorry, may be I could not get this point correctly. Do you mean that,
> I should create a static mapping for IN0_MEM_SIZE (200 MB) and
> IN_IO_SIZE (20 MB) during board initialization itself?
Only IN_IO_SIZE. The I/O space is implicitly assumed to be mapped, while
the memory space is mapped by device drivers individually.
> >> diff --git a/arch/arm/mach-spear13xx/include/mach/hardware.h b/arch/arm/mach-spear13xx/include/mach/hardware.h
> >> index fd8c2dc..6169d4f 100644
> >> --- a/arch/arm/mach-spear13xx/include/mach/hardware.h
> >> +++ b/arch/arm/mach-spear13xx/include/mach/hardware.h
> >> @@ -28,4 +28,8 @@
> >> /* typesafe io address */
> >> #define __io_address(n) __io(IO_ADDRESS(n))
> >
> > Please reread my previous comments. You have to redefine __io() in order to make
> > the I/O port accesses work. When you do that, you cannot define
> > __io_address (which is used by non-PCI code) as using __io.
> >
>
> __io_address is not used by PICe routines. Also, this is not part of
> this patch.
Yes, that was my point.
> >> +/*
> >> + * In current implementation address translation is done using IN0 only. So IN1
> >> + * start address and IN0 end address has been kept same
> >> +*/
> >> +#define IN1_MEM_SIZE (0 * 1024 * 1024 - 1)
> >> +#define IN_IO_SIZE (20 * 1024 * 1024 - 1)
> >> +#define IN_CFG0_SIZE (1 * 1024 * 1024 - 1)
> >> +#define IN_CFG1_SIZE (1 * 1024 * 1024 - 1)
> >> +#define IN_MSG_SIZE (1 * 1024 * 1024 - 1)
> >
> > Is IN_IO_SIZE per host, or this shared across all hosts?
>
> This is per host. So is it not a practical size?
> What should be a reasonable IO size?
64 KB is more than enough per host. That is the maximum that an x86 PC
can address, so devices usually use very little of this, if anything.
There are some advantages to using 64KB combined for all hosts, but
the easiest way should probably be to reserve 1 MB for the space
and use 64 KB for each of them.
If you have a PCI-ISA bridge chip or a card that has one, it needs to
be on a host that has its I/O space in the first 64 KB.
Arnd
next prev parent reply other threads:[~2011-04-11 15:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1298977728.git.viresh.kumar@st.com>
2011-03-23 4:52 ` [PATCH V7 02/17] SPEAr13xx: Add PCIe host controller base driver support Viresh Kumar
2011-03-23 8:28 ` Arnd Bergmann
2011-04-11 12:26 ` pratyush
2011-04-11 15:22 ` Arnd Bergmann [this message]
2011-04-13 12:11 ` pratyush
2011-04-12 15:32 ` Rob Herring
2011-04-13 12:25 ` pratyush
2011-04-17 20:19 ` Arnd Bergmann
2011-04-27 6:52 ` Pratyush Anand
2011-04-27 9:03 ` Arnd Bergmann
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=201104111722.18309.arnd@arndb.de \
--to=arnd@arndb.de \
--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 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.