linux-kernel - Re: [PATCH V9 3/5] i2c: tegra: Add DMA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Feb 2019 09:18:29 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Sowjanya Komatineni <skomatineni@...dia.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Mantravadi Karthik <mkarthik@...dia.com>,
        Shardar Mohammed <smohammed@...dia.com>,
        Timo Alho <talho@...dia.com>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: Re: [PATCH V9 3/5] i2c: tegra: Add DMA support

On Sun, Feb 03, 2019 at 07:48:09PM +0300, Dmitry Osipenko wrote:
> 02.02.2019 21:32, Sowjanya Komatineni пишет:
> >>> This patch adds DMA support for Tegra I2C.
> >>>
> >>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for 
> >>> transfer size of the max FIFO depth and DMA mode is used for transfer 
> >>> size higher than max FIFO depth to save CPU overhead.
> >>>
> >>> PIO mode needs full intervention of CPU to fill or empty FIFO's and 
> >>> also need to service multiple data requests interrupt for the same 
> >>> transaction. This adds delay between data bytes of the same transfer 
> >>> when CPU is fully loaded and some slave devices has internal timeout 
> >>> for no bus activity and stops transaction to avoid bus hang. DMA mode 
> >>> is helpful in such cases.
> >>>
> >>> DMA mode is also helpful for Large transfers during downloading or 
> >>> uploading FW over I2C to some external devices.
> >>>
> >>> Signed-off-by: Sowjanya Komatineni <skomatineni@...dia.com>
> >>> ---
> >>
> >>
> >>> +static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev) {
> >>> +	struct dma_chan *dma_chan;
> >>> +	u32 *dma_buf;
> >>> +	dma_addr_t dma_phys;
> >>> +	int err = 0;
> >>> +
> >>> +	if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA))
> >>> +		return -ENODEV;
> >>
> >> Another detail is that we need to keep older kernels working on
> >> T186+ after its device-tree will get the "dmas" property,
> >> device-tree changes shall be backwards-compatible with older
> >> kernels. Hence we need to check that platform actually wants the
> >> APB DMA driver, otherwise T186+ will be failing with -EPROBE_DEFER.
> > 
> > Yes, that will be a separate patch later for adding DMA support for
> > Tegra186 and later chips once we check on GPCDMA upstream
> > 
> > 
> 
> Sure, and there is a requirement in upstream to keep older kernel
> versions working with the later device-tree updates, as I pointed
> above. Please include the ".has_apb_dma checking" that I'm suggesting
> into the next version.

I don't think that's true. The requirement is for the device-tree ABI to
remain stable, but that technically only requires that kernel updates do
not require a DTB update.

The assumption on which this is based is that the DTB may be shipping in
read-only storage, like it used to fairly commonly in the distant past.

Conversely, if you update the DTB the assumption is that you can also
update the kernel, so the compatibility doesn't need to go that way.

That said, I think what you're proposing here makes sense and is pretty
trivial, so might as well add it at this time.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)