All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Gary Thomas <gary@mlbassoc.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>, avorontsov@ru.mvista.com
Subject: Re: PCI on 834x
Date: Thu, 25 Feb 2010 17:49:51 -0600	[thread overview]
Message-ID: <4B870C9F.5060308@freescale.com> (raw)
In-Reply-To: <4B870B17.7080701@mlbassoc.com>

Gary Thomas wrote:
> On 02/25/2010 02:24 PM, Scott Wood wrote:
>> Gary Thomas wrote:
>>> On 02/25/2010 02:03 PM, Scott Wood wrote:
>>>> Gary, can you check that the MMIO addresses are going to the PCI bus 
>>>> as-is, and aren't being translated down to zero? I.e. POTARn should 
>>>> equal POBARn, and likewise in the device
>>>> tree's pci node's ranges.
>>>
>>> Hmm, that doesn't match with how I've always had this setup. I have:
>>> POTAR0 = 0x00000000
>>> POTBR0 = 0x000C0000 (0xC0000000 >> 12)
>>>
>>> My device tree mappings are:
>>> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x10000000
>>> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>
>>
>> That ranges property says that host address 0xc0000000 maps to PCI 
>> address 0xc0000000, so Linux will program the BAR to 0xc0000000, but 
>> the actual accesses will go elsewhere
>> because POTAR0 is zero.
>>
>> Setting POTAR to zero is also a bad idea because it's aliasing your 
>> DMA window (it may work in certain situations based on who's 
>> initiating the transaction, but it seems like it's
>> asking for trouble), plus it seems some cards just don't like address 
>> zero.
>>
>> Try setting POTAR0 to 0x000c0000 and see what happens.
> 
> Sadly, that doesn't work at all - neither RedBoot nor Linux
> can talk to any of the PCI devices.

Make sure that whatever is doing the PCI enumeration is allocating MMIO 
addresses starting at 0xc0000000.  That anything worked at all before 
indicates that something was probably allocating from zero, despite 
what's in the device tree.

-Scott

  reply	other threads:[~2010-02-25 23:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 15:49 PCI on 834x Gary Thomas
2010-02-24 18:48 ` Scott Wood
2010-02-24 19:14   ` Gary Thomas
2010-02-24 19:31     ` Scott Wood
2010-02-24 19:47       ` Gary Thomas
2010-02-24 20:26         ` Scott Wood
2010-02-24 20:51           ` Anton Vorontsov
2010-02-24 22:14             ` Gary Thomas
2010-02-24 22:25               ` Kumar Gala
2010-02-24 23:08                 ` Gary Thomas
2010-02-25 14:25                   ` Gary Thomas
2010-02-25 20:49                     ` Benjamin Herrenschmidt
2010-02-25 21:03                       ` Scott Wood
2010-02-25 21:11                         ` Gary Thomas
2010-02-25 21:24                           ` Scott Wood
2010-02-25 23:43                             ` Gary Thomas
2010-02-25 23:49                               ` Scott Wood [this message]
2010-02-25 22:36                         ` Benjamin Herrenschmidt

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=4B870C9F.5060308@freescale.com \
    --to=scottwood@freescale.com \
    --cc=avorontsov@ru.mvista.com \
    --cc=gary@mlbassoc.com \
    --cc=linuxppc-dev@ozlabs.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.