On 20/08/2019 11:15, Vivek Gautam wrote:
[...]
Hi Robin,
Sorry for responding late to this series. I have couple of doubts here
that I wanted to discuss.
Are we standardizing these implementation specific ops? Each vendor
implementations will have something peculiar to take care. Things are
good right now with 'reset', 'cfg_probe', and 'init_context' hooks.
But, on top of vendor implementation details, there can be SoC specific
errata changes that need to be added.
The idea behind the impl hooks is to try to have them in logical places
which should be suitable for multiple different workarounds (e.g.
init_context is arranged to allow replacing smmu_domain->tlb_ops) - I
want to avoid proliferating dozens of them that end up each being
specific to individual workarounds, but that's not to say that the
design we're starting with here is by any means complete or final. We're
almost certainly going to evolve more hooks (and possibly adjust the
current ones) in future.
Moreover, adding implementation data based on __model__ may not suffice
for long. Do you suggest adding any other data variable in the
ARM_SMMU_MATCH_DATA?
As commented in the code, the setup for the existing quirks works out to
be deceptively simple, and it can and will change. Ultimately I'm fully
expecting to end up with complex logic hanging off arm_smmu_impl_init()
to detect the integration details and compose sets of impl hooks in
various ways as appropriate - I doubt that it's going to be practical or
even possible to have static data for *every* possibility. The
fundamental shape of the code is based on "model" quirks being more
general than "integration" quirks, such that the latter should be in a
position to dynamically inherit (or statically replace, in simple cases)
the hooks of the former.
To show SoC specific needs, I have the change attached in this email to
take care of the SDM845 'wait-for-safe' sequence.
Please take a look.
Other than that introducing QCOM_SMMU500 seems to be redundant, and
whether it also needs ACPI-based detection, that certainly seems fairly
reasonable for a simple isolated workaround. However, is the firmware
call really a one-off probe-time thing? If the firmware does take care
of preserving the wait-for-safe state across
suspend/resume/hibernate/etc. then fair enough, but I would have assumed
that the reset hook would be the more likely place to put it.
Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
