From: Jon Hunter <jonathanh@xxxxxxxxxx> Date: Jul/23/2019, 11:38:33 (UTC+00:00) > > On 23/07/2019 11:07, Jose Abreu wrote: > > From: Jon Hunter <jonathanh@xxxxxxxxxx> > > Date: Jul/23/2019, 11:01:24 (UTC+00:00) > > > >> This appears to be a winner and by disabling the SMMU for the ethernet > >> controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663 > >> this worked! So yes appears to be related to the SMMU being enabled. We > >> had to enable the SMMU for ethernet recently due to commit > >> 954a03be033c7cef80ddc232e7cbdb17df735663. > > > > Finally :) > > > > However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663": > > > > + There are few reasons to allow unmatched stream bypass, and > > + even fewer good ones. If saying YES here breaks your board > > + you should work on fixing your board. > > > > So, how can we fix this ? Is your ethernet DT node marked as > > "dma-coherent;" ? > > TBH I have no idea. I can't say I fully understand your change or how it > is breaking things for us. > > Currently, the Tegra DT binding does not have 'dma-coherent' set. I see > this is optional, but I am not sure how you determine whether or not > this should be set. >From my understanding it means that your device / IP DMA accesses are coherent regarding the CPU point of view. I think it will be the case if GMAC is not behind any kind of IOMMU in the HW arch. I don't know about this SMMU but the source does have some special conditions when device is dma-coherent. --- Thanks, Jose Miguel Abreu
