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