Messages in this thread | | | Subject | Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC | From | Robin Murphy <> | Date | Fri, 9 Jul 2021 14:56:47 +0100 |
| |
On 2021-07-08 09:08, Joerg Roedel wrote: > On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote: >> a) Nothing is inherently broken with my current approach. >> >> b) My current approach doesn't make anybody terribly upset even if >> nobody is totally in love with it. > > Well, no, sorry :) > > I don't think it is a good idea to allow drivers to opt-out of the > strict-setting. This is a platform or user decision, and the driver > should accept whatever it gets. > > So the real question is still why strict is the default setting and how > to change that. Or document for the users that want performance how to > change the setting, so that they can decide.
As I mentioned before, conceptually I think this very much belongs in sysfs as a user decision. We essentially have 4 levels of "strictness":
1: DMA domain with bounce pages 2: DMA domain 3: DMA domain with flush queue 4: Identity domain
The "make this device go faster because I trust it" use-case is why we have the sysfs interface to switch between 2 and 4, so it's entirely logical to have the intermediate option as well for when 3 is "faster" enough while still giving a bit more peace of mind than full-on bypass.
Making it a platform-specific decision that's hidden in a driver - arm-smmu-qcom can be considered a dumping ground of detailed platform knowledge ;) - happens to work as a reasonable compromise for this specific case, but I concur that it could be viewed as setting a precedent for other cases which we definitely aren't as reasonable.
I've been thinking about the sysfs thing some more, and since it's Friday afternoon and I can't concentrate on what I'm supposed to be doing anyway, let's see how far I can get by Monday...
Robin.
| |