On 12/04/2012 11:37 AM, Hiroshi Doyu wrote:
> Most of platform devices are IOMMU'able in Tegra30 SoC. Registering
> all IOMMU'able devices manually isn't nice. This patch allows
> platform bus_notifier to register IOMMU devices. Map info can be
> passed from DT. Info format is:
>
> dma-window = <0 0x40000000>;
>
> TODO:
> A map can be shared with mutiple devices. This info also could be
> passed from DT or default map can be set in advance.
> +static int tegra_smmu_device_notifier(struct notifier_block *nb,
> + unsigned long event, void *_dev)
> + switch (event) {
> + case BUS_NOTIFY_ADD_DEVICE:
> + err = of_get_dma_window(dev->of_node, NULL, 0, NULL, &base,
> + &size);
> + if (!err)
> + map = arm_iommu_create_mapping(&platform_bus_type,
> + base, size, 0);
So, this ends up attempting to hook up the Tegra SMMU for /any/ node on
a platform bus that has a dma-window property. That seems a little
dangerous. I guess it's not true for Tegra30, but what if there are
multiple buses on the SoC, each with a separate IOMMU - using this
approach would mean the two IOMMU drivers end up fighting to register
mappings for devices on each-others buses.
I think the solution here is one of:
a) Explicitly represent the bus structure in DT (something we don't do
on Tegra at present), and have the bus itself indicate which IOMMU
device is the IOMMU for that bus.
b) Add another property to each device that has a dma-window, containing
the phandle of the IOMMU that handles its accesses. The code above could
then validate that it was the IOMMU for each device as it was registered.
Probably, devices should not be registered until the IOMMU that serves
them is available. Otherwise, can't a device probe, start making IO
accesses using a physical/bus memory map, and then later have that
yanked out and replaced by the IOMMU'd memory map. How is that
co-ordinated? That somewhat argues for each device explicitly setting up
the IOMMU registration, or the driver core handling the dependencies.
Finally, what is the implication of the TODO above? Given the limited
number of ASIDs on Tegra30, isn't that something we need to solve before
deploying this patch. Presumably solving it requires a DT binding to be
designed and reviewed?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
