/alps/pcitool

To get this branch, use:
bzr branch http://suren.me/webbzr/alps/pcitool

« back to all changes in this revision

Viewing changes to docs/ToDo

  • Committer: Suren A. Chilingaryan
  • Date: 2015-09-24 02:28:45 UTC
  • mfrom: (305.1.19 views)
  • Revision ID: csa@suren.me-20150924022845-p7hc8lh8v0q48g0r
Finalyze XML support and provide initial support for views (only descriptions so far)

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/ToDo
1
1
High Priority (we would need it for IPE Camera)
2
2
=============
3
 
 1. Allow overriding of registers and banks (performance?).
 
3
 1. Join multiple XML files and on error use simplified XSD scheme on all files to find the file causing error
 
4
 2. Universal tree-style api to access the independent views, frontend all registers as well (pci -l /register; pci -r /register/reg1; pci -r /sensor/width;) Unit is path of the view /view[:unit] or just /unit for register vies
 
5
 3. Information on bank and the view values in the pci -i <reg>
 
6
 4. Integrate hash tables for views, units, and registers
4
7
 
5
8
Normal Priority (it would make just few things a bit easier)
6
9
===============
10
13
 
11
14
Low Priority (only as generalization for other projects)
12
15
============
13
 
 1. XML configurations describing registers (and DMA engines?)
14
 
 2. Access register/bank/lock lookups using hash tables
15
 
 3. Support for Network Registers and Network DMA
16
 
 4. Define a syntax for register dependencies / delays (?)
17
 
 5. Use pthread_condition_t instead of polling
18
 
 6. Support FIFO reads/writes from/to registers
19
 
 7. We managed kmem performance using next kmem prediction, but it is still wise to provide additionally a binary tree for faster search
 
16
 1. Shall we allow overriding of registers?
 
17
 2. Support for Network Registers and Network DMA
 
18
 3. Define a syntax for register dependencies / delays (?)
 
19
 4. Use pthread_condition_t instead of polling
 
20
 5. Support FIFO reads/writes from/to registers
 
21
 6. We managed kmem performance using next kmem prediction, but it is still wise to provide additionally a binary tree for faster search
20
22
 
21
23
Performance
22
24
===========