[PATCH] [POWERPC] Fix interrupt routing and setup of ULI M1575 on FSL boards

Kumar Gala galak at kernel.crashing.org
Wed Sep 12 05:08:14 EST 2007


On Sep 11, 2007, at 1:43 PM, Becky Bruce wrote:

>
> On Sep 11, 2007, at 1:33 PM, Kumar Gala wrote:
>
>>
>> On Sep 11, 2007, at 1:22 PM, Olof Johansson wrote:
>>
>>> On Tue, Sep 11, 2007 at 01:00:47PM -0500, Kumar Gala wrote:
>>>>
>>>> On Sep 11, 2007, at 12:20 PM, Olof Johansson wrote:
>>>>
>>>>> On Fri, Aug 17, 2007 at 12:03:48AM -0500, Kumar Gala wrote:
>>>>>>
>>>>>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>>>>>> ---
>>>>>>  arch/powerpc/boot/dts/mpc8544ds.dts        |   88 ++++------
>>>>>>  arch/powerpc/boot/dts/mpc8641_hpcn.dts     |  114 +++----------
>>>>>>  arch/powerpc/platforms/85xx/Kconfig        |    1 +
>>>>>>  arch/powerpc/platforms/85xx/mpc8544_ds.c   |  214
>>>>>> ++----------------------
>>>>>>  arch/powerpc/platforms/86xx/Kconfig        |    1 +
>>>>>>  arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |  224
>>>>>> ++-----------------------
>>>>>>  arch/powerpc/platforms/Kconfig             |    8 +
>>>>>>  arch/powerpc/platforms/Makefile            |    3 +
>>>>>>  arch/powerpc/platforms/fsl_uli1575.c       |  255
>>>>>> ++++++++++++++++++++++++++++
>>>>>>  9 files changed, 363 insertions(+), 545 deletions(-)
>>>>>>  create mode 100644 arch/powerpc/platforms/fsl_uli1575.c
>>>>>>
>>>>>
>>>>> Since when do we add code directly under powerpc/platforms? Isn't
>>>>> that
>>>>> what we have sysdev for?
>>>>>
>>>>> I know this is already picked up, but I just noticed it when
>>>>> looking at
>>>>> Kumar's 8572 patch. :-(
>>>>
>>>> I put it in platforms since it was related to the boards not the
>>>> chips.  We
>>>> can go around about what sysdev actual means, but I'm using the
>>>> assumption
>>>> that its for processor & bridges (for discrete processors 10x,
>>>> mv640x0,
>>>> etc).  Things that are board specific like the ULI I'm putting  
>>>> under
>>>> platforms/
>>>
>>> Hmm, I don't like the pollution of that directory myself,
>>> especially since
>>> we've been able to keep it clean up until now.
>>
>> What's it matter if we have files under platforms/
>>
>
> The original intent of platforms as we (Kumar included) laid it out  
> was that it *only* contain platform subdirs.  This makes it easy to  
> poke around in platforms, and it makes reading the "ls" of that  
> directory much more meaningful and informative.  It also makes it  
> easy to figure out where a file might be without having to have too  
> much knowledge about the devices themselves. I really don't like  
> the idea of polluting this directory.

That's bogus already.  Parts of platform code exist in sysdev/ or  
arch/powerpc/kernel/ so there isnt a single place to look.  While  
that might have been the intent its not true in practice.

>> Would you feel better if it was in platforms/common/ or platforms/fsl
>>
>>> Maybe it would make more sense for you guys to slice the platforms
>>> differently, and have a common platform for the eval boards you have
>>> with ULi on them instead of grouping it by core used by the  
>>> processor
>>> on the board.
>>>
>>> (In other words, move 86xx over under 85xx, since there wouldn't be
>>> much
>>> left over anyway).
>>
>> Moving 86xx (classic 74xx core) under 85xx (book e500 core) makes
>> even less sense to me.
>
> Yeah, that makes *no* sense to me either.  It's an unfortunate  
> artifact of the naming of boards to include the core name.  While  
> the devices and boards may be similar, once you have bookE vs non- 
> bookE cores, they become quite different.
>
> I still don't see why this isn't in "sysdev".  We intended that to  
> be the device "kitchen sink".  If we really don't want to put it  
> there, then I would prefer creating a "fsl_common" or "common"  
> directory under platforms.
>
> I'm also guilty of not noticing the original patch - my apologies.

maybe we should just have a platforms/fsl for all boards from  
freescale.  Not having things broken up by which processor family  
they are for.

- k



More information about the Linuxppc-dev mailing list