[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ1PR12MB6339A665889F4F4B55AE81E5C0519@SJ1PR12MB6339.namprd12.prod.outlook.com>
Date: Fri, 23 Sep 2022 16:22:51 +0000
From: Akhil R <akhilrajeev@...dia.com>
To: Jonathan Hunter <jonathanh@...dia.com>,
Laxman Dewangan <ldewangan@...dia.com>,
"vkoul@...nel.org" <vkoul@...nel.org>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 3/3] dmaengine: tegra: Add support for dma-channel-mask
> >> 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?
> > There is an offset from the base address which the per channel registers start.
> > Although this offset value happens to match with the channel_reg_size, this is
> > not actually the per channel register size.
>
> Yes I see that, but I mean why do we even bother having this
> channel_reg_size parameter? Does not look like we need this (currently).
> All we need is ...
>
> tdc->chan_base_offset = TEGRA_GPCDMA_CHANNEL_BASE_ADDR_OFFSET +
> (i * SZ_64K);
>
Ah. Ok. Got it now. Would add this as an improvement in another patch.
Thanks,
Akhil
Powered by blists - more mailing lists