linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
Date: Tue, 22 Jan 2013 10:32:14 -0800	[thread overview]
Message-ID: <20130122183213.GN15361@atomide.com> (raw)
In-Reply-To: <50FE8C5C.2030409@ti.com>

* Benoit Cousson <b-cousson@ti.com> [130122 04:59]:
> Hi Tony,
> 
> On 01/21/2013 07:01 PM, Tony Lindgren wrote:
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130121 07:09]:
> >>>
> >> So I looked at this one with help of Rajendra. We can get rid of the
> >> IRQ and DMA data(needs DMA biding updates) easily. The address
> >> space though is needed since hwmod code uses it to setup the
> >> sysconfig registers.
> > 
> > OK great. The address space tinkering in hwmod code should be
> > moved to be done in the drivers.
> > 
> > As discussed earlier, there should be a driver specific reset
> > function driver_xyz_reset() in the driver header file so the
> > hwmod code can call it too in a late_initcall if no driver is
> > loaded.
> > 
> >> Extracting that from DT code seems to be really expensive and
> >> ugly [1]. I am yet to try out DMA lines removal but that seems
> >> to be doable by pulling Vinod'd DMA engine branch and updating
> >> DT file.
> > 
> > The overhead here does not matter as it should only happen in a
> > late_initcall and only for some of the drivers. For that to
> > happen we just need to go through the list of modules not yet
> > probed. We also need to have some locking in the driver specific
> > reset function to avoid races with the loadable modules.
> 
> Mmm, not really, that address is used by *every* hwmod for sysconfig
> access. So iterating over every DT nodes for every hwmods seems pretty
> ugly and un-optimized.

I think you missed one point. Iterating over all the modules should
only happen for the unused modules. With sysconfig access moved to the
drivers getting the ioaddress is done in the standard way in the driver
probe instead of iterating over all of them.
 
> That being said, it might worth checking the overhead. That will not
> make the fix nicer anyway, but at least it will allow a smooth
> transition toward a real clean solution. Assuming someone will work on
> that later, which might never happen.

Right, so who is going to do all the work needed?

Regards,

Tony

  reply	other threads:[~2013-01-22 18:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18 15:27 [PATCH 00/10] ARM: OMAP5: hwmod, clock and prm data files Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 01/10] ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 02/10] ARM: OMAP5: CM: " Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 03/10] ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 04/10] ARM: OMAP5: SCRM: Add OMAP54XX header file Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 05/10] ARM: OMAP2+: clockdomain data: Add OMAP54XX data and update the header Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 06/10] ARM: OMAP5: powerdomain " Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers Santosh Shilimkar
2013-01-18 17:19   ` Tony Lindgren
2013-01-21  8:14     ` Santosh Shilimkar
2013-01-21 18:08       ` Tony Lindgren
2013-01-21 14:27   ` Sebastien Guiriec
2013-01-21 14:31     ` Santosh Shilimkar
2013-01-21 21:34       ` Sebastien Guiriec
2013-01-30 17:37   ` Jon Hunter
2013-01-31 11:49     ` Rajendra Nayak
2013-01-18 15:27 ` [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar
2013-01-18 17:15   ` Tony Lindgren
2013-01-21  8:11     ` Santosh Shilimkar
2013-01-21 14:25       ` Sebastien Guiriec
2013-01-21 15:06       ` Santosh Shilimkar
2013-01-21 18:01         ` Tony Lindgren
2013-01-22 12:55           ` Benoit Cousson
2013-01-22 18:32             ` Tony Lindgren [this message]
2013-01-29 13:57               ` Santosh Shilimkar
2013-01-29 17:24                 ` Tony Lindgren
2013-01-30  9:10                   ` Santosh Shilimkar
2013-01-22 13:14           ` Rajendra Nayak
2013-01-22 18:39             ` Tony Lindgren
2013-01-24  9:50               ` Rajendra Nayak
2013-01-25 16:55                 ` Tony Lindgren
2013-01-18 15:27 ` [PATCH 09/10] ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data Santosh Shilimkar
2013-01-18 15:27 ` [PATCH 10/10] ARM: OMAP5: Enable build and frameowrk initialisations Santosh Shilimkar
2013-02-01  9:13 ` [PATCH 00/10] ARM: OMAP5: hwmod, clock and prm data files Santosh Shilimkar
2013-04-03 20:13 ` Paul Walmsley
2013-04-04 10:36   ` Santosh Shilimkar

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=20130122183213.GN15361@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.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).