Messages in this thread | | | Date | Wed, 22 Dec 2021 11:40:57 -0500 | From | Tom Rini <> | Subject | Re: [GIT PULL 1/2] arm64: TI K3 SoC configs changes for v5.17 |
| |
On Wed, Dec 22, 2021 at 12:56:06PM +0530, Vignesh Raghavendra wrote: > > > On 21/12/21 9:39 pm, Tom Rini wrote: > > On Tue, Dec 21, 2021 at 04:55:48PM +0100, Arnd Bergmann wrote: > >> On Tue, Dec 21, 2021 at 4:32 PM Tom Rini <trini@konsulko.com> wrote: > >>> On Mon, Dec 20, 2021 at 11:10:25PM +0530, Vignesh Raghavendra wrote: > >>>> > >>>> Currently its not possible to build PCIE_CADENCE_PLAT_HOST/EP drivers as > >>>> modules (symbols are bool only). > >>>> PCIe is not necessary for basic boot either. So, I can drop these > >>>> configs until these drivers are build able as modules, if you prefer. > >>> > >>> Is PCIe required for basic boot for the other platforms in the defconfig > >>> which do enable it in the defconfig today? It is required for non-basic > >>> boot (whatever storage one puts in a PCIe slot). If someone is going to > >>> be fixing the PCIe driver to be able to be modular, that's fine too but > >>> I ran in to this trying to see what works out of the box in the > >>> defconfig, on this platform and hit both of these rather large > >>> omissions. > >> > >> If PCI is often used for storage, then that's ok. There are a number of > >> other platforms where PCIe is only used for wireless networking or > >> other secondary devices, but they are still built-in because they got > >> added before it became possible for PCIe host drivers to be loadable > >> modules. I would like to eventually go through and turn those into > >> loadable modules, but for the moment it would be good to only add > >> built-in drivers where this is actually useful. > > > > That's good to know. My question tho is, what's actually useful? The > > EVM is 2 PCIe x8 type slots. I honestly don't know if that means "super > > useful, arbitrary devices are expected to work" or "not useful, > > arbitrary devices are not expected to work". Is the functional > > definition of what's in the defconfig vs left up to users, > > distributions, etc, to find and enabled defined, or at least well known > > / explained somewhere? Where I'm coming from on this is that these > > platforms practically are, and can be SystemReady IR certified. So > > what's needed here to ensure there's a good experience distros to enable > > what needs enabling for full functionality? What we hit was "lets throw > > some stuff at this board to test it out and.. wait, PCIe isn't enabled > > at all? USB host isn't enabled at all?" > > > > And all that said, if someone is going to be fixing the PCIe drivers to > > be enabled as modules soon, and just getting it handled that way in the > > next appropriately timed merge window, OK, fine, good enough. > > > > Looks like its not a big effort to convert J7 PCIe driver to build as > module and can be done for v5.18 Merge Window. So how about we enable > only USB controller drivers now and then enable PCIe after its > build-able as module?
Works for me, thanks!
-- Tom
| |