Devicetree has been formed by and for SoC vendors to represent what they have on their platforms (CPUs, Memory, interconnects, IOMMUs, ports, IRQ lines, firmware - http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf)..... so it looks like very similar to what Petri is talking about.
ACPI has also a concept of a proximity domains and the relative cost to use a resource from another domain. Handling NUMA requires a well thought through approach because it has implications at many levels in particular for device and driver framework. Bottom line, regardless if it's value, the introduction of the API seem too early as I haven't seen the use case that it supports and in particular the device and drivers framework. FF On 6 December 2016 at 14:23, Bill Fischofer <bill.fischo...@linaro.org> wrote: > > > On Tue, Dec 6, 2016 at 5:03 AM, Francois Ozog <francois.o...@linaro.org> > wrote: > >> Hi Bill, >> >> could you clarify if this "device" is related to devicetree as defined by >> Linaro (https://github.com/devicetree-org/devicetree-specification) or >> the devices that are in the scope of Christophe Millard, or some other >> device concept ? >> > > This is the Device ID proposal that Petri suggested at BKK16. It is not > related to devtree or any other specific taxonomy as the idea was to > establish an abstract "device" framework that would support both individual > sockets or multi-SoC environments. In odp-linux these are basically > placeholder functions as we don't have any cross-platform concept of NUMA. > The idea is that each individual platform that does support NUMA should be > able to map their native concepts into this framework to permit > applications to associate an internal odp_dev_t handle with named devices. > > >> >> FF >> >> >> >> On 6 December 2016 at 04:43, Bill Fischofer <bill.fischo...@linaro.org> >> wrote: >> >>> Ping. v3 of this patch is still awaiting review. >>> >>> On Mon, Oct 24, 2016 at 4:29 PM, Bill Fischofer >>> <bill.fischo...@linaro.org> wrote: >>> > Add the odp_dev_id() API used for NUMA support >>> > >>> > Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org> >>> > --- >>> > Changes for v3: >>> > - Correct ODP_DEV_ANY to ODP_DEV_DEFAULT >>> > >>> > Changes for v2: >>> > - Incorporate changes suggested by Petri >>> > >>> > include/odp/api/spec/dev.h | 89 ++++++++++++++++++++++++++++++ >>> ++++++++++++++++ >>> > 1 file changed, 89 insertions(+) >>> > create mode 100644 include/odp/api/spec/dev.h >>> > >>> > diff --git a/include/odp/api/spec/dev.h b/include/odp/api/spec/dev.h >>> > new file mode 100644 >>> > index 0000000..76d861a >>> > --- /dev/null >>> > +++ b/include/odp/api/spec/dev.h >>> > @@ -0,0 +1,89 @@ >>> > +/* Copyright (c) 2016, Linaro Limited >>> > + * All rights reserved. >>> > + * >>> > + * SPDX-License-Identifier: BSD-3-Clause >>> > + */ >>> > + >>> > +/** >>> > + * @file >>> > + * >>> > + * ODP device >>> > + */ >>> > + >>> > +#ifndef ODP_API_DEV_H_ >>> > +#define ODP_API_DEV_H_ >>> > +#include <odp/visibility_begin.h> >>> > + >>> > +#ifdef __cplusplus >>> > +extern "C" { >>> > +#endif >>> > + >>> > +#include <odp/api/std_types.h> >>> > + >>> > +/** @defgroup odp_dev ODP DEVICE >>> > + * Operations on devices >>> > + * @{ >>> > + */ >>> > + >>> > +/** >>> > + * @typedef odp_dev_t >>> > + * ODP Device >>> > + */ >>> > + >>> > +/** >>> > + * @def ODP_DEV_NAME_LEN >>> > + * Maximum device name length in chars >>> > + */ >>> > + >>> > +/** >>> > + * @def ODP_DEV_DEFAULT >>> > + * Default device >>> > + */ >>> > + >>> > +/** >>> > + * @def ODP_DEV_INVALID >>> > + * Invalid device >>> > + */ >>> > + >>> > +/** >>> > + * Get Device ID by Name >>> > + * >>> > + * Get an implementation-defined device identifier from a device >>> name. Device >>> > + * names are supplied as parameter info (command line, file, etc.) to >>> the >>> > + * application. This routine translates this symbolic name into an >>> internal >>> > + * identifier that can be used to define a device connection >>> hierarchy for >>> > + * NUMA or other purposes. >>> > + * >>> > + * The reserved id ODP_DEV_DEFAULT may be used as a "don't care" >>> placeholder >>> > + * wherever a device id is required. >>> > + * >>> > + * @param name Name of the device >>> > + * >>> > + * @return Device ID >>> > + * @retval ODP_DEV_INVALID Device is unknown >>> > + */ >>> > +odp_dev_t odp_dev_id(const char *name); >>> > + >>> > +/** >>> > + * Get printable value for an odp_dev_t >>> > + * >>> > + * @param hdl odp_dev_t handle to be printed >>> > + * @return uint64_t value that can be used to print/display this >>> > + * handle >>> > + * >>> > + * @note This routine is intended to be used for diagnostic purposes >>> > + * to enable applications to generate a printable value that >>> represents >>> > + * an odp_dev_t handle. >>> > + */ >>> > +uint64_t odp_dev_to_u64(odp_dev_t hdl); >>> > + >>> > +/** >>> > + * @} >>> > + */ >>> > + >>> > +#ifdef __cplusplus >>> > +} >>> > +#endif >>> > + >>> > +#include <odp/visibility_end.h> >>> > +#endif >>> > -- >>> > 2.7.4 >>> > >>> >> >> >> >> -- >> [image: Linaro] <http://www.linaro.org/> >> François-Frédéric Ozog | *Director Linaro Networking Group* >> T: +33.67221.6485 >> francois.o...@linaro.org | Skype: ffozog >> >> > -- [image: Linaro] <http://www.linaro.org/> François-Frédéric Ozog | *Director Linaro Networking Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
