[PATCH 0/7] Fix omap-iommu probe and convert to DT for 3.14

[florian.vaussard@epfl.ch (Florian Vaussard)]

Hi Suman,

On 12/23/2013 07:52 PM, Anna, Suman wrote:
> Hi Florian,
>
> On 12/17/2013 06:53 AM, Florian Vaussard wrote:
>> OMAP2+ is heading towards a full device tree boot for 3.14. Currently,
>> the iommu used by the OMAP3 camera subsystem is not yet converted. It
>> cannot be probed as necessary data are only passed through device tree.
>>
>> Patches 1 and 2 are small fixes for problems encountered while developing
>> this series.
>>
>> Patches 3 to 5 add the device tree logic to omap-iommu, and complete
>> iommu
>> data in omap3.dtsi. Patches 6 and 7 remove unused iommu hwmod data and
>> platform code from OMAP2+.
>
> This is a good starting patch series for the OMAP iommu DT conversion,
> but it only handles OMAP3 ISP MMU. The OMAP3 ISP MMU is not the only MMU
> handled by the OMAP iommu driver. There is also an OMAP3 IVA MMU and
> MMUs associated with DSP and IPU in OMAP4/OMAP5. The conversion is
> simpler just with the OMAP3 ISP MMU, as it doesn't have any reset lines
> associated with it. But all the other MMUs would require
> asserting/deasserting the resets (performed currently through the pdata
> function pointers). Your patch series removes that functionality
> completely, and if this were to go into 3.14, this has to be handled
> through some pdata quirks until all the resets in hwmod data are
> converted to a reset driver.
>

Indeed, this patchset currently addresses only the OMAP ISP IOMMU.
For the OMAP3 IVA, the current implementation looks completely
different (inside drivers/staging/tidspbridge/). And to the best of
my knowledge, the current omap-iommu driver can handle only one
instance. By calling

bus_set_iommu(&platform_bus_type, &omap_iommu_ops);

the driver register the iommu on the platform bus (which is maybe
not the best choice). This call will fill the struct iommu_ops of
the bus_type, but if an iommu is already present, it will fail
and return EBUSY. Thus only one iommu can be set on the same bus.

But for the OMAP4 and OMAP5, I understand your concern. If a reset
is needed for these IPs, then a solution must be found. pdata-quirks
can be a temporary solution for 3.14. Otherwise a proper reset
controller should be devised from the current PRM module. Even if
I already looked at the reset core, I do not know the amount of work
necessary for this solution. And I do not have the hardware to
test the solution. But I can have a look after the XMAS break.

> I have provided some more comments directly in the respective patches.
>

And I will answer inline. Thank you very much!

Regards,

Florian