RFC: cpm2_devices.c

[Allen Curtis]

> On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:
>
>> My personal opinions:
>>
>> 	* Use macro-offsets into a cpm2_map_t struct
>
> Not going to happen.  Sorry.
>

Interesting... So are you thinking of eliminating the cpm_map_t 
structure all together?

>> 	* Put fcc_c regs back in
>
> Can you explain this.  I'm not 100% sure what regs you are referring 
> to.
>

The registers that he is referring to are in my patch with a comment 
about moving them to the device driver specific structure. The base 
address changed depending on processor.

>> 	* dpram[PROFF_*] should be in the resources list
>
> The patch I posted seems to do that.  I'm guessing these comments may 
> be against Allen's initial patch.
>
My patch did you the #defines from cpm2.h to specify the PROFF 
locations. It did not use dpram[PROFF] since that would be an address 
not an offset from the base.

>> 	* cpm2_* is a better name than MPC82xx_* or MPC85xx_*
>> 	* Keep CPM2_DMA, etc, as these *should* be showing up in
>> 	  /proc/iomem, since, IIRC, the platform layer does
>> 	  reserve them upon registration. (And I *do* have a DMA
>> 	  layer then uses CPM2_DMA as a driver-ish thing)
>
> I'll agree on DMA, do you see value in CPM, SI1 and SI2 being here?  
> And if so for what?
>
I really do not want to belabor this point about naming conventions but 
I believe it will become more of a problem in the future. The problem 
as I see it is the PQ2 is a multi-core processor composed of a PPC 603 
and a CPM. So the question is, is it more efficient to describe the 
multi-core permutations or the pieces that are put together to create 
the processor. As industry uses more IP blocks to create SoCs I can see 
the "describe the chip" approach to be a exponential problem.

DMA and CPM should be in the device list. They represent a shared 
resource or a management function shared by the "real" devices. Putting 
them in the list has the advantage that their resources are mapped with 
the device is registered. (as mentioned by Jason M.) Perhaps there will 
be a need for a DMA manager.