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 1/3 v3] ARM Realview PCIX map include file changes
Date: Thu, 6 Oct 2011 17:57:59 +0200	[thread overview]
Message-ID: <201110061757.59232.arnd@arndb.de> (raw)
In-Reply-To: <F01D8B85CFF58440B2A13965FBA90CA47375AC17BD@GEORGE.Emea.Arm.com>

On Thursday 06 October 2011, Colin Tuckley wrote:
> Ah, that wasn't clear from the original email - I was making the changes incrementally and testing as I went.
> 
> > This is how it works:
> >
> > 1. The PCI IO window is supposed to be 64K in size.
> 
> Yes, that bit was obvious after a bit of thought. I suspect the original value was just a cut 'n paste error.
> 
> > 2. "pcibios_min_io" sets the minimum offset into the PCI IO window
> > which
> >    PCI IO BARs should be assigned.  It is assumed that a PCI IO BAR
> > value
> >    of 0 corresponds with the virtual base address of this window.
> > 3. inb() et.al. take the PCI IO offset and not the physical address
> > nor the virtual address of the desired access.
> 
> That seems sensible.
> 
> However, after changing both __io() and pcibios_min_io as Arnd suggested
> the boot still hangs after " Uncompressing Linux... done, booting the kernel."

No idea. If you send me the full patch, I'll have a look if I can spot
something odd. I can very much recommend debugging this in qemu,
which should support booting your kernels and provide you a
gdb interface to see what's going on.

I noticed that the original code (without your patch) describes a 4KB
I/O space window. Maybe there is a hardware limitation and you actually
have to set PCIBIOS_MIN_IO to zero and IO_SPACE_LIMIT to 0xFFF.
This would however be a fairly unusual hw quirk.
 
> I did notice that there seems to have been some code changes and
> refactoring in the pci sub-system between 3.1 and 2.6.38 where I 
> was testing before. Are there any significant changes I should be 
> aware of?

Nothing major, no. There are always patches going in there, but
the fundamental bits stay very stable.

	Arnd

  reply	other threads:[~2011-10-06 15:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-22 13:09 [PATCH 0/3 v3] ARM Realview PCIX preparation Colin Tuckley
2011-08-22 13:09 ` [PATCH 1/3 v3] ARM Realview PCIX map include file changes Colin Tuckley
2011-09-05 14:35   ` Arnd Bergmann
2011-09-05 15:06     ` Arnd Bergmann
2011-09-08  9:09     ` Russell King - ARM Linux
2011-09-08 10:06       ` Colin Tuckley
2011-10-06 14:00     ` Colin Tuckley
2011-10-06 14:23       ` Russell King - ARM Linux
2011-10-06 14:50         ` Colin Tuckley
2011-10-06 15:57           ` Arnd Bergmann [this message]
2011-10-07 11:25           ` Catalin Marinas
2011-10-07 12:26             ` Arnd Bergmann
2011-08-22 13:10 ` [PATCH 2/3 v3] ARM Realview PCIX IRQ " Colin Tuckley
2011-08-22 13:10 ` [PATCH 3/3 v3] RM Realview PCIX board " Colin Tuckley

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