Re: hwmod data duplication (was: Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency)

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 6132 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]