alistair23-linux/drivers/staging/greybus/greybus.h

204 lines
5.8 KiB
C
Raw Normal View History

/*
* Greybus driver and device API
*
* Copyright 2014-2015 Google Inc.
* Copyright 2014-2015 Linaro Ltd.
*
* Released under the GPLv2 only.
*/
#ifndef __LINUX_GREYBUS_H
#define __LINUX_GREYBUS_H
#ifdef __KERNEL__
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/list.h>
#include <linux/slab.h>
#include <linux/device.h>
#include <linux/module.h>
#include <linux/idr.h>
#include "kernel_ver.h"
#include "greybus_id.h"
#include "greybus_manifest.h"
#include "greybus_protocols.h"
#include "manifest.h"
#include "endo.h"
#include "svc.h"
greybus: add module support Modules in the greybus system sit above the interface, so insert them early in the sysfs tree. We dynamically create them when we have an interface that references a module, as we don't get a "module create" message directly. They also dynamically go away when the last interface associated with a module is removed. Naming scheme for modules/interfaces/bundles/connections is bumped up by one ':', and now looks like the following: /sys/bus/greybus $ tree . ├── devices │   ├── 7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7 │   ├── 7:7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7 │   ├── 7:7:0 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0 │   └── 7:7:0:1 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0/7:7:0:1 ├── drivers ├── drivers_autoprobe ├── drivers_probe └── uevent 6 directories, 3 files /sys/bus/greybus $ grep . devices/*/uevent devices/7/uevent:DEVTYPE=greybus_module devices/7:7/uevent:DEVTYPE=greybus_interface devices/7:7:0/uevent:DEVTYPE=greybus_bundle devices/7:7:0:1/uevent:DEVTYPE=greybus_connection We still have some "confusion" about interface ids and module ids, which will be cleaned up later when the svc control protocol changes die down, right now we just name a module after the interface as we don't have any modules that have multiple interfaces in our systems. This has been tested with gbsim. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-21 15:10:26 -07:00
#include "module.h"
#include "control.h"
#include "interface.h"
#include "bundle.h"
#include "connection.h"
#include "protocol.h"
greybus: introduce an operation abstraction This patch defines a new "operation" abstraction. An operation is a request from by one end of a connection to the function (or AP) on the other, coupled with a matching response returned to the requestor. The request indicates some action to be performed by the target of the request (such as "read some data"). Once the action has completed the target sends back an operation response message. Additional data can be supplied by the sender with its request, and/or by the target with its resposne message. Each request message has a unique id, generated by the sender. The sender recognizes the matching response by the presence of this id value. Each end of a connection is responsible for creating unique ids for the requests it sends. An operation also has a type, whose interpretation is dependent on the function type on the end of the connection opposite the sender. It is up to the creator of an operation to fill in the data (if any) to be sent with the request. Note that not all requests are initiated by the AP. Incoming data on a module function can result in a request message being sent from that function to the AP to notify of the data's arrival. Once the AP has processed this, it sends a response to the sender. Every operation response contains a status byte. If it's value is 0, the operation was successful. Any other value indicates an error. Add a defintion of U16_MAX to "kernel_ver.h". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:15 -06:00
#include "operation.h"
/* Matches up with the Greybus Protocol specification document */
#define GREYBUS_VERSION_MAJOR 0x00
#define GREYBUS_VERSION_MINOR 0x01
#define GREYBUS_DEVICE_ID_MATCH_DEVICE \
(GREYBUS_DEVICE_ID_MATCH_VENDOR | GREYBUS_DEVICE_ID_MATCH_PRODUCT)
#define GREYBUS_DEVICE(v, p) \
.match_flags = GREYBUS_DEVICE_ID_MATCH_DEVICE, \
.vendor = (v), \
.product = (p),
#define GREYBUS_DEVICE_SERIAL(s) \
.match_flags = GREYBUS_DEVICE_ID_MATCH_SERIAL, \
.serial_number = (s),
/* XXX I couldn't get my Kconfig file to be noticed for out-of-tree build */
#ifndef CONFIG_CPORT_ID_MAX
#define CONFIG_CPORT_ID_MAX 128
#endif /* !CONFIG_CPORT_ID_MAX */
/* Maximum number of CPorts usable by a host device */
/* XXX This should really be determined by the AP module manifest */
#define CPORT_ID_MAX CONFIG_CPORT_ID_MAX
#define CPORT_ID_BAD U16_MAX /* UniPro max id is 4095 */
/* For SP1 hardware, we are going to "hardcode" each device to have all logical
* blocks in order to be able to address them as one unified "unit". Then
* higher up layers will then be able to talk to them as one logical block and
* properly know how they are hooked together (i.e. which i2c port is on the
* same module as the gpio pins, etc.)
*
* So, put the "private" data structures here in greybus.h and link to them off
* of the "main" gb_module structure.
*/
struct greybus_host_device;
2014-09-07 14:12:11 -06:00
struct svc_msg;
/* Greybus "Host driver" structure, needed by a host controller driver to be
* able to handle both SVC control as well as "real" greybus messages
*/
struct greybus_host_driver {
size_t hd_priv_size;
int (*message_send)(struct greybus_host_device *hd, u16 dest_cport_id,
struct gb_message *message, gfp_t gfp_mask);
void (*message_cancel)(struct gb_message *message);
int (*submit_svc)(struct svc_msg *svc_msg,
struct greybus_host_device *hd);
};
struct greybus_host_device {
struct kref kref;
struct device *parent;
const struct greybus_host_driver *driver;
struct list_head interfaces;
struct list_head connections;
struct ida cport_id_map;
u8 device_id;
/* Host device buffer constraints */
size_t buffer_size_max;
struct gb_endo *endo;
/* Private data for the host driver */
unsigned long hd_priv[0] __aligned(sizeof(s64));
};
struct greybus_host_device *greybus_create_hd(struct greybus_host_driver *hd,
struct device *parent,
size_t buffer_size_max);
int greybus_endo_setup(struct greybus_host_device *hd, u16 endo_id,
u8 ap_intf_id);
2014-09-07 14:12:11 -06:00
void greybus_remove_hd(struct greybus_host_device *hd);
struct greybus_driver {
const char *name;
int (*probe)(struct gb_bundle *bundle,
const struct greybus_bundle_id *id);
void (*disconnect)(struct gb_bundle *bundle);
int (*suspend)(struct gb_bundle *bundle, pm_message_t message);
int (*resume)(struct gb_bundle *bundle);
const struct greybus_bundle_id *id_table;
struct device_driver driver;
};
#define to_greybus_driver(d) container_of(d, struct greybus_driver, driver)
/* Don't call these directly, use the module_greybus_driver() macro instead */
int greybus_register_driver(struct greybus_driver *driver,
struct module *module, const char *mod_name);
void greybus_deregister_driver(struct greybus_driver *driver);
/* define to get proper THIS_MODULE and KBUILD_MODNAME values */
#define greybus_register(driver) \
greybus_register_driver(driver, THIS_MODULE, KBUILD_MODNAME)
#define greybus_deregister(driver) \
greybus_deregister_driver(driver)
/**
* module_greybus_driver() - Helper macro for registering a Greybus driver
* @__greybus_driver: greybus_driver structure
*
* Helper macro for Greybus drivers to set up proper module init / exit
* functions. Replaces module_init() and module_exit() and keeps people from
* printing pointless things to the kernel log when their driver is loaded.
*/
#define module_greybus_driver(__greybus_driver) \
module_driver(__greybus_driver, greybus_register, greybus_deregister)
int greybus_disabled(void);
int greybus_svc_in(struct greybus_host_device *hd, u8 *data, int length);
int gb_ap_init(void);
void gb_ap_exit(void);
void gb_debugfs_init(void);
2014-08-31 17:17:04 -06:00
void gb_debugfs_cleanup(void);
struct dentry *gb_debugfs_get(void);
2014-08-31 17:17:04 -06:00
extern struct bus_type greybus_bus_type;
extern struct device_type greybus_endo_type;
greybus: add module support Modules in the greybus system sit above the interface, so insert them early in the sysfs tree. We dynamically create them when we have an interface that references a module, as we don't get a "module create" message directly. They also dynamically go away when the last interface associated with a module is removed. Naming scheme for modules/interfaces/bundles/connections is bumped up by one ':', and now looks like the following: /sys/bus/greybus $ tree . ├── devices │   ├── 7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7 │   ├── 7:7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7 │   ├── 7:7:0 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0 │   └── 7:7:0:1 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0/7:7:0:1 ├── drivers ├── drivers_autoprobe ├── drivers_probe └── uevent 6 directories, 3 files /sys/bus/greybus $ grep . devices/*/uevent devices/7/uevent:DEVTYPE=greybus_module devices/7:7/uevent:DEVTYPE=greybus_interface devices/7:7:0/uevent:DEVTYPE=greybus_bundle devices/7:7:0:1/uevent:DEVTYPE=greybus_connection We still have some "confusion" about interface ids and module ids, which will be cleaned up later when the svc control protocol changes die down, right now we just name a module after the interface as we don't have any modules that have multiple interfaces in our systems. This has been tested with gbsim. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-21 15:10:26 -07:00
extern struct device_type greybus_module_type;
extern struct device_type greybus_interface_type;
extern struct device_type greybus_bundle_type;
extern struct device_type greybus_connection_type;
static inline int is_gb_endo(const struct device *dev)
{
return dev->type == &greybus_endo_type;
}
greybus: add module support Modules in the greybus system sit above the interface, so insert them early in the sysfs tree. We dynamically create them when we have an interface that references a module, as we don't get a "module create" message directly. They also dynamically go away when the last interface associated with a module is removed. Naming scheme for modules/interfaces/bundles/connections is bumped up by one ':', and now looks like the following: /sys/bus/greybus $ tree . ├── devices │   ├── 7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7 │   ├── 7:7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7 │   ├── 7:7:0 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0 │   └── 7:7:0:1 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0/7:7:0:1 ├── drivers ├── drivers_autoprobe ├── drivers_probe └── uevent 6 directories, 3 files /sys/bus/greybus $ grep . devices/*/uevent devices/7/uevent:DEVTYPE=greybus_module devices/7:7/uevent:DEVTYPE=greybus_interface devices/7:7:0/uevent:DEVTYPE=greybus_bundle devices/7:7:0:1/uevent:DEVTYPE=greybus_connection We still have some "confusion" about interface ids and module ids, which will be cleaned up later when the svc control protocol changes die down, right now we just name a module after the interface as we don't have any modules that have multiple interfaces in our systems. This has been tested with gbsim. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-21 15:10:26 -07:00
static inline int is_gb_module(const struct device *dev)
{
return dev->type == &greybus_module_type;
}
static inline int is_gb_interface(const struct device *dev)
{
return dev->type == &greybus_interface_type;
}
static inline int is_gb_bundle(const struct device *dev)
{
return dev->type == &greybus_bundle_type;
}
static inline int is_gb_connection(const struct device *dev)
{
return dev->type == &greybus_connection_type;
}
static inline bool cport_id_valid(u16 cport_id)
{
return cport_id != CPORT_ID_BAD && cport_id <= CPORT_ID_MAX;
}
#endif /* __KERNEL__ */
#endif /* __LINUX_GREYBUS_H */