David Brownell <[email protected]> writes: > On Wednesday 18 February 2009, Mark A. Greer wrote: >> > These changes expect boards only to ever use one chiprev and >> > product variant, which seems like a dubious model to impose >> > on the board manufacturing side ... which may need to shift >> > to lower cost or bugfixed versions over time, ideally without >> > coupling such changes to new software releases. >> >> Agreed but the support isn't there in the old code, not required >> yet, and can be handled pretty easily with the changes mentioned >> above so I'd still like to get rid of id.c. How fiercely do you >> object to that? > > Not fiercely at all, I just thought it was worth noting > this changed assumption. The support that's there isn't > really used yet.
Yeah, I'm not crazy about this changed assumption. IOW, I don't like the board files setting the CPU type. I'm not crazy about dropping the JTAG ID support either, but I agree it isn't really used at all currently. However, with more parts and revisions coming out, I'm sure someone making a custom hw will need something like this evenutally. How about this as a compromise, starting from this patch... This could be done in davinci_soc_init() or a new function in common.c: - drop the 'cpu_id' setting from the board files - add 'jtag_id_base' and 'jtag_id' to davinci_soc_info - read info->jtag_id_base to info->jtag_id - add back something like the ids.c:davinci_ids[] to common.c, but using your new defines as the 'type' field. - use the jtag_id to set the cpu_id field For now, I don't think we need to bother with functions for reading out the variant etc. Just checking the part_no and setting the cpu_id accordingly should be fine for now. If, down the road, we need to get more CPU variant deatils, this could be added to the <device>.c files as needed. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
