On 23/09/2022 11:17, Akhil R wrote:
On 19/09/2022 12:25, Akhil R wrote:
Add support for dma-channel-mask so that only the specified channels
are used. This helps to reserve some channels for the firmware.
This was initially achieved by limiting the channel number to 31 in
the driver and adjusting the register address to skip channel0 which
was reserved for a firmware. Now, with this change, the driver can
align more to the actual hardware which has 32 channels.
Signed-off-by: Akhil R <akhilrajeev@xxxxxxxxxx>
---
drivers/dma/tegra186-gpc-dma.c | 37 +++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-
dma.c
index fa9bda4a2bc6..1d1180db6d4e 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -161,7 +161,10 @@
#define TEGRA_GPCDMA_BURST_COMPLETION_TIMEOUT 5000 /* 5
msec */
/* Channel base address offset from GPCDMA base address */
-#define TEGRA_GPCDMA_CHANNEL_BASE_ADD_OFFSET 0x20000
+#define TEGRA_GPCDMA_CHANNEL_BASE_ADDR_OFFSET 0x10000
Why did this value change? There is no mention in the commit message. If
this was incorrect before, then this needs to be a separate patch and
tagged with the appropriate fixes tag so that this can be picked up for
stable.
This is mentioned in the commit message.
"... and adjusting the register address to skip channel0 ..."
Probably it is not very clear that it directs to this change. Shall I update the
commit message to have a clearer context?
Ah OK. I was wondering how this worked with 'channel_reg_size' but
looking closer I see channel_reg_size is always SZ_64K. I wonder why we
even bother having this parameter and don't use SZ_64K directly?
Anyway, for now this is fine.
Jon
--
nvpublic
