做网站可以不写代码,中文网站排名,网站备案流程详细,深圳网站建设怎样做1. 总线BUS
在物理层面上#xff0c;代表不同的工作时序和电平特性#xff1a;
总线代表着同类设备需要共同遵守的工作时序#xff0c;不同的总线对于物理电平的要求是不一样的#xff0c;对于每个比特的电平维持宽度也是不一样#xff0c;而总线上传递的命令也会有自己…1. 总线BUS
在物理层面上代表不同的工作时序和电平特性
总线代表着同类设备需要共同遵守的工作时序不同的总线对于物理电平的要求是不一样的对于每个比特的电平维持宽度也是不一样而总线上传递的命令也会有自己的格式约束。如I2C总线、USB总线、PCI总线等等。以I2C总线为例在同一组I2C总线上连接着不同的I2C设备。
在软件层面上
总线的主要作用是管理设备与驱动。
Linux内核中使用struct bus_type描述一个总线其中包含了该总线的所有信息。
/**所在文件:kernel/msm-5.4/include/linux/device.hkernel/drivers/base/base.h
*/
/*** struct bus_type - The bus type of the device** name: The name of the bus.* dev_name: Used for subsystems to enumerate devices like (foo%u, dev-id).* dev_root: Default device to use as the parent.* bus_groups: Default attributes of the bus.* dev_groups: Default attributes of the devices on the bus.* drv_groups: Default attributes of the device drivers on the bus.* match: Called, perhaps multiple times, whenever a new device or driver* is added for this bus. It should return a positive value if the* given device can be handled by the given driver and zero* otherwise. It may also return error code if determining that* the driver supports the device is not possible. In case of* -EPROBE_DEFER it will queue the device for deferred probing.* uevent: Called when a device is added, removed, or a few other things* that generate uevents to add the environment variables.* probe: Called when a new device or driver add to this bus, and callback* the specific drivers probe to initial the matched device.* sync_state: Called to sync device state to software state after all the* state tracking consumers linked to this device (present at* the time of late_initcall) have successfully bound to a* driver. If the device has no consumers, this function will* be called at late_initcall_sync level. If the device has* consumers that are never bound to a driver, this function* will never get called until they do.* remove: Called when a device removed from this bus.* shutdown: Called at shut-down time to quiesce the device.** online: Called to put the device back online (after offlining it).* offline: Called to put the device offline for hot-removal. May fail.** suspend: Called when a device on this bus wants to go to sleep mode.* resume: Called to bring a device on this bus out of sleep mode.* num_vf: Called to find out how many virtual functions a device on this* bus supports.* dma_configure: Called to setup DMA configuration on a device on* this bus.* pm: Power management operations of this bus, callback the specific* device drivers pm-ops.* iommu_ops: IOMMU specific operations for this bus, used to attach IOMMU* driver implementations to a bus and allow the driver to do* bus-specific setup* p: The private data of the driver core, only the driver core can* touch this.* lock_key: Lock class key for use by the lock validator* need_parent_lock: When probing or removing a device on this bus, the* device core should lock the devices parent.** A bus is a channel between the processor and one or more devices. For the* purposes of the device model, all devices are connected via a bus, even if* it is an internal, virtual, platform bus. Buses can plug into each other.* A USB controller is usually a PCI device, for example. The device model* represents the actual connections between buses and the devices they control.* A bus is represented by the bus_type structure. It contains the name, the* default attributes, the bus methods, PM operations, and the driver cores* private data.*/
struct bus_type {const char *name;const char *dev_name;struct device *dev_root;const struct attribute_group **bus_groups;const struct attribute_group **dev_groups;const struct attribute_group **drv_groups;int (*match)(struct device *dev, struct device_driver *drv);int (*uevent)(struct device *dev, struct kobj_uevent_env *env);int (*probe)(struct device *dev);void (*sync_state)(struct device *dev);int (*remove)(struct device *dev);void (*shutdown)(struct device *dev);int (*online)(struct device *dev);int (*offline)(struct device *dev);int (*suspend)(struct device *dev, pm_message_t state);int (*resume)(struct device *dev);int (*num_vf)(struct device *dev);int (*dma_configure)(struct device *dev);const struct dev_pm_ops *pm;const struct iommu_ops *iommu_ops;struct subsys_private *p;struct lock_class_key lock_key;bool need_parent_lock;ANDROID_KABI_RESERVE(1);ANDROID_KABI_RESERVE(2);ANDROID_KABI_RESERVE(3);ANDROID_KABI_RESERVE(4);
};/*** struct subsys_private - structure to hold the private to the driver core portions of the bus_type/class structure.** subsys - the struct kset that defines this subsystem* devices_kset - the subsystems devices directory* interfaces - list of subsystem interfaces associated* mutex - protect the devices, and interfaces lists.** drivers_kset - the list of drivers associated* klist_devices - the klist to iterate over the devices_kset* klist_drivers - the klist to iterate over the drivers_kset* bus_notifier - the bus notifier list for anything that cares about things* on this bus.* bus - pointer back to the struct bus_type that this structure is associated* with.** glue_dirs - glue directory to put in-between the parent device to* avoid namespace conflicts* class - pointer back to the struct class that this structure is associated* with.** This structure is the one that is the actual kobject allowing struct* bus_type/class to be statically allocated safely. Nothing outside of the* driver core should ever touch these fields.*/
struct subsys_private {struct kset subsys;struct kset *devices_kset;struct list_head interfaces;struct mutex mutex;struct kset *drivers_kset;struct klist klist_devices;struct klist klist_drivers;struct blocking_notifier_head bus_notifier;unsigned int drivers_autoprobe:1;struct bus_type *bus;struct kset glue_dirs;struct class *class;
};
2. 设备device
设备代表真实的、具体的物理器件。
在软件层面上用器件的独特的参数属性来代表该器件。如I2C总线上连接的I2C从设备都有一个标识自己的设备地址由这个设备地址来确定主设备发过来的命令是否该由它来响应。
struct device是一个基类被设备相关的数据结构包含其中包含了该设备的信息。
/*** struct device - The basic device structure* parent: The devices parent device, the device to which it is attached.* In most cases, a parent device is some sort of bus or host* controller. If parent is NULL, the device, is a top-level device,* which is not usually what you want.* p: Holds the private data of the driver core portions of the device.* See the comment of the struct device_private for detail.* kobj: A top-level, abstract class from which other classes are derived.* init_name: Initial name of the device.* type: The type of device.* This identifies the device type and carries type-specific* information.* mutex: Mutex to synchronize calls to its driver.* lockdep_mutex: An optional debug lock that a subsystem can use as a* peer lock to gain localized lockdep coverage of the device_lock.* bus: Type of bus device is on.* driver: Which driver has allocated this* platform_data: Platform data specific to the device.* Example: For devices on custom boards, as typical of embedded* and SOC based hardware, Linux often uses platform_data to point* to board-specific structures describing devices and how they* are wired. That can include what ports are available, chip* variants, which GPIO pins act in what additional roles, and so* on. This shrinks the Board Support Packages (BSPs) and* minimizes board-specific #ifdefs in drivers.* driver_data: Private pointer for driver specific info.* links: Links to suppliers and consumers of this device.* power: For device power management.* See Documentation/driver-api/pm/devices.rst for details.* pm_domain: Provide callbacks that are executed during system suspend,* hibernation, system resume and during runtime PM transitions* along with subsystem-level and driver-level callbacks.* pins: For device pin management.* See Documentation/driver-api/pinctl.rst for details.* msi_list: Hosts MSI descriptors* msi_domain: The generic MSI domain this device is using.* numa_node: NUMA node this device is close to.* dma_ops: DMA mapping operations for this device.* dma_mask: Dma mask (if dmable device).* coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all* hardware supports 64-bit addresses for consistent allocations* such descriptors.* bus_dma_mask: Mask of an upstream bridge or bus which imposes a smaller DMA* limit than the device itself supports.* dma_pfn_offset: offset of DMA memory range relatively of RAM* dma_parms: A low level driver may set these to teach IOMMU code about* segment limitations.* dma_pools: Dma pools (if dmable device).* dma_mem: Internal for coherent mem override.* cma_area: Contiguous memory area for dma allocations* archdata: For arch-specific additions.* of_node: Associated device tree node.* fwnode: Associated device node supplied by platform firmware.* devt: For creating the sysfs dev.* id: device instance* devres_lock: Spinlock to protect the resource of the device.* devres_head: The resources list of the device.* knode_class: The node used to add the device to the class list.* class: The class of the device.* groups: Optional attribute groups.* release: Callback to free the device after all references have* gone away. This should be set by the allocator of the* device (i.e. the bus driver that discovered the device).* iommu_group: IOMMU group the device belongs to.* iommu_fwspec: IOMMU-specific properties supplied by firmware.* iommu_param: Per device generic IOMMU runtime data** offline_disabled: If set, the device is permanently online.* offline: Set after successful invocation of bus types .offline().* of_node_reused: Set if the device-tree node is shared with an ancestor* device.* state_synced: The hardware state of this device has been synced to match* the software state of this device by calling the driver/bus* sync_state() callback.* dma_coherent: this particular device is dma coherent, even if the* architecture supports non-coherent devices.* dma_coherent_hint_cached: Tell the framework to try and treat the device* as DMA coherent when working with CPU cached* buffers.* At the lowest level, every device in a Linux system is represented by an* instance of struct device. The device structure contains the information* that the device model core needs to model the system. Most subsystems,* however, track additional information about the devices they host. As a* result, it is rare for devices to be represented by bare device structures;* instead, that structure, like kobject structures, is usually embedded within* a higher-level representation of the device.*/
struct device {struct kobject kobj;struct device *parent;struct device_private *p;const char *init_name; /* initial name of the device */const struct device_type *type;struct bus_type *bus; /* type of bus device is on */struct device_driver *driver; /* which driver has allocated thisdevice */void *platform_data; /* Platform specific data, devicecore doesnt touch it */void *driver_data; /* Driver data, set and get withdev_set_drvdata/dev_get_drvdata */
#ifdef CONFIG_PROVE_LOCKINGstruct mutex lockdep_mutex;
#endifstruct mutex mutex; /* mutex to synchronize calls to* its driver.*/struct dev_links_info links;struct dev_pm_info power;struct dev_pm_domain *pm_domain;#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAINstruct irq_domain *msi_domain;
#endif
#ifdef CONFIG_PINCTRLstruct dev_pin_info *pins;
#endif
#ifdef CONFIG_GENERIC_MSI_IRQstruct list_head msi_list;
#endifconst struct dma_map_ops *dma_ops;u64 *dma_mask; /* dma mask (if dmaable device) */u64 coherent_dma_mask;/* Like dma_mask, but foralloc_coherent mappings asnot all hardware supports64 bit addresses for consistentallocations such descriptors. */u64 bus_dma_mask; /* upstream dma_mask constraint */unsigned long dma_pfn_offset;struct device_dma_parameters *dma_parms;struct list_head dma_pools; /* dma pools (if dmable) */#ifdef CONFIG_DMA_DECLARE_COHERENTstruct dma_coherent_mem *dma_mem; /* internal for coherent memoverride */
#endif
#ifdef CONFIG_DMA_CMAstruct cma *cma_area; /* contiguous memory area for dmaallocations */
#endif/* arch specific additions */struct dev_archdata archdata;struct device_node *of_node; /* associated device tree node */struct fwnode_handle *fwnode; /* firmware device node */#ifdef CONFIG_NUMAint numa_node; /* NUMA node this device is close to */
#endifdev_t devt; /* dev_t, creates the sysfs dev */u32 id; /* device instance */spinlock_t devres_lock;struct list_head devres_head;struct class *class;const struct attribute_group **groups; /* optional groups */void (*release)(struct device *dev);struct iommu_group *iommu_group;struct iommu_fwspec *iommu_fwspec;struct iommu_param *iommu_param;bool offline_disabled:1;bool offline:1;bool of_node_reused:1;bool state_synced:1;
#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)bool dma_coherent:1;
#endif
#if defined(CONFIG_DMA_COHERENT_HINT_CACHED)bool dma_coherent_hint_cached:1;
#endifANDROID_KABI_RESERVE(1);ANDROID_KABI_RESERVE(2);ANDROID_KABI_RESERVE(3);ANDROID_KABI_RESERVE(4);ANDROID_KABI_RESERVE(5);ANDROID_KABI_RESERVE(6);ANDROID_KABI_RESERVE(7);ANDROID_KABI_RESERVE(8);
};/** The type of device, struct device is embedded in. A class* or bus can contain devices of different types* like partitions and disks, mouse and event.* This identifies the device type and carries type-specific* information, equivalent to the kobj_type of a kobject.* If name is specified, the uevent will contain it in* the DEVTYPE variable.*/
struct device_type {const char *name;const struct attribute_group **groups;int (*uevent)(struct device *dev, struct kobj_uevent_env *env);char *(*devnode)(struct device *dev, umode_t *mode,kuid_t *uid, kgid_t *gid);void (*release)(struct device *dev);const struct dev_pm_ops *pm;
};
/*** struct device_private - structure to hold the private to the driver core portions of the device structure.** klist_children - klist containing all children of this device* knode_parent - node in sibling list* knode_driver - node in driver list* knode_bus - node in bus list* knode_class - node in class list* deferred_probe - entry in deferred_probe_list which is used to retry the* binding of drivers which were unable to get all the resources needed by* the device; typically because it depends on another driver getting* probed first.* async_driver - pointer to device driver awaiting probe via async_probe* device - pointer back to the struct device that this structure is* associated with.* dead - This device is currently either in the process of or has been* removed from the system. Any asynchronous events scheduled for this* device should exit without taking any action.** Nothing outside of the driver core should ever touch these fields.*/
struct device_private {struct klist klist_children;struct klist_node knode_parent;struct klist_node knode_driver;struct klist_node knode_bus;struct klist_node knode_class;struct list_head deferred_probe;struct device_driver *async_driver;struct device *device;u8 dead:1;
};
#define to_device_private_parent(obj) \container_of(obj, struct device_private, knode_parent)
#define to_device_private_driver(obj) \container_of(obj, struct device_private, knode_driver)
#define to_device_private_bus(obj) \container_of(obj, struct device_private, knode_bus)
#define to_device_private_class(obj) \container_of(obj, struct device_private, knode_class)
3. 驱动driver
驱动代表着操作设备的方式和流程。
驱动主要包括两部分
第一是通过对外设的控制寄存器进行编程按总线要求输出时序和命令成功地与外围设备进行交互
第二是对第一步中得到的数据进行处理并向应用层提供特定格式的数据。
struct driver是一个基类被驱动相关的数据结构包含其中包含了该驱动的信息。
/*** struct device_driver - The basic device driver structure* name: Name of the device driver.* bus: The bus which the device of this driver belongs to.* owner: The module owner.* mod_name: Used for built-in modules.* suppress_bind_attrs: Disables bind/unbind via sysfs.* probe_type: Type of the probe (synchronous or asynchronous) to use.* of_match_table: The open firmware table.* acpi_match_table: The ACPI match table.* probe: Called to query the existence of a specific device,* whether this driver can work with it, and bind the driver* to a specific device.* sync_state: Called to sync device state to software state after all the* state tracking consumers linked to this device (present at* the time of late_initcall) have successfully bound to a* driver. If the device has no consumers, this function will* be called at late_initcall_sync level. If the device has* consumers that are never bound to a driver, this function* will never get called until they do.* remove: Called when the device is removed from the system to* unbind a device from this driver.* shutdown: Called at shut-down time to quiesce the device.* suspend: Called to put the device to sleep mode. Usually to a* low power state.* resume: Called to bring a device from sleep mode.* groups: Default attributes that get created by the driver core* automatically.* dev_groups: Additional attributes attached to device instance once the* it is bound to the driver.* pm: Power management operations of the device which matched* this driver.* coredump: Called when sysfs entry is written to. The device driver* is expected to call the dev_coredump API resulting in a* uevent.* p: Driver cores private data, no one other than the driver* core can touch this.** The device driver-model tracks all of the drivers known to the system.* The main reason for this tracking is to enable the driver core to match* up drivers with new devices. Once drivers are known objects within the* system, however, a number of other things become possible. Device drivers* can export information and configuration variables that are independent* of any specific device.*/
struct device_driver {const char *name;struct bus_type *bus;struct module *owner;const char *mod_name; /* used for built-in modules */bool suppress_bind_attrs; /* disables bind/unbind via sysfs */enum probe_type probe_type;const struct of_device_id *of_match_table;const struct acpi_device_id *acpi_match_table;int (*probe) (struct device *dev);void (*sync_state)(struct device *dev);int (*remove) (struct device *dev);void (*shutdown) (struct device *dev);int (*suspend) (struct device *dev, pm_message_t state);int (*resume) (struct device *dev);const struct attribute_group **groups;const struct attribute_group **dev_groups;const struct dev_pm_ops *pm;void (*coredump) (struct device *dev);struct driver_private *p;ANDROID_KABI_RESERVE(1);ANDROID_KABI_RESERVE(2);ANDROID_KABI_RESERVE(3);ANDROID_KABI_RESERVE(4);
};struct driver_private {struct kobject kobj;struct klist klist_devices;struct klist_node knode_bus;struct module_kobject *mkobj;struct device_driver *driver;
};
#define to_driver(obj) container_of(obj, struct driver_private, kobj)4. bus device driver三者关系 上图为平台总线设备驱动模型的整体框架。
在总线设备驱动模型中需关心总线、设备和驱动这3个实体总线将设备和驱动绑定。
1驱动向总线注册的流程
当系统向内核注册每一个驱动程序时都要通过调用驱动注册函数xxx_driver_register将驱动程序注册到总线并将其放入所属总线的drv链表中注册驱动的时候会调用所属总线的match函数寻找该总线上与之匹配的每一个设备如果找到与之匹配的设备则会调用相应的probe函数将相应的设备和驱动进行绑定
2设备向总线注册的流程
同样的当系统向内核注册每一个设备时都要通过调用设备注册函数xxx_device_register将设备注册到总线并将其放入所属总线的dev链表中注册设备的时候同样也会调用所属总线的match函数寻找该总线上与之匹配的每一个驱动程序如果找到与之匹配的驱动程序时会调用相应的probe函数将相应的设备和驱动进行绑定而这一匹配的过程是由总线自动完成的。
3总线管理
总线在匹配设备和驱动之后驱动要考虑一个这样的问题设备对应的软件数据结构代表着静态的信息真实的物理设备此时是否正常还不一定因此驱动需要探测这个设备是否正常。总线的管理代码中会有这样的逻辑 if(match(device, driver) OK)driver-probe();
总线匹配设备和驱动之后驱动探测到设备正常开始创建设备文件。调用class_create()、device_create()函数在/dev目录下创建相应的设备文件其内部原理是通过sysfs文件系统、uevent事件通知机制和后台应用服务mdev程序配合能够成功地在/dev目录创建对应的设备文件。
【创建设备文件的两种方式
1手动创建mknod命令
在驱动程序insmod成功之后通过mknod命令手动创建设备文件至/dev目录下mknod /dev/xxx c 主设备号 次设备号。c表示字符设备、b表示块设备、p表示网络设备
2自动创建设备文件mdev
在设备驱动注册到系统后调用class_create为该设备在/sys/class目录下创建一个设备类再调用device_create函数为每个设备创建对应的设备并通过uevent机制调用mdev嵌入式linux由busybox提供来调用mknod创建设备文件至/dev目录下。
详情参考https://www.cnblogs.com/linfeng-learning/p/9316224.html 】
5. 什么是设备树
设备树描述开发板上总线所连接的设备的硬件信息并指定所匹配的驱动。 6. 设备树形态
DTSdevcie tree source设备树源码文件 DTBdevice tree binary将 .dts 编译后得到二进制文件下载到 DDR 中的是 .dtb 文件 DTCdevice tree compiler将 .dts 编译为 .dtb 的编译工具它有个文件夹经过编译后得到
7. 设备树关键内容解析
设备树由一系列的节点和属性组成节点可包含子节点。在设备树中可描述的信息包括 CPU数量和类型内存基地址和大小总线和桥外设连接中断控制器和中断使用情况GPIO控制器和GPIO使用情况时钟控制器和时钟使用情况 compatible
compatible 属性值为字符串列表⽤于将设备和驱动绑定起来字符串列表⽤于选择设备所要使用的驱动程序。
model 属性
model 属性描述设备模块信息比如名字什么的如model “XXX”。
#address-cells 和 #size-cells 属性
#address-cells 和 #size-cells 描述⼦节点应如何编写 reg 属性值
#address-cells表示用于表示reg的地址的长度
#size-cells 从起始地址开始的寄存器值所占用的地址空间长度
中断号和电平触发方式
interrupts X Y ; //中断号为X触发方式为Y
#电平触发方式定义 1 low-to-high edge triggered 2 high-to-low edge triggered 4 active high level-sensitive 8 active low level-sensitive
8. 设备树和驱动的配合流程 系统启动时会解析dtb将获得的设备树的所有信息体现在设备文件中/proc/device-tree目录下根据节点名字创建不同设备节点文件夹后续驱动初始化时如果需要获得对应设备的信息可以通过如下提供的系统函数来获得 查找节点of_find_node_by_path 函数通过指定全路径来查找指定节点。 提取属性值of_find_property 函数 获取到的值保存到了 property 结构体中。 读取属性中字符串值of_property_read_string 函数。 读取属性中数组数据of_property_read_u32_array 函数常用于一次读取 reg 属性的所有数据。 直接内存映射of_iomap 函数获取内存地址所对应的虚拟地址(用于将硬件设备的寄存器的物理地址映射到进程空间的虚拟地址空间中便于访问和操作)
