[WIP][POC][RFC] Generic Device Data Context #47446
Conversation
Rename existing struct device_state to struct device_context as this structure will hold more than just state stuff. Remove struct device's state attribute, saving some ROM space. Instead order the device_contexts sections the same way as the devices one so a device context can be easily retrieved from it's device pointer (same "index" in the list of device context). Signed-off-by: Tomasz Bursztyka <[email protected]>
- Make it as a unique bitfield of 32 unsigned integer - Clarify init_res attribute documentation Signed-off-by: Tomasz Bursztyka <[email protected]>
Some device may use a generic object (such as MMIO) on their data structure, but there is no possibility to combine multiple generic objects. Thus introducing a generic device data context, known as 'ddc', to solve this issue. This will permit, with a good flexibility, to mix mmio and device domain statistics, or device generic control (in a near future) mechanism object. All without bloating ROM and RAM usage. Signed-off-by: Tomasz Bursztyka <[email protected]>
Can be used, via DDC, to protect device's access by 2+ threads. This will require using device_get/device_release functions inside each exposed API related functions. Signed-off-by: Tomasz Bursztyka <[email protected]>
Up to i2c drivers to use DDC accordingly in order to get the statistics for themselves. The changes are minimal per-driver, and will enable using other generic objects as well in the future. Signed-off-by: Tomasz Bursztyka <[email protected]>
This adds a synchronization semaphore to generalize call synchronization among all device drivers. This will permit to avoid for drivers maintainers to implement their own solution. This makes use of DDC. Signed-off-by: Tomasz Bursztyka <[email protected]>
There will be more specific tests inside tests/kernel/device Signed-off-by: Tomasz Bursztyka <[email protected]>
This is testing generic locking and syncing on device calls. Signed-off-by: Tomasz Bursztyka <[email protected]>
tbursztyka
requested review from
MaureenHelm,
andy-liu-telink,
andyross,
dcpleung,
galak,
nashif and
tejlmand
as code owners
zephyrbot
added
area: I2C
area: Base OS
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This shouldn't be closed yet, and I'm intrigued by the ideas here |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
4 participants
Note: this is a WIP. It's not ready yet (a few modification still required to get the test working), it's only published in this PR for pre-review.
This is at attempt to solve the issues that came up during #44693, but it goes way beyond the original idea of bringing generic control mechanism for device instances.
Instead, it tries to normalize (not generalize: this is totally optional and can be used only per device instance, on the contrary to previous referenced PR) device context into it's data pointer. Such context can be about concurrent access (control mechanism) but also statistics (on i2c or can), or anything else sufficiently generic that could exist among a bunch drivers.
Doing it that way solves all the issues from previous PR:
Current implementation is only meant to be a PoC. Naming, technical choices (like the q&d python script) may change. It's only there to present the idea.