On 25 October 2016 at 08:39, Brian Brooks <brian.bro...@linaro.org> wrote:
> On 10/31 19:58:39, Christophe Milard wrote:
>> The driver registration function (and a draft of its parameters) is
>> defined, the goal being to define the driver registration framework only.
>>
>> Signed-off-by: Christophe Milard <christophe.mil...@linaro.org>
>> ---
>> include/odp/drv/spec/driver.h | 76
>> +++++++++++++++++++++++++++++++++++++++++++
>> platform/Makefile.inc | 1 +
>> 2 files changed, 77 insertions(+)
>> create mode 100644 include/odp/drv/spec/driver.h
>>
>> diff --git a/include/odp/drv/spec/driver.h b/include/odp/drv/spec/driver.h
>> new file mode 100644
>> index 0000000..467201a
>> --- /dev/null
>> +++ b/include/odp/drv/spec/driver.h
>> @@ -0,0 +1,76 @@
>> +/* Copyright (c) 2016, Linaro Limited
>> + * All rights reserved.
>> + *
>> + * SPDX-License-Identifier: BSD-3-Clause
>> + */
>> +
>> +/**
>> + * @file
>> + *
>> + * ODPDRV driver
>> + */
>> +
>> +#ifndef ODPDRV_DRIVER_H_
>> +#define ODPDRV_DRIVER_H_
>> +#include <odp/visibility_begin.h>
>> +
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +/**
>> + * @addtogroup odpdrv_driver
>> + * @details
>> + * NIC driver interface to ODP
>
> Is 'NIC driver interface' just a pktio (pktio_if_ops_t) or is there more?
The pktio is mostly what is visible on the north API, the other bit
(on the north API) being the odp_load_driver() function defined in
this patch serie.
Roughly speaking, the idea is as follows:
Drivers are either statically linked, or loaded at run-time by the
application (probably during its init phase).
In Both cases, drivers will be running their (__contructor__) init
function which will call odpdrv_driver_register(), to register itself.
odpdrv_driver_register() is an odp function belonging to the ODP south
(drv) interface, hence the prefix, odrdrv_*.
The registration call to odpdrv_driver_register() includes a structure
telling ODP which bus the driver can handle (only PCI is the focus
right now but we there make room for others), and which kind of driver
is registering (some will require physical address knowledge while
some other -such as pci-vfio- will not... so ODP has to know)
The structure will also include pointer to the probe function of the
driver, which will be called after enumeration (or possibly
immediately if the driver is being loaded after enumeration has been
done)
> There is a packet copy in mbuf_to_pkt(), does this driver layer involve
> memory?
Not sure I get the question...
I had outlined what I though was required (as a first step), regarding
memory in the following mail:
https://lists.linaro.org/pipermail/lng-odp/2016-September/025695.html
(note that all these should actually have been prefixed with the
odpdrv_* prefix, as these funtions actually belong to the south
(driver) interface.
Hope this does answer your question. if not, please precise :-)
>
> 'odpdrv_driver' sounds like the top-most driver for the whole board or an
> entire
> ODP implementation. Would there be other layers in this driver?
odpdrv_driver: odpdrv is the prefix identifying anything belonging to
ODP south (driver) interface (as odp is the prefix for the north API
interface).
odpdrv_driver is the part of ODP handling driver registration and init.
So odpdrv_driver is not a part of any driver, it is the part of odp
handling drivers.
>
>> + * @{
>> + */
>> +
>> +/**
>> + * Different busses drivers can handle:
>> + */
>> +typedef enum odpdrv_bus_t {
>> + UNKNOWN_BUS, /**< error case: no driver should use that */
>> + PCI /**< pci bus, for all kind of pci drivers */
>> +} odpdrv_bus_t;
>>
>> +/**
>> + * Different driver types
>> + */
>> +typedef enum odpdrv_driver_types_t {
>> + UNKNOWN_TYPE, /**< error case: no driver should use that */
>> + PCI_VIRTIO, /**< pci virtio driver */
>> + PCI_VFIO /**< pci_vfio: vfio interface required */
>
> Should 'PCI' be a suffix instead of a prefix?
I don't think so: when many busses will be supported, having the bus
name as the prefix here will nicely order the different driver types
per buss.
>
> Could a VFIO-based driver issue R or W transactions that go over a bus other
> than PCI like MDIO or maybe no bus at all?
I cannot see how a driver could become bus-agnostic.
I do not understanf the "no bus att all" case.
>
>> +} odpdrv_driver_types_t;
>> +
>> +/**
>> + * Parameter to be given at driver registration:
>> + */
>> +typedef struct odpdrv_driver_param_t {
>> + const char *name; /**< Driver name. */
>> + odpdrv_bus_t bus; /**< Driver type. */
>> + odpdrv_driver_types_t type; /**< Driver type. */
>> +} odpdrv_driver_param_t;
>> +
>> +/**
>> + * Register a Driver.
>> + * A call to this function should be made by all drivers at init time.
>> + * (called by an init function in the driver, probably using gcc/clang
>> + * __constructor__ attribute.
>> + *
>> + * @param drv_param Pointer to a driver registration structure.
>> + * @return 0 on success, non-zero on error. On error, drivers
>> + * should release allocated resources and return.
>> + */
>> +int odpdrv_driver_register(odpdrv_driver_param_t *drv_param);
>> +
>> +/**
>> + * @}
>> + */
>> +
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +
>> +#include <odp/visibility_end.h>
>> +#endif
>> diff --git a/platform/Makefile.inc b/platform/Makefile.inc
>> index b31b95b..69ee878 100644
>> --- a/platform/Makefile.inc
>> +++ b/platform/Makefile.inc
>> @@ -67,6 +67,7 @@ odpdrvspecinclude_HEADERS = \
>> $(top_srcdir)/include/odp/drv/spec/barrier.h \
>> $(top_srcdir)/include/odp/drv/spec/byteorder.h \
>> $(top_srcdir)/include/odp/drv/spec/compiler.h \
>> + $(top_srcdir)/include/odp/drv/spec/driver.h \
>> $(top_srcdir)/include/odp/drv/spec/shm.h \
>> $(top_srcdir)/include/odp/drv/spec/spinlock.h \
>> $(top_srcdir)/include/odp/drv/spec/std_types.h \
>> --
>> 2.7.4
>>
