On Wed, Mar 9, 2011 at 9:43 AM, Sakari Ailus
<sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> David Cohen wrote:
>> ISP doesn't consider 0x0 as a valid address, so it should explicitly
>> exclude first page from allowed 'da' range.
>>
>> Signed-off-by: David Cohen <dacohen@xxxxxxxxx>
>> ---
>> Âarch/arm/mach-omap2/omap-iommu.c | Â Â2 +-
>> Â1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
>> index 3fc5dc7..3bea489 100644
>> --- a/arch/arm/mach-omap2/omap-iommu.c
>> +++ b/arch/arm/mach-omap2/omap-iommu.c
>> @@ -33,7 +33,7 @@ static struct iommu_device omap3_devices[] = {
>> Â Â Â Â Â Â Â Â Â Â Â .name = "isp",
>> Â Â Â Â Â Â Â Â Â Â Â .nr_tlb_entries = 8,
>> Â Â Â Â Â Â Â Â Â Â Â .clk_name = "cam_ick",
>> - Â Â Â Â Â Â Â Â Â Â .da_start = 0x0,
>> + Â Â Â Â Â Â Â Â Â Â .da_start = 0x1000,
>> Â Â Â Â Â Â Â Â Â Â Â .da_end = 0xFFFFF000,
>> Â Â Â Â Â Â Â },
>> Â Â Â },
>
> Hi David!
Hi Sakari,
>
> Thanks for the patch.
And thanks for the comments. :)
>
> My question is once again: is this necessary? My understanding is that
> the IOMMU allows mapping the NULL address if the user wishes to map it
> explicitly. da_end specifies the real hardware limit for the mapped top
> address, da_start should do the same for bottom.
Hm. da_start/da_end in this case belong to OMAP3 IOMMU ISP VM. It
means they're related to OMAP3 ISP only. But they do not reflect the
hw limit, as the range limit is anything which fits in u32. They say
what's the range OMAP3 ISP is expecting to have mapped. And the answer
to this question is the first page is not expected. Then, why say the
opposite in da_start?
>
> I think that the IOMMU users should be either able to rely that they get
> no NULL allocated automatically for them. Do we want or not want it to
> be part of the API? I don't think the ISP driver is a special case of
> all the possible drivers using the IOMMU.
My understanding after this discussion is address 0x0 should be
allowed (what is done by patch 3/3 of this set). But as a safer
choice, it won't be returned without explicitly request (what is done
in path 1/3). Because of that, I'm OK in drop this patch 2/3. But then
there's one question which is the motivation for this change:
If the current OMAP3 ISP driver doesn't want the first page, (1)
should we pass a generic information and expect IOVMM driver to
correct it to ISP need or (2) should we pass the information which
reflects the real ISP driver's need?
My understanding is (2). But I'm fine with (1) as it will lead to the
same result.
>
> On the other hand, probably there will be an API change at some point
> for the IOMMU since as far as I remember, there are somewhat
> established APIs for IOMMUs in existence.
At some point we need to find a standard for many IOMMU drivers. But
for now we need to stick with what we have. :)
Regards,
David Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
