Message-ID: <20211222164057.GN2773246@bill-the-cat>
Date:   Wed, 22 Dec 2021 11:40:57 -0500
From:   Tom Rini <trini@...sulko.com>
To:     Vignesh Raghavendra <vigneshr@...com>
Cc:     Arnd Bergmann <arnd@...db.de>, Nishanth Menon <nm@...com>,
        Olof Johansson <olof@...om.net>, SoC <soc@...nel.org>,
        arm-soc <arm@...nel.org>, Tero Kristo <kristo@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KISHON VIJAY ABRAHAM <kishon@...com>
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@...sulko.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

Powered by blists - more mailing lists