From: s-anna@ti•com (Suman Anna)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Date: Wed, 26 Feb 2014 16:28:08 -0600 [thread overview]
Message-ID: <530E6A78.9060503@ti.com> (raw)
In-Reply-To: <530E682D.9070005@ti.com>
On 02/26/2014 04:18 PM, Suman Anna wrote:
> Hi Laurent,
>
> On 02/26/2014 02:36 PM, Laurent Pinchart wrote:
>> Hi Suman,
>>
>> On Wednesday 26 February 2014 14:23:03 Suman Anna wrote:
>>>> On Wednesday 26 February 2014 11:02:24 Suman Anna wrote:
>>>>> On 02/25/2014 08:13 PM, Laurent Pinchart wrote:
>>>>>> On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
>>>>>>> On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
>>>>>>>> On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
>>>>>>>>> From: Florian Vaussard <florian.vaussard@epfl•ch>
>>>>>>>>>
>>>>>>>>> This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
>>>>>>>>> the standard bindings used by OMAP peripherals, this patch uses a
>>>>>>>>> 'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
>>>>>>>>> bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl•ch>
>>>>>>>>> [s-anna at ti.com: split bindings document, add dra7 and bus error
>>>>>>>>> back]
>>>>>>>>> Signed-off-by: Suman Anna <s-anna@ti•com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> .../devicetree/bindings/iommu/ti,omap-iommu.txt | 28
>>>>>>>>> ++++++++++++
>>>>>>>>> 1 file changed, 28 insertions(+)
>>>>>>>>> create mode 100644
>>>>>>>>> Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
>>>>>>>>>
>>>>>>>>> diff --git
>>>>>>>>> a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
>>>>>>>>> b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new
>>>>>>>>> file
>>>>>>>>> mode 100644
>>>>>>>>> index 0000000..116492d
>>>>>>>>> --- /dev/null
>>>>>>>>> +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
>>>>>>>>> @@ -0,0 +1,28 @@
>>>>>>>>> +OMAP2+ IOMMU
>>>>>>>>> +
>>>>>>>>> +Required properties:
>>>>>>>>> +- compatible : Should be one of,
>>>>>>>>> + "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
>>>>>>>>> + "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
>>>>>>>>> + "ti,dra7-iommu" for DRA7xx IOMMU instances
>>>>>>>>> +- ti,hwmods : Name of the hwmod associated with the IOMMU
>>>>>>>>> instance
>>>>>>>>> +- reg : Address space for the configuration registers
>>>>>>>>> +- interrupts : Interrupt specifier for the IOMMU instance
>>>>>>>>> +- dma-window : IOVA start address and length
>>>>>>>>
>>>>>>>> Isn't the dma window more of a system configuration property than a
>>>>>>>> hardware property ? How do you expect it to be set?
>>>>>>>
>>>>>>> We are setting it based on the addressable range for the MMU.
>>>>>>
>>>>>> A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both
>>>>>> support the full 4GB VA space. Why do you need to restrict it ?
>>>>>
>>>>> I should have rephrased it better when I said addressable range. While
>>>>> the MMUs are capable of programming the full 4GB space, there are some
>>>>> address ranges that are private from the processor view. This
>>>>> window is
>>>>> currently used to set the range for the omap-iovmm driver (which only
>>>>> OMAP3 ISP is using atm), and there is no point in allowing the
>>>>> omap-iovmm driver the full range when the processor could never
>>>>> reach/access those addresses.
>>>>
>>>> But the IOMMU VA space is from a device point of view, not from a CPU
>>>> point of view. Could you point me to where those private ranges are
>>>> documented, in order to understand the problem correctly ?
>>>
>>> Yes, they are indeed from the device perspective. I meant DSP and/or IPU
>>> by processor.
>>>
>>> For example on OMAP3, you can refer to Table 2-9 in section 2.4.5 "DSP
>>> Subsystem Memory Space Mapping" of the OMAP36xx TRM, and the external
>>> addressable range starts from 0x11000000.
>>
>> OK, so it looks more like a property of the IOMMU master than a
>> property of
>> the IOMMU itself. It would be better to express it as such, but I
>> wonder how
>> that could be done, and if it would be worth it in this case.
>
> This property is currently solely used to configure the range for the
> omap-iovmm module, which were supplied through platform data in the
> non-DT case. I am wondering if the way to go here is to use
> iommu_domain_set_attr() and use the domain geometry values.
The other option is to supply these as driver match data, and switching
the compatible strings to identify the MMU instance precisely.
regards
Suman
>>
>> As not all masters (the OMAP3 ISP doesn't for instance) have restrictions
>> regarding the VA range they can address, should this property be at
>> least made
>> optional ?
>>
>>>>>>> We are reusing the existing defined property and it allows us to get
>>>>>>> rid of the IOVA start and end addresses defined in the pre-DT OMAP
>>>>>>> iommu platform data.
>>>>>>>
>>>>>>>>> +Optional properties:
>>>>>>>>> +- ti,#tlb-entries : Number of entries in the translation
>>>>>>>>> look-aside
>>>>>>>>> buffer. + Should be either 8 or 32 (default:
>>>>>>>>> 32)
>>>>>>>>> +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports
>>>>>>>>> throwing
>>>>>>>>> + back a bus error response on MMU faults.
>>>>>>>>
>>>>>>>> Do these features vary per IOMMU instance or per IOMMU model ?
>>>>>>>> In the
>>>>>>>> latter case they could be inferred from the compatible string by
>>>>>>>> the
>>>>>>>> driver without requiring them to be explicit in DT (whether you
>>>>>>>> want
>>>>>>>> to do so is left to you though).
>>>>>>>
>>>>>>> Well, these are fixed features given an IOMMU instance, like the
>>>>>>> OMAP3
>>>>>>> ISP is the only one that has 8 TLB entries, all the remaining
>>>>>>> ones have
>>>>>>> 32, and the IPU iommu instances are the only ones that support
>>>>>>> the bus
>>>>>>> error response back. I have no preference to any particular way, and
>>>>>>> sure the driver can infer these easily based on unique compatible
>>>>>>> strings per subsystem per SoC. I just happened to go with defining
>>>>>>> compatible strings per SoC, with the optional properties
>>>>>>> differentiating the fixed behavior between different IOMMU
>>>>>>> instances on
>>>>>>> that SoC. This is where I was looking for some inputs/guidance
>>>>>>> from the
>>>>>>> DT bindings maintainers on what is the preferred method.
>>>>>>
>>>>>> I think you've made the right choice. I wasn't sure whether those
>>>>>> parameters varied across IOMMU instances of compatible devices
>>>>>> (from a
>>>>>> compatible string point of view) or were constant. As they vary they
>>>>>> should be expressed in DT.
>>>>>
>>>>> Yeah, I wasn't sure if these qualify as features (as per
>>>>> Documentation/devicetree/bindings/ABI.txt section II.2).
>>>>>
>>>>> regards
>>>>> Suman
>>>>>
>>>>>>>>> +Example:
>>>>>>>>> + /* OMAP3 ISP MMU */
>>>>>>>>> + mmu_isp: mmu at 480bd400 {
>>>>>>>>> + compatible = "ti,omap2-iommu";
>>>>>>>>> + reg = <0x480bd400 0x80>;
>>>>>>>>> + interrupts = <24>;
>>>>>>>>> + ti,hwmods = "mmu_isp";
>>>>>>>>> + ti,#tlb-entries = <8>;
>>>>>>>>> + dma-window = <0 0xfffff000>;
>>>>>>>>> + };
>>
>
next prev parent reply other threads:[~2014-02-26 22:28 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 18:15 [PATCHv2 00/16] OMAP IOMMU DT adaptation and cleanup Suman Anna
2014-02-13 18:15 ` [PATCHv2 01/16] iommu/omap: convert to devm_* interfaces Suman Anna
2014-02-25 21:10 ` Laurent Pinchart
2014-02-13 18:15 ` [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL Suman Anna
2014-02-25 21:13 ` Laurent Pinchart
2014-02-25 22:32 ` Suman Anna
2014-02-26 2:05 ` Laurent Pinchart
2014-02-26 16:45 ` Suman Anna
2014-02-13 18:15 ` [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings Suman Anna
2014-02-24 12:57 ` Florian Vaussard
2014-02-24 18:09 ` Suman Anna
2014-02-25 21:26 ` Laurent Pinchart
2014-02-25 23:02 ` Suman Anna
2014-02-26 2:13 ` Laurent Pinchart
2014-02-26 17:02 ` Suman Anna
2014-02-26 19:32 ` Laurent Pinchart
2014-02-26 20:23 ` Suman Anna
2014-02-26 20:36 ` Laurent Pinchart
2014-02-26 22:18 ` Suman Anna
2014-02-26 22:28 ` Suman Anna [this message]
2014-02-26 22:43 ` Laurent Pinchart
2014-02-26 23:14 ` Suman Anna
2014-02-13 18:15 ` [PATCHv2 04/16] iommu/omap: add devicetree support Suman Anna
2014-02-26 17:08 ` Tony Lindgren
2014-02-13 18:15 ` [PATCHv2 05/16] iommu/omap: enable bus-error back on supported iommus Suman Anna
2014-02-13 18:15 ` [PATCHv2 06/16] iommu/omap: allocate archdata on the fly for DT-based devices Suman Anna
2014-02-13 18:15 ` [PATCHv2 07/16] iommu/omap: allow enable/disable even without pdata Suman Anna
2014-02-25 21:15 ` Laurent Pinchart
2014-02-25 22:41 ` Suman Anna
2014-02-13 18:15 ` [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2 Suman Anna
2014-02-25 21:17 ` Laurent Pinchart
2014-02-26 17:09 ` Tony Lindgren
2014-02-26 17:15 ` Tony Lindgren
2014-02-28 19:58 ` Paul Walmsley
2014-02-28 20:42 ` Suman Anna
2014-02-13 18:15 ` [PATCHv2 09/16] ARM: OMAP2+: change the ISP device archdata MMU name Suman Anna
2014-02-13 18:15 ` [PATCHv2 10/16] ARM: OMAP2+: use pdata quirks for iommu reset lines Suman Anna
2014-02-26 17:17 ` Tony Lindgren
2014-02-26 18:04 ` Suman Anna
2014-02-13 18:15 ` [PATCHv2 11/16] ARM: OMAP3: fix iva mmu programming issues Suman Anna
2014-02-13 18:15 ` [PATCHv2 12/16] ARM: OMAP5: hwmod data: add mmu data for ipu & dsp Suman Anna
2014-02-13 18:15 ` [PATCHv2 13/16] ARM: OMAP2+: extend iommu pdata-quirks to OMAP5 Suman Anna
2014-02-13 18:15 ` [PATCHv2 14/16] ARM: OMAP3: hwmod data: cleanup data for IOMMUs Suman Anna
2014-02-26 17:18 ` Tony Lindgren
2014-02-26 17:59 ` Suman Anna
2014-02-27 9:16 ` Florian Vaussard
2014-02-28 0:25 ` Tony Lindgren
2014-02-13 18:15 ` [PATCHv2 15/16] ARM: OMAP4: " Suman Anna
2014-02-13 18:15 ` [PATCHv2 16/16] ARM: OMAP2+: Remove legacy omap-iommu.c Suman Anna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530E6A78.9060503@ti.com \
--to=s-anna@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox