| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Implement uhd::rfnoc::rfnoc_graph::enumerate_*_connections()
|
| | |
|
| |
|
|
|
| |
This will call init_props() on every block after the device
initialization is complete, but before control returns to the user.
|
| |
|
|
|
|
| |
During construction of the rfnoc_graph, flush and reset each block in
each motherboard we need to enumerate. This will ensure that each
block is in a clean state when we construct it's block controller.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During registration, blocks must now specify which clock they are using
for the timebase (i.e., for timed commands) and for the ctrlport (this
is used to determine the length of sleeps and polls). For example, the
X300 provides bus_clk and radio_clk; typically, the former is used for
the control port, and the latter for the timebase clock.
Another virtual clock is called "__graph__", and it means the clock is
derived from property propagation via the graph.
The actual clocks are provided by the mb_iface. It has two new API
calls: get_timebase_clock() and get_ctrlport_clock(), which take an
argument as to which clock exactly is requested. On block
initialization, those clock_iface objects are copied into the block
controller.
The get_tick_rate() API call for blocks now exclusively checks the
timebase clock_iface, and will no longer cache the current tick rate in
a separate _tick_rate member variable. Block controllers can't manually
modify the clock_iface, unless they also have access to the
mb_controller (like the radio block), and that mb_controller has
provided said access.
This commit also adds the clock selection API changes to the DDC block,
the Null block, and the default block.
|
| |
|
|
|
|
|
|
| |
On destruction, the rfnoc_graph will call shutdown() on all blocks. This
allows a safe de-initialization of blocks independent of the lifetime of
the noc_block_base::sptr.
Also adds the shutdown feature to null_block_control.
|
| | |
|
| | |
|
| |
|
|
|
| |
During construction of the rfnoc_graph, enumerate all of the connected
blocks, construct their controllers, and store them in the graph.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The mb_controller is an interface to hardware-specific functions of the
motherboard. The API works in two ways:
- The user can request access to it, and thus interact directly with the
motherboard
- RFNoC blocks can request access to it, if they need to interact with
the motherboard themselves.
|
|
|
This replaces device3() for RFNoC applications.
|
