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 17:14:01 -0600 [thread overview]
Message-ID: <530E7539.6040106@ti.com> (raw)
In-Reply-To: <2109933.259zooPLHZ@avalon>
Hi Laurent,
>
> On Wednesday 26 February 2014 16:28:08 Suman Anna wrote:
>> On 02/26/2014 04:18 PM, Suman Anna wrote:
>>> On 02/26/2014 02:36 PM, Laurent Pinchart wrote:
>>>> 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.
>
> If I'm not mistaken omap-iovmm is something we want to get rid of. I know that
> the OMAP3 ISP driver is the only user of that module, and I've started working
> on fixing that, but I'm currently lacking time to complete the work.
>
> Now, if we get rid of omap-iovmm, does that mean that the dma-window property
> won't need to be specified anymore ? If so, given that the only omap-iovmm
> user is the OMAP3 ISP driver, I would propose to drop the property and just
> hardcode the value.
Yeah, none of our OMAP4+ stacks use omap-iovmm, or similar dynamic
reservation scheme at the moment. I am perfectly fine with dropping the
property and hard-coding it in the driver with a note. DSP/Bridge has a
similar usage (in dmm.c), but that code is localized within the driver.
Thanks for all the comments.
regards
Suman
>
> Please let me know if there's something I've missed.
>
>>> 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.
>
> [snip]
>
next prev parent reply other threads:[~2014-02-26 23:14 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
2014-02-26 22:43 ` Laurent Pinchart
2014-02-26 23:14 ` Suman Anna [this message]
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=530E7539.6040106@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