On 17/12/23 16:48, Péter Ujfalusi wrote: > > > On 15/12/2023 08:08, Siddharth Vadapalli wrote: >>>> err: >>>> @@ -395,6 +410,40 @@ struct k3_udma_glue_tx_channel *k3_udma_glue_request_tx_chn(struct device *dev, >>>> } >>>> EXPORT_SYMBOL_GPL(k3_udma_glue_request_tx_chn); >>>> >>>> +struct k3_udma_glue_tx_channel * >>>> +k3_udma_glue_request_tx_chn_by_id(struct device *dev, struct k3_udma_glue_tx_channel_cfg *cfg, >>>> + struct device_node *udmax_np, u32 thread_id) >>> >>> udmax_np is not dev->of_node ? >> >> I am not sure I fully understand the question. If you meant to ask if the driver >> which uses this API will not have its device's of_node set to udmax_np, then yes >> that's correct. >> >> The driver shall be probed over RPMsg-bus, due to which its device's of_node >> will not be udmax_np. Additionally, the udmax_np is the device-tree node of one >> of the DMA Controllers described in the device-tree. The driver shall obtain the >> reference to the udmax_np node using the API: >> of_find_compatible_node() >> with the compatible to be passed to the above API being a part of the driver's >> data. Thus, it is possible to specify which DMA Controller to use by specifying >> the compatible in the driver's data. I hope that I have answered your question. >> Please let me know otherwise. > > I see, thank you for the detailed explanation! > >> Thank you for reviewing the series. I will rename the API as mentioned above and >> if the question you had above regarding the of_node has been addressed, I will >> post the v3 series. Kindly let me know. > > I don't have other open issues, thanks for the updates > Thank you for the confirmation. I will implement your suggestions and post the v3 series. -- Regards, Siddharth.
