Hi Robin,

-----Original Message-----
From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Robin Murphy
Sent: Wednesday, February 08, 2017 8:01 PM
To: Mark Rutland <mark.rutland@arm.com>; Sricharan <redacted>
Cc: devicetree at vger.kernel.org; mathieu.poirier at linaro.org; linux-arm-msm at vger.kernel.org; joro at 8bytes.org;
will.deacon at arm.com; iommu at lists.linux-foundation.org; robh+dt at kernel.org; sboyd at codeaurora.org; linux-arm-
kernel at lists.infradead.org; m.szyprowski at samsung.com
Subject: Re: [PATCH V2 1/3] iommu/arm-smmu: Add pm_runtime/sleep ops

On 08/02/17 13:52, Mark Rutland wrote:

quoted

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

quoted

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.

Right, that's what I feared. As far as I can make out the current ARM
implementations, transactions passing through will require at least
TBUn_BCLK for the appropriate TBU, but would also need the page table
walker clocked with CCLK to resolve TLB misses. But then the programming
interface is also in the CCLK domain (not counting the incoming APB or
AXI clock for the actual slave port itself). Thus this 'generic' clock
binding already isn't compatible with MMU-40x/500.

Right, this implementation's clock bindings are not going to compatible with
MMU-500. There is also another soc which integrates MMU-500.  So
will have to add the clock bindings for MMU-500 as well separately.
Also in MMU-500 i saw that there is a possibility where the clock-domain
can be shared between the TCU logic, programming interface and PTW read
channel.  Does this mean that the TCU-clock has to be 'ON' for both register
access and PTW, similar to above ?. So for MMU-500 clock bindings there
can be a CFG_CLK (optional and not required in shared case), TBUn_CLK and
TCU_CLK

Regards,
 Sricharan

quoted

quoted

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.

Exactly.

Robin.

quoted

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel