All of lore.kernel.org
 help / color / mirror / Atom feed
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: Wed, 23 Mar 2011 09:28:18 +0100	[thread overview]
Message-ID: <201103230928.18445.arnd@arndb.de> (raw)
In-Reply-To: <6a4328fcb24af3fa28b2188864875cbecc6f533a.1298977728.git.viresh.kumar@st.com>

On Wednesday 23 March 2011, Viresh Kumar wrote:
> From: Pratyush Anand <pratyush.anand@st.com>
> 
> SPEAr13xx family contains Synopsys designware PCIe version 3.30a. This
> patch adds support for this PCIe module for spear platform.

Looks almost good now, but I still have my doubts about the I/O space handling.
Most importantly, I cannot even see where the I/O space is getting mapped to.
This becomes rather interesting when you have multiple root ports that each
have their own physical I/O space windows, and there are multiple ways it can
be done.

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).

> Changes since V6:
> - Read request size in RC'c PCIE capability is forced to 128 bytes.
> - Max payload is forced to the minimum value of max payload of any of the
>   device in tree.
> - Request_resource for IO Space is from ioport_resource now. Earlier it was from
>   iomem_resource.

This seems like a mistake. The I/O space window resides inside of
iomem_resource, so you have to register it from there.

The ioport_resource refers to ports in the range between 0x1000 and 0x2ffff
that get mapped into that window, so you cannot register the window inside
of itself.

You should probably register both -- add the physical address to iomem_resource,
and register the I/O port range for each PCIe port to ioport_resource.

> 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.

> +#define PCIBIOS_MIN_IO		0

PCIBIOS_MIN_IO should be 0x1000, to make sure that any ISA or PCMCIA
devices behind a bridge cannot interfere with regular PCI or PCIe
devices.

> +/*
> + * 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?

	Arnd

  reply	other threads:[~2011-03-23  8:28 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 [this message]
2011-04-11 12:26     ` pratyush
2011-04-11 15:22       ` Arnd Bergmann
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=201103230928.18445.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.