On Wed, Jan 4, 2017 at 9:31 AM, Rob Clark <robdclark@xxxxxxxxx> wrote: > On Wed, Jan 4, 2017 at 8:33 AM, Sricharan <sricharan@xxxxxxxxxxxxxx> wrote: >> Hi, >> >>>-----Original Message----- >>>From: linux-arm-msm-owner@xxxxxxxxxxxxxxx [mailto:linux-arm-msm-owner@xxxxxxxxxxxxxxx] On Behalf Of Jordan Crouse >>>Sent: Wednesday, January 04, 2017 3:59 AM >>>To: Rob Clark <robdclark@xxxxxxxxx> >>>Cc: Will Deacon <will.deacon@xxxxxxx>; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx; Sricharan R >>><sricharan@xxxxxxxxxxxxxx> >>>Subject: Re: [RFC 2/3] iommu/arm-smmu: Add qcom implementation >>> >>>On Tue, Jan 03, 2017 at 04:30:55PM -0500, Rob Clark wrote: >>>> At least on the db820c I have, with the firmware I have, I'm not seeing >>>> the SS bit set, even though the iommu is in a stalled state. So for >>>> this implementation ignore not having SS bit set. >>> >>>The SS bit gets set if SCTLR.CFCFG is set to 1. It works in the downstream >>>kernel because the GPU driver writes directly to SCTLR in the IOMMU hardware >>>(which of course is a crime against humanity but that is one of the many reasons >>>why it is a *downstream* driver). >>> >>>My understanding is that SCTLR.CFCFG == 0 should automatically terminate the >>>transaction so I don't understand why we need to write to RESUME. I'm not >>>doubting Rob's patch, I'm doubting why we need it in the first place. It seems >>>that if we have to write it regardless of the value of CFCFG then we should >>>probably just do that instead of relying on the SS bit. >>> >> >> The patch is setting CFCFG to 1, hence we require clearing the fault with a >> write to the RESUME register. I tested these patches on arm-smmu with >> the DB820c and saw that the 'FSR_SS' bit is getting set properly after a >> fault on the adreno smmu. > > I'll drop this patch and re-test.. hopefully later today. It's > possible that I was having the problem w/ SS not set due to some other > issue. (This was what I was seeing initially after just reverting the > patch that removed the stall/resume stuff.) I probably need to double > checkk that CFCFG bit isn't getting cleared somewhere. > Ok, we can drop this patch, I've confirmed the SS bit is getting set properly so we don't need a hack. Not really sure what was going on earlier when I had this problem before, maybe CFCFG wasn't getting set properly.. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html