[PATCH 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)

[Geoff Thorpe]

Hi,

Leaping in here a little after the fact, to add a bit of background info on the hardware in case it helps.

> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: October-23-14 7:16 AM
> To: Medve Emilian-EMMEDVE1
> 
> On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil Medve wrote:
> > Hello Mark,
> >
> >
> > Thanks for having a look at this
> >
> > On 10/22/2014 09:29 AM, Mark Rutland wrote:
> > > On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
> > >> Portals are used by software running on processor cores,
> accelerators and
> > >> network interfaces to communicate with the BMan
> > >
> > > What exactly is a portal?
> > >
> > > Is it a region of shared memory? A device?

Just to supplement what Emil already mentioned, the portals each contain two memory-mapped regions and a single interrupt. One of the regions is a conventional 4K page of 32-bit cache-inhibited registers (and this includes all the controls and status for the portal's interrupt line, which conveys a variety of individually-configurable interrupt source conditions). The other region is a 16K cache-enabled space, so the "registers" are cacheline width - interaction with this relies on cacheline manipulation instructions (flushing, prefetching, etc), and in some configurations hardware will initiate stashing (cache-warming) for some of those cachelines, which is one of the reasons that these portals have "LIODN" information configured into them (stashing transactions go through the IOMMU). The other reason for LIODN/IOMMU context is that all the accelerator and networking functions accessed via a portal will be subjected to the IOMMU context info of that portal. In this way, a portal that is mapped/used by a given software context can be setup such that DMA generated by its hardware interactions will respect the same guest-physical translations and restrictions as apply to the software context itself.

BTW, a subset of the CCSR registers for the QMan and BMan blocks are used to configure these LIODN/IOMMU attributes of the portals, as opposed to those attributes being exposed in the register space of the portals themselves. In this way, the user of a memory-mapped portal cannot set their own LIODN/IOMMU attributes, that decision belongs to whoever twiddles with CCSR.

> > Given the description above, surely you need to know what the
> portal is
> > > used for? Or is that queried from the portal?
> >
> > We don't need/want to include such information in the DT. Portals
> are
> > "allocated" dynamically and used by the respective context
> 
> Ok. So they have no fixed purpose and software allocates as necessary?
> There are no constraints on how each portal may be used, or which
> portal
> another agetn might use?

Yes, precisely. They're interchangeable windows/contexts into the hardware, for issuing various kinds of commands and obtaining various kinds of results/status. The SoC provides a certain number of these portals, and software can allocate them out and configure them in whatever manner (static, dynamic, ...). Because of the CCSR-controlled LIODN/IOMMU portal attributes, two portals can be set up to have different "access" and operate in different contexts (eg. apps, virtual machines), but that is determined by control software (kernel driver) configuration of those portals before their use. In short, there's nothing intrinsic to the portals (ie. from a hardware perspective) that distinguishes them or predetermines their use.

Cheers,
Geoff