linux-kernel - RE: [PATCH V12 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] [day] [month] [year] [list]

Message-ID: <BYAPR12MB3398ACF7999DFA8F24AB09DEC26F0@BYAPR12MB3398.namprd12.prod.outlook.com>
Date:   Wed, 6 Feb 2019 14:48:23 +0000
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Thierry Reding <thierry.reding@...il.com>
CC:     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 V12 3/5] i2c: tegra: Add DMA support

> >>>>>> Yes please post full log of PIO only and DMA only Also, in above 
> >>>>>> log, lots of DMA transfer went thru fine except this one transfer 
> >>>>>> where DMA timed out.
> >>>>>> DMA completion doesnt happen on DMA submit during this particular 
> >>>>>> transaction timeframe for some reason.
> >>>>>
> >>>>> Dmitry, can you provide some background information on the setup 
> >>>>> that you're using? I vaguely remember something about i2c@...0d000 
> >>>>> being special on older Tegra devices. Perhaps there's something 
> >>>>> additional that we need to take into account?
> >>>>>
> >>>>> Aha! Look at tegra_i2c_reg_addr() which special-cases I2C_TX_FIFO 
> >>>>> on the DVC variant of the controller, which is exactly the one 
> >>>>> that you are seeing the timeouts on and it's exactly the register 
> >>>>> that we use as destination for the DMA transfer.
> >>>>>
> >>>>> I think we need to do something like this:
> >>>>>
> >>>>> 	slv_config.dst_addr = i2c_dev->base_phys + 
> >>>>> tegra_i2c_reg_addr(i2c_dev, I2C_TX_FIFO);
> >>>>>
> >>>>> to make sure we pass the right FIFO register address to DMA.
> >>>>
> >>>> I'm running it on T20 at the moment. I don't know about the DVC quirks, but sounds plausible. Please let me know if you need any other info.
> >>>>
> >>>> Here the full logs:
> >>>>
> >>>> PIO-only: http://dpaste.com/2MX3EAN.txt
> >>>> DMA-only: http://dpaste.com/3VXZSSM.txt
> >>>>
> >>>> Note the "Failed to read T44 and T5 (-110)" error that happens in DMA-only. And it happens on i2c@...0c000, DVC is i2c@...0d000.
> >>>
> >>> Yes this is due to same issue theirry mentioned.
> >>> Prior to transfer timeout for touch, tps6586x regulator probe failed due to i2c timeout which uses DVC (7000D000) and since DMA mode is enforced > all DVC/PWR I2C transactions also go thru DMA and FIFO register for DVC offset is not accounted when configure to dma slave.
> >>> Will fix and send so you can see for repro with updated patch..
> >>>

> >> I think tps6586x and atmel-touch should be independent issues, but will see. Thanks!
> > Whats your platform setup? Is atmel touch power ON default or its programmed during boot by SW whcih need to use DVC?
> > 
> 
> It's "power ON default". I tried to boot in PIO-only mode with tps6586x disabled and there is no "Failed to read T44 and T5" error, atmel probed > successfully.

I see in DMA log bunch of 7000D000 i2c transfers before atmel touch probe. VDD-SYS for 5V is not seen.
So still could be related to power due to DVC transactions timedout as change doesnt account for DVC offset.

Please try updated patch which has fix for DVC transaction failures.