Arm device tree wonder

[Pierre Beaumon]

Hello Paul,

thanks for your reply.

> On Tue, 30 Aug 2011, Pierre Beaumon wrote:
> 
> > Also I believe one big arm problem is a lack of common
> > infrastructure that lead to code duplication. Some machine try to
> > do too much things. omap2 (mach-omap2 + plat-omap) is about 80
> > KSLOC over 400KSLOC (76 mach 
> > + plat directories). That 8 times bigger than the average 
> > ((80/2)/(400/76))! There are either common stuff that should be
> > shared, or some stuff should be moved in drivers.
> 
> Here are some additional data points you might consider adding to
> your analysis:
> 
> - Consider taking into account what percentage of those lines are for 
>   SoC-specific device data files.  Where should those files be moved, 
>   before a DT (or other data format) conversion?
Soc specific data are mainly in file starting with board* on omap and take only 15 KSLOC.

Most of code come from  omap_device, clock, powerdomain, hwmod, mux code (in mach-omap2 more than 30KSLOC for clock* omap_hwmod* mux*)
This code won't be removed when we switch to DT, and I believe this code can be shared with others.

For each driver/framework in bsp (plat-*/mach-*) it could be interesting to have an answer to the following questions : 
- what it does
- why it is specific to this SOC
- can it be usefull for other SOC
- can an existing framework be used/enhanced

For example the mux code it a common problem to all SOC and is not specific to omap. Having a generic framework could be great (pinmux ?) 


hwmod [1] doesn't look like specific to OMAP and can apply to any arm SOC. Why should it be in omap code ?
Platform_bus is limited (see my example on pci like bus) and arm may need a better bus. Why not omap_device/hwmod ?

This make me think of the time when linux didn't get a wifi stack and each driver came with its own stack.


> - Consider accounting for the extra code and data needed for
> fine-grained power management, compared to the average SoC core code,
> assuming the SoC supports it.
Yes omap is fine tuned for power management, but the power management concept is not limited to omap and can be shared.
See for example the pm_runtime framework that can be used by everybody (pc, arm, ...).



[1]
 * One way to view an OMAP SoC is as a collection of largely unrelated
 * IP blocks connected by interconnects.  The IP blocks include
 * devices such as ARM processors, audio serial interfaces, UARTs,
 * etc.  Some of these devices, like the DSP, are created by TI;
 * others, like the SGX, largely originate from external vendors.  In
 * TI's documentation, on-chip devices are referred to as "OMAP
 * modules."  Some of these IP blocks are identical across several
 * OMAP versions.  Others are revised frequently.
[...]
* OMAP hwmod provides a consistent way to describe the on-chip
 * hardware blocks and their integration into the rest of the chip.
 * This description can be automatically generated from the TI
 * hardware database.  OMAP hwmod provides a standard, consistent API
 * to reset, enable, idle, and disable these hardware blocks.  And
 * hwmod provides a way for other core code, such as the Linux device 
 * code or the OMAP power management and address space mapping code,
 * code or the OMAP power management and add
ress space mapping code,
 * to query the hardware database.