Hi Bill, Do you have any slides/docs on Petri's suggestion? Thank you, Honnappa
On 6 December 2016 at 09:10, Francois Ozog <francois.o...@linaro.org> wrote: > For the link, I think it ate the .... following it. > Here it is without decoration: > http://free-electrons.com/pub/conferences/2013/elce/petazzoni-device-tree-dummies/petazzoni-device-tree-dummies.pdf > > > > On 6 December 2016 at 16:05, Francois Ozog <francois.o...@linaro.org> wrote: > >> OK. So let's defer the API but not the discussion. >> I think we need a "strategic architecture" call. >> >> FF >> >> >> >> On 6 December 2016 at 15:59, Bill Fischofer <bill.fischo...@linaro.org> >> wrote: >> >>> I have no problem deferring this if we want to have one of the SoC >>> vendors drive a more comprehensive approach based on their capabilities >>> which can then be generalized. BTW, your link doesn't resolve. Typo >>> somewhere? >>> >>> On Tue, Dec 6, 2016 at 8:47 AM, Francois Ozog <francois.o...@linaro.org> >>> wrote: >>> >>>> 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/petazzon >>>> i-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 >>>> >>>> >>> >> >> >> -- >> [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