On Mon, Feb 25, 2019 at 1:12 PM Hyun Kwon <hyun.kwon@xxxxxxxxxx> wrote: > > Hi Rob, > > Thanks for the review. > > On Mon, 2019-02-18 at 13:17:39 -0800, Rob Herring wrote: > > On Mon, Jan 21, 2019 at 05:12:16PM -0800, Hyun Kwon wrote: > > > Add the dt bindings for Xilinx AI Engine, which is a tile processor > > > with many cores. The compatible string, 'xlnx,mathengine' is kept for > > > backward compatibility as it's the legacy name. > > > > > > Signed-off-by: Hyun Kwon <hyun.kwon@xxxxxxxxxx> > > > Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx> > > > --- > > > .../devicetree/bindings/soc/xilinx/xlnx,ai_engine.txt | 19 +++++++++++++++++++ > > > MAINTAINERS | 5 +++++ > > > 2 files changed, 24 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/soc/xilinx/xlnx,ai_engine.txt > > > > > > diff --git a/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai_engine.txt b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai_engine.txt > > > new file mode 100644 > > > index 0000000..fade9d0 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/soc/xilinx/xlnx,ai_engine.txt > > > @@ -0,0 +1,19 @@ > > > +Xilinx AI Engine > > > +---------------- > > > + > > > +The Xilinx AI Engine is a tile processor with many cores (up to 400) that > > > +can run in parallel. The data routing between cores is configured through > > > +internal switches, and shim tiles interface with external interconnect, such > > > +as memory or PL. > > > + > > > +Required properties: > > > + > > > +- compatible: Must be "xlnx,ai_engine", or "xlnx,mathengine" for legacy name. > > > > Use '-' rather than '_'. No legacy names. It didn't reviewed and we're > > not going to be stuck with it. > > Sure will do. > > > > > Only 1 version of the IP? The compatible should be more specific. > > I'll confirm on the proper ip version for the string. > > > > > Are details like number of cores discoverable? > > No, the information will need to be added. At the moment, this information > is not used in the driver, but it will be needed. It can be either > properties (number of columns / number of rows / shift), or this can be > embedded in compatible string as a device type. The latter may be less > scalable, considering variations including emulation platforms which can > change and so on. Could you please share input on which one would be more > appropriate? There's no hard rule here. If it is determined by end users configuring soft IP, then separate properties is probably better. For configuration fixed in an SoC design, then implied by compatible is usually best. Rob