On 04/13/2012 06:15 AM, Thierry Reding wrote:
> * Hiroshi Doyu wrote:
>> Thierry Reding wrote:
>>> * Hiroshi Doyu wrote:
>>>> + smmu: smmu@7000f000 {
>>>> + compatible = "nvidia,tegra30-smmu";
>>>> + reg = < 0x7000f000 0x400 /* controller registers */
>>>> + 0x6000c000 0x150 /* AHB Arbitration registers */
>>>> + 0x00001000 0x3ffff000 >;/* Virtual address space range
>>>> + * Exclude the 1st & last page
>>>> + */
>>>> + interrupts = < 0 13 0x40 >;
>>>> + };
>>>> };
>>>
>>> Why is the virtual address space range limited to 1 GiB? What is the reason
>>> for the exclusion of the first and last pages?
>>
>> It's because physical RAM is located 2-4GB, and we may want to use
>> those area 1-1(V==P) mapping in some cases. This could be extended
>> with larger RAM without 1-1 mapping theoretically. So far 1GB seems to
>> be enough.
>
> I'm thinking that this would be better off in a separate property so that
> it's easier for boards to override it.
Yes, and for another reason: The entries in the reg property are
supposed to be within the bus address space that contains the device,
whereas here this 3rd reg entry is being used to define something about
an entirely unrelated address space - the virtual address space seen by
SMMU clients.
>> The 1st page for AVP vector, and the last one is required by another
>> H/W entity.
>
> I would expect such peculiarities to be handled by the driver internally.
> That way users wouldn't have to know or care about these kind of details.
> If it can't be handled by the driver then at least it should be mentioned
> explicitly in the binding documentation.
I agree, but:
Why do those pages even need special handling? Doesn't the AVP get its
own address space ID, and then can set it up however it wants?
--
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
