archive mirror
 help / color / mirror / Atom feed
* pci mvebu issue (memory controller)
@ 2021-02-09 13:17 Marek Behún
  2021-02-10  8:54 ` Thomas Petazzoni
  0 siblings, 1 reply; 9+ messages in thread
From: Marek Behún @ 2021-02-09 13:17 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Stefan Roese, Phil Sutter, Mario Six, Pali Rohár,
	Lorenzo Pieralisi, Bjorn Helgaas, linux-pci

Hello Thomas,

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

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

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-11-01 18:11 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20210602110703.ymdt6nxsjl7e6glk@pali>
2021-06-02 19:14 ` [EXT] Re: pci mvebu issue (memory controller) Bjorn Helgaas
2021-06-02 20:39   ` Pali Rohár
2021-06-02 21:01     ` Bjorn Helgaas
2021-06-02 21:13       ` Pali Rohár
2021-06-02 21:59         ` Marek Behún
2021-02-09 13:17 Marek Behún
2021-02-10  8:54 ` Thomas Petazzoni
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

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