Re: RFC: cpm2_devices.c

Allen Curtis wrote:

quoted

On Jun 15, 2005, at 9:24 AM, Jason McMullan wrote:

quoted

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?

I guess not that tough. I used to have really disappointing problem when 
on of the patches added a small error to immr structure. Whole day of 
ghost hust while the problem wasn't even mine. So the hardcoded offsets 
are intended to prevent such cases. I don't think cpm_map_t will be 
eliminated as structure is much more comfortable and understandable than 
pure offsets.  Bus I agree that structure-dependence within platform 
definitions is not very good idea. IMHO.

quoted

quoted

    * 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.

quoted

quoted

    * 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.

quoted

quoted

    * 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.

Definitely.And there isn't only one issue. For example, I think 8xx will 
never get such device/sys files because the fact that the board has 8xx 
chip means nearly nothing in term of what devices it has. The best 
decision this case to manually call platform_device_register on 
structures created within board-specific code.

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.

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-- 
Sincerely, 
Vitaly