On 5/12/26 11:30, Torsten Duwe wrote:
On Mon, 11 May 2026 16:50:48 +0200
Neil Armstrong <[email protected]> wrote:
On 5/8/26 17:42, Torsten Duwe wrote:
[...]
+#define DEV_ADDR(a) dev_phys_to_bus(dev->udev, (a))
This doesn't look very clean, I would do something closer to linux by
precalculating
the DMA addresses after allocation like:
====================><================================
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 2b14437f69c..1ce06402a90 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -241,6 +241,7 @@ static struct nvme_queue *nvme_alloc_queue(struct nvme_dev
*dev,
nvmeq->sq_cmds = (void *)memalign(4096, NVME_SQ_SIZE(depth));
if (!nvmeq->sq_cmds)
goto free_queue;
+ nvmeq->sq_dma_addr = dev_phys_to_bus(dev->udev, nvmeq->sq_cmds);
memset((void *)nvmeq->sq_cmds, 0, NVME_SQ_SIZE(depth));
nvmeq->dev = dev;
@@ -393,7 +394,7 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
dev->ctrl_config |= NVME_CC_IOSQES | NVME_CC_IOCQES;
writel(aqa, &dev->bar->aqa);
- nvme_writeq((ulong)nvmeq->sq_cmds, &dev->bar->asq);
+ nvme_writeq((ulong)nvmeq->sq_dma_addr, &dev->bar->asq);
nvme_writeq((ulong)nvmeq->cqes, &dev->bar->acq);
result = nvme_enable_ctrl(dev);
Hm, time / space tradeoff. I don't really have a strong preference
regarding this, I'd worry most about U-Boot code size (for which this
doesn't make much of a difference). However, I was under the impression
that during regular NVMe business a lot of those buffers and addresses
get allocated and the translations are required often. That's probably
only true once a full-blown operating system is running.
I'll check the allocations and assignments. Any other opinions?
Other that that, I think it's fine, Linux is basically doing the same.
Thanks,
Neil
Torsten
