Hi all,
Today's linux-next merge of the slave-dma tree got a conflict in:
drivers/dma/ti/k3-udma.c
between commit:
16cd3c670183 ("dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer")
from Linus' tree and commit:
db8d9b4c9b30 ("dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs")
from the slave-dma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/dma/ti/k3-udma.c
index 0536866a58ce,1e6aac87302d..000000000000
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@@ -149,8 -128,19 +149,9 @@@ struct udma_dev
struct udma_chan *channels;
u32 psil_base;
+ u32 atype;
};
-struct udma_hwdesc {
- size_t cppi5_desc_size;
- void *cppi5_desc_vaddr;
- dma_addr_t cppi5_desc_paddr;
-
- /* TR descriptor internal pointers */
- void *tr_req_base;
- struct cppi5_tr_resp_t *tr_resp_base;
-};
-
struct udma_desc {
struct virt_dma_desc vd;
@@@ -3381,98 -3276,66 +3409,158 @@@ static int udma_setup_resources(struct
return ch_count;
}
+static int udma_setup_rx_flush(struct udma_dev *ud)
+{
+ struct udma_rx_flush *rx_flush = &ud->rx_flush;
+ struct cppi5_desc_hdr_t *tr_desc;
+ struct cppi5_tr_type1_t *tr_req;
+ struct cppi5_host_desc_t *desc;
+ struct device *dev = ud->dev;
+ struct udma_hwdesc *hwdesc;
+ size_t tr_size;
+
+ /* Allocate 1K buffer for discarded data on RX channel teardown */
+ rx_flush->buffer_size = SZ_1K;
+ rx_flush->buffer_vaddr = devm_kzalloc(dev, rx_flush->buffer_size,
+ GFP_KERNEL);
+ if (!rx_flush->buffer_vaddr)
+ return -ENOMEM;
+
+ rx_flush->buffer_paddr = dma_map_single(dev, rx_flush->buffer_vaddr,
+ rx_flush->buffer_size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, rx_flush->buffer_paddr))
+ return -ENOMEM;
+
+ /* Set up descriptor to be used for TR mode */
+ hwdesc = &rx_flush->hwdescs[0];
+ tr_size = sizeof(struct cppi5_tr_type1_t);
+ hwdesc->cppi5_desc_size = cppi5_trdesc_calc_size(tr_size, 1);
+ hwdesc->cppi5_desc_size = ALIGN(hwdesc->cppi5_desc_size,
+ ud->desc_align);
+
+ hwdesc->cppi5_desc_vaddr = devm_kzalloc(dev, hwdesc->cppi5_desc_size,
+ GFP_KERNEL);
+ if (!hwdesc->cppi5_desc_vaddr)
+ return -ENOMEM;
+
+ hwdesc->cppi5_desc_paddr = dma_map_single(dev, hwdesc->cppi5_desc_vaddr,
+ hwdesc->cppi5_desc_size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, hwdesc->cppi5_desc_paddr))
+ return -ENOMEM;
+
+ /* Start of the TR req records */
+ hwdesc->tr_req_base = hwdesc->cppi5_desc_vaddr + tr_size;
+ /* Start address of the TR response array */
+ hwdesc->tr_resp_base = hwdesc->tr_req_base + tr_size;
+
+ tr_desc = hwdesc->cppi5_desc_vaddr;
+ cppi5_trdesc_init(tr_desc, 1, tr_size, 0, 0);
+ cppi5_desc_set_pktids(tr_desc, 0, CPPI5_INFO1_DESC_FLOWID_DEFAULT);
+ cppi5_desc_set_retpolicy(tr_desc, 0, 0);
+
+ tr_req = hwdesc->tr_req_base;
+ cppi5_tr_init(&tr_req->flags, CPPI5_TR_TYPE1, false, false,
+ CPPI5_TR_EVENT_SIZE_COMPLETION, 0);
+ cppi5_tr_csf_set(&tr_req->flags, CPPI5_TR_CSF_SUPR_EVT);
+
+ tr_req->addr = rx_flush->buffer_paddr;
+ tr_req->icnt0 = rx_flush->buffer_size;
+ tr_req->icnt1 = 1;
+
+ /* Set up descriptor to be used for packet mode */
+ hwdesc = &rx_flush->hwdescs[1];
+ hwdesc->cppi5_desc_size = ALIGN(sizeof(struct cppi5_host_desc_t) +
+ CPPI5_INFO0_HDESC_EPIB_SIZE +
+ CPPI5_INFO0_HDESC_PSDATA_MAX_SIZE,
+ ud->desc_align);
+
+ hwdesc->cppi5_desc_vaddr = devm_kzalloc(dev, hwdesc->cppi5_desc_size,
+ GFP_KERNEL);
+ if (!hwdesc->cppi5_desc_vaddr)
+ return -ENOMEM;
+
+ hwdesc->cppi5_desc_paddr = dma_map_single(dev, hwdesc->cppi5_desc_vaddr,
+ hwdesc->cppi5_desc_size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, hwdesc->cppi5_desc_paddr))
+ return -ENOMEM;
+
+ desc = hwdesc->cppi5_desc_vaddr;
+ cppi5_hdesc_init(desc, 0, 0);
+ cppi5_desc_set_pktids(&desc->hdr, 0, CPPI5_INFO1_DESC_FLOWID_DEFAULT);
+ cppi5_desc_set_retpolicy(&desc->hdr, 0, 0);
+
+ cppi5_hdesc_attach_buf(desc,
+ rx_flush->buffer_paddr, rx_flush->buffer_size,
+ rx_flush->buffer_paddr, rx_flush->buffer_size);
+
+ dma_sync_single_for_device(dev, hwdesc->cppi5_desc_paddr,
+ hwdesc->cppi5_desc_size, DMA_TO_DEVICE);
+ return 0;
+}
+
+ #ifdef CONFIG_DEBUG_FS
+ static void udma_dbg_summary_show_chan(struct seq_file *s,
+ struct dma_chan *chan)
+ {
+ struct udma_chan *uc = to_udma_chan(chan);
+ struct udma_chan_config *ucc = &uc->config;
+
+ seq_printf(s, " %-13s| %s", dma_chan_name(chan),
+ chan->dbg_client_name ?: "in-use");
+ seq_printf(s, " (%s, ", dmaengine_get_direction_text(uc->config.dir));
+
+ switch (uc->config.dir) {
+ case DMA_MEM_TO_MEM:
+ seq_printf(s, "chan%d pair [0x%04x -> 0x%04x], ", uc->tchan->id,
+ ucc->src_thread, ucc->dst_thread);
+ break;
+ case DMA_DEV_TO_MEM:
+ seq_printf(s, "rchan%d [0x%04x -> 0x%04x], ", uc->rchan->id,
+ ucc->src_thread, ucc->dst_thread);
+ break;
+ case DMA_MEM_TO_DEV:
+ seq_printf(s, "tchan%d [0x%04x -> 0x%04x], ", uc->tchan->id,
+ ucc->src_thread, ucc->dst_thread);
+ break;
+ default:
+ seq_printf(s, ")\n");
+ return;
+ }
+
+ if (ucc->ep_type == PSIL_EP_NATIVE) {
+ seq_printf(s, "PSI-L Native");
+ if (ucc->metadata_size) {
+ seq_printf(s, "[%s", ucc->needs_epib ? " EPIB" : "");
+ if (ucc->psd_size)
+ seq_printf(s, " PSDsize:%u", ucc->psd_size);
+ seq_printf(s, " ]");
+ }
+ } else {
+ seq_printf(s, "PDMA");
+ if (ucc->enable_acc32 || ucc->enable_burst)
+ seq_printf(s, "[%s%s ]",
+ ucc->enable_acc32 ? " ACC32" : "",
+ ucc->enable_burst ? " BURST" : "");
+ }
+
+ seq_printf(s, ", %s)\n", ucc->pkt_mode ? "Packet mode" : "TR mode");
+ }
+
+ static void udma_dbg_summary_show(struct seq_file *s,
+ struct dma_device *dma_dev)
+ {
+ struct dma_chan *chan;
+
+ list_for_each_entry(chan, &dma_dev->channels, device_node) {
+ if (chan->client_count)
+ udma_dbg_summary_show_chan(s, chan);
+ }
+ }
+ #endif /* CONFIG_DEBUG_FS */
+
#define TI_UDMAC_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
Hi Stephen, Vinod,
On 12/03/2020 7.26, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the slave-dma tree got a conflict in:
>
> drivers/dma/ti/k3-udma.c
>
> between commit:
>
> 16cd3c670183 ("dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer")
>
> from Linus' tree
In Linus' tree the drivers/dma/ti/k3-udma.c latest commit is:
8390318c04bb ("dmaengine: ti: k3-udma: Fix terminated transfer handling")
git log --oneline drivers/dma/ti/k3-udma.c shows:
8390318c04bb dmaengine: ti: k3-udma: Fix terminated transfer handling
c7450bb211f3 dmaengine: ti: k3-udma: Use the channel direction in pause/resume functions
6cf668a4ef82 dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and cyclic
a97934071fc3 dmaengine: ti: k3-udma: Move the TR counter calculation to helper function
16cd3c670183 dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer
1c83767c9d41 dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion check
6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
> and commit:
>
> db8d9b4c9b30 ("dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs")
However slave-dma's next branch shows the following log for k3-udma.c:
db8d9b4c9b30 dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs
0ebcf1a274c5 dmaengine: ti: k3-udma: Implement support for atype (for virtualization)
6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
The 5.6-rc5 patches (1c83767c9d41...8390318c04bb) is not present in slave-dma/next which
causes the conflict.
> from the slave-dma tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
I ended up with the exactly same resolution patch when merging dlave-dma/next
to Linus' tree.
Stephen, thank you!
Vinod, is there anything I can do?
- P?ter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 12-03-20, 09:16, Peter Ujfalusi wrote:
> Hi Stephen, Vinod,
>
> On 12/03/2020 7.26, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the slave-dma tree got a conflict in:
> >
> > drivers/dma/ti/k3-udma.c
> >
> > between commit:
> >
> > 16cd3c670183 ("dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer")
> >
> > from Linus' tree
>
> In Linus' tree the drivers/dma/ti/k3-udma.c latest commit is:
> 8390318c04bb ("dmaengine: ti: k3-udma: Fix terminated transfer handling")
>
> git log --oneline drivers/dma/ti/k3-udma.c shows:
> 8390318c04bb dmaengine: ti: k3-udma: Fix terminated transfer handling
> c7450bb211f3 dmaengine: ti: k3-udma: Use the channel direction in pause/resume functions
> 6cf668a4ef82 dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and cyclic
> a97934071fc3 dmaengine: ti: k3-udma: Move the TR counter calculation to helper function
> 16cd3c670183 dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer
> 1c83767c9d41 dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion check
> 6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
> d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
> 25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
>
> > and commit:
> >
> > db8d9b4c9b30 ("dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs")
>
> However slave-dma's next branch shows the following log for k3-udma.c:
> db8d9b4c9b30 dmaengine: ti: k3-udma: Implement custom dbg_summary_show for debugfs
> 0ebcf1a274c5 dmaengine: ti: k3-udma: Implement support for atype (for virtualization)
> 6c0157be02f0 dmaengine: ti: k3-udma: fix spelling mistake "limted" -> "limited"
> d70241913413 dmaengine: ti: k3-udma: Add glue layer for non DMAengine users
> 25dcb5dd7b7c dmaengine: ti: New driver for K3 UDMA
>
> The 5.6-rc5 patches (1c83767c9d41...8390318c04bb) is not present in slave-dma/next which
> causes the conflict.
Yeah I typically dont merge fixes to next, unless we have a dependency.
> > from the slave-dma tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> I ended up with the exactly same resolution patch when merging dlave-dma/next
> to Linus' tree.
Thanks for confirming.. I will let Linus know about this, I dont think
we need to do much here :)
--
~Vinod