RE: [PATCH V2 1/3] iommu/arm-smmu: Add pm_runtime/sleep ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robin,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Robin Murphy
>Sent: Wednesday, February 08, 2017 8:01 PM
>To: Mark Rutland <mark.rutland@xxxxxxx>; Sricharan <sricharan@xxxxxxxxxxxxxx>
>Cc: devicetree@xxxxxxxxxxxxxxx; mathieu.poirier@xxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx; joro@xxxxxxxxxx;
>will.deacon@xxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx; robh+dt@xxxxxxxxxx; sboyd@xxxxxxxxxxxxxx; linux-arm-
>kernel@xxxxxxxxxxxxxxxxxxx; m.szyprowski@xxxxxxxxxxx
>Subject: Re: [PATCH V2 1/3] iommu/arm-smmu: Add pm_runtime/sleep ops
>
>On 08/02/17 13:52, Mark Rutland wrote:
>> On Wed, Feb 08, 2017 at 07:15:37PM +0530, Sricharan wrote:
>>>> 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).
>>>
>>>> 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

>>>> 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.
>
>>
>> Thanks,
>> Mark.
>>
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux