hwmod data duplication (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency)
Felipe Balbi
balbi at ti.com
Tue Feb 19 17:22:15 EST 2013
Hi,
On Tue, Feb 19, 2013 at 02:09:33PM -0800, Tony Lindgren wrote:
> > On Tue, Feb 19, 2013 at 11:31:22AM -0800, Tony Lindgren wrote:
> > > > However... if you think you're going to get away with another total
> > > > rewrite of OMAP device support away from hwmod to a new scheme with a
> > > > new load of huge churn, think again. Remember, churn is evil. I've
> > > > complained to you about the amount of churn that OMAP manufactures
> > > > in the past. Linus has complained about it too. You can't continue
> > > > like this.
> > >
> > > I don't think there's any churn needed here if done properly. It's
> > > mostly a question of dropping duplicate data from hwmod that we
> > > already have available in device tree. That means we can shrink the
> > > hwmod data needed.
> >
> > how about starting by removing register addresses and interrupt numbers
> > which are passed by devicetree today ? If you want to move to DT-only
> > now even without all drivers DT-adapted, you can have something like
> > what Marvel folks did for kirkwood:
> >
> > static void __init kirkwood_dt_init(void)
> > {
> >
> > [ ... ]
> >
> > if (of_machine_is_compatible("globalscale,dreamplug"))
> > dreamplug_init();
> >
> > if (of_machine_is_compatible("dlink,dns-kirkwood"))
> > dnskw_init();
> >
> > if (of_machine_is_compatible("iom,iconnect"))
> > iconnect_init();
> >
> > [ ... ]
> >
> > of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
> > }
> >
> > those machine-based inits are there just to initialize drivers which
> > aren't converted to DT.
>
> Yes we could do that at least partially, but..
>
> > this would let you remove all board-files except board-generic.c and
> > remove data which is already passed in via DT. It has the benefit of
> > showing Linus (or whoever cares) that we are working to remove the
> > "churn" while also removing some of the pressure of DT conversion, since
> > there are still details which need to be sorted out (UART function
> > pointers, clock nodes via DT - see Roger's discussion with Rajendra, DMA
> > nodes, etc etc).
>
> ..that means massive amount of churn in the board-*.c files to convert
> them to various init functions to be called from board-generic.c and
> removing the ones that are working with DT.
why ? I meant that only what's not converted to DT today should be
handled this way. Also, most of the "churn" is already there
(usb_musb_init(), usb_ehci_init(), etc etc), it just needs to be called
from a different place. We don't need to have one function for each
board, however, maybe we could target by-soc:
if (of_is_compatible("omap3"))
omap3_init_devices(); /* or whatever you wanna call it */
omap_init_devices() has initialization for everything which isn't DT
adapted today and as we move things to DT, there's a single place to
remove code from.
> I think we're better off making first sure things are usable with
> DT, then just dropping the board-*.c files as we go.
>
> And omap4 is the place to start as we only have blaze and panda
> board files. Once DSS, USB and WLAN work with the .dts files, we
> can just drop those board files and make omap4 DT only.
fair enough.
> We may be able to drop omap4 board-*.c files faster than going full
> DT with few selected legacy init functions in board-generic.c for
> things like LCD panel configuration etc.
>
> > Only on board-files we're talking about over 13K lines:
> >
> > arch/arm/mach-omap2/board-2430sdp.c | 289 ------
> > arch/arm/mach-omap2/board-3430sdp.c | 602 ------------
> > arch/arm/mach-omap2/board-3630sdp.c | 216 -----
> > arch/arm/mach-omap2/board-4430sdp.c | 730 ---------------
> > arch/arm/mach-omap2/board-am3517crane.c | 97 --
> > arch/arm/mach-omap2/board-am3517evm.c | 398 --------
> > arch/arm/mach-omap2/board-apollon.c | 342 -------
> > arch/arm/mach-omap2/board-cm-t35.c | 769 ----------------
> > arch/arm/mach-omap2/board-cm-t3517.c | 302 ------
> > arch/arm/mach-omap2/board-devkit8000.c | 648 -------------
> > arch/arm/mach-omap2/board-flash.c | 242 -----
> > arch/arm/mach-omap2/board-flash.h | 62 --
> > arch/arm/mach-omap2/board-h4.c | 347 -------
> > arch/arm/mach-omap2/board-igep0020.c | 673 --------------
> > arch/arm/mach-omap2/board-ldp.c | 440 ---------
> > arch/arm/mach-omap2/board-n8x0.c | 762 ---------------
> > arch/arm/mach-omap2/board-omap3beagle.c | 549 -----------
> > arch/arm/mach-omap2/board-omap3evm.c | 762 ---------------
> > arch/arm/mach-omap2/board-omap3logic.c | 249 -----
> > arch/arm/mach-omap2/board-omap3pandora.c | 623 -------------
> > arch/arm/mach-omap2/board-omap3stalker.c | 432 ---------
> > arch/arm/mach-omap2/board-omap3touchbook.c | 391 --------
> > arch/arm/mach-omap2/board-omap4panda.c | 467 ----------
> > arch/arm/mach-omap2/board-overo.c | 556 -----------
> > arch/arm/mach-omap2/board-rm680.c | 165 ----
> > arch/arm/mach-omap2/board-rx51-peripherals.c | 1276 --------------------------
> > arch/arm/mach-omap2/board-rx51-video.c | 89 --
> > arch/arm/mach-omap2/board-rx51.c | 128 ---
> > arch/arm/mach-omap2/board-rx51.h | 11 -
> > arch/arm/mach-omap2/board-ti8168evm.c | 62 --
> > arch/arm/mach-omap2/board-zoom-debugboard.c | 139 ---
> > arch/arm/mach-omap2/board-zoom-display.c | 147 ---
> > arch/arm/mach-omap2/board-zoom-peripherals.c | 304 ------
> > arch/arm/mach-omap2/board-zoom.c | 155 ----
> > arch/arm/mach-omap2/board-zoom.h | 10 -
> > 35 files changed, 13434 deletions(-)
> >
> > If we remove all addresses and interrupts, numbers look even better.
>
> Yeah. Let's start with omap4 first when DSS + USB + WLAN work.
USB is going to be ready for v3.10, likely Wlan too.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130220/c373cf44/attachment.sig>
More information about the linux-arm-kernel
mailing list