On Wed, Feb 08, 2017 at 07:15:37PM +0530, Sricharan wrote:

quoted

Clocks are not architectural, so it only makes sense to associate them
with an implementation-specific compatible string. There's also no

ok, it for this the QCOM specific implementation binding is tried(going to).

quoted

guarantee that different microarchitectures have equivalent internal
clock domains - I'm not sure if "the SMMU's underlying bus access" is
meant to refer to accesses *by* the SMMU, i.e. page table walks,
accesses *through* the SMMU by upstream masters, or both

In the above QCOM case, it is actually both. Its the same path for both the
page table walker and upstream masters.

quoted

differences are rather significant. I'd also note that an MMU-500
configuration may have up to *33* clocks.

Either way, the QCOM implementation deserves its own compatible if only
for the sake of the imp-def gaps in the architecture (e.g. FSR.SS
behaviour WRT to IRQs as touched upon in the other thread).

Ok, slightly unclear, so you mean then *clocks* are not good enough reason
to have a new compatible ?

I beleive Robin's point was even if the clocks didn't matter, there are
other reasons we should have the QCOM-specific compatible string.

So we should have one regardless.

Thanks,
Mark.