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

["Anna, Suman" <s-anna-l0cyMroinI0@public.gmane.org>]

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

Not really, the omap_iommu_ops are identical for all instances. The 
usage would be by different drivers, with each of them doing a attach 
for the respective device.

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

Yeah, the DT conversion has been on my list, and wanted to do this after 
the TI reset framework changes. That would probably take some time as it 
also involves the hwmod framework, so the only short term solution to 
enable this would be to use the pdata-quirks.

Tony, do you have any objections to this approach?

regards
Suman