archive mirror
 help / color / mirror / Atom feed
From: Thomas Petazzoni <>
To: "Marek Behún" <>
Cc: "Stefan Roese" <>, "Phil Sutter" <>,
	"Mario Six" <>, "Pali Rohár" <>,
	"Lorenzo Pieralisi" <>,
	"Bjorn Helgaas" <>,, "Stefan Chulski" <>
Subject: Re: pci mvebu issue (memory controller)
Date: Wed, 10 Feb 2021 09:54:08 +0100	[thread overview]
Message-ID: <20210210095408.75839806@windsurf.home> (raw)
In-Reply-To: <>

Hello Marek,

On Tue, 9 Feb 2021 14:17:59 +0100
Marek Behún <> wrote:

> (sending this e-mail again because previously I sent it to Thomas' old
> e-mail address at free-electrons)

Thanks. Turns out I still receive e-mail sent to,
so I had seen your previous e-mail but didn't had the chance to reply.

> we have enountered an issue with pci-mvebu driver and would like your
> opinion, since you are the author of commit
> After upgrading to new version of U-Boot on a Armada XP / 38x device,
> some WiFi cards stopped working in kernel. Ath10k driver, for example,
> could not load firmware into the card.
> We discovered that the issue is caused by U-Boot:
> - when U-Boot's pci_mvebu driver was converted to driver model API,
>   U-Boot started to configure PCIe registers not only for the newtork
>   adapter, but also for the Marvell Memory Controller (that you are
>   mentioning in your commit).
> - Since pci-mvebu driver in Linux is ignoring the Marvell Memory
>   Controller device, and U-Boot configures its registers (BARs and what
>   not), after kernel boots, the registers of this device are
>   incompatible with kernel, or something, and this causes problems for
>   the real PCIe device.
> - Stefan Roese has temporarily solved this issue with U-Boot commit
>   which basically just masks the Memory Controller's existence.
> - in Linux commit f4ac99011e54 ("pci: mvebu: no longer fake the slot
>   location of downstream devices") you mention that:
>    * On slot 0, a "Marvell Memory controller", identical on all PCIe
>      interfaces, and which isn't useful when the Marvell SoC is the PCIe
>      root complex (i.e, the normal case when we run Linux on the Marvell
>      SoC).
> What we are wondering is:
> - what does the Marvell Memory controller really do? Can it be used to
>   configure something? It clearly does something, because if it is
>   configured in U-Boot somehow but not in kernel, problems can occur.
> - is the best solution really just to ignore this device?
> - should U-Boot also start doing what commit f4ac99011e54 does? I.e.
>   to make sure that the real device is in slot 0, and Marvell Memory
>   Controller in slot 1.
> - why is Linux ignoring this device? It isn't even listed in lspci
>   output.

To be honest, I don't have much details about what this device does,
and my memory is unclear on whether I really ever had any details. I
vaguely remember that this is a device that made sense when the Marvell
PCIe controller is used as an endpoint, and in such a situation this
device also the root complex to "see" the physical memory of the
Marvell SoC. And therefore in a situation where the Marvell PCIe
controller is the root complex, seeing this device didn't make sense.

In addition, I /think/ it was causing problems with the MBus windows
allocation. Indeed, if this device is visible, then we will try to
allocate MBus windows for its different BARs, and those windows are in
limited number.

I know this isn't a very helpful answer, but the documentation on this
is pretty much nonexistent, and I don't remember ever having very
solid and convincing answers.

I've added in Cc Stefan Chulski, from Marvell, who has recently posted
patches on the PPv2 driver. I don't know if he will have details about
PCIe, but perhaps he will be able to ask internally at Marvell.

Best regards,

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering

  reply	other threads:[~2021-02-10  8:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 13:17 pci mvebu issue (memory controller) Marek Behún
2021-02-10  8:54 ` Thomas Petazzoni [this message]
2021-02-10 13:59   ` [EXT] " Stefan Chulski
2021-02-19 17:44     ` Pali Rohár
2021-03-04 18:29       ` Bjorn Helgaas
2021-11-01 18:07         ` Jason Gunthorpe
2021-10-03 12:09 ` Pali Rohár
  -- strict thread matches above, loose matches on Subject: below --
2021-02-08 15:08 Marek Behún

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210210095408.75839806@windsurf.home \ \ \ \ \ \ \ \ \ \ \

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