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
