Enable generic PCIe by default in the RISC-V defconfig, this allows us
to use QEMU's PCIe support out of the box. Also remove the Xilinx PCIe
support by default as this is rarely used and conflicts with the more
commonly used (out of tree) MicroSemi PCIe root complex.
Signed-off-by: Alistair Francis <[email protected]>
---
arch/riscv/configs/defconfig | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index ef4f15df9adf..71475c20b8ce 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -14,7 +14,13 @@ CONFIG_EXPERT=y
CONFIG_BPF_SYSCALL=y
CONFIG_SMP=y
CONFIG_PCI=y
-CONFIG_PCIE_XILINX=y
+CONFIG_PCI_ECAM=y
+CONFIG_PCI_HOST_COMMON=y
+CONFIG_PCI_HOST_GENERIC=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_PCIEAER=y
+CONFIG_PCIEASPM=y
+CONFIG_PCIEASPM_DEFAULT=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_NET=y
--
2.19.1
Hello Alistair,
On Fri, 21 Dec 2018, Alistair Francis wrote:
> Enable generic PCIe by default in the RISC-V defconfig, this allows us
> to use QEMU's PCIe support out of the box. Also remove the Xilinx PCIe
> support by default as this is rarely used and conflicts with the more
> commonly used (out of tree) MicroSemi PCIe root complex.
There are many folks working on FPGAs who use the Xilinx driver.
Also, we should not remove support for an in-tree driver because an
out-of-tree driver conflicts. The right approach is to get the
out-of-tree driver upstream.
Enabling general support for PCIe in the defconfig should be fine, though.
- Paul
On Fri, 2018-12-21 at 11:13 -0800, Paul Walmsley wrote:
> Hello Alistair,
>
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > Enable generic PCIe by default in the RISC-V defconfig, this allows
> > us
> > to use QEMU's PCIe support out of the box. Also remove the Xilinx
> > PCIe
> > support by default as this is rarely used and conflicts with the
> > more
> > commonly used (out of tree) MicroSemi PCIe root complex.
>
> There are many folks working on FPGAs who use the Xilinx driver.
>
> Also, we should not remove support for an in-tree driver because an
> out-of-tree driver conflicts. The right approach is to get the
> out-of-tree driver upstream.
I'm happy to keep it in.
When the MicroSemi driver does eventually go upstream this will
probably have to be discussed though as either the config or device
tree will need to be edited to ensure only one PCIe device is present.
>
> Enabling general support for PCIe in the defconfig should be fine,
> though.
Ok, I'll send a v2 with the Xilinx PCIe still enabled.
Alistair
>
>
> - Paul
>
On Fri, 2018-12-21 at 11:27 -0800, Paul Walmsley wrote:
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > When the MicroSemi driver does eventually go upstream this will
> > probably have to be discussed though as either the config or device
> > tree will need to be edited to ensure only one PCIe device is
> > present.
>
> The right way to do that is to have two separate DT files: one for
> the
> HiFive-U board alone; the other for the HiFive-U plus the expansion
> board
> combo. There shouldn't be any problems with keeping both drivers
> enabled
> in the defconfig.
Agreed, the only problem is that the device tree comes from the boards
firmware at the moment.
Alistair
>
>
> - Paul
On Fri, 21 Dec 2018, Alistair Francis wrote:
> On Fri, 2018-12-21 at 11:27 -0800, Paul Walmsley wrote:
> > On Fri, 21 Dec 2018, Alistair Francis wrote:
> >
> > > When the MicroSemi driver does eventually go upstream this will
> > > probably have to be discussed though as either the config or device
> > > tree will need to be edited to ensure only one PCIe device is
> > > present.
> >
> > The right way to do that is to have two separate DT files: one for the
> > HiFive-U board alone; the other for the HiFive-U plus the expansion
> > board combo. There shouldn't be any problems with keeping both
> > drivers enabled in the defconfig.
>
> Agreed, the only problem is that the device tree comes from the boards
> firmware at the moment.
The switchover is in progress:
https://lore.kernel.org/linux-riscv/[email protected]/T/#t
- Paul
On Fri, 21 Dec 2018, Alistair Francis wrote:
> When the MicroSemi driver does eventually go upstream this will
> probably have to be discussed though as either the config or device
> tree will need to be edited to ensure only one PCIe device is present.
The right way to do that is to have two separate DT files: one for the
HiFive-U board alone; the other for the HiFive-U plus the expansion board
combo. There shouldn't be any problems with keeping both drivers enabled
in the defconfig.
- Paul
On Fri, 2018-12-21 at 14:34 -0800, Paul Walmsley wrote:
>
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
> > On Fri, 2018-12-21 at 11:27 -0800, Paul Walmsley wrote:
> > > On Fri, 21 Dec 2018, Alistair Francis wrote:
> > >
> > > > When the MicroSemi driver does eventually go upstream this will
> > > > probably have to be discussed though as either the config or
> > > > device
> > > > tree will need to be edited to ensure only one PCIe device is
> > > > present.
> > >
> > > The right way to do that is to have two separate DT files: one
> > > for the
> > > HiFive-U board alone; the other for the HiFive-U plus the
> > > expansion
> > > board combo. There shouldn't be any problems with keeping both
> > > drivers enabled in the defconfig.
> >
> > Agreed, the only problem is that the device tree comes from the
> > boards
> > firmware at the moment.
>
> The switchover is in progress:
>
> https://lore.kernel.org/linux-riscv/[email protected]/T/#t
Great! I didn't know it was in progress.
Alistair
>
>
> - Paul
>
On Fri, 21 Dec 2018 11:27:39 PST (-0800), Paul Walmsley wrote:
>
> On Fri, 21 Dec 2018, Alistair Francis wrote:
>
>> When the MicroSemi driver does eventually go upstream this will
>> probably have to be discussed though as either the config or device
>> tree will need to be edited to ensure only one PCIe device is present.
>
> The right way to do that is to have two separate DT files: one for the
> HiFive-U board alone; the other for the HiFive-U plus the expansion board
> combo. There shouldn't be any problems with keeping both drivers enabled
> in the defconfig.
We actually need at least three:
* One for the HiFive Unleashed
* One for the HiFive Unleashed, when attached to the Micro Semi expansion
board.
* One for the HiFive Unleashed, when attached to a VC707.
We may end up needing additional device trees for the newer Xilinx boards,
depending on if it's possible to probe for that 32-bit DMA limit on the VC707
or not. Then, of course, we'll need an image-specific device tree whenever we
put an accelerator on the FPGA.
Ideally we'd have a discoverable bus, but that's going to be a bit of a way
out. For now we'll have to get by with different device trees, but that should
get significantly easier when we get a proper bootloader working.