| Message ID | 20200930091412.8020-8-peter.ujfalusi@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA | expand |
On 30-09-20, 12:14, Peter Ujfalusi wrote: > Glue layer users should use the device of the DMA for DMA mapping and > allocations as it is the DMA which accesses to descriptors and buffers, > not the clients > > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> > --- > drivers/dma/ti/k3-udma-glue.c | 14 ++++++++++++++ > drivers/dma/ti/k3-udma-private.c | 6 ++++++ > drivers/dma/ti/k3-udma.h | 1 + > include/linux/dma/k3-udma-glue.h | 4 ++++ > 4 files changed, 25 insertions(+) > > diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c > index a367584f0d7b..a53bc4707ae8 100644 > --- a/drivers/dma/ti/k3-udma-glue.c > +++ b/drivers/dma/ti/k3-udma-glue.c > @@ -487,6 +487,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn) > } > EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq); > > +struct device * > + k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn) How about.. struct device * k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn) > +{ > + return xudma_get_device(tx_chn->common.udmax); > +} > +EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device); Hmm why would you need to export this device.. Can you please outline all the devices involved here... why not use dmaI_dev->dev or chan->dev? -- ~Vinod
On 07/10/2020 9.53, Vinod Koul wrote: > On 30-09-20, 12:14, Peter Ujfalusi wrote: >> Glue layer users should use the device of the DMA for DMA mapping and >> allocations as it is the DMA which accesses to descriptors and buffers, >> not the clients >> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> >> --- >> drivers/dma/ti/k3-udma-glue.c | 14 ++++++++++++++ >> drivers/dma/ti/k3-udma-private.c | 6 ++++++ >> drivers/dma/ti/k3-udma.h | 1 + >> include/linux/dma/k3-udma-glue.h | 4 ++++ >> 4 files changed, 25 insertions(+) >> >> diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c >> index a367584f0d7b..a53bc4707ae8 100644 >> --- a/drivers/dma/ti/k3-udma-glue.c >> +++ b/drivers/dma/ti/k3-udma-glue.c >> @@ -487,6 +487,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn) >> } >> EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq); >> >> +struct device * >> + k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn) > > How about.. > > struct device * > k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn) OK. > >> +{ >> + return xudma_get_device(tx_chn->common.udmax); >> +} >> +EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device); > > Hmm why would you need to export this device.. Can you please outline > all the devices involved here... In upstream we have one user of the udma-glue layer: drivers/net/ethernet/ti/am65-cpsw-nuss.c It is allocating memory to be used with DMA (descriptor pool), it needs to use correct device for DMA API. The cpsw atm using it's own dev for allocation, which is wrong, but it worked fine as am654/j721e/j7200 is all coherent. > why not use dmaI_dev->dev or chan->dev? The glue layer does not use DMAengine API to request a channel as it require special resource setup compared to what is possible via generic API. We have kept the DMAengine and Glue layer as separate until I have time to extend the core to support the features we would need to remove the Glue layer. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c index a367584f0d7b..a53bc4707ae8 100644 --- a/drivers/dma/ti/k3-udma-glue.c +++ b/drivers/dma/ti/k3-udma-glue.c @@ -487,6 +487,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn) } EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq); +struct device * + k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn) +{ + return xudma_get_device(tx_chn->common.udmax); +} +EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device); + static int k3_udma_glue_cfg_rx_chn(struct k3_udma_glue_rx_channel *rx_chn) { const struct udma_tisci_rm *tisci_rm = rx_chn->common.tisci_rm; @@ -1189,3 +1196,10 @@ int k3_udma_glue_rx_get_irq(struct k3_udma_glue_rx_channel *rx_chn, return flow->virq; } EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_irq); + +struct device * + k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn) +{ + return xudma_get_device(rx_chn->common.udmax); +} +EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_dma_device); diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c index aa24e554f7b4..8ff7a264be03 100644 --- a/drivers/dma/ti/k3-udma-private.c +++ b/drivers/dma/ti/k3-udma-private.c @@ -50,6 +50,12 @@ struct udma_dev *of_xudma_dev_get(struct device_node *np, const char *property) } EXPORT_SYMBOL(of_xudma_dev_get); +struct device *xudma_get_device(struct udma_dev *ud) +{ + return ud->dev; +} +EXPORT_SYMBOL(xudma_get_device); + u32 xudma_dev_get_psil_base(struct udma_dev *ud) { return ud->psil_base; diff --git a/drivers/dma/ti/k3-udma.h b/drivers/dma/ti/k3-udma.h index 09c4529e013d..d1cace0cb43b 100644 --- a/drivers/dma/ti/k3-udma.h +++ b/drivers/dma/ti/k3-udma.h @@ -112,6 +112,7 @@ int xudma_navss_psil_unpair(struct udma_dev *ud, u32 src_thread, u32 dst_thread); struct udma_dev *of_xudma_dev_get(struct device_node *np, const char *property); +struct device *xudma_get_device(struct udma_dev *ud); void xudma_dev_put(struct udma_dev *ud); u32 xudma_dev_get_psil_base(struct udma_dev *ud); struct udma_tisci_rm *xudma_dev_get_tisci_rm(struct udma_dev *ud); diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h index 5eb34ad973a7..d7c12f31377c 100644 --- a/include/linux/dma/k3-udma-glue.h +++ b/include/linux/dma/k3-udma-glue.h @@ -41,6 +41,8 @@ void k3_udma_glue_reset_tx_chn(struct k3_udma_glue_tx_channel *tx_chn, u32 k3_udma_glue_tx_get_hdesc_size(struct k3_udma_glue_tx_channel *tx_chn); u32 k3_udma_glue_tx_get_txcq_id(struct k3_udma_glue_tx_channel *tx_chn); int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn); +struct device * + k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn); enum { K3_UDMA_GLUE_SRC_TAG_LO_KEEP = 0, @@ -130,5 +132,7 @@ int k3_udma_glue_rx_flow_enable(struct k3_udma_glue_rx_channel *rx_chn, u32 flow_idx); int k3_udma_glue_rx_flow_disable(struct k3_udma_glue_rx_channel *rx_chn, u32 flow_idx); +struct device * + k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn); #endif /* K3_UDMA_GLUE_H_ */
Glue layer users should use the device of the DMA for DMA mapping and allocations as it is the DMA which accesses to descriptors and buffers, not the clients Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> --- drivers/dma/ti/k3-udma-glue.c | 14 ++++++++++++++ drivers/dma/ti/k3-udma-private.c | 6 ++++++ drivers/dma/ti/k3-udma.h | 1 + include/linux/dma/k3-udma-glue.h | 4 ++++ 4 files changed, 25 insertions(+) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki