On Dec 03, 2011, at 10:53, Kumar Gala wrote:
> On Dec 2, 2011, at 10:27 AM, Kyle Moffett wrote:
>> Instead of using the open-coded "reg" property lookup and address
>> translation in mpic_alloc(), directly call of_address_to_resource().
>> This includes various workarounds for special cases which the naive
>> of_address_translate() does not.
>> 
>> Afterwards it is possible to remove the copiously copy-pasted calls to
>> of_address_translate() from the 85xx/86xx/powermac platforms.
>> 
>> Signed-off-by: Kyle Moffett <kyle.d.moff...@boeing.com>
>> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
>> Cc: Paul Mackerras <pau...@samba.org>
>> Cc: Grant Likely <grant.lik...@secretlab.ca>
>> Cc: Kumar Gala <ga...@kernel.crashing.org>
>> ---
>> arch/powerpc/platforms/85xx/corenet_ds.c  |    9 +----
>> arch/powerpc/platforms/85xx/ksi8560.c     |    9 +----
>> arch/powerpc/platforms/85xx/mpc8536_ds.c  |    9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ads.c |    9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_cds.c |    9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_ds.c  |   11 +----
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c |    9 +----
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   11 +----
>> arch/powerpc/platforms/85xx/p1010rdb.c    |    9 +----
>> arch/powerpc/platforms/85xx/p1022_ds.c    |    9 +----
>> arch/powerpc/platforms/85xx/p1023_rds.c   |    9 +----
>> arch/powerpc/platforms/85xx/sbc8548.c     |    9 +----
>> arch/powerpc/platforms/85xx/sbc8560.c     |    9 +----
>> arch/powerpc/platforms/85xx/socrates.c    |    9 +----
>> arch/powerpc/platforms/85xx/stx_gp3.c     |    9 +----
>> arch/powerpc/platforms/85xx/tqm85xx.c     |    9 +----
>> arch/powerpc/platforms/85xx/xes_mpc85xx.c |    9 +----
>> arch/powerpc/platforms/86xx/pic.c         |    4 +-
>> arch/powerpc/platforms/powermac/pic.c     |    8 +---
>> arch/powerpc/sysdev/mpic.c                |   61 
>> ++++++++++++++++-------------
>> 20 files changed, 55 insertions(+), 175 deletions(-)
> 
> What about cleaning up:
> 
> arch/powerpc/platforms/chrp/setup.c:    chrp_mpic = mpic_alloc(np, opaddr, 
> MPIC_PRIMARY,
> arch/powerpc/platforms/embedded6xx/holly.c:     mpic = mpic_alloc(tsi_pic, 
> mpic_paddr,
> arch/powerpc/platforms/embedded6xx/linkstation.c:       mpic = 
> mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c:      mpic = 
> mpic_alloc(tsi_pic, mpic_paddr,
> arch/powerpc/platforms/embedded6xx/storcenter.c:        mpic = 
> mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC
> arch/powerpc/platforms/maple/setup.c:   mpic = mpic_alloc(mpic_node, 
> openpic_addr, flags,
> arch/powerpc/platforms/pasemi/setup.c:  mpic = mpic_alloc(mpic_node, 
> openpic_addr,
> arch/powerpc/platforms/pseries/setup.c: mpic = mpic_alloc(pSeries_mpic_node, 
> openpic_addr,
> 
> Seems like we should be able to remove the 'phys_addr' argument altogether.

Well, ideally the MPIC code would just be a OF platform_driver with a
bit of supplementary platform_data to deal with device-tree flaws.
Unfortunately it's quite a long way from that.

Some platforms seem to prefer to use a "platform-open-pic" property on
the root node instead of setting up the "reg" node of the open-pic
itself.

Furthermore, the ISU configuration seems to be board-specific.  pSeries
seems to have all of the ISUs configured as additional cells in the
"platform-open-pic" property, but almost all of the rest are just
hard-coded offsets from the PIC address in the board-support code.

If it was possible to fix the device-trees on the systems with hardcoded
offsets then we could put the ISU addresses into the "platform-open-pic"
property and test that in mpic_alloc().

Otherwise there's still going to be a fair amount of hardcoding for
specific boards.

Regardless, I think this patch series is a good first cut and cleaning
up some of the more egregious code duplication there.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to