On 24.04.2024 12:28, Dmitry Baryshkov wrote:
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.
Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.
This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
diff --git a/drivers/soc/qcom/qcom_pd_mapper.c b/drivers/soc/qcom/qcom_pd_mapper.c
...
+
+static const struct qcom_pdm_domain_data *sdm660_domains[] = {
+ &adsp_audio_pd,
+ &adsp_root_pd,
+ &mpss_wlan_pd,
+ NULL,
+};
+
On my SDM660 device (xiaomi-lavender) I see also the following files on
modem partition:
- adsps.jsn with sensor_pd (instance id 74)
- cdspr.jsn with cdsp root_pd (instance id 76)
- modemr.jsn with root_pd (instance id 180)
I see these numbers match those you already have defined above, so
perhaps sdm660_domains should also have adsp_sensor_pd, cdsp_root_pd,
and mpss_root_pd?
I'm not sure how useful they are currently, as AFAIK cdsp is not added
to sdm660 DT at all; and ADSP sensors are very hard to use/test, needs
very special userspace...
--
Regards,
Alexey Minnekhanov
postmarketOS developer
