linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: Integrator PCI base dilemma
Date: Wed, 20 Mar 2013 18:54:24 -0500	[thread overview]
Message-ID: <514A4C30.9080402@gmail.com> (raw)
In-Reply-To: <CACRpkdaOjFhWR21w5x_rR_60ffQF3Ym_MQd2svNyzm0guwOUoQ@mail.gmail.com>

On 03/20/2013 06:15 PM, Linus Walleij wrote:
> When trying to convert the Integrator/AP to use Device Tree
> for the PCI bridge/hose I run into these two problems:
> 
> - Unable to assign vga_base early since this should be a virtual
>   address assigned really early. If I sacrifice this and try to
>   just remap the stuff, I still run into:

This could be a fixed mapping like we did for the i/o space.

> - Unable to ioremap the PCI memory and config window because
>   it is 16 MiB big. (I guess this is the problem?)
> 
> Part of the code path is called from .map_io() and basically looks
> like this:
> 
> int __init pci_v3_early_init(void)
> {
> 	iotable_init(pci_v3_io_desc, ARRAY_SIZE(pci_v3_io_desc));
> 	vga_base = PCI_MEMORY_VADDR;
> 	pci_map_io_early(__phys_to_pfn(PHYS_PCI_IO_BASE));
> 	return 0;
> }
> 
> The VGA console seems to be the sole user (unsure what
> pci_map_io_early() is for), and we like to support VGA console.

It's for the same problem you have, but for the i/o space.

> 
> The problem is that at this point at iomap the device tree is not yet
> populated.
> 
> We can attempt to do it later but then the kernel hangs when
> I try to remap the two 16MiB chunks for the non-prefetched
> memory and the config window.
> 
> The iomem table looks like this:
> 
> /*
>  * Static mappings for the PCIv3 bridge
>  *
>  * e8000000	40000000	PCI memory		PHYS_PCI_MEM_BASE	(max 512M)
>  * ec000000	61000000	PCI config space	PHYS_PCI_CONFIG_BASE	(max 16M)
>  * fee00000	60000000	PCI IO			PHYS_PCI_IO_BASE	(max 16M)
>  */
> static struct map_desc pci_v3_io_desc[] __initdata __maybe_unused = {
> 	{
> 		.virtual	= (unsigned long)PCI_MEMORY_VADDR,
> 		.pfn		= __phys_to_pfn(PHYS_PCI_MEM_BASE),
> 		.length		= SZ_16M,
> 		.type		= MT_DEVICE
> 	}, {
> 		.virtual	= (unsigned long)PCI_CONFIG_VADDR,
> 		.pfn		= __phys_to_pfn(PHYS_PCI_CONFIG_BASE),
> 		.length		= SZ_16M,
> 		.type		= MT_DEVICE
> 	}
> };
> 
> Does anyone have any hints on how to get out of this need to have the
> base addresses so early?

Wouldn't the drivers' ioremap create a mapping with the the memory
space? The only user of this mapping may be VGA.

For the config space, how much do you really need? You could ioremap
this on demand. I think this issue came up before on another platform
where the config space was very sparsely accessed.

Rob

  reply	other threads:[~2013-03-20 23:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 23:15 Integrator PCI base dilemma Linus Walleij
2013-03-20 23:54 ` Rob Herring [this message]
2013-03-21  9:16   ` Linus Walleij
2013-03-21 13:22     ` Rob Herring
2013-03-21 16:17       ` Arnd Bergmann
2013-03-22 11:05       ` Russell King - ARM Linux
2013-03-21 13:02 ` Arnd Bergmann
2013-03-21 23:40   ` Russell King - ARM Linux
2013-03-22  9:48     ` Arnd Bergmann
2013-03-22 10:37       ` Russell King - ARM Linux
2013-03-22 11:52         ` Arnd Bergmann
2013-03-22 12:12           ` Russell King - ARM Linux
2013-03-22 12:34             ` Arnd Bergmann
2013-03-22 18:33               ` Jason Gunthorpe
2013-03-22 18:35                 ` Russell King - ARM Linux
2013-03-22 19:22         ` Linus Walleij
2013-03-22 20:05           ` Arnd Bergmann
2013-03-22 21:13           ` Wolfgang Denk
2013-03-22 22:35             ` Linus Walleij
2013-03-22 23:48               ` Russell King - ARM Linux
2013-03-23  0:19               ` Wolfgang Denk

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=514A4C30.9080402@gmail.com \
    --to=robherring2@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).