promise/plugin/check_sdr_busy: Don't hardcode /dev/sdr0@0
Currently check_sdr_busy always checks /dev/sdr0 (via `-c 0`) and also implicitly DMA channel 0 as sdr_util help explains: ./sdr_util -h ... -c device_num select the device (default = all) -d channel_num select the channel (default = 0) This works well for ORS, which always has only single SDR board. However for cases when there are either a) multiple SDR boards, or b) single CPRI board, the assumption is incorrect: - for multiple SDR boards we need to be able to specify /dev/sdrX instead of sdr0. - for the case of one CPRI boards, links to different Radio Units attached to different SFP ports are associated with different DMA channels, so to test e.g. whether RU1 is being used it is necessary to check e.g. sdr0@0, while for RU2 it is necessary to check sdr0@1. I explicitly verified that for CPRI case a) Amarisoft kernel driver allows /dev/sdrX associated with CPRI card to be opened multiple times simultaneously - up to the amount of SFP ports = # of DMA channels, and b) that only DMA channels / SFP ports actually being in use are reported as busy by sdr_util, while the other DMA channels / SFP ports are not reported as busy. I also verified that for regular SDR board (not CPRI) using -d 0 does not change any verification semantic as such SDR boards have only one DMA channel. -> As a preparatory step for multiRU work adjust check_sdr_busy promise to take SDR device number and DMA channel number as arguments instead of hardcoding sdr0@0. For now this change is accompanied by the following change in ors-amarisoft SR to keep it working as before: --- a/software/ors-amarisoft/instance-enb.jinja2.cfg +++ b/software/ors-amarisoft/instance-enb.jinja2.cfg @@ -615,6 +615,8 @@ name = ${:_buildout_section_name_} promise = check_sdr_busy config-testing = {{ slapparameter_dict.get("testing", False) }} config-sdr = {{ sdr }} +config-sdr_dev = 0 +config-dma_chan = 0 (posted in slapos!1458) /cc @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /partly-reviewed-by @tomo /reviewed-on !125
Showing
Please register or sign in to comment