David Collins | 2369cc4 | 2013-03-25 15:57:34 -0700 | [diff] [blame^] | 1 | Introduction |
| 2 | ============ |
| 3 | |
| 4 | BIF (Battery Interface) is a MIPI (Mobile Industry Processor Interface) |
| 5 | Alliance specification for a serial interface between a host device and a |
| 6 | battery pack. It provides a means to handle smart battery packs which can |
| 7 | communicate over BIF as well as low cost battery packs which provide no |
| 8 | serial communication interface. |
| 9 | |
| 10 | The BIF bus supports 1 master and up to 256 slaves. It supports data rates |
| 11 | up to 250 kbps. The master is in charge of initiating all bus |
| 12 | communications. Slaves may only respond asynchronously when they need to |
| 13 | signal the master that they have an interrupt pending and when the bus is |
| 14 | configured for interrupt mode. |
| 15 | |
| 16 | The BIF framework consists of a core into which BIF controller drivers |
| 17 | register. At runtime, consumers are notified of various events (e.g. battery |
| 18 | insertion and battery removal) via a notifier. Various framework functions are |
| 19 | available for consumers to read and write slave registers as well as to send |
| 20 | arbitrary BIF commands on the bus. |
| 21 | |
| 22 | Hardware description |
| 23 | ==================== |
| 24 | |
| 25 | The BIF bus is a 1-wire wired-or interface. The bus signal is referred to as |
| 26 | the battery communication line (BCL). The BCL is pulled high by a resistor on |
| 27 | the host side and is driven low when the master or one of the slaves is |
| 28 | communicating. Additionally, there is a pull down resistor in the battery |
| 29 | pack which is used to identify whether or not the battery pack has BIF slaves. |
| 30 | Battery removal detection is achieved by comparing the analog voltage of the BCL |
| 31 | when idle to the host side reference voltage. If these voltages are within a |
| 32 | certain threshold, then a battery pack is not present. |
| 33 | |
| 34 | Slaves are addressed on the BIF bus using an 8-bit device address (DEV_ADR). |
| 35 | Notably, it is possible for no slaves to have defined DEV_ADR. In this case, |
| 36 | slave addressing is achieved via the always present unique ID (UID). The UID |
| 37 | of a slave is 80 bits long and guaranteed to be globally unique. A UID search |
| 38 | algorithm can be followed in order determine the UID of all slaves on the bus. |
| 39 | |
| 40 | BIF slaves come in two varieties: primary and secondary. A single primary |
| 41 | slave may be present on the battery pack and a single primary slave may be |
| 42 | present on the host. A battery pack primary slave has DEV_ADR=0x01. The |
| 43 | DEV_ADR of a host primary slave is set by the manufacturer. A given primary |
| 44 | slave contains a list of the UIDs of all secondary slaves in the same |
| 45 | subsystem. This provides a fast mechanism to determine the address of all |
| 46 | slaves without having to resort to the lengthy UID search algorithm. |
| 47 | |
| 48 | Each slave has a 64 kB address space. Part of this address space consists of |
| 49 | generic DDB L1 and L2 data structures at known addresses. This allows for |
| 50 | runtime discovery of supported battery properties and functions of a given |
| 51 | smart battery pack. |
| 52 | |
| 53 | System Diagram: |
| 54 | +-------------------------------+ +---------------------------------+ |
| 55 | | Host | | Smart Battery Pack | |
| 56 | | | | | |
| 57 | | Vbat-<+>-------<+>----------------------------+ | |
| 58 | | | | | | |
| 59 | | +--------------+ | | +--------------+ | | |
| 60 | | | Master BIF<+>-+---------<+>--BCL--<+>------+-<+>BIF Primary | | | |
| 61 | | | | | | | | | Slave | | | |
| 62 | | +--------------+ | | | | +--------------+ | | |
| 63 | | | | | | | | |
| 64 | | + - - - - - - -+ | | | | + - - - - - - -+ | | |
| 65 | | | Primary BIF<+>-+ | | +-<+>BIF Secondary| | | |
| 66 | | | Slave | | | | | | Slave | | | |
| 67 | | +- - - - - - - + | | | | +-- - - - - - -+ | | |
| 68 | | | | | | | | |
| 69 | | + - - - - - - -+ | | | | + - - - - - - -+ | | |
| 70 | | |Secondary BIF<+>-+ | | +-<+>BIF Secondary| | | |
| 71 | | |Slave | | | | | | Slave | | | |
| 72 | | +- - - - - - - + | | | | +-- - - - - - -+ | | |
| 73 | | / | | / | | |
| 74 | | Vref \ Rpu | | Rid \ ---- | |
| 75 | | ___ / | | / Battery -- | |
| 76 | | | \ | | \ Cell ---- | |
| 77 | | +-------+ | | | -- | |
| 78 | | | | | | | |
| 79 | | GND-<+>-------<+>------+---------------------+ | |
| 80 | | | | | |
| 81 | +-------------------------------+ +---------------------------------+ |
| 82 | |
| 83 | An overview of BIF is available at: |
| 84 | http://mipi.org/specifications/battery-interface |
| 85 | |
| 86 | Software description |
| 87 | ==================== |
| 88 | |
| 89 | A given BIF hardware interface driver registers as a BIF controller in the |
| 90 | BIF framework during its probe function. The controller specifies a set of |
| 91 | callback functions which are used by the BIF framework to initiate bus |
| 92 | transactions (e.g. register read, register write, wait for slave interrupt) |
| 93 | and to configure the bus. The framework exposes a small API to controllers |
| 94 | which is used to notify the framework about asynchronous events such as |
| 95 | battery pack insertion/removal and slave interrupts. |
| 96 | |
| 97 | A given BIF consumer is linked to a BIF controller by specifying a property |
| 98 | in the consumer's device tree node which takes as its value the phandle of |
| 99 | the BIF controller's device tree node. |
| 100 | |
| 101 | A consumer driver calls a get function during its probe function with its |
| 102 | device pointer in order to get a handle to the BIF controller if it has probed. |
| 103 | If it hasn't, then ERR_PTR(-EPROBE_DEFER) is returned. The controller handle |
| 104 | can be used directly by the consumer to issue raw bus transactions if needed. |
| 105 | The controller handle can then be used to query which slaves are currently |
| 106 | present on the bus, if any. Handles to these slaves may be used by a consumer |
| 107 | driver in high level framework APIs such as register read and register write |
| 108 | which are slave oriented. All BIF framework API functions are synchronous, |
| 109 | blocking, and can sleep. |
| 110 | |
| 111 | Consumer drivers may also register a notifier function which is called when |
| 112 | certain bus activities occur such as battery pack insertion and removal. |
| 113 | Additionally, consumer drivers may register a notifier function which is called |
| 114 | when a specified slave interrupt fires. |
| 115 | |
| 116 | The framework maintains several linked-lists. One list contains all controllers |
| 117 | that have been registered. A second list contains all slaves that have been |
| 118 | seen since the system booted as well as a flag to indicate if they are currently |
| 119 | present or not. This scheme is used to avoid issues with slave handles existing |
| 120 | after a slave is removed and also so that function and object values do not have |
| 121 | to be searched when a slave is reinserted in the system since slaves are |
| 122 | globally unique and these features are read-only. Two further lists are |
| 123 | maintained inside slave device structures which contain BIF functions and |
| 124 | objects found in the slave. API functions are provided so that consumers can |
| 125 | find functions supported by slaves. |
| 126 | |
| 127 | Design |
| 128 | ====== |
| 129 | |
| 130 | Design Goals: |
| 131 | One major goal of the BIF framework is to provide a uniform API for BIF |
| 132 | consumers to communicate with battery packs. This ensures that consumers are |
| 133 | unaffected by changes in the controller driver which actually interfaces with |
| 134 | the BCL at a hardware level. |
| 135 | |
| 136 | Another goal of the framework is to ensure the BIF bus can be shared between |
| 137 | multiple consumers in a simple and functionally correct way. Locking is used |
| 138 | inside of the framework to provide mutual exclusion on the bus. |
| 139 | |
| 140 | The framework also exposes features that almost all consumers will need, such |
| 141 | as BIF slave identification and BIF function enumeration within a given slave. |
| 142 | |
| 143 | The framework allows consumers to issue very specific bus commands which may |
| 144 | not be used within high level APIs. This provides maximum flexibility so |
| 145 | that consumers can make use of manufacturer defined bus commands which cannot be |
| 146 | handled in a generic fashion. |
| 147 | |
| 148 | Design Trade-offs: |
| 149 | The choice to not treat BIF like a traditional Linux bus was made because |
| 150 | there is nothing within BIF that naturally maps to a device on the bus for a |
| 151 | driver to manage. Slave devices would be a good candidate except that |
| 152 | consumers will not be managing slaves so much as functions exposed within |
| 153 | slaves. Bus matching could then instead be made at a BIF slave function |
| 154 | level. Unfortunately, the BIF specification allows for manufacturer specific |
| 155 | features to reside at any non-defined addresses. Additionally, consumers may |
| 156 | wish only to read and make policy decisions based on BIF non-volatile memory |
| 157 | (NVM) objects read out of memory. Thus, there are use-cases that require |
| 158 | consumers to utilize the bus without having a particular function to match to. |
| 159 | |
| 160 | Another trade-off was the choice to use custom interrupt handling functions |
| 161 | instead of the Linux interrupt framework. This choice was made because there is |
| 162 | no obvious way to handle IRQ chip registration given the dynamic nature of BIF |
| 163 | slaves (i.e. slaves may come and go at runtime if battery packs are swapped). |
| 164 | |
| 165 | Software layering: |
| 166 | BIF controller drivers register a set of callback functions with the BIF |
| 167 | framework which implement various BIF transaction primitives. These |
| 168 | callbacks ensure that tight timing constraints are met such as when receiving |
| 169 | a bus query response immediately after issuing a command. Such actions |
| 170 | cannot be carried out at the framework level as timing requirements are on |
| 171 | the order of 32 us when using the maximum data rate. |
| 172 | |
| 173 | The BIF framework provides easy access to standard BIF features such as |
| 174 | slave, functions, and interrupts. The framework also ensures mutual exclusion |
| 175 | between different BIF consumers. |
| 176 | |
| 177 | BIF consumer drivers make use of the API exposed by the framework in order |
| 178 | utilize functionality found on smart battery packs. One example of a |
| 179 | consumer driver is a temperature monitoring driver which reads the |
| 180 | temperature reported by the BIF temperature function on a BIF slave and |
| 181 | reports it to the Linux thermal framework. |
| 182 | |
| 183 | Power Management |
| 184 | ================ |
| 185 | |
| 186 | The framework does not perform any special actions during system suspend and |
| 187 | resume. Controller drivers may choose to enter low power states during |
| 188 | suspend if they wish as long as it does not affect the logical state of the |
| 189 | bus. |
| 190 | |
| 191 | SMP/multi-core |
| 192 | ============== |
| 193 | |
| 194 | Various linked lists are maintained inside of the framework which are |
| 195 | protected by mutexes. Mutex locks are also used during transactions at a bus |
| 196 | level in order to ensure mutual exclusion between consumers of the bus. |
| 197 | |
| 198 | Performance |
| 199 | =========== |
| 200 | |
| 201 | The BIF bus is inherently slow. Consumers should expect transactions to take |
| 202 | a long time to execute. Consumers are responsible for blocking suspend if |
| 203 | their transactions must be completed before the system enters suspend. |
| 204 | |
| 205 | Interface - BIF Consumer API |
| 206 | ============================ |
| 207 | |
| 208 | BIF framework structs, enums, and functions used by BIF consumers are defined in |
| 209 | include/linux/bif/consumer.h |
| 210 | |
| 211 | Detailed descriptions of the BIF framework functions can be found in: |
| 212 | drivers/bif/bif-core.c |
| 213 | |
| 214 | Get/put handle for a BIF controller: |
| 215 | ------------------------------------ |
| 216 | |
| 217 | struct bif_ctrl *bif_ctrl_get(struct device *consumer_dev); |
| 218 | |
| 219 | void bif_ctrl_put(struct bif_ctrl *ctrl); |
| 220 | |
| 221 | int bif_ctrl_count(void); |
| 222 | |
| 223 | struct bif_ctrl *bif_ctrl_get_by_id(unsigned int id); |
| 224 | |
| 225 | The function bif_ctrl_get() is intended to be the primary way to get a consumer |
| 226 | BIF controller handle. It relies upon the consumer device specifying a |
| 227 | "qcom,bif-ctrl" property in its device tree node which points to the phandle of |
| 228 | the BIF controller it wishes to use. |
| 229 | |
| 230 | A secondary mechanism is also provided for drivers without device tree support. |
| 231 | bif_ctrl_count() returns the number of BIF controllers currently registered. |
| 232 | bif_ctrl_get_by_id() returns a handle to the id'th controller enumerated in |
| 233 | registration order. |
| 234 | |
| 235 | Get/put handle for a BIF slave: |
| 236 | ------------------------------- |
| 237 | |
| 238 | int bif_slave_match_count(const struct bif_ctrl *ctrl, |
| 239 | const struct bif_match_criteria *match_criteria); |
| 240 | |
| 241 | struct bif_slave *bif_slave_match_get(const struct bif_ctrl *ctrl, |
| 242 | unsigned int id, const struct bif_match_criteria *match_criteria); |
| 243 | |
| 244 | void bif_slave_put(struct bif_slave *slave); |
| 245 | |
| 246 | A consumer finds a slave attached to a given BIF controller by specifying a set |
| 247 | of matching criteria. The criteria can include such quantities as manufacturer |
| 248 | ID, product ID, function type or function version. It is possible that multiple |
| 249 | slaves will match the criteria. bif_slave_match_count() returns how many slaves |
| 250 | match the specified criteria. bif_slave_match_get() returns the id'th slave |
| 251 | which matches the criteria in an arbitrary, but fixed order (for a constant set |
| 252 | of slaves). Consumer drivers need to be able to handle the case of multiple |
| 253 | slaves matching the criteria. |
| 254 | |
| 255 | Additionally, if a battery pack is inserted or removed, then the output of |
| 256 | bif_slave_match_count() and bif_slave_match_get() could change. A consumer |
| 257 | driver can register to receive notification of battery pack insertion and |
| 258 | removal using the bif_ctrl_notifier_register() function listed below. |
| 259 | |
| 260 | Check if slave handle is still meaningful: |
| 261 | ------------------------------------------ |
| 262 | |
| 263 | int bif_slave_is_present(struct bif_slave *slave); |
| 264 | |
| 265 | If a battery pack is removed, then the handles for its slaves will no longer be |
| 266 | meaningful. All transactions using a handle for a slave that isn't present will |
| 267 | fail. The function bif_slave_is_present() allows a consumer to determine if |
| 268 | a given slave is still physically present in the system. |
| 269 | |
| 270 | Get access to the controller handle present in a slave handle: |
| 271 | -------------------------------------------------------------- |
| 272 | |
| 273 | struct bif_ctrl *bif_get_ctrl_handle(struct bif_slave *slave); |
| 274 | |
| 275 | This function is useful if a consumer wishes to only store a slave handle but |
| 276 | also has need to call bus oriented BIF framework functions. |
| 277 | |
| 278 | Get version and register offset of a BIF function if it is present in a slave: |
| 279 | ------------------------------------------------------------------------------ |
| 280 | |
| 281 | int bif_slave_find_function(struct bif_slave *slave, u8 function, u8 *version, |
| 282 | u16 *function_pointer); |
| 283 | |
| 284 | This function is used by consumers who wish to support given BIF functions |
| 285 | (e.g. temperature measurement, authentication, etc.) found inside of slaves. |
| 286 | |
| 287 | Receive notification upon battery insertion and removal: |
| 288 | -------------------------------------------------------- |
| 289 | |
| 290 | int bif_ctrl_notifier_register(struct bif_ctrl *ctrl, |
| 291 | struct notifier_block *nb); |
| 292 | |
| 293 | int bif_ctrl_notifier_unregister(struct bif_ctrl *ctrl, |
| 294 | struct notifier_block *nb); |
| 295 | |
| 296 | |
| 297 | Read or write BIF slave registers: |
| 298 | ---------------------------------- |
| 299 | |
| 300 | int bif_slave_read(struct bif_slave *slave, u16 addr, u8 *buf, int len); |
| 301 | |
| 302 | int bif_slave_write(struct bif_slave *slave, u16 addr, u8 *buf, int len); |
| 303 | |
| 304 | |
| 305 | Get or set the BIF bus state or period: |
| 306 | --------------------------------------- |
| 307 | |
| 308 | int bif_ctrl_get_bus_state(struct bif_ctrl *ctrl); |
| 309 | |
| 310 | int bif_ctrl_set_bus_state(struct bif_ctrl *ctrl, enum bif_bus_state state); |
| 311 | |
| 312 | int bif_ctrl_get_bus_period(struct bif_ctrl *ctrl); |
| 313 | |
| 314 | int bif_ctrl_set_bus_period(struct bif_ctrl *ctrl, int period_ns); |
| 315 | |
| 316 | Bus states include: active for communication, active waiting for interrupt, |
| 317 | standby, and power down. The MIPI-BIF specification defines the allowed range |
| 318 | of bus periods as 2000 ns to 153000 ns. Individual controllers may further |
| 319 | restrict the range of allowed periods. When bif_ctrl_set_bus_period() is called |
| 320 | the first supported period that greater than or equal to the specified period |
| 321 | will be set. |
| 322 | |
| 323 | Measure battery pack resistance: |
| 324 | -------------------------------- |
| 325 | |
| 326 | int bif_ctrl_measure_rid(struct bif_ctrl *ctrl); |
| 327 | |
| 328 | This function returns an estimate of the battery pack resistance in ohms. If |
| 329 | no battery pack is connected, then the output of this function is undefined. |
| 330 | |
| 331 | Utilize BIF slave tasks and interrupts: |
| 332 | --------------------------------------- |
| 333 | |
| 334 | int bif_request_irq(struct bif_slave *slave, unsigned int task, |
| 335 | struct notifier_block *nb); |
| 336 | |
| 337 | int bif_free_irq(struct bif_slave *slave, unsigned int task, |
| 338 | struct notifier_block *nb); |
| 339 | |
| 340 | int bif_trigger_task(struct bif_slave *slave, unsigned int task); |
| 341 | |
| 342 | int bif_task_is_busy(struct bif_slave *slave, unsigned int task); |
| 343 | |
| 344 | A consumer can request a slave interrupt and specify a notifier to call when the |
| 345 | interrupt is triggered. Once the interrupt is requested the consumer will need |
| 346 | to call bif_trigger_task() in order to start the task associated with the |
| 347 | interrupt (both are identified by the same index). Polling for task completion |
| 348 | is also supported via the bif_task_is_busy() function. |
| 349 | |
| 350 | Raw BIF bus transactions: |
| 351 | ------------------------- |
| 352 | |
| 353 | void bif_ctrl_bus_lock(struct bif_ctrl *ctrl); |
| 354 | |
| 355 | void bif_ctrl_bus_unlock(struct bif_ctrl *ctrl); |
| 356 | |
| 357 | int bif_ctrl_raw_transaction(struct bif_ctrl *ctrl, int transaction, u8 data); |
| 358 | |
| 359 | int bif_ctrl_raw_transaction_read(struct bif_ctrl *ctrl, int transaction, |
| 360 | u8 data, int *response); |
| 361 | |
| 362 | int bif_ctrl_raw_transaction_query(struct bif_ctrl *ctrl, int transaction, |
| 363 | u8 data, bool *query_response); |
| 364 | |
| 365 | int bif_slave_is_selected(struct bif_slave *slave); |
| 366 | |
| 367 | int bif_slave_select(struct bif_slave *slave); |
| 368 | |
| 369 | The function bif_ctrl_bus_lock() locks the BIF bus for exclusive use by the |
| 370 | consumer. No other transactions will be allowed on the bus including those |
| 371 | that would arise from battery insertion/removal or slave interrupt reception. |
| 372 | This lock is primarily intended to be used along with the raw transaction |
| 373 | functions. These functions allow a consumer to issue any BIF transaction |
| 374 | including manufacturer specific bus commands not handled by the BIF framework. |
| 375 | |
| 376 | While performing raw transactions, features normally performed transparently by |
| 377 | the core, such as device selection, are not available. The functions |
| 378 | bif_slave_select() and bif_slave_is_selected() can be used to fill in this gap |
| 379 | so that raw transactions are performed on the desired slave. |
| 380 | |
| 381 | Notify the BIF core that a battery has been inserted or removed: |
| 382 | ---------------------------------------------------------------- |
| 383 | |
| 384 | int bif_ctrl_signal_battery_changed(struct bif_ctrl *ctrl); |
| 385 | |
| 386 | This function should only be called on systems where the BIF controller driver |
| 387 | is architecturally unable to detect battery insertion and removal on its own. |
| 388 | |
| 389 | Perform BIF object CRC using CRC-CCITT algorithm: |
| 390 | ------------------------------------------------- |
| 391 | |
| 392 | u16 bif_crc_ccitt(const u8 *buffer, int len); |
| 393 | |
| 394 | Interface - BIF Controller API |
| 395 | ============================== |
| 396 | |
| 397 | BIF framework structs and functions used by BIF controllers are defined in: |
| 398 | include/linux/bif/driver.h |
| 399 | |
| 400 | Ops found in struct bif_ctrl_ops: |
| 401 | --------------------------------- |
| 402 | |
| 403 | int (*bus_transaction) (struct bif_ctrl_dev *bdev, int transaction, u8 data); |
| 404 | |
| 405 | int (*bus_transaction_query) (struct bif_ctrl_dev *bdev, int transaction, |
| 406 | u8 data, bool *query_response); |
| 407 | |
| 408 | int (*bus_transaction_read) (struct bif_ctrl_dev *bdev, int transaction, |
| 409 | u8 data, int *response); |
| 410 | |
| 411 | int (*read_slave_registers) (struct bif_ctrl_dev *bdev, u16 addr, |
| 412 | u8 *data, int len); |
| 413 | |
| 414 | int (*write_slave_registers) (struct bif_ctrl_dev *bdev, u16 addr, |
| 415 | const u8 *data, int len); |
| 416 | |
| 417 | int (*get_bus_period) (struct bif_ctrl_dev *bdev); |
| 418 | |
| 419 | int (*set_bus_period) (struct bif_ctrl_dev *bdev, int period_ns); |
| 420 | |
| 421 | int (*get_battery_presence) (struct bif_ctrl_dev *bdev); |
| 422 | |
| 423 | int (*get_battery_rid) (struct bif_ctrl_dev *bdev); |
| 424 | |
| 425 | int (*get_bus_state) (struct bif_ctrl_dev *bdev); |
| 426 | |
| 427 | int (*set_bus_state) (struct bif_ctrl_dev *bdev, int state); |
| 428 | |
| 429 | A BIF controller driver registers a set of call back functions which instantiate |
| 430 | these ops. The BIF framework then calls these functions based on internal and |
| 431 | consumer needs. |
| 432 | |
| 433 | The ops bus_transaction(), bus_transaction_query(), and bus_transaction_read() |
| 434 | carry out the controller hardware specific actions to perform BIF transactions |
| 435 | on the BIF bus. These transactions result in no slave response, a pulse in |
| 436 | response, or a word in response respectively. The ops read_slave_registers() |
| 437 | and write_slave_registers() internally must perform all transactions necessary |
| 438 | to read and write to BIF slave registers. These ops exist so that burst reads |
| 439 | and writes can take place since these activities have very tight timing |
| 440 | constraints that the BIF core cannot handle. |
| 441 | |
| 442 | The ops get_bus_period() and set_bus_period() return the current bus clock base |
| 443 | period in nanoseconds and change the period to a new value respectively. The |
| 444 | ops get_bus_state() and set_bus_state() allow for monitoring and controlling the |
| 445 | bus state (i.e. active for communication, active waiting for interrupt, standby, |
| 446 | or power down). The op get_battery_presence() returns if any battery pack |
| 447 | (smart or low cost) is currently connected to the BCL. The op get_battery_rid() |
| 448 | returns a best estimate of the Rid battery pack pull down ID resistance in ohms |
| 449 | which can be used to determine if the battery pack is smart or low cost. |
| 450 | |
| 451 | Register/unregister a BIF controller: |
| 452 | ------------------------------------- |
| 453 | |
| 454 | struct bif_ctrl_dev *bif_ctrl_register(struct bif_ctrl_desc *bif_desc, |
| 455 | struct device *dev, void *driver_data, struct device_node *of_node); |
| 456 | |
| 457 | void bif_ctrl_unregister(struct bif_ctrl_dev *bdev); |
| 458 | |
| 459 | Notify the BIF framework that a battery has been inserted or removed: |
| 460 | --------------------------------------------------------------------- |
| 461 | |
| 462 | int bif_ctrl_notify_battery_changed(struct bif_ctrl_dev *bdev); |
| 463 | |
| 464 | The BIF core will then call the get_battery_presence() op internally to |
| 465 | determine if the event is an insertion or removal. |
| 466 | |
| 467 | Notify the BIF framework that a slave interrupt has been received: |
| 468 | ------------------------------------------------------------------ |
| 469 | |
| 470 | int bif_ctrl_notify_slave_irq(struct bif_ctrl_dev *bdev); |
| 471 | |
| 472 | Upon receiving this call, the BIF core interrogates each slave to determine |
| 473 | which slaves have pending interrupts. It then iterates through all interrupts |
| 474 | on those slaves clearing all pending interrupts and notifying any consumers |
| 475 | waiting for the interrupts. |
| 476 | |
| 477 | Get BIF controller private data: |
| 478 | -------------------------------- |
| 479 | |
| 480 | void *bdev_get_drvdata(struct bif_ctrl_dev *bdev); |
| 481 | |
| 482 | Config options |
| 483 | ============== |
| 484 | |
| 485 | CONFIG_BIF - Enables BIF framework support. |
| 486 | |
| 487 | User space utilities |
| 488 | ==================== |
| 489 | |
| 490 | No user space interface is provided in the BIF framework. Therefore, user |
| 491 | space will not be able to directly use it. |
| 492 | |
| 493 | To do |
| 494 | ===== |
| 495 | |
| 496 | It is conceivable that the BIF framework should take some action during |
| 497 | system suspend and resume. However, it is not clear exactly what should be |
| 498 | done given that the BCL would still need to be active in order to detect |
| 499 | battery removal while suspended. |
| 500 | |
| 501 | sysfs nodes could be added which describe slaves as well as functions and |
| 502 | objects within the slaves. However these nodes would be read-only and would |
| 503 | really only be useful for descriptive as opposed to control purposes. |
| 504 | |
| 505 | The exact time at which slave searching, function enumeration, and object |
| 506 | loading takes place could be optimized in order to improve performance to |
| 507 | some degree. It could also be made configurable at a controller level if |
| 508 | needed. |