On Thu, Jan 19, 2023 at 09:41:12AM -0700, Simon Glass wrote:
> Hi Abdellatif,
>
> On Thu, 19 Jan 2023 at 09:32, Abdellatif El Khlifi
> <abdellatif.elkhl...@arm.com> wrote:
> >
> > On Wed, Jan 18, 2023 at 08:59:32AM -0500, Tom Rini wrote:
> > > On Wed, Jan 18, 2023 at 01:46:54PM +0000, Sudeep Holla wrote:
> > > > On Wed, Jan 18, 2023 at 12:49 PM Tom Rini <tr...@konsulko.com> wrote:
> > > >
> > > > >
> > > > > I guess the problem comes down to, can we have one discovery method
> > > > > that
> > > > > everyone shares, or do we have to let everyone invent a new discovery
> > > > > method every time?
> > > >
> > > >
> > > > No one needs to invent any discovery method every time if the firmware
> > > > specification
> > > > provides one and as Rob mentioned many times in the thread, all new
> > > > firmware
> > > > specification must provide one and we are trying to make sure that is
> > > > the case with all new
> > > > specs from Arm.
> > > >
> > > >
> > > > > FF-A, Op-tee, U-Boot, coreboot, barebox (and
> > > > > everyone else I'm unintentionally forgetting) could just discover
> > > > > these
> > > > > things via device tree.
> > > >
> > > >
> > > > I leave that to the individual projects to decide and agree but
> > > > fundamentally if
> > > > the specification provides a way to discover, not sure why we are even
> > > > discussing
> > > > an alternative method here.
> > > >
> > > >
> > > > > Or, we could all write our own code to perform
> > > > > the discovery.
> > > >
> > > >
> > > > For what reason ? I can understand if there is no discovery mechanism
> > > > but
> > > > that's not the
> > > > case in $subject.
> > > >
> > > >
> > > > > And when RISC-V comes along with similar functionality,
> > > > > we could probe their device tree and see they've implemented the same
> > > > > concept, but a little differently, but still have the discovery
> > > > > portion
> > > > > be in the device tree. To which it sounds like your answer is "not in
> > > > > the device tree".
> > > > >
> > > >
> > > > I see U-boot seem to have made a decision to create DT node for each and
> > > > everything
> > > > that needs to be added to DM which seems bit unfortunate but I don't
> > > > understand the
> > > > history/motive/background for it but I respect the decision if it is
> > > > already made.
> > > >
> > > > These firmware interfaces are standard on all Arm platforms and can be
> > > > discovered
> > > > based on PSCI/SMCCC. Not using the same and use DT node needs
> > > > unnecessary
> > > > addition of DT nodes for all the f/w i/f on all the platforms that need
> > > > the
> > > > support when
> > > > one can be just discovered.
> > > >
> > > > Sorry for the sudden appearance on this thread, I was avoiding getting
> > > > into
> > > > this but thought
> > > > I will at least express my opinion and also the way the firmware
> > > > specifications from Arm is
> > > > expected to be evolved from now on. With that I will leave it to you and
> > > > other U-boot
> > > > maintainers and the community in general to decide the right course in
> > > > this
> > > > case.
> > >
> > > To be clear, if the position is that "this is what everyone else will
> > > use, really" then yes, we'll follow this in U-Boot.
> >
> > Hi Simon, Tom,
> >
> > The FF-A transport is a SW bus and is not associated to any HW peripheral or
> > undiscoverable base address.
> >
> > There is only 1 way of discovering the FF-A bus and it's through the FF-A SW
> > interfaces. The FF-A spec [1] describes this in details.
>
> Can you add a DT node for the 'FF-A SW interfaces' and attach some
> sort of top-level driver to that? Perhaps simple-bus, or your own
> thing? You don't need to add compatible strings for subnodes (devices
> that are discoverable within that).
>
> If you don't want to submit the compatible string to Linux, I will do
> it. If it has to have a 'u-boot,' prefix then so be it, but I don't
> see why that is necessary, since Linux can ignore it if it likes.
>
> We have been talking about this for far too long, IMO. Would you like
> me to send a patch? It is something like this:
>
> ff-a {
> compatible = "arm,ff-a";
> };No, we don't need a DT node here. Everyone else is insisting that we can solve the problems without it. So, lets go ahead and prove it. The approach they're describing can be integrated without a device tree node, in to the rest of the framework we have. -- Tom
signature.asc
Description: PGP signature
