iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
To: Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
Subject: Re: [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2
Date: Tue, 23 Sep 2014 11:04:22 -0500	[thread overview]
Message-ID: <54219A06.80201@ti.com> (raw)
In-Reply-To: <2586861.3TFFdmAzkQ@avalon>

Hi Laurent,

>
> On Tuesday 09 September 2014 17:31:44 Suman Anna wrote:
>>> On Tuesday 09 September 2014 16:33:11 Suman Anna wrote:
>>>> On 09/09/2014 10:45 AM, Laurent Pinchart wrote:
>>>>> The OMAP IOMMU driver supports both the OMAP1 and OMAP2+ IOMMU variants
>>>>> by splitting the driver into a core module and a thin arch-specific
>>>>> operations module.
>>>>>
>>>>> (In practice only the OMAP2+ module omap-iommu2 is implemented, but
>>>>> let's not denigrate the effort.)
>>>>
>>>> Thank you for the patch. I had something similar in my list of cleanup
>>>> TODO items on the OMAP IOMMU driver, but I was intending to cut down
>>>> more and consolidate the omap-iommu.c and omap-iommu2.c files into a
>>>> single one.
>>>>
>>>> This had been the case from the introduction of the driver going back to
>>>> v2.6.30, and OMAP1 was never added and I doubt it would be added anytime
>>>> in the foreseeable future.
>>>>
>>>>> The arch-specific operations module registers itself with the OMAP IOMMU
>>>>> core module at initialization time. This initializes a module global
>>>>> arch-specific operations pointer, used at runtime by the IOMMU
>>>>> instances.
>>>>>
>>>>> This scheme causes several issues. In addition to making it impossible
>>>>> to support different OMAP IOMMU types in a single system (which in all
>>>>> fairness is quite unlikely to happen),
>>>>
>>>> Yep, except for a few enhancements (like reporting Fault PC address on
>>>> OMAP4 DSPs, and dropping both endianness support), the core IOMMU
>>>> functionality hasn't changed much between OMAP2 and the latest OMAP4+
>>>> SoCs. So, my plan was to completely get rid of the iommu_functions (it
>>>> also eliminates the need for exporting most of the OMAP IOMMU API). So
>>>> while I am ok with the current patch, I prefer consolidation than
>>>> keeping the scalability alive, it can always be added if a need for that
>>>> arises. What do you think?
>>>
>>> I agree with your approach, but in the meantime we have a problem to
>>> solve.
>>> How about applying this patch now (it goes in the right direction anyway),
>>> and then removing the iommu functions when you will have time ?
>>
>> Can you give the subsys_initcall solution a try to see if that resolves
>> the problem at hand? That would be a much smaller change, if that
>> doesn't work we can go with this patch.
> 
> It seems to work.
> 
>> I will work on my cleanup list for 3.19.
> 
> Does that schedule still hold ? If so I'll submit a simple subsys_initcall() 
> patch for v3.18.

Yes, that would be great. I am working on the patches and will post them
in a couple of days.

regards
Suman

> 
>>>>  it also causes initialization
>>>>  
>>>>> ordering issues by requiring the arch-specific operations module to be
>>>>> loaded before any IOMMU user. This results in a probe breakage with the
>>>>> OMAP3 ISP driver when not compiled as a module.
>>>>
>>>> This can be fixed if we make the current omap-iommu2.c as a
>>>> subsys_initcall as well, right?
>>>>
>>>> regards
>>>> Suman
>>>>
>>>>> Fix the problem by inverting the dependency. Instead of having the
>>>>> omap-iommu2 module register itself to iommu-omap, make the iommu-omap
>>>>> retrieve the omap-iommu2 operations structure directly when probing the
>>>>> IOMMU device. This ensures that a probed IOMMU will always have valid
>>>>> arch-specific operations.
>>>>>
>>>>> As the arch-specific operations pointer is now initialized at probe
>>>>> time, this change requires turning it from a global variable into a
>>>>> per-device variable.
>>>>>
>>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>>>>> ---
>>>>>
>>>>>  drivers/iommu/omap-iommu-debug.c |  6 ++-
>>>>>  drivers/iommu/omap-iommu.c       | 94 +++++++++++++--------------------
>>>>>  drivers/iommu/omap-iommu.h       | 10 ++++-
>>>>>  drivers/iommu/omap-iommu2.c      | 18 +-------
>>>>>  4 files changed, 45 insertions(+), 83 deletions(-)
> 

  reply	other threads:[~2014-09-23 16:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09 15:45 [PATCH 0/2] OMAP IOMMU cleanups Laurent Pinchart
     [not found] ` <1410277545-32157-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-09-09 15:45   ` [PATCH 1/2] iommu/omap: Reverse dependency between omap-iommu and omap-iommu2 Laurent Pinchart
     [not found]     ` <1410277545-32157-2-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-09-09 21:33       ` Suman Anna
     [not found]         ` <540F7217.3070501-l0cyMroinI0@public.gmane.org>
2014-09-09 21:59           ` Laurent Pinchart
2014-09-09 22:31             ` Suman Anna
     [not found]               ` <540F7FD0.4010109-l0cyMroinI0@public.gmane.org>
2014-09-20 13:12                 ` Laurent Pinchart
2014-09-23 16:04                   ` Suman Anna [this message]
2014-09-09 15:45   ` [PATCH 2/2] iommu/omap: Remove omap_iommu unused owner field Laurent Pinchart
2014-09-09 21:41     ` Suman Anna
     [not found]     ` <1410277545-32157-3-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-09-25 13:57       ` Joerg Roedel

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=54219A06.80201@ti.com \
    --to=s-anna-l0cymroini0@public.gmane.org \
    --cc=florian.vaussard-p8DiymsW2f8@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).