Re: [PATCH v12 00/31] iommu/exynos: Fixes and Enhancements of System MMU driver with DT

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

 




On Mon, Apr 28, 2014 at 2:04 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote:
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because a System MMU resides in the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System MMUs
>> as the parent of the device which owns the System MMU to receive the
>> information when the device is turned off or turned on.
>>
>> Another big change to the driver is the support for devicetree.
>> The bindings for System MMU is described in
>> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> Sorry I've been absent from the review so far. Most of the patches
> seem entirely reasonable to me, but I'm worried about the DT binding
> aspect. We are going to see more systems shipping with IOMMUs now,
> and we are seeing an increasing number of submissions for 64-bit
> systems. We really have to work out what the DT representation for
> IOMMUs should look like in general before adding another ad-hod
> implementation that is private to one driver.

Hi Arnd,

No issues. Its good that finally you are here :)

I am going through the possibilities for new bindings that you
mentioned in the other thread.
    -- [PATCH v12 11/31] documentation: iommu: add binding document of
Exynos System MMU

Exynos IOMMU driver is pretty simple with only one exception, "some
devices are using multiple IOMMUs".

>From starting (of this patch set), we were trying to fix three major issues.
[1] How to control the probing order of required IOMMU(s) for a given
device and a device itself.
[2] Handling multiple IOMMUs for one device.
[3] Generic DT bindings to link Device and IOMMUs.

I have gone through the implementation of Tegra SMMU driver by "Hiroshi Doyu"
    -- [PATCHv7 00/12] Unifying SMMU driver among Tegra SoCs
[https://lkml.org/lkml/2013/12/12/74]

For the first point [1],
------------------------------
Tegra implementation tries to fix this issue with these two patches
    -- iommu/of: check if dependee iommu is ready or not
[http://patchwork.ozlabs.org/patch/300560/]
    -- driver/core: populate devices in order for IOMMUs
[http://patchwork.ozlabs.org/patch/300558/]
I can follow this driver if this approach is acceptable.

For the second point [2]
----------------------------------
Currently we are handling this issue by providing same mapping for all
IOMMUs linked to the same device.
And current Exynos drivers doesn't have any special implementation to
handle this case differently.

I thought of understanding how Tegra SMMU driver is handling this case.
Frankly speaking, I didn't understand how its done there.

For the third point [3]
-------------------------------
As Tegra SMMU driver is inline with the discussion in other thread, we
can follow the same bindings, unless
the discussion takes us in the other direction.

"KyongHo Cho" is the author for this driver and hope he has more inputs.

Regards,
Shaik



>
>         Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux