Grant Likely wrote: > On 10/15/07, Kumar Gala <[EMAIL PROTECTED]> wrote: >> (Comments just on SRAM code) >> >> I think this should be made generic and be utility functionality to >> rheap. >> >> CPM, CPM2, QE, L2 SRAM, etc can all use this. I'd rather we didn't >> have 3 ways to do the exact same functionality. (cpm_dpalloc, >> cpm_dpfree, qe_muram_alloc, qe_muram_free) > > Fair enough; but not in this patch set. This series is working > support for bestcomm. To go to the more generic level of being used > by multiple parts should be done in a separate series.
I suggested this a couple months ago and a couple people here said a generic SRAM driver would be a bad idea.. (even the tsi1xx and Marvell chips could use a generic SRAM driver)? Module probe order comes into play, which is why it was a bad idea; how do you make sure that SRAM and all it's finer points (which may not be handled by a generic rheap library - after all, the address, size, alignment needs to be *passed* to rheap init) is there and probed before bestcomm, qe ethernet units or cryptography, axe on the 5121e, gigabit on the marvell, deep sleep code on the 5200b (just listing users atm) or something or other, without turning the drivers into a hard dependency of the sram subsystem? -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
