How to handle named resources with DT?

[Paul Walmsley]

On Fri, 26 Aug 2011, David Gibson wrote:

> static struct of_device_id foodevice_of_match[] __devinitdata = {
> 	{ .compatible = "foocorp,foodevice1234",
> 	  .resource_names = {"base_regs", "extra_regs", }, },
> 	{ .compatible = "foocorp,foodevice1239",
> 	  .resource_names = {"base_regs", "extra_regs", "more_regs", }, }, 
> 	{ },
> };

This preserves platform_device_get_byname(), which is good.  It also 
facilitates debugging: like naming resources in the device tree data, it 
provides something human-readable to output to /proc/iomem and similar 
mechanisms.

But it doesn't resolve the problem on the DT generation side.

When someone at a hardware vendor writes the DT generator code, they'll 
have to implement a similar table to yours for each IP block with multiple 
resources of the same type.

IP blocks with multiple resources of the same type are not isolated cases.  
For example, of the 82 IP block instances on the OMAP4 that have hwmod 
data currently upstream (a subset of what's actually on the chip), at 
least 68 of them (83%) have multiple resources of the same type[1][2].

Certainly, from a kernel development perspective, one can decide to just 
dump this kind of DT generation problem back on the hardware vendors.  
But it seems more efficient and less error-prone to simply remove both 
mapping tables, and to export names directly from the IP block data into 
the device data format.


- Paul

1. The number is actually higher than this.  This count doesn't
   include IP blocks with multiple address ranges on different 
   interconnects.

2. Data from arch/arm/mach-omap2/omap_hwmod_44xx_data.c, as of Linux 
   v3.1-rc3.
   Available from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod_44xx_data.c;h=6201422c0606b5103c01e563f67060134658774d;hb=HEAD